Subject: [Rfced-future] Historical Properties

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Nov 2021 16:43:21 +1300

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Nov 2021 15:40:59 +0000

Hiya,

FWIW, I like Brian's text. Were that added I'd be fine with
supporting the draft.

As a nice to have, I'd maybe also like something about our
processes being as open as possible, but that is one that
may well be better as a topic for the RSWG as, a) it'd be
a new thing if does series-wide and b) it might take a good
bit of work to figure some of that out as processes vary
from stream to stream.

Cheers,
S.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Nov 2021 10:47:10 -0500

It seems to me that some version of stable document references / 
unmodifiabl / archival belongs in that list.  (Archival is in the 
introduction.  Repeating here seems sensible to me.)

Yours,
Joel

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 24 Nov 2021 14:44:38 -0700

> introduction.  Repeating here seems sensible to me.)

I searched some relevant RFCs for the term "archive" or "archival"; 
although there are brief or passing mentions in RFC 1358, RFC 1601, RFC 
2555, RFC 5540, and RFC 8700 (and perhaps others), the most relevant 
information comes from RFC 4844 (and its successor, RFC 8729)...

###

1.  Introduction

    The first Request for Comments (RFC) document was published in April
    of 1969 as part of the effort to design and build what we now know of
    as the Internet.  Since then, the RFC Series has been the archival
    series dedicated to documenting Internet technical specifications,
    including both general contributions from the Internet research and
    engineering community as well as standards documents.

    ...

    As the IETF has grown up and celebrated its own 20 years of history,
    its requirements for archival publication of its output have changed
    and become more rigorous.

    ...

    As part of its charter (see Appendix A), the IAB has a responsibility
    for the RFC Editor.  Acknowledging the IETF's and the general
    Internet engineering and research community's evolving needs, the IAB
    would like to see a future for the RFC Series that continues to meet
    its original mandate of providing the archival series for the
    technical research and engineering documentation that describes the
    Internet.

    ...

2.  RFC Series Mission

    The RFC Series is the archival series dedicated to documenting
    Internet technical specifications, including general contributions
    from the Internet research and engineering community as well as
    standards documents.

    ...

4.  Framework

    ...

    There are 3 categories of activity, and a 4th category of series-wide
    rules and guidelines, described for implementing the RFC Series to
    support its mission:

    o  Approval of documents.

    o  Editing, processing, and publication of documents.

    o  Archiving and indexing the documents and making them accessible.

    o  Series rules and guidelines.

    ...

    Each stream has its own documented approval process.  The RFC Editor
    is responsible for the approval of documents in one of the streams
    (Independent Submission stream, see Section 5.1.4) and works with the
    other approving bodies to ensure smooth passage of approved documents
    into the next phases, ultimately to publication and archiving as an
    RFC.

    ...

4.3.  Archiving, Indexing, and Accessibility

    The activities of archiving, indexing, and making accessible the RFC
    Series can be informed by specific subject matter expertise in
    general document series editing.  It is also important that they are
    informed by requirements from the whole community.  As long as the
    RFC Series is to remain coherent, there should be uniform archiving
    and indexing of RFCs across all streams and a common method of
    accessing the resulting documents.

4.3.1.  Definition

    In principle, there should be a community consensus document
    describing the archiving, indexing, and accessibility requirements
    for the RFC Series.  In practice, we continue with the archive as
    built by the capable RFC Editors since the series' inception.

    Any specific concrete requirements for the archive, index, and
    accessibility operations are the subject of agreements between the
    IASA and the RFC Editor (e.g., contracts, statements of work, service
    level agreements, etc).

4.3.2.  Operational Implementation

    The RFC Editor is responsible for ensuring that the RFC archive and
    index are maintained appropriately and that the resulting documents
    are made available to anybody wishing to access them via the
    Internet.  The RFC Editor works with the IASA for regular reporting
    and feedback.

4.3.3.  Process Change

    Should there be a community move to propose changes to the
    requirements for the RFC archive and index or accessibility, the IAB
    will work with the RFC Editor to get community input and it will
    approve changes by validating appropriate consideration of community
    requirements.

    ...

6.  Security Considerations

    The processes for the publication of documents must prevent the
    introduction of unapproved changes.  Since the RFC Editor maintains
    the index of publications, sufficient security must be in place to
    prevent these published documents from being changed by external
    parties.  The archive of RFC documents, any source documents needed
    to recreate the RFC documents, and any associated original documents
    (such as lists of errata, tools, and, for some early items, non-
    machine readable originals) need to be secured against failure of the
    storage medium and other similar disasters.

###

By my reading, the term "archival series" is shorthand for the fact that 
there's an archive (i.e., a public store and record) of the documents 
that have been published in the series. Maintaining this archive is part 
of the RPC responsibilities defined in previous versions of the RFC 
Editor Model as well as in the Internet-Draft we're working on in this 
Program, so I don't see anything especially controversial about 
including more text from Section 4.3 of RFC 4844/8729 in our document.

Peter

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Nov 2021 15:52:53 -0800

On Wed, Nov 24, 2021 at 7:47 AM Joel M. Halpern <[email-masked]> wrote:

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Nov 2021 19:03:02 -0500

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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> I think this gets at the intersection between the descriptive ("this is 
> how things are historically")
> For example, I doubt it's any surprise to people here that I think it 
> would be better if we made
> 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
> 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
> of approval only for principles that we all agree should be, we should 
> not have a heightened
>      > (https://trustee.ietf.org/documents/trust-legal-provisions/
>     <https://trustee.ietf.org/documents/trust-legal-provisions/>) apply.
>      >
>      > ## Accessibility
>      >
>      > eulogies [RFC2468].  Various communities have contributed to the
>     rich
>      > history
>     [email-masked] <mailto:[email-masked]>
>     <https://www.iab.org/mailman/listinfo/rfced-future>
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Nov 2021 16:17:31 -0800

> 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

> revisions seems to be something that needs much more interaction with

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 25 Nov 2021 11:30:22 +1100

> On 25 Nov 2021, at 11:03 am, Joel M. Halpern <[email-masked]> wrote:
> 
> 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,

>> On Wed, Nov 24, 2021 at 7:47 AM Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
>>    unmodifiabl / archival belongs in that list. I think this gets at the intersection between the descriptive ("this is how things are historically")
>> 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
>> 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
>>    --     Rfced-future mailing list

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Nov 2021 01:04:33 +0000

Hiya,

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

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

>> Yours, Joel
>>> On Wed, Nov 24, 2021 at 7:47 AM Joel M. Halpern
>>> <[email-masked] <mailto:[email-masked]>> 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 
>>>> 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:
>>>> 
>>>> 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
>>>> as possible to communities that have special needs, e.g., for
>>>> those with impaired sight.
>>>> 
>>>> ## Publication Language
>>>> 
>>>> 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.
>>>> 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
>>> --     Rfced-future mailing list [email-masked]
>>> <mailto:[email-masked]> 
>> -- Rfced-future mailing list [email-masked] 
> -- Mark Nottingham   https://www.mnot.net/
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 25 Nov 2021 12:17:41 +1100

> On 25 Nov 2021, at 12:04 pm, Stephen Farrell <[email-masked]> wrote:
> 

I think the problematic aspects here are mostly centred around creating vague, onerous and/or external procedural hurdles to getting things done in the RSWG.

If people want to say 'handle these things with care, please' without imposing such barriers, that's not as much of an issue to me. That said, I don't really see the point, as presumably those people would be able to represent their views in the RSWG and assure that proper care were taken.

Cheers,

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Nov 2021 17:20:34 -0800

> obviously important Internet protocol? (Or words to that

Well, I actually don't think that changes of this type should
have anywhere near the level of thoroughness to major
changes to protocols which represent significant fractions
of Internet traffic, so I wouldn't be in favor of this kind
of language. Moreover, I don't think we should be doing
anything in *this* document to privilege one side or the other
wrt changing anything that we know to currently be contested,
and it seems to me that this text or anything like it would have
that effect.

Stepping back, it seems to me that the examples of TLS 1.3 and
congestion suggest that the community is perfectly capable of
determining which changes need more scrutiny and which need
less without any specific text.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Nov 2021 01:38:11 +0000

Hiya,

On 25/11/2021 01:17, Mark Nottingham wrote:
> I think the problematic aspects here are mostly centred around
> creating vague, onerous and/or external procedural hurdles to getting
> things done in the RSWG.

I'd also hope we're not going that way myself.

OTOH, "getting things done" covers too broad a range doesn't
it? For example, some better way to validate and present
validated errata should, I hope not be difficult. But there's
a continuum where such changes could rise to the level where
something onerous really does need to be done - ekr's example
is a good one in that respect.

> 
> If people want to say 'handle these things with care, please' without
> imposing such barriers, 

FWIW, I don't think what I proposed is at all a "barrier"
more along the lines of guidance to be taken seriously.

> that's not as much of an issue to me. That
> said, I don't really see the point, as presumably those people would
> be able to represent their views in the RSWG and assure that proper
> care were taken.

For me, that's why the heritage thing becomes a topic - if
one considers that the set of active participants changes a
lot over the longer periods of time for which the series has
already demonstrated relevance, I do think we'd be better off
with longer term guidance when it comes to the future of the
series. (I'm not trying to convince you to think the same,
just trying to explain where I'm coming from.)

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Nov 2021 01:39:08 +0000

Hiya,

On 25/11/2021 01:20, Eric Rescorla wrote:
> of Internet traffic,

And I think we disagree there. *Significant* changes to
the series can easily affect all protocols including those
that represent lots of traffic. For example the one you
mentioned earlier could have such effects perhaps relating
to RFPs/conformance or badly-crafted regulations.

> so I wouldn't be in favor of this kind

I don't see it that way TBH - I don't think at least what
I just proposed privileges any "side" (and on such topics
there are many such, not just two).

> less without any specific text.

That's fair, but doesn't that also fall afoul of mnot's
critique of Brian's text wrt "what's the community"?

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Nov 2021 17:56:36 -0800

> to RFPs/conformance or badly-crafted regulations.

Fortunately, we don't have to agree, as I'm simply saying
that these changes ought to go through the usual RSWG
process.

> there are many such, not just two).

Any text which says that a change should have heightened
scrutiny has the effect of making that change more difficult
That's privileging one side.

> critique of Brian's text wrt "what's the community"?

I don't see why it would, no.

-Ekr

Cheers,

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Nov 2021 02:18:45 +0000

> scrutiny has the effect of making that change more difficult

Yes. And that's a good idea IMO, for a very limited and
short fragment of text such as Brian proposed. (Modulo
wordsmithing so that doesn't accidentally invent new
process barriers which I agree wouldn't be good.)

> That's privileging one side.

Again, not trying to convince you, but I think the idea
that we're dealing with two sides in dispute about where
to land on a one dimensional axis is not at all how I'm
thinking about any of this.

S.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Nov 2021 21:23:06 -0500

Based on this discussion, I am trying to think through what is going to 
happen with the structure as we have written it when there is a conflict.

Suppose the RSWG approves a change somewhat more drastic than the one 
EKR has hypothesized.

And suppose the RSAB looks at it and says "No, that would do damage to 
the long term health of the series".
Let us presume that the RSAB members raised this during the discucssion, 
but were found by the chairs to be in the rough.  (Let us assume they 
were in the minority.  Whether or not they were in the rough depends 
upon which of the any definitions of rough consensus actually applies in 
this non-technical sort-fo-working-group.)

So now the RSAB sends it back?  And we have a shouting match about who 
has the authority to make a decision?

Part of the point of requiring additional external consultation for 
major issues was to make sure that the RSAB either had good reasons for 
their objections, or could with confidence say that the larger community 
agrees even though it makes them (the RSAB members) nervous.

How is this really supposed to work?

Yours,
Joel

On 11/24/2021 8:56 PM, Eric Rescorla wrote:
> 
> 
> On Wed, Nov 24, 2021 at 5:39 PM Stephen Farrell 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     Hiya,
> 
>      > On Wed, Nov 24, 2021 at 5:04 PM Stephen Farrell
>     <[email-masked] <mailto:[email-masked]>>
>      > wrote:
>      >
>      >>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Nov 2021 15:25:13 +1300

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

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

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 25 Nov 2021 13:31:23 +1100

> On 25 Nov 2021, at 1:25 pm, Brian E Carpenter <[email-masked]> wrote:
> 

This is getting there. How 'broad discussion.. in the user community' is measured may become an issue. 

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

That would be really helpful -- it's much more in keeping with the approach we've hammered out. In your mind, would the decision about what needs broader attention and how it's assessed be safe in the hands of the RSAG?

Cheers,

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Nov 2021 18:31:33 -0800

> has the authority to make a decision?

ISTM that the document makes quite clear in S 3.2.2 that this is within
their remit,
subject to appeal to the IAB that they did not follow the correct process
(S 3.2.4).
So I suppose we could have some shouting in the sense that anyone can
shout about anything, but I don't think the process is unclear.

> How is this really supposed to work?

The way I understand this is that the RSAB is supposed to apply their
independent judgement, regardless of whatever consensus may or
may not exist. I suppose it would not be unreasonable for them to
say "seeing evidence of strong consensus would reduce our concern
about risk of harm to the series"

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Nov 2021 15:52:16 +1300

> This is getting there. How 'broad discussion.. in the user community' is measured may become an issue.

Like how you measure community assent for anything, I think. Taking the example of RFC10001.1 again, if the response from the community is mainly <shrug> or "Great Idea", or mainly "Off with their heads!", the RSWG/RSAB will know how to proceed.

> That would be really helpful -- it's much more in keeping with the approach we've hammered out. In your mind, would the decision about what needs broader attention and how it's assessed be safe in…

I think that would be OK.

Regards
     Brian

---

From: Christian Huitema <[email-masked]>
Date: Wed, 24 Nov 2021 20:14:26 -0800

On 11/24/2021 6:52 PM, Brian E Carpenter wrote:
>
> Like how you measure community assent for anything, I think. Taking 
> the example of RFC10001.1 again...

Which of course is a straw-man, because design by committee will likely 
produce something like RFC10001.2053.r05...

-- Christian Huitema

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Nov 2021 08:08:58 +0100

> understood that sometimes this stands in the way of rapid publication.

This misses out on the actual overriding requirement underlying all of this:
The documents need to be suitable for their intended purpose.

For standards, this implies stability, and usability as a technical reference (which includes the ability, and desire, to reference it from another standard).
For IRTF documents, this implies fitting into the publication concept (which includes ability and appropriateness of referencing it in another publication).

As this involves other entities that need to make adoption decisions, for most purposes, this also implies maintaining, and building upon, the reputation of the series (in addition to, and interlinked with, the reputation of each of its streams).
This is rather difficult to capture, but probably the most important (and most difficult to attain/easy to damage) concept that needs to survive the tsunami of process changes.

This is not a principle that was present in this form for RFC 1, but it certainly has been relevant at least since the 1990s.  
Rather obviously, it never has been written up while it became more and more important over time, so we can’t just cite/interpret the founding fathers.

Grüße, Carsten

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 25 Nov 2021 19:19:02 +0900

> to the first tranche of errata, etc.). I agree that:

I'm not sure what the right solution will be, but the recent RFC 9141, 
which says
         Title:      Updating References to the IETF
                     FTP Service

         Updates:    RFC 2077, RFC 2418, RFC 2648, RFC 2954,
                     RFC 2955, RFC 3020, RFC 3083, RFC 3201,
                     RFC 3202, RFC 3295, RFC 3684, RFC 3962,
                     RFC 3970, RFC 4036, RFC 4131, RFC 4251,
                     RFC 4323, RFC 4546, RFC 4547, RFC 4639,
                     RFC 4682, RFC 5098, RFC 5428, RFC 6756,
                     RFC 7241
to me definitely suggests that *something* in the direction of 
RFC10001.1 (not sure exactly what) may be desirable. The convenience of 
the everyday reader of an RFC surely should have priority over the needs 
of historians and patent lawyers, who can easily take an extra step to 
find the original.

[Aside: It may actually be designed so that it isn't used retroactively, 
i.e. only numbers above 10000 would have decimal places (not sure Eric 
intended it that way), and older RFCs would first have to go through one 
'traditional' revision. Introducing such a change at 10000 would have 
the additional advantage that external bodies might have to change some 
of their software to handle 5-digit RFC numbers anyway.]

But the devil is in the details. The W3C recently made it easier to 
issue Recommendations including errata, but it's not clear that the way 
they do it currently will stay for long because it's quite tedious on 
editors,...

> standard of approval for the very principles which are contested.

I don't think about a heightened standard in terms of contested or not. 
I think about it in terms of how wide an effect it has. For the example 
above, it's very clear to me that the RSWG/RSAG can't do this alone. 
They may have the most perfect solution (in terms of technical 
publishing,...), and the most perfect consensus, but if the streams 
don't care (in the sense that they never approve a .1 version), or want 
something else (year instead of decimal digit, you name it, or see 
Christian's mail :-), no kind of consensus in the RSWG/RSAG will help.

So saying, in one way or another, that some things require extra work 
makes sense to me. People who understand things (which includes people 
on this list now) will recognize that as something obvious, but it may 
help others, in particular newcomers and outsiders, understand the 
situation.

The exact form that "these require extra care" takes isn't too important 
to me, as long as it's written down somewhere in our document.

Regards,   Martin.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 25 Nov 2021 12:53:39 +0100

Hi Peter,

Thanks for digging this out. Actually looking at RFC8729 it already talks about principles, and the mission of the RFGC series is written down there as well:

2 <https://datatracker.ietf.org/doc/html/rfc8729#section-2>. RFC Series Mission

   RFCs are available free of charge to anyone via the Internet.

The principles covered n RFC8729 are Archiving, Indexing, and Accessibility as well as uniform style and content for RFCs across all streams.

It seems to me that RFC8729 is the right place for the principle and if we think need to add additional things, this should probably be a separate document to update to RFC8729.

I think what’s not covered from Brian’s text is publication language, diversity of Interests, and document quality. But at least I personally remain less connivence that these are series-wide principles or rather than per-stream principles. For the IETF stream quality is covered by the IETF mission. Maybe there is a point about diversity of opinions but I would think that is implicitly anchored by the way the current stream structure is set up in RFC8729. And we already have a different process to change this structure.

Not sure need anything else in the RFC model document. Actually having looked again at RFC8729, I’m now even more convinced hat then RFC (operation) model is the wrong place to write down these principles.

Mirja

P.S. Btw. RFC8729 also says 

“the role of the IAB is focused on ensuring that principles are met”.

In draft-iab-rfcefdp-rfced-model we say

"This document updates [RFC8729] by replacing the RFC Editor role with the RSWG, RSAB, and RSCE.”

but nothing about the role of the IAB.

> On 24. Nov 2021, at 22:44, Peter Saint-Andre <[email-masked]> wrote:
> 
>> It seems to me that some version of stable document references / unmodifiabl / archival belongs in that list.  (Archival is in the introduction.  Repeating here seems sensible to me.)
> 
> I searched some relevant RFCs for the term "archive" or "archival"; although there are brief or passing mentions in RFC 1358, RFC 1601, RFC 2555, RFC 5540, and RFC 8700 (and perhaps others), the most relevant information comes from RFC 4844 (and its successor, RFC 8729)...
> 
> ###
> 
> 1.  Introduction
> 
> By my reading, the term "archival series" is shorthand for the fact that there's an archive (i.e., a public store and record) of the documents that have been published in the series. Maintaining this archive is part of the RPC responsibilities defined in previous versions of the RFC Editor Model as well as in the Internet-Draft we're working on in this Program, so I don't see anything especially controversial about including more text from Section 4.3 of RFC 4844/8729 in our document.
> 
> Peter
> 
> --

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 25 Nov 2021 12:57:43 +0100

Below.

> On 25. Nov 2021, at 03:31, Mark Nottingham <[email-masked]> wrote:
> 
> 
> 

My assumption was that it is actually part of the role of the RSAB to figure which document needs broad outreach and send out calls respectively and which things might be rather smaller detailed changes that might be less relevant for the specific community the RSAB member is representing.

I agree to the comments below that we might want to rather add something in the "Community Calls for Comment” section about different levels of outreach potentially needed if that is not explicitly covered yet.

Mirja

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Nov 2021 09:45:49 +1300

> The documents need to be suitable for their intended purpose.

Well yes, but that implies that we agree what the intended purposes are
(plural intended). Isn't that for each stream to define for itself?

    Brian

> This is not a principle that was present in this form for RFC 1, but it 
certainly has been relevant at least since the 1990s.
> Rather obviously, it never has been written up while it became more and 
more important over time, so we can’t just cite/interpret the founding fathers.
> .

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Nov 2021 23:28:22 +0100

> (plural intended). Isn't that for each stream to define for itself?

Yes.

I was trying to point out that these, at least for some of the streams, rely on the common asset that is the RFC series and its reputation.
While that observation is implicit to some of the process we have invented (e.g., a stream being able to veto a change), it needs to be made explicit.
This should be a positive goal, informing actions of the RSCE and others.

Grüße, Carsten

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 28 Nov 2021 11:27:53 -0700

> On 25/11/2021 01:17, Mark Nottingham wrote:

<snip/>

> series.

This is interesting. Fast forward 20 years: there's a mostly different 
set of active participants who perceive different needs for the Series 
based on changes that we can't currently foresee. Why would we now, who 
don't know what those future needs might be, limit the range of 
solutions that those folks might consider?

I reiterate that we're establishing a process here...

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 28 Nov 2021 11:31:14 -0700

> I agree to the comments below that we might want to rather add something in the "Community Calls for Comment” section about different levels of outreach potentially needed if that is not explicitly…

I *think* we have this covered in that section, but with my editor hat 
on I'm happy to add clarifying text.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 28 Nov 2021 11:32:48 -0700

> This should be a positive goal, informing actions of the RSCE and others.

Again, I'm happy to add text along these lines, or to receive proposed 
text on list.

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 28 Nov 2021 19:59:58 +0000

Hiya,

> solutions that those folks might consider?

It might be good for them. I think it likely would in fact.
Some knowledge of the background, history or even heritage
related to a topic is often invaluable. And ignorance of
those same things can lead to avoidable repetition and error.

One can also look back 20 years - if one does, some, but not
all of the same people are involved, so 20 years is maybe too
short a time. But we can look back at, and learn from, quite
a lot. For example the raven list [1] has hit that age now
but is still highly relevant as is rfc2804. My bookmark for
that list [1] however now redirects to [2] (thanks to the
good work of the tools team) but that may not be the case in
another 20 years. Of course, rfc2804 doesn't capture all of
that detail (*) but I'm pretty convinced it will last longer
and it represents a good summary of what was a wide ranging
list discussion. That RFC was also a part of much more recent
discussions on related topics and I'd bet will continue to
be useful like that.

I see no reason why people looking back from 2041 ought be
so disadvantaged compared to today's situation. IMO we can
and should try pass on some agreed principles that affect
the series to gain benefits similar to those mentioned above
wrt rfc2804.

Lastly: "limit the range" just isn't what's being proposed
here. (Even though that appears to be a fear some share.)

S.

(*) I'd like if our lists were also better archived for
the long term but that's a different day's work.

[1] http://www.ietf.org/mail-archive/web/raven/current/maillist.html
[2] https://mailarchive.ietf.org/arch/browse/raven/