Re: [Rfced-future] Historical Properties

[Brian E Carpenter <[e-mail]>]

On 25-Nov-21 13:30, Mark Nottingham wrote:
...


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


So how about this?:

    Proposals to modify any of these properties should not be taken forward without a broad discussion including not only active RSWG/RSAB members but also the user community of each RFC stream.


> 
> As written, these measures look more likely to guarantee that these things will never be changed.


That wasn't my intention.

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


Because we know from experience of pretty much every discussion of procedural or admin matters in the past that only a tiny minority of people actually take part. I don't believe that Mike's formulation addresses that issue, because that minority includes the people who end up in I* "leadership" positions anyway. So my text aims for *wider* assent than Mike's, even if informally defined.

(As far as I'm concerned, that statement about "broad discussion" for these topics could be wordsmithed elsewhere in the document, e.g. in the "Community Calls for Comment" section.)

    Brian

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