Re: [Rfced-future] Historical Properties

[Eric Rescorla <[e-mail]>]

On Wed, Nov 24, 2021 at 4:03 PM Joel M. Halpern <[e-mail]> wrote:

> 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.
>

Well, as has we've discussed extensively, the RSWG can't do anything
unilaterally, so this would not be just a matter for the RSWG but for
the RSWG and the RSAB. So the question is what (if anything)
falls outside of that process and requires some kind of heightened process


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.
>

I think reasonable people can differ about what level of consultation any
individual change would require. My position here is merely that that
discussion about what level of consultation is required is one that should
be had in the RSWG -- and if necessary in the RSAB -- rather than
decided now in what's effectively the charter for the RSWG, especially
for issues where we already know that there is diversity of opinion.

-Ekr


> 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>
> >
>