Re: [Rfced-future] Historical Properties

["Joel M. Halpern" <[e-mail]>]

I would agree that the topic falls within the remit of the RSWG.

Where I suspect we differ is in what aspects of it are simply a matter 
for the RSWG, and what requires more care.

While I am not sure I like the idea of dot versions, and I think there 
are more problems hidden there, lets put that aside.

I suspect I am missing many of the complications associated with such a 
proposal.  But the one that leaps out at me is that this seems to change 
the meaning of what we promised folks was a stable reference e.g. to RFC 
8200.  Changing that to mean the most current version of a document that 
gets "revisions" even with a careful definition of what are acceptable 
revisions seems to be something that needs much more interaction with 
the larger community.

Yours,
Joel

On 11/24/2021 6:52 PM, Eric Rescorla wrote:
> On Wed, Nov 24, 2021 at 7:47 AM Joel M. Halpern <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     It seems to me that some version of stable document references /
>     unmodifiabl / archival belongs in that list. 
> 
> 
> I think this gets at the intersection between the descriptive ("this is 
> how things are historically")
> and the normative ("extra consensus is required to change") angles.
> 
> For example, I doubt it's any surprise to people here that I think it 
> would be better if we made
> RFCs #s correspond to semantically identical rather than bitwise objects 
> (e.g., RFC 10001
> would point to a document that incorporated errata, etc. and that you 
> could use something
> like RFC 10001.0 to refer to the originally published version, 
> RFC10001.1 to refer
> to the first tranche of errata, etc.). I agree that:
> 
> 1. This is not how the RFC series has traditionally been managed.
> 2. Many people do not agree with me and we do not currently have even 
> rough consensus to make this change.
> 
> However, I don't agree that we should have a heightened process for 
> making this change
> than other changes (indeed, isn't part of the point of the RSWG to be 
> able to consider
> this kind of thing?). For that reason, while it might be OK to either 
> (1) have some historical
> text with nothing about a heightened standard of approval (2) have a 
> heightened standard
> of approval only for principles that we all agree should be, we should 
> not have a heightened
> standard of approval for the very principles which are contested.
> 
> -Ekr
> 
>     (Archival is in the
>     introduction.  Repeating here seems sensible to me.)
> 
>     Yours,
>     Joel
> 
>     On 11/23/2021 10:43 PM, Brian E Carpenter wrote:
>      > At the risk of finding a lot of messages in my inbox tomorrow,
>      > here's a proposed shorter alternative to Mike's "RFC Principles".
>      > Obviously a different slant, and I'm sure Peter will spot
>      > some overlaps with existing text:
>      >
>      > # Historical Properties of the RFC Editor Series
>      >
>      > The following describes some historical properties of
>      > the RFC Series. Proposals to modify any of these properties
>      > should not be taken forward without a strong community consensus
>      > including not only active RSWG/RSAB members but also the user
>      > community of each RFC stream.
>      >
>      > ## Availability
>      >
>      > The RFC series documents have been freely available digitally for
>     more
>      > than 35 years, with no fee for access. The IETF Trust [legal
>     provisions]
>      > (https://trustee.ietf.org/documents/trust-legal-provisions/
>     <https://trustee.ietf.org/documents/trust-legal-provisions/>) apply.
>      >
>      > ## Accessibility
>      >
>      > There is a general goal to make the RFC series documents as
>     accessible
>      > as possible to communities that have special needs, e.g., for those
>      > with impaired sight.
>      >
>      > ## Publication Language
>      >
>      > The publication language of the series is English. Although
>      > translations of RFCs into other languages are welcomed, the
>      > English version is normative.
>      >
>      > ## Diversity of Interests
>      >
>      > In addition to Internet standards, the RFC series has published
>      > procedural and informational documents, thought experiments,
>     speculative
>      > ideas, research papers, histories, humor [RFC1149, RFC2549], and even
>      > eulogies [RFC2468].  Various communities have contributed to the
>     rich
>      > history
>      > of the RFC series, and to its somewhat human-centric take on
>     networking.
>      > This why several streams of RFCs exist in addition to the IETF
>     stream,
>      > and why the RFC "brand" is wider than the IETF. This is also why the
>      > series does not have a "house style" and allows for individual
>     expression.
>      >
>      > ## Document Quality
>      >
>      > Nevertheless, since RFCs need to be archived indefinitely and must
>      > be of use to a widespread international community, quality,
>     readability
>      > and accuracy are key to the success of the RFC Series. It is
>      > understood that sometimes this stands in the way of rapid
>     publication.
>      >
>      >     Brian C
>      >
> 
>     -- 
>     Rfced-future mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.iab.org/mailman/listinfo/rfced-future
>     <https://www.iab.org/mailman/listinfo/rfced-future>
>