Re: [Rfced-future] Historical Properties

[Mark Nottingham <[e-mail]>]

> On 25 Nov 2021, at 11:03 am, 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.
> 
> 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.

Sure. I agree very much that such a change would be complex, and perhaps problematic unless handled with great care. It very well may be something we don't want to do at all.

What's missing is why it's necessary to mandate (in our document) extra process for specific topics -- the seeming presumption being that the RSWG would not take such care, and its oversight and consultation mechanisms as defined would be ineffective.

Additionally, Brian's proposal includes this language:

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

... which seems problematic, because:

* 'Strong consensus' requires interpretation -- who judges that, and what is the bar for determining it? Can a single person argue that their objection, even if not well supported, prevents 'strong consensus'? What about five people?

* As we've discussed ad nauseam, how does one gauge the consensus of the user community of a stream? Do we need to reconvene this body to do so, even if the RSWG already exists? This also begs the question of whether the RSWG's currently proposed mechanisms fail to achieve such consensus (as much as can be done).

As written, these measures look more likely to guarantee that these things will never be changed. If we merely want to assure that any changes to them have adequate consideration and review, I again question why the RSWG's proposed processes -- executed in good faith and overseen by the RSAG -- are not adequate. 

This discussion started with a desire to include principles in the document, to help guide the policies defined. People have argued -- perhaps persuasively -- that doing so is necessary. However, what it now seems to be morphing into is a set of pre-emptive policies that surface some people's desires to lock their preferences into the series, even over the will of the broader community as expressed in the RSWG. 

Cheers,


> 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>
> 
> -- 
> Rfced-future mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/rfced-future

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