Subject: [Rfced-future] "Technical specifications" and the document

From: John C Klensin <[email-masked]>
Date: Tue, 23 Nov 2021 21:59:28 -0500

Peter,

I hope this is a small editorial matter rather than something
that will stir up more controversy, but I have objected a couple
of times to the use of "Internet technical specifications" in
the opening sentence of draft-iab-rfcefdp-rfced-model-06 (and
earlier) but have not been able to come up with a good
alternative.  Fortunately one came up in a discussion of a
completely different topic this morning, describing something
unrelated to the RFC Series but, I think, still useful.  

I also think there is a problem with the "as well as standards
documents" phrasing and how it might be construed.   I
consequently recommend changing:

OLD:
	The Request for Comments (RFC) Series is the archival
	series dedicated to documenting Internet technical
	specifications, including general contributions from the
	Internet research and engineering community as well as
	standards documents. 

NEW:
	The Request for Comments (RFC) Series is the archival
	series dedicated to documenting the technical evolution
	and administration of Internet resources, including
	standards documents, general contributions from the
	Internet research and engineering community, and related
	commentary. 

That avoids the potential confusion RFC 2026 and that particular
type of technical specification, gives the standards documents
the first position in return, and includes everything ("related
commentary" reasonably includes even April 1 documents).

Thanks for Chris Buckridge for the key "technical evolution..."
statement and insight.

best,
   john

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Nov 2021 14:05:22 +1100

I don't mind this, except that the phrase 'Internet resources' is a bit odd, and could be read to be more expansive than what we intend (especially because of the meaning of 'resource' on the Web). Is there a reason to use that instead of just 'Internet'?

Cheers,

> On 24 Nov 2021, at 1:59 pm, John C Klensin <[email-masked]> wrote:
> 
> Peter,
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

--
Mark Nottingham   https://www.mnot.net/

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Nov 2021 20:10:59 -0800

On Tue, Nov 23, 2021 at 7:05 PM Mark Nottingham <[email-masked]> wrote:

> I don't mind this, except that the phrase 'Internet resources' is a bit
> odd, and could be read to be more expansive than what we intend (especially
> because of the meaning of 'resource' on the Web). Is there a reason to use
> that instead of just 'Internet'?
>

Nit: "the Internet"

Also, I would prefer "publishing" rather than "documenting" (I realize that
"documenting" is in the original). However, it's not like we're writing
documentation about protocols, we are publishing their specifications.

-Ekr

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Nov 2021 01:12:07 -0500

--On Wednesday, November 24, 2021 14:05 +1100 Mark Nottingham
<[email-masked]> wrote:

> I don't mind this, except that the phrase 'Internet resources'
> is a bit odd, and could be read to be more expansive than what
> we intend (especially because of the meaning of 'resource' on
> the Web). Is there a reason to use that instead of just
> 'Internet'?

Not much.  I rather liked Chris's language and so minimally
adapted it.  But, if dropping "resources" gets us to an
acceptable level of consensus more easily, it is fine with me...
I'm just really bothered by the implication of "technical
specification" being a standards track IETF document.

   john

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Nov 2021 01:23:10 -0500

--On Tuesday, November 23, 2021 20:10 -0800 Eric Rescorla
<[email-masked]> wrote:

>> I don't mind this, except that the phrase 'Internet
>> resources' is a bit odd, and could be read to be more
>> expansive than what we intend (especially because of the
>> meaning of 'resource' on the Web). Is there a reason to use

we are getting down to the issues that I think can safely be
left to editor's discretion or, if necessary, to the RPC.  But,
yes, I prefer that too.

> Also, I would prefer "publishing" rather than "documenting" (I
> realize that "documenting" is in the original). However, it's
> not like we're writing documentation about protocols, we are
> publishing their specifications.

I don't see much difference except that "publishing" gets us
tied up with the question of what institution or piece of one is
actually the publisher and I rather hope we can avoid going
there.  Also keep in mind that a very significant fraction of
the RFC Series is not specifications of protocols.  While the
latter doesn't have quite the same associations as "technical
specification", no BCP (whether technical or procedural) is
supposed to provide specifications of a  protocol, some
standards track documents do not, and many informational
documents don't either ... as Peter indicated in his original
text and I included but edited a bit.  There are also some edge
cases in the categories he and I used, but my text, and I assume
his, were intended to avoid turning them into a point of
controversy.  If those distinctions ever need to be resolved, I
am happy to leave them to the relevant streams (the ISE, IRTF,
and probably the IAB may publish protocol specifications too,
just not standards track ones). and/or the RSWG/RSAB.

    john

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 28 Nov 2021 10:38:18 -0700

> 	Internet research and engineering community, and related

Hi John, thanks for the suggested text.

With respect to "archival series": yes, I know this is in the original 
but as I noted in another thread, I'm not sure that the adjective does 
much for us as a fundamental definition of the Series as opposed one 
aspect of how the documents are handled.

Also, series of what? Documents, clearly.

Taking into account comments from Mark and Ekr, I suggest:

NEWER:
       The Request for Comments (RFC) Series is a series of documents
       regarding the technical evolution and administration of the
       Internet, including standards documents, general contributions
       from the Internet research and engineering community, and related
       commentary.

Changing "the" to "a" might be considered controversial, but I perceive 
a touch of hubris in asserting that no other documents address these 
matters.

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 28 Nov 2021 17:43:03 +0000

Hiya,

> aspect of how the documents are handled.

FWIW, I disagree. The archival nature of the series is, for
me, a crucial part of why the series has been, and hopefully
will continue to be, relevant.

So I'd be against a change to "NEWER"

Cheers,
S.

---

From: John C Klensin <[email-masked]>
Date: Sun, 28 Nov 2021 13:13:38 -0500

--On Sunday, November 28, 2021 17:43 +0000 Stephen Farrell
<[email-masked]> wrote:

>> With respect to "archival series": yes, I know this is in the
>> original  but as I noted in another thread, I'm not sure that
>> the adjective does  much for us as a fundamental definition
>> of the Series as opposed one 

Agreed.  While we may not have a precise definition of
"archival", especially one that would satisfy everyone, it has a
range of important implications, ones that become even more
important if the document is not to state [other] principles.  I
note that the traditional interpretation of "archival" in the
RFC Series includes documents, once published under a given
number, being static.  An overlapping part of that traditional
interpretation is the reason why STD and BCP (and the ill-fated
NEWTRK ISDs) are overlay systems and not those primary document
numbers.  And that, in turn, made the decision to switch from
normative ASCII to normative XML a major strategic decision (one
on whose wisdom I fear the jury is still out) rather than a
minor policy change and would make, e.g., renumbering RFC 5322
to RFC 822.3 or 822:2008 a similarly important strategy
decision.   It is also part of why we have RFC 7414 rather than
having delayed all changes to TCP (including what became RFCs
1122, 3168, 6093, and 6528) until we were ready to publish a
comprehensive and integrated RFC793bis.  One can argue against
any of those decisions and their consequences (I note a recent
passionate posting that would imply just that integrated 793bis
strategy), but they would be much more significant decisions
than, e.g., an adjustment to the Style Guide or extending
xml2rfc v3 to include a new element or argument.

     john

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 28 Nov 2021 11:13:55 -0700

> So I'd be against a change to "NEWER"

It's true that the documents published in the Series are kept in an 
archive or handled in archival ways; see especially §4.3 of RFC 4844 
(some or all of which I've suggested we pull into the Program document 
we're working on). I still remain unsure what calling it an "archival 
series" really accomplishes.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 28 Nov 2021 11:16:55 -0700

On 11/28/21 11:13 AM, John C Klensin wrote:
> important if the document is not to state [other] principles. 

My point is that merely asserting it's an "archival series" isn't all 
that valuable on its own: what matters is specifying those implications 
somewhere, not pinning all of one's hopes on the adjective "archival".

Peter

---

From: Michael StJohns <[email-masked]>
Date: Sun, 28 Nov 2021 13:46:23 -0500

On 11/28/2021 1:13 PM, Peter Saint-Andre wrote:
>>> original but as I noted in another thread, I'm not sure that the 
>>> adjective does much for us as a fundamental definition of the Series 
>>> as opposed one aspect of how the documents are handled.
>>
Archival is the opposite of "ephemeral".   Long lasting, well known 
location, well known taxonomy, suitable to be used in archives, .    
Contrast with ephemeral:  lasting a short time, transient, fleeting, 
changing, momentary.

Or better yet: https://dictionary.archivists.org/entry/archival-nature.html

  archival nature

n.The characteristics that are inherent in archival documents resulting 
from the circumstances of their creation, including naturalness, organic 
nature or interrelationship, impartiality, authenticity, and uniqueness.

https://dictionary.archivists.org/index.html

Mike

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 28 Nov 2021 13:55:29 -0500

I would note that the principle that the series is archival, with a 
moderately long time frame, has driven actions such as making PDF/A 
available for RFCs, including the XML in the PDF/A, and arranging for 
long term archival facilities to mirror our PDF/A repository.

Yours,
Joel

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 28 Nov 2021 11:07:18 -0800

On Sun, Nov 28, 2021 at 10:46 AM Michael StJohns <[email-masked]>
wrote:

> With respect to "archival series": yes, I know this is in the original but
> as I noted in another thread, I'm not sure that the adjective does much for
> us as a fundamental definition of the Series as opposed one
> archive or handled in archival ways; see especially §4.3 of RFC 4844 (some
> or all of which I've suggested we pull into the Program document we're
> working on). I still remain unsure what calling it an "archival series"
> really accomplishes.
>
> Peter
>
> Or better yet:
> https://dictionary.archivists.org/entry/archival-nature.html
> archival nature n.The characteristics that are inherent in archival
> documents resulting from the circumstances of their creation, including
> naturalness, organic nature or interrelationship, impartiality,
> authenticity, and uniqueness.
>

This seems like a good example of where a dictionary definition is not
helping us very much at all.

1. I don't know what naturalness means, especially in the context of
techical documentation.
2. Our documents most certainly are not impartial.
3. I don't know what it would mean for our documents to be authentic.
4. I also do not know if our documents are unique.

Moreover, I don't think that this definition--or indeed any generic
one--sheds much light on what
people seem to want "archival" to mean. As a concrete example, I've
regularly heard "archival"
used as an argument against "living standards" (as should be apparent, I do
not share this
view) but I think you'd have to work pretty hard to get that out of this
definition.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 28 Nov 2021 19:42:42 +0000

Just on a few bits of the discussion, but not really
directly addressing John so much...

On 28/11/2021 18:13, John C Klensin wrote:
> While we may not have a precise definition of
> "archival", especially one that would satisfy everyone, 

To be honest and frank, I find it really hard to believe
that we really need a better definition of that word. We
can validly disagree as to whether it's a principle around
here or not, but it's pretty obvious what it means. I hope
we don't get distracted into quibbling over definitions.

> I
> number, being static.  

FWIW, I believe that not all but many versions of what ekr
has said he'd like to see (i.e. RFC10000.1 superceded by
RFC10000.2 or similar) can be entirely consistent with an
archival series.

Yes, it'd be a change that'd require significant review and
maybe even onerous efforts on the part of those who'd want
that change, but that'd be true in all cases. Whether or not
it'd be a change for the good is an open question for me. If
a form of what ekr wanted resulted is the series no longer
being describable as an archival series, then that would be
a bad change that I'd oppose myself.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 28 Nov 2021 11:47:37 -0800

> we don't get distracted into quibbling over definitions.

I don't generally find claims that something is "obvious" to be
very persuasive. If it's in fact "obvious" then we should have
no trouble converging on a definition. If we end up "quibbling"
that's generally a sign that it's not in fact obvious.

-Ekr

---

From: John C Klensin <[email-masked]>
Date: Sun, 28 Nov 2021 14:49:01 -0500

--On Sunday, November 28, 2021 11:16 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>> "archival", especially one that would satisfy everyone, it
>> has a range of important implications, ones that become even
>> more important if the document is not to state [other]
>> principles. 
> 
> My point is that merely asserting it's an "archival series"
> isn't all that valuable on its own: what matters is specifying
> those implications somewhere, not pinning all of one's hopes
> on the adjective "archival".

I see that a little differently.  I suggest that the people
around the IETF who have been using and thinking about the RFC
Series for at least several years have a reasonable shared
understanding of what the term implies. Yes, that understanding
is more intuitive and/or based in oral tradition than something
we are prepared to write down.  If there are people here who
believe we should be making changes that might make the Series
less "archival", it is not because of disagreement about the
definition; it is disagreement about principles (whoops, that
word), goals, or philosophy.  And, yes, trying to agree on a
precise and comprehensive definition would take us down ratholes
of almost unimaginable size and complexity.

But I don't think "we can't define that precisely and should not
try" translates into either "the term is meaningless and should
be removed" or "let's take it out of the document and pretend it
is not an issue".   If, instead of a definition, you want
examples of some of the things that implies, I gave a couple in
my earlier note.  As mentioned by others, I think something
about very long term availability and accessibility without
dragging along a lot of obsolete baggage [1] would also belong
in there.  But I don't think we move forward by dropping
"archival" and replacing it with nothing.

best,
   john

[1] For examples of excessive "baggage", consider what it would
take to run an assembly language program for a 1960s-era machine
on a modern Linux setup or what you would need to do to retrieve
information from a eight inch floppy disc.  Certainly not
impossible unless the bits or surface of the medium have
deteriorated, but a lot more trouble than most would consider
reasonable.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 28 Nov 2021 12:00:13 -0800

On Sun, Nov 28, 2021 at 11:49 AM John C Klensin <[email-masked]> wrote:

> word), goals, or philosophy.
>

It seems to me that this statement assumes its conclusion, namely
that people want to make changes that would make the series
less "archival", but of course that assumes that those changes
would in fact do so.

To go back to my previous example. imagine that we changed
the RFC series such that any given RFC had a set of concrete
semantically identical versions numbered RFC X.1, RFC X.2, etc.
and that one could always link to RFC X.Y but that RFC X went
to the latest version. I do not believe that this would make the
series less archival (indeed, arguably it would make it moreso
in that it preserves history rather than burying it in a series
of non-archived errata plus a roll-up -bis version). On the other
hand, I've heard this idea criticized precisely on the grounds
that it would make the series less archival.

My point here is that having the word "archival" here obscures
that disagreement over the basic principle about what the
series ought to be like, rather than illuminating it.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 28 Nov 2021 20:03:43 +0000

Hiya,

> that's generally a sign that it's not in fact obvious.

The above is often true. It's also often true that
(entirely well meaning) people use proxies and tactics
when arguing.

I'll re-assert that I find it hard to believe people
really need that term better defined for this discussion.

S.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 28 Nov 2021 15:13:36 -0500

If we change the meaning of the string "RFC 8200" (or similar existing 
referents) as your text implies, I would have serious objections.

On the other hand, if the proposal were that starting with RFC 11000 
(10000 is probably too soon to pull it off), we switched to the meaning 
you want, would be happy to engage in a discussion of the benefits and 
drawbacks of such a change, including the meaning of semantically 
identical, and other related issues.

However, as currently written, the former would require no more 
stringent community checking and support than the latter.  That is an 
example of why I think we need principles written down, and text saying 
that changing them requires more care.

Yours,
Joel

On 11/28/2021 3:00 PM, Eric Rescorla wrote:
...

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 28 Nov 2021 12:13:57 -0800

> really need that term better defined for this discussion.

I'm honestly not sure how to answer this, given that I've already
said repeatedly that I do need it better defined for this discussion,
and indeed given several examples of how I think it's unclear.

Presumably, I know my internal state better than you do, however
hard you may find it to believe that that is my state.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 28 Nov 2021 13:19:00 -0800

> that changing them requires more care.

We are in agreement that retroactively changing the meaning of existing
RFC references would require quite a bit more thinking than for future
references [0] , and merely as a substantive matter, I would be more than
happy to leave all RFCs before 11000 (or whatever) in a different state
than RFCs after that.

As to the procedural matter, it seems to me that the same people who
are concerned about the impact of this kind of change are going to
be around to object to it and would be able to insist on a more careful
review. It's not clear to me that it needs to be encoded into this document,
and it seems to me that there are real harms in doing so, both in terms
of the difficulty of drawing the right line -- and the costs of drawing the
wrong one -- and of having our ability make even noncontroversial changes
extremely limited by the lack of completion of this process.

-Ekr

[0] Though I'm not sure the meaning is as clear-cut as people often think.

Yours,

---

From: Adam Roach <[email-masked]>
Date: Sun, 28 Nov 2021 19:04:18 -0600

> really need that term better defined for this discussion. 

There have been multiple occurrences on this very list of people saying 
something along the lines of "This assertion that I make now is 
something that I, as a long time participant, know to be true, and to 
have always been true. Others who have been doing this for as long as I 
have will surely agree. I regret that we didn't write it down in RFC 
{5620,6635,etc}, but we clearly should have."

Let's end this cycle of regretting that we didn't write it down.

If the properties are clear, it should be easy write them down both for 
the edification of people who aren't you, and for the ability to 
reference those properties in the future.

If the properties are not clear, then writing the word "archival" into a 
document is manifestly problematic, since we're going to claim that the 
resulting document represents consensus when it actually means different 
things to different people -- which isn't consensus at all; cf. 
<http://www.literaturepage.com/read/throughthelookingglass-54.html>.

On 11/28/2021 1:49 PM, John C Klensin wrote:
> I suggest that the people
> we are prepared to write down.

I do not believe that an unwritten oral history of important topics 
serves our community well -- especially based on the multiple 
lamentations of "we should have written that down" that I mention above 
-- and further assert that it is actively unwelcoming to newcomers.

/a

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Nov 2021 01:35:33 +0000

Hiya,

On 29/11/2021 01:04, Adam Roach wrote:
> document is manifestly problematic,

I honestly disagree, while at the same time believing those
with whom I'm disagreeing are being honest and up-front. It
seems to me that those for whom use of that word is seen as
problematic do have the same understanding of what it means,
but just do not agree that it ought be used.

IOW, I don't think this is a matter of a definition, but one
where some of us are trying to ensure what we think of as an
important feature of the current series is maintained (while
of course not preventing future consensus to make such major
changes) whereas others of prefer to not say that in case it
makes those potential future changes harder.

More simply: my belief is that we all understand the term and
its consequences, but some us of do/don't want to see it used
here. In general, I think the arguments for inclusion of such
"principles" have been made already and don't need repetition
in this mail. I acknowledge that those arguments have not yet
been accepted by all:-)

Cheers,
S.

---

From: Adam Roach <[email-masked]>
Date: Sun, 28 Nov 2021 19:38:16 -0600

On 11/28/2021 7:35 PM, Stephen Farrell wrote:
>> If the properties are not clear, then writing the word "archival" 
>> into a document is manifestly problematic,
>

There's glory for you.

/a

---

From: Jay Daley <[email-masked]>
Date: Mon, 29 Nov 2021 15:08:31 +1300

> On 29/11/2021, at 2:35 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
>> If the properties are not clear, then writing the word "archival" into a document is manifestly problematic,
> 

Here’s a list of all of the specific properties of RFCs that I have heard/understood to come under the general principle of 'archival':

- Canonical format chosen for maximum device-independence and longevity as a structured, computer readable format
- Content never changes once published (nobody has suggested this mean that revisions can’t be published, only that they become ’new’ documents)
- Suitable for 'permanent' (i.e. WORM) storage
- Always available
- Assigned unique global references always available through those
- Proactively deposited with multiple archives
- Clearly identified and available as part of a set (the 'archive')
- Documented provenance
- Author and date stamped
- Metadata available separately and with much of the same 'archival' characteristics as the series

Some of these may sit better under the principle of 'published series' than 'archival', which perhaps illustrates the danger of considering a single principle in isolation.

I suspect though that defining a list will not take us closer to a resolution as there will still be a split between those who believe we can agree such a list and those who want that left to the RSWG to tackle.

Jay

> 
> Cheers,
> S.
> 
> <OpenPGP_0x5AB2FAF17B172BEA.asc>-- 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Nov 2021 02:25:33 +0000

Hiya,

> - Metadata available separately and with much of the same 'archival' characteristics as the series

Seems like a reasonable list to me, though I've always
thought of RFCs are being for humans to read:-)

> I suspect though that defining a list will not take us closer to a resolution as there will still be a split between those who believe we can agree such a list and those who want that left to the R…

I mostly agree. I don't think our problem in this sub-thread
is with definitions.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 28 Nov 2021 18:36:47 -0800

On Sun, Nov 28, 2021 at 6:08 PM Jay Daley <[email-masked]> wrote:

> Here’s a list of all of the specific properties of RFCs that I have
> heard/understood to come under the general principle of 'archival':
>
> - Content never changes once published (nobody has suggested this mean
> that revisions can’t be published, only that they become ’new’ documents)
>
> Some of these may sit better under the principle of 'published series'
> than 'archival', which perhaps illustrates the danger of considering a
> single principle in isolation.
>
> I suspect though that defining a list will not take us closer to a
> resolution as there will still be a split between those who believe we can
> agree such a list and those who want that left to the RSWG to tackle.
>

Thanks for providing this list. It seems to me that some of these are
trivial and unobjectionable and some of them are contested.

It might be useful to ask whether those who think "archival" is a useful
word would be willing to replace it with the list of uncontested ones. Then
we can avoid the argument about whether "archival" encompasses them.

-Ekr

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 28 Nov 2021 21:50:50 -0500

1) I find it interesting that "archival" is now an argument, when no one 
objected to it being definitional for the series before.

2) I can not comment on whether the "unconstested" part of the list 
would be acceptable because I have no idea which parts are actually 
contested.  (I do assume some is.  I just don't know which ones.)

Your,
Joel

On 11/28/2021 9:36 PM, Eric Rescorla wrote:
> 
> 
> On Sun, Nov 28, 2021 at 6:08 PM Jay Daley <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>      > On 29/11/2021, at 2:35 PM, Stephen Farrell
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >
>      >
>      > Hiya,
>      >
>      >> If the properties are not clear, then writing the word
>     "archival" into a document is manifestly problematic,
>      >
>     - Canonical format chosen for maximum device-independence and
>     longevity as a structured, computer readable format
>     - Content never changes once published (nobody has suggested this
>     mean that revisions can’t be published, only that they become ’new’
>     documents)
> 
>     Some of these may sit better under the principle of 'published
>     series' than 'archival', which perhaps illustrates the danger of
>     considering a single principle in isolation.
> 
>     resolution as there will still be a split between those who believe
>     we can agree such a list and those who want that left to the RSWG to
>     tackle.
> 
> 
> word would be willing to replace it with the list of uncontested ones. 
> Then we can avoid the argument about whether "archival" encompasses them.
> 
> -Ekr
> 
> 
>     Jay
> 
>      >
>      > Cheers,
>      > S.
>      >
>      > [email-masked] <mailto:[email-masked]>
>     <https://www.iab.org/mailman/listinfo/rfced-future>
> 
>     -- 
>     Jay Daley
>     IETF Executive Director
>     [email-masked] <mailto:[email-masked]>
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Nov 2021 02:57:04 +0000

> contested.  (I do assume some is.  I just don't know which ones.)

+1 to both points.

S.

>>      > On 29/11/2021, at 2:35 PM, Stephen Farrell
>>      >
>>      >
>>      > Hiya,
>>      >
>>      > On 29/11/2021 01:04, Adam Roach wrote:
>>      >> If the properties are not clear, then writing the word
>>      >
>>      > I honestly disagree, while at the same time believing those
>>      > with whom I'm disagreeing are being honest and up-front. It
>>      > seems to me that those for whom use of that word is seen as
>>      > problematic do have the same understanding of what it means,
>>      > but just do not agree that it ought be used.
>>      >
>>      > IOW, I don't think this is a matter of a definition, but one
>>      > where some of us are trying to ensure what we think of as an
>>      > important feature of the current series is maintained (while
>>      > of course not preventing future consensus to make such major
>>      > changes) whereas others of prefer to not say that in case it
>>      > makes those potential future changes harder.
>>      >
>>      > More simply: my belief is that we all understand the term and
>>      > its consequences, but some us of do/don't want to see it used
>>      > here. In general, I think the arguments for inclusion of such
>>      > "principles" have been made already and don't need repetition
>>      > in this mail. I acknowledge that those arguments have not yet
>>      > been accepted by all:-)
>>
>> It might be useful to ask whether those who think "archival" is a 
>> useful word would be willing to replace it with the list of 
>> uncontested ones. Then we can avoid the argument about whether 
>> "archival" encompasses them.
>>
>> -Ekr
>>
>>
>>     Jay
>>
>>      >
>>      > Cheers,
>>      > S.
>>      >
>>      > <OpenPGP_0x5AB2FAF17B172BEA.asc>--
>>      > Rfced-future mailing list
>>      > [email-masked] <mailto:[email-masked]>
>>      > https://www.iab.org/mailman/listinfo/rfced-future
>>     --     Jay Daley

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 28 Nov 2021 19:01:26 -0800

> objected to it being definitional for the series before.

Well, I for one, never liked it, though I found it to be largely rhetorical
in the
current text, and so didn't really object that much. However, now that it
seems
to be attached to text about a heightened degree of scrutiny for changes,
I find it important to know what it means.

So, I don't think it's that interesting, and if we had agreement to abandon
any text about heightened scrutiny, I would be fine to have the current
text that says "archival"

> contested.  (I do assume some is.  I just don't know which ones.)

Well, as I've noted a number of times "Content never changes once
published" seems to
be one such piece.

I don't know what the following mean"

> - Suitable for 'permanent' (i.e. WORM) storage

In what sense is rfc-editor.org "always available" that (say) ietf.org is
not?

> - Documented provenance

It seems to me that the provenance of our documents is rather fuzzy -- or
at least
that the documentation is not itself archival.

-Ekr

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 28 Nov 2021 22:06:04 -0500

The two you list are how and why we have outside long term repositories 
maintaining copies of the series.  In order to do so, there had to be a 
form suitable for such storage.  PDF/A with the included XML met that 
requirement.

Yours,
Joel

On 11/28/2021 10:01 PM, Eric Rescorla wrote:
> 
> 
> On Sun, Nov 28, 2021 at 6:50 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Well, I for one, never liked it, though I found it to be largely 
> rhetorical in the
> current text, and so didn't really object that much. However, now that 
> it seems
> In what sense is rfc-editor.org <http://rfc-editor.org> "always 
> available" that (say) ietf.org <http://ietf.org> is not?
> 
> It seems to me that the provenance of our documents is rather fuzzy -- 
> or at least
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>      >
>      >
>      >
>      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >      >
>      >      >
>      >      > Hiya,
>      >      >
>      >     - Metadata available separately and with much of the same
>     'archival'
>      >     characteristics as the series
>      >
>     useful
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <https://www.iab.org/mailman/listinfo/rfced-future
>     <https://www.iab.org/mailman/listinfo/rfced-future>>
>      >
>      >     --
>      >     Jay Daley
>      >     IETF Executive Director
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >
>      >
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 28 Nov 2021 19:12:11 -0800

> form suitable for such storage.  PDF/A with the included XML met that

Thanks for the clarification, as it helps me understand what this text
means.

In that case, I don't agree with this as a basic principle. I guess it's
sort of
useful to have the RFCs backed up somewhere, but I don't think that is
actually a really hard requirement: to the extent to which they continue
to be relevant, I have high confidence that they will continue to be
available
somewhere (if only on archive.org) and to the extent to which they are not
relevant, I'm not sure that I care that much.

This is not to say that it's bad, but merely that if it turned out that it
was in
conflict with something else (say an RFC format that was more immediately
useful in some other way) then, I wouldn't want this to be a blocker.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Nov 2021 17:37:18 +1300

On 29-Nov-21 16:12, Eric Rescorla wrote:
> 
> 
> On Sun, Nov 28, 2021 at 7:06 PM Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Thanks for the clarification, as it helps me understand what this text means.
> 
> In that case, I don't agree with this as a basic principle. I guess it's sort of
> to be relevant, I have high confidence that they will continue to be available
> somewhere (if only on archive.org <http://archive.org>) and to the extent to which they are not
> This is not to say that it's bad, but merely that if it turned out that 
it was in
> useful in some other way) then, I wouldn't want this to be a blocker.

I'm confused. How could it be a problem for somebody wanting to publish
RFC8200 using the Revised Martian Gopher format that there's a copy in
PDF/A format somewhere in the basement of the Bodleian Library at
Oxford University?

>>      > It seems to me that the provenance of our documents is rather fuzzy --

I think not. Both the RFC Editor service and the IETF Secretariat routinely
respond to subpoenas with sworn provenance of RFCs and I-Ds, as I understand
it.

The one I thought might raise real debate was:

>>      'archival'     characteristics as the series

Why? Because the IETF has *never* figured out a decent way to identify
exactly which documents define a particular standard on a particular day.
At the moment, that is tied up with variable metadata such as "updated by"
and "obsoleted by". So I'd take this aspect out of Jay's list, because
such metadata do change routinely.

    Brian

>      > On Sun, Nov 28, 2021 at 6:50 PM Joel M. Halpern <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >  > - Suitable for 'permanent' (i.e. WORM) storage
>      >  > - Always available
>      >
>      > In what sense is rfc-editor.org <http://rfc-editor.org> <http://rfc-editor.org <http://rfc-editor.org>> "always
>      > available" that (say) ietf.org <http://ietf.org> <http://ietf.org <http://ietf.org>> is not?
>      >
>      >  > - Documented provenance
>      >
>      >      > On Sun, Nov 28, 2021 at 6:08 PM Jay Daley <[email-masked] <mailto:[email-masked]>
>      >      > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >     wrote:
>      >      >
>      >      >
>      >      >
>      >      >      > On 29/11/2021, at 2:35 PM, Stephen Farrell
>      >      >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >      >
>      >      >      >
>      >      >      > Hiya,
>      >      >      >
>      >      >      > On 29/11/2021 01:04, 
Adam Roach wrote:
>      >      >      >> If the properties are not clear, then writing the word
>      >      >     "archival" into a document is manifestly problematic,
>      >      >      >
>      >      >      > I honestly disagree, 
while at the same time believing those
>      >      >      > with whom I'm disagreeing are being honest and up-front. It
>      >      >      > seems to me that those for whom use of that word is seen as
>      >      >      > problematic do have the same understanding of what it means,
>      >      >      > but just do not agree that it ought be used.
>      >      >      >
>      >      >      > IOW, I don't think this is a matter of a definition, but one
>      >      >      > where some of us are 
trying to ensure what we think of as an
>      >      >      > important feature of 
the current series is maintained (while
>      >      >      > of course not preventing future consensus to make such major
>      >      >      > changes) whereas others of prefer to not say that in case it
>      >      >      > makes those potential future changes harder.
>      >      >      >
>      >      >      > More simply: my belief is that we all understand the term and
>      >      >      > its consequences, but some us of do/don't want to see it used
>      >      >      > here. In general, I think the arguments for inclusion of such
>      >      >      > "principles" have been made already and don't need repetition
>      >      >      > in this mail. I acknowledge that those arguments have not yet
>      >      >      > been accepted by all:-)
>      >      >
>      >      >     Here’s a list of all of the specific properties of RFCs that
>      >     I have
>      >      >     heard/understood to come under the general principle of
>      >     'archival':
>      >      >
>      >      >     - Canonical format chosen for maximum device-independence and
>      >      >     longevity as a structured, computer readable format
>      >      >     - Content never changes 
once published (nobody has suggested this
>      >      >     mean that revisions can’t be published, only that they become
>      >     ’new’
>      >      >     documents)
>      >      >
>      >      >     - Suitable for 'permanent' (i.e. WORM) storage
>      >      >     - Always available
>      >      >     - Assigned unique global references always available through
>      >     those
>      >      >     - Proactively deposited 
with multiple archives
>      >      >     - Clearly identified and available as part of a set (the
>      >     'archive')
>      >      >     - Documented provenance
>      >      >     - Author and date stamped
>      >      >     - Metadata available separately and with much of the same
>      >     'archival'
>      >      >     characteristics as the series
>      >      >
>      >      >     Some of these may sit better under the principle of 'published
>      >      >     series' than 'archival', which perhaps illustrates the danger of
>      >      >     considering a single principle in isolation.
>      >      >
>      >      >     I suspect though that defining a list will not take us closer
>      >     to a
>      >      >     resolution as there will still be a split between those who
>      >     believe
>      >      >     we can agree such a list and those who want that left to the
>      >     RSWG to
>      >      >     tackle.
>      >      >
>      >      >
>      >      > Thanks for providing this list. It seems to me that some of these
>      >     are
>      >      > trivial and unobjectionable and some of them are contested.
>      >      >
>      >      > It might be useful to ask whether those who think "archival" is a
>      >     useful
>      >      > word would be willing to replace it with the list of uncontested
>      >     ones.
>      >      > Then we can avoid the argument about whether "archival"
>      >     encompasses them.
>      >      >
>      >      > -Ekr
>      >      >
>      >      >
>      >      >     Jay
>      >      >
>      >      >      >
>      >      >      > Cheers,
>      >      >      > S.
>      >      >      >
>      >      >      > <OpenPGP_0x5AB2FAF17B172BEA.asc>--
>      >      >      > Rfced-future mailing 
list
>      >      >      > [email-masked] 
<mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      > https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
>      >     <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>>
>      >      >     <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
>      >     <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>>>
>      >      >
>      >      >     --
>      >      >     Jay Daley
>      >      >     IETF Executive Director
>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >
>      >      >
>      >
> 
>

---

From: Jay Daley <[email-masked]>
Date: Mon, 29 Nov 2021 18:28:22 +1300

> On 29/11/2021, at 4:02 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> In what sense is rfc-editor.org "always available" that (say) ietf.org is not?

This should be seen in the full context of all the sites that make RFCs available, which is one of the reasons for proactive deposit.  ‘Always available’ via things such as DOIs does rely on the rfc-editor.org though. 
> It seems to me that the provenance of our documents is rather fuzzy -- or at least

In practice a lot of effort is put in to make that documentation archival with the publication of:
- proceedings of all IETF meetings 
- mailing lists archives
- all revisions of all I-Ds
- jabber messages 
- IESG actions

Clearly, the ‘documented provenance’ and the ‘canonical format’ properties have strengthened over time. 

Jay

-- 
Jay Daley
IETF Executive Director 
[email-masked]

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 29 Nov 2021 15:13:34 +0900

Hello Peter, others,

> On 11/23/21 7:59 PM, John C Klensin wrote:

<snip>

> a touch of hubris in asserting that no other documents address these 

I think the the/a choice and "archival" are quite connected. We seem to 
try to interpret "archival" mostly in absolute terms. But it's actually 
possible (and probably more productive) to see it in relative terms. The 
way I understand it, and would explain it to an outsider, is that 
whatever is considered to be of (reasonably) long term value is made 
into an RFC.

So RFCs are *the* archival series, whereas other stuff (IDs, meeting 
proceedings, mail archives, ...) are the "other" non-archival stuff, 
which are mostly transitory. Of course, even such (relatively) archival 
stuff can get obsolete (as Ekr has explained) or even lost (not yet, 
fortunately, for RFCs), and some of the other ("ephemeral"?) stuff can 
occasionally become important (e.g. subpoenas for patent cases,...).

Taken in this respect, I hope nobody disagrees. I'm not sure how we can 
make this clear in the text.

Regards,   Martin.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Nov 2021 05:26:18 -0800

> PDF/A format somewhere in the basement of the Bodleian Library at

The concern would be an objection to publishing RFC 10000 in the Revised
Martian
Gopher format on the grounds that it was not readily convertible to PDF/A.

> respond to subpoenas with sworn provenance of RFCs and I-Ds, as I

But all of that is ephemera.

If we're only concerned about these properties applying as long as the IETF
Secretariat
continues to exist, the problem is much easier. But presumably you want the
provenance
of these documents to be verifiable beyond that (FWIW, I don't think that's
very
important, but, I'm trying to scope out the requirements others seem to
have).

-Ekr

> >      > On Sun, Nov 28, 2021 at 6:50 PM Joel M. Halpern <
> [email-masked] <mailto:[email-masked]>
> >      >     1) I find it interesting that "archival" is now an argument,
> when no
> >      >     one
> >      > In what sense is rfc-editor.org <http://rfc-editor.org> <
> http://rfc-editor.org <http://rfc-editor.org>> "always
> >      >      > On Sun, Nov 28, 2021 at 6:08 PM Jay Daley <
> >      >     <mailto:[email-masked] <mailto:[email-masked]
> >>
> >      >      > <mailto:[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>>>
> >      >     wrote:
> >      >      >
> >      >      >
> >      >      >
> >      >      >     <[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>
> >      >      >     Here’s a list of all of the specific properties of
> RFCs that
> >      >     I have
> >      >      >     - Content never changes
> >      >      >     mean that revisions can’t be published, only that they
> become
> >      >     ’new’
> >      >      >     documents)
> >      >      >
> >      >      >     - Assigned unique global references always available
> through
> >      >     those
> >      >      >     - Proactively deposited
> with multiple archives
> >      >      >     - Clearly identified and available as part of a set
> (the
> >      >     'archive')
> >      >      >     - Documented provenance
> >      >      >     I suspect though that defining a list will not take us
> closer
> >      >     to a
> >      >      >     resolution as there will still be a split between
> those who
> >      >     believe
> >      >      >     we can agree such a list and those who want that left
> to the
> >      >     RSWG to
> >      >      >     tackle.
> >      >      >
> >      >      >
> >      >      > Thanks for providing this list. It seems to me that some
> of these
> >      >     are
> >      >      > word would be willing to replace it with the list of
> uncontested
> >      >     ones.
> >      >      >      > Rfced-future mailing
> >      >     <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
> >      >      >      > https://www.iab.org/mailman/listinfo/rfced-future <
> https://www.iab.org/mailman/listinfo/rfced-future>
> >      >     <https://www.iab.org/mailman/listinfo/rfced-future <
> https://www.iab.org/mailman/listinfo/rfced-future>>
> >      >      >     <https://www.iab.org/mailman/listinfo/rfced-future <
> https://www.iab.org/mailman/listinfo/rfced-future>
> >      >     <https://www.iab.org/mailman/listinfo/rfced-future <
> https://www.iab.org/mailman/listinfo/rfced-future>>>
> >      >      >
> >      >      >     --
> >      >      >     Jay Daley
> >      >      >     IETF Executive Director
> >      >     <mailto:[email-masked] <mailto:[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Nov 2021 05:27:24 -0800

On Sun, Nov 28, 2021 at 9:28 PM Jay Daley <[email-masked]> wrote:

> This should be seen in the full context of all the sites that make RFCs
> available, which is one of the reasons for proactive deposit.  ‘Always
> available’ via things such as DOIs does rely on the rfc-editor.org
> though.
>
>

As I indicated to Brian, all of that information is ephemera from the
perspective of the
RFC Series.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 29 Nov 2021 14:58:26 +0000

Truly excellent points.  Thank you!

---

From: John C Klensin <[email-masked]>
Date: Mon, 29 Nov 2021 12:01:00 -0500

>> Changing "the" to "a" might be considered controversial, but
>> I perceive  a touch of hubris in asserting that no other
>> documents address these  matters.
> 
> I think the the/a choice and "archival" are quite connected.
> We seem to try to interpret "archival" mostly in absolute
> terms. But it's actually possible (and probably more
> productive) to see it in relative terms. The way I understand
> it, and would explain it to an outsider, is that whatever is
> considered to be of (reasonably) long term value is made into
> an RFC.
> 
> So RFCs are *the* archival series,

For IETF, IAB, and related work per language Peter has already
written.  And that distinction should be clear in the document
if we are going to stay with "the".  I think it already is
clear, but don't know if that opinion is shared.

>  whereas other stuff (IDs,
> meeting proceedings, mail archives, ...) are the "other"
> non-archival stuff, which are mostly transitory. Of course,
> even such (relatively) archival stuff can get obsolete (as Ekr
> has explained) or even lost (not yet, fortunately, for RFCs),
> and some of the other ("ephemeral"?) stuff can occasionally
> become important (e.g. subpoenas for patent cases,...).
> 
> Taken in this respect, I hope nobody disagrees. I'm not sure
> how we can make this clear in the text.

I, at least, agree.   Let me probe two examples, one from your
list above and one from an example Jay gave to see if it
clarifies things further.

Once upon a time, the IETF compiled and published meeting
proceedings.  They appeared on reasonable-quality paper, in
bound volumes that were widely distributed.  They were
self-contained and did not change once published.  They were
intended to be part of the historical record, not something one
read and discarded.  Assuming the paper quality was good enough,
they would have a fair claim to "archival" by most reasonable
definitions.    After some years, they started being issued on
CDs and the paper versions were abandoned.  Like the RFC Series,
which had abandoned paper as the main distribution medium much
earlier, if someone wanted to go into the business of making
paper versions, nothing would be done to discourage them (I
assume that CNRI would even have provided that service for a
significant nuisance fee).   However, unlike good quality paper
that is properly stored, CDs and conventional DVDs are
questionable as archival media (in case people don't know, there
are international standards for that and, for those who care,
understanding the physical differences between DVD disc and
M-DISC technology is worthwhile), so additional precautions were
taken to be sure there were widely-distributed online copies
and/or care taken to periodically copy the CDs before their
likely deterioration dates.  And eventually we abandoned the CDs
(again, if someone wanted to make them, we would not try to
block that).  Still archival?  Probably, but without the very
systematic efforts that several people have cited to be sure
RFCs stayed available and accessible.   So maybe a bit closer to
archival by accident rather than archival by careful design and
planning.

Then, at some stage and with little or no discussion in/with the
community, "we" stopped compiling proceedings.  Instead, "the
proceedings" became an extension of meeting agendas with links
to meeting materials, minutes, video and/or audio recordings,
etc., with quality and comprehensibility even a few months or
years after the meeting occurred varying by WG.  Because,
AFAICT, it was no one's responsibility to verify those links and
the availability of all  the materials over time, some of the
links deteriorated to the point that locating all of the bits
that made up the supposed proceedings several years later (much
less decades or centuries) often became a real challenge.  

Archival proceedings now?  Nope... actually rather far into
ephemeral.  Difference between that and RFCs?  Ultimately more a
matter of intent and commitment rather than, e.g., choices of
technology or a catalog of attributes.  And, to push the analogy
a bit further, if there is ever a proposal to allow RFCs to be
published that are really just an index to a collection of links
(as the "proceedings" have become), it is probably important to
be sure that idea gets careful consideration by as wide a
collection of parties who would likely be affected as possible
rather than having it depend on who is participating in the RSWG
in a given year or treated as if it were an administrative
decision.

The second example is that Jay mentioned the use of WORM media
as a path  to "archival".  But the "availability" part of the
story is not just about the media, but about long-term
readability and interpretability.   In the late 1980s, I was
involved it a project that was recording collections of images
of long-term scholarly significance onto LaserDisc, a WORM
format.   But try to read one of those discs today, starting
with finding a working player and then, if indexing and image
retrieval were on a computer, finding the appropriate software
and computer system.  Certainly not impossible, but not
consistent with "archival and accessible".  Those images were
not lost because the content of those LaserDiscs were
systematically copied to other media and the access programs
updated (at least for a while), but those steps were, again, a
matter of intent and commitment above and beyond whatever went
into curating and creating the collection and recording it onto
some medium in the first place.

best,
   john

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Nov 2021 10:24:48 +1300

On 30-Nov-21 02:26, Eric Rescorla wrote:
> 
> 
> On Sun, Nov 28, 2021 at 8:37 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>      > On Sun, Nov 28, 2021 at 7:06 PM Joel M. Halpern <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      > somewhere (if only on archive.org <http://archive.org> <http://archive.org <http://archive.org>>) and to the extent to which they are not
> The concern would be an objection to publishing RFC 10000 in the Revised Martian

I see, but is there any proposed language that would appear to forbid an
alternative format? I'm not convinced there's an active danger here.
[I suggest a 3-D printer able to create cuneiform clay tablets.]

> 
> 
>      >> - Documented provenance
>      >>      >
>      >>      > It seems to me that the provenance of our 
documents is rather fuzzy --
> If we're only concerned about these properties applying as long as the IETF Secretariat
> continues to exist, the problem is much easier. But presumably you want 
the provenance
> of these documents to be verifiable beyond that (FWIW, I don't think that's very
have).

We'd probably like these documents to be available until the end of the Internet.
Beyond that, professional archivists can do whatever they think best.

    Brian

>      >      > On Sun, Nov 28, 2021 at 6:50 PM Joel M. Halpern <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >
>      >      >     1) I find it interesting that "archival" is now an argument, when no
>      >      >     one
>      >      >     objected to it being definitional for the series before.
>      >      >
>      >      >
>      >      > Well, I for one, never liked it, though I found it to be largely
>      >      > rhetorical in the
>      >      > current text, and so didn't really object that much. However, now that
>      >      > it seems
>      >      > to be attached to text about a heightened degree of scrutiny for
>     changes,
>      >      > I find it important to know what it means.
>      >      >
>      >      > So, I don't think it's that interesting, and if we had agreement
>     to abandon
>      >      > any text about heightened scrutiny, I would be fine to have the current
>      >      > text that says "archival"
>      >      >
>      >      >
>      >      >     2) I can not comment on 
whether the "unconstested" part of the list
>      >      >     would be acceptable because I have no idea which parts are actually
>      >      >     contested.  (I do assume some is.  I just don't know which ones.)
>      >      >
>      >      >
>      >      > Well, as I've noted a number of times "Content never changes once
>      >      > published" seems to
>      >      > be one such piece.
>      >      >
>      >      > I don't know what the following mean"
>      >      >
>      >      >  > - Suitable for 'permanent' (i.e. WORM) storage
>      >      >  > - Always available
>      >      >
>      >      > In what sense is rfc-editor.org <http://rfc-editor.org> <http://rfc-editor.org <http://rfc-editor.org>> <http://rfc-editor.org <http://rfc-editor.org> <http://rfc-editor.org <http://rfc-editor.org>>> "always
>      >      > available" that (say) ietf.org <http://ietf.org> <http://ietf.org <http://ietf.org>> <http://ietf.org <http://ietf.org> <http://ietf.org <http://ietf.org>>> is not?
>      >      >
>      >      > I also don't really know what this means:
>      >      >
>      >      >  > - Documented provenance
>      >      >
>      >      > It seems to me that the provenance of our documents is rather fuzzy --
>      >      > or at least
>      >      > that the documentation is not itself archival.
>      >      >
>      >      > -Ekr
>      >      >
>      >      >
>      >      >     Your,
>      >      >     Joel
>      >      >
>      >      >     On 11/28/2021 9:36 PM, Eric Rescorla wrote:
>      >      >      >
>      >      >      >
>      >      >      > On Sun, Nov 28, 2021 
at 6:08 PM Jay Daley <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
<mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>
>      >      >     wrote:
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      >      > On 29/11/2021, at 2:35 PM, Stephen Farrell
>      >      >      >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:
>      >      >      >      >
>      >      >      >      >
>      >      >      >      > Hiya,
>      >      >      >      >
>      >      >      >      > On 29/11/2021 01:04,
>     Adam Roach wrote:
>      >      >      >      >> If the properties are not clear, then writing the word
>      >      >      >     "archival" into a document is manifestly problematic,
>      >      >      >      >
>      >      >      >      > I honestly disagree,
>      >      >      >      > with whom I'm disagreeing are being honest and up-front. It
>      >      >      >      > seems to me that those for whom use of that word is seen as
>      >      >      >      > problematic do have the same understanding of what it means,
>      >      >      >      > but just do not agree that it ought be used.
>      >      >      >      >
>      >      >      >      > IOW, I don't think this is a matter of a definition, but one
>      >      >      >      > where some of us are
>      >      >      >      > important feature of
>      >      >      >      > of course not preventing future consensus to make such major
>      >      >      >      > changes) whereas others of prefer to not say that in case it
>      >      >      >      > makes those potential future changes harder.
>      >      >      >      >
>      >      >      >      > More simply: my belief is that we all understand the term and
>      >      >      >      > its consequences, but some us of do/don't want to see it used
>      >      >      >      > here. In general, I think the arguments for inclusion of such
>      >      >      >      > "principles" have been made already and don't need repetition
>      >      >      >      > in this mail. I acknowledge that those arguments have not yet
>      >      >      >      > been accepted by all:-)
>      >      >      >
>      >      >      >     Here’s a list of all of the specific properties of RFCs that
>      >      >     I have
>      >      >      >     heard/understood to come under the general principle of
>      >      >     'archival':
>      >      >      >
>      >      >      >     - 
Canonical format chosen for maximum device-independence and
>      >      >      >     longevity as a structured, computer readable format
>      >      >      >     - 
Content never changes
>      >      >      >     mean that revisions can’t be published, only that they become
>      >      >     ’new’
>      >      >      >     documents)
>      >      >      >
>      >      >      >     - 
Suitable for 'permanent' (i.e. WORM) storage
>      >      >      >     - 
Always available
>      >      >      >     - 
Assigned unique global references always available through
>      >      >     those
>      >      >      >     - 
Proactively deposited
>      >      >      >     - 
Clearly identified and available as part of a set (the
>      >      >     'archive')
>      >      >      >     - 
Documented provenance
>      >      >      >     - 
Author and date stamped
>      >      >      >     - 
Metadata available separately and with much of the same
>      >      >     'archival'
>      >      >      >     characteristics as the series
>      >      >      >
>      >      >      >     Some of these may sit better under the principle of 'published
>      >      >      >     series' than 'archival', which perhaps illustrates the danger of
>      >      >      >     considering a single principle in isolation.
>      >      >      >
>      >      >      >     I 
suspect though that defining a list will not take us closer
>      >      >     to a
>      >      >      >     resolution as there will still be a split between those who
>      >      >     believe
>      >      >      >     we can agree such a list and those who want that left to the
>      >      >     RSWG to
>      >      >      >     tackle.
>      >      >      >
>      >      >      >
>      >      >      > Thanks for providing 
this list. It seems to me that some of these
>      >      >     are
>      >      >      > trivial and unobjectionable and some of them are contested.
>      >      >      >
>      >      >      > It might be useful to ask whether those who think "archival" is a
>      >      >     useful
>      >      >      > word would be willing to replace it with the list of uncontested
>      >      >     ones.
>      >      >      > Then we can avoid the argument about whether "archival"
>      >      >     encompasses them.
>      >      >      >
>      >      >      > -Ekr
>      >      >      >
>      >      >      >
>      >      >      >     Jay
>      >      >      >
>      >      >      >      >
>      >      >      >      > Cheers,
>      >      >      >      > S.
>      >      >      >      >
>      >      >      >      > <OpenPGP_0x5AB2FAF17B172BEA.asc>--
>      >      >      >      > Rfced-future mailing
>     list
>      >      >      >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >      >      > https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future> <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>>
>      >      >     <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future> <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>>>
>      >      >      >     <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future> <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>>
>      >      >     <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future> <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>>>>
>      >      >      >
>      >      >      >     --
>      >      >      >     Jay Daley
>      >      >      >     IETF Executive Director
>      >      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >      >
>      >      >      >
>      >      >
>      >
>      >
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 29 Nov 2021 14:52:08 -0700

On 11/28/21 11:13 PM, Martin J. Dürst wrote:
>> Changing "the" to "a" might be considered controversial, but I 
>> perceive a touch of hubris in asserting that no other documents 
>> address these matters.
> 

Saying that the RFC Series is *the* series of documents regarding the 
technical evolution and administration of the Internet could be taken to 
imply that any other series of documents (produced by, say, W3C, Ecma, 
or ISO) don't count. That strikes me as hubris.

Peter