Re: [Rfced-future] Historical Properties

[Stephen Farrell <[e-mail]>]

Hiya,

GOTO the end of this message ... :-)

On 25/11/2021 00:30, Mark Nottingham wrote:
> 
>> 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.

I agree that arguing that "strong consensus" is problematic
is a fair criticism of Brian's good text, though I don't
personally know of any intent to try lock in personal
preferences while at the same time understanding that that's
something some of us do seem to be concerned about.

We do have a history of being somewhat more thorough when
handling some changes compared to others though. E.g. TLS1.3
security properties or TCP congestion rightly tend to be more
thoroughly considered than your average change or new thing.
And I'd hope we'd agree that's been a good plan.

So maybe there's a form of words to try describe that kind
of thoroughness, without inventing some new better thing than
rough consensus or crafting new processes?

How about we say that significant changes to these features
(or even principles:-) call for a level of thoroughness
equivalent to what we'd want if discussing a change to some
obviously important Internet protocol? (Or words to that
effect.)

Cheers,
S.


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