Subject: [Rfced-future] RFC Principles - long delayed

From: Michael StJohns <[email-masked]>
Date: Thu, 11 Nov 2021 12:20:32 -0500

I apologize for the delay in providing the following.  This is the 
aftermath of Stephen's question/comment about heritage and it morphed 
into a document that attempts to describe current RFC series 
principles.  I've passed this by 1/2dz or so folk and this incorporates 
their comments.

# Principles for the RFC Editor Series

The following principles provide some guidance as to the scope of
documents that the RSWG may propose and the RSAB may approve.
Documents or proposals which suggest modifications of any of the
principles shall require additional approvals past that of the
RSWG/RSAB, specifically consent from the IAB, IESG and the LLC and
such approvals shall be granted only after gaining strong community
consensus for such a change.

## Availability

The RFC series documents have been freely available digitally for more
than 35 years.  No change shall be made to the model which would
introduce fees for access to any or all of the RFC series documents.
Distribution of RFCs shall continue to be subject to the Trust
license<<REF:
https://trustee.ietf.org/documents/trust-legal-provisions/>>.

## Accessibility

There is a general goal to make the RFC series documents as accessible
as possible to communities that have special needs - e.g. seeing
impaired. Proposals that might negatively impact accessibility shall
require the approvals of the IESG, IAB and LLC in addition to that of
the RSAB.

## Publication Language

The publication language of the series is, and shall remain, English.
No action shall be taken which will prohibit the publication of
translations of the RFC series in other languages, but the normative
content language of an RFC shall remain English.

## Commonality of Purpose

The RFC series is the general publication system for information
related to the Internet, networking technology, and community
discussions on those topics.  Neither an expansion nor contraction of
that scope is desired.

## Diversity of Interests

The RFC series has published thought experiments, speculative ideas,
research papers, histories, humor [RFC1149, RFC2549], and even
eulogies [RFC2468].  And, more recently, Internet standards.  Each of
these RFCs and their communities have contributed to the rich history
of the RFC series, and to its somewhat human-centric take on networking.
If we did not acknowledge this and attempt to conserve the means of
such expression we would probably be poorer for it.

As the Independent Stream and IRTF Stream are the primary places that
non-standards related conversations take place, and with a desire to
maintain diversity of interests in the system, neither of these
streams may be disestablished except by the approval of the IESG, IAB,
LLC Board, and with strong community consensus.

The RFC brand shall not be reserved at any time now or in the future
solely to apply to a single community of interest i.e., IETF
publications.

## Breadth of Expression

While the RFC series has its own brand and style, the series is
expected to account for individual expression where possible.

## Archival Quality

Paraphrasing from the introduction to [RFC8153]:

The RFC Editor System provides both publication and archival services
for the RFC Series, although there is nothing prohibiting those roles
being split apart. In the archival role the main goal is to preserve
both the information described and the documents themselves for the
indefinite future.  To meet both publication and archival needs, the
RFC Editor System must find the necessary balance between the
publication needs of today and the archival needs of tomorrow, while
acknowledging a finite set of resources to complete both aspects of
the RFC Editor System functions.

As there may be legal implications related to changes in archive
policy, changes in the applicability of RFC8153 to the RFC Series, and/or
changes to RFC8153 shall require the approvals of the IAB, IESG and
LLC in addition to RSAB approval.

## World-class Publication

As a world-class publication, quality, readability and accuracy are
key to the success of the RFC Series. The publication process is
designed in part to enhance those characteristics.  Unfortunately,
those ideals are sometimes at odds with a desire for an increase in
speed of publication.  Any RSWG proposals that promote speed at the
expense of quality, readability or accuracy shall require the
approvals of the IESG, IAB and LLC in addition to that of the RSAB.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Nov 2021 09:30:49 -0800

Hi Mike,

Thanks for sending this. I agree with some of these principles and disagree
with others,
but as I indicated at the meeting, I don't think any of them should be
especially encoded
in this document. Rather, I think that our ordinary mechanisms are
sufficient to examine
and decide on any proposed changes in these areas.

-Ekr

On Thu, Nov 11, 2021 at 9:21 AM Michael StJohns <[email-masked]>
wrote:

> --
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Nov 2021 12:38:41 -0500

This seems to me to be a good list of points to include in the RFC so as 
to capture our communal goals.

Yours,
Joel

---

From: Brian Rosen <[email-masked]>
Date: Thu, 11 Nov 2021 12:40:06 -0500

Mike

Thanks for this.

Prior to working on specific wording, I would like to understand how many of us think we need something a lot like this in our document.

Alternatives to working on this proposed text might include:
1. Nothing, we agree mostly, but don’t think we should be so proscriptive in this document
2. Something a whole lot smaller that gets at the idea but without the detail

What do you think?

Brian

> On Nov 11, 2021, at 12:20 PM, Michael StJohns <[email-masked]> wrote:
> 
> I apologize for the delay in providing the following.  This is the aftermath of Stephen's question/comment about heritage and it morphed into a document that attempts to describe current RFC series principles.  I've passed this by 1/2dz or so folk and this incorporates their comments.
> 
> 
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Nov 2021 09:43:30 -0800

As I said at the meeting, I believe the current text is sufficient and that
attempting to converge on these principles will be very expensive

-Ekr

On Thu, Nov 11, 2021 at 9:40 AM Brian Rosen <[email-masked]> wrote:

> Mike
>
> Thanks for this.
>
> Prior to working on specific wording, I would like to understand how many
> of us think we need something a lot like this in our document.
>
> aftermath of Stephen's question/comment about heritage and it morphed into
> a document that attempts to describe current RFC series principles.  I've
> passed this by 1/2dz or so folk and this incorporates their comments.
> >
> >
> >
> >

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Nov 2021 17:49:25 -0000

Thanks Mike,

I find these to useful foundations. On the whole I might take them as well-known, but I think that future-proofing the discussions by setting out this text is helpful.

It will, of course, disturb Brian and Eliot if we have to spend time on this discussion now, but it seems to me that if we don't have agreement on these points (the major points, not the wordsmithing) then we have an elephant in the room with us. Failing to address that elephant now would be gross neglect.

Since I agree with this text, I find it hard to understand which points someone might disagree with. It would be helpful that if someone is made uncomfortable by this text, they could at least flag the high level what their concerns are so I can see the scale of the disagreement.

I do understand that some might say, "There is no need to include this material," but this comes back to my first point, and putting in writing something you don't consider necessary is not immediately harmful.

Cheers,
Adrian

-----Original Message-----
From: Rfced-future <[email-masked]> On Behalf Of Michael StJohns
Sent: 11 November 2021 17:21
To: [email-masked]
Subject: [Rfced-future] RFC Principles - long delayed

## Availability

## Accessibility

## Publication Language

## Breadth of Expression

## Archival Quality

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Nov 2021 18:54:34 +0100

> attempting to converge on these principles will be very expensive

… is a good summary of why I’m so uncomfortable with what is going on here.

Grüße, Carsten

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Nov 2021 13:22:21 -0500

--On Thursday, November 11, 2021 09:30 -0800 Eric Rescorla
<[email-masked]> wrote:

> Hi Mike,
> 
> Thanks for sending this. I agree with some of these principles
> and disagree with others,
> but as I indicated at the meeting, I don't think any of them
> should be especially encoded
> in this document. Rather, I think that our ordinary mechanisms
> are sufficient to examine

Eric,

I somewhat disagree.  I thing the largest two problems facing
this group since it started, and the ones that has spawned the
most controversies, have been "what problem(s) are we trying to
solve" and "what are we willing to give up to make various
solutions work".   The current draft is a good statement of
roles, details, and procedures going forward, but does not
appear to address either question.  I think that not holding up
the document until we can reach consensus on a clear statement
of either of those topics is the right decision.  However,
Mike's statement of principles responds to the easier question
of "what is this all about historically and for the long term".
By helping to differentiate between all of the pragmatic
operational and procedural decisions we have made from those
fundamental principles, it would, IMO, make the overall document
much stronger and the prospects for the future much brighter.
And, unless I'm sadly mistaken, his draft does not say anything
to which we have not at least tacitly agreed several times.

Looked a differently, I think our ordinary mechanisms should be
more than adequate to deal with ordinary issues and problems.
With some flexibility and good sense added in, they should be
adequate to deal with short-term and narrow-scope problems that
we have not anticipated as well.  But proposed changes that
would affect those principles are anything but ordinary and
should get special scrutiny.  In that regard, I am actually less
concerned about the extraordinary approval rules in Mike's draft
than I am to provide the RSWG some good guidance that a change
that affects these things is not ordinary but is A Big Deal.  To
the degree that works, so will the ordinary process.  If it
sometime does not, those rules are an important safeguard.

best,
    john

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 11 Nov 2021 18:17:19 +0000

> I don't think any of them should be especially encoded
in this document. Rather, I think that our ordinary mechanisms are sufficient to examine
and decide on any proposed changes in these areas.

I strongly agree with this.  As in “this should not be written into this document and our existing mechanisms suffice.”  Name of the predecessor documents had this kind of thing.

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Nov 2021 13:34:29 -0500

Brian,

In case it was not clear from the response I just sent to ekr,

I think what this documents says is at least close to right and
is at about the right level of detail.  I think it also
addresses (by working around) some issues that have come in and
out of the discussions but that have never turned into tickets
because no one could figure out how to get to text on which
there was a significant chance we could reach consensus.

As to "a whole lot smaller", I think the option of a version
with even more detail and at least somewhat more clarity should
be considered as a possibility too and would be happy to provide
suggestions :-).  But my guess, today, without either of those
hypothetical shorter or longer texts in front of us, is that
Mike's proposal has the balance about right.

And, FWIW, I agree with Adrian: of we are not largely in
agreement about these principles (wordsmithing aside), then
there is a mean-tempered elephant in the room.  I'd go a step
further and suggest that the presence of such an elephant would
suggest that the current document, rather than representing
actual consensus, represents a papering-over of hard issues and
a certain amount of the sort of general exhaustion that
interferes with clear thinking and actual agreement.

best,
   john

--On Thursday, November 11, 2021 12:40 -0500 Brian Rosen
<[email-masked]> wrote:

> Mike
> 
> Thanks for this.
> 
> Prior to working on specific wording, I would like to
> understand how many of us think we need something a lot like
> this in our document.
> 
> 1. Nothing, we agree mostly, but don't think we should be so
> proscriptive in this document 2. Something a whole lot smaller
> that gets at the idea but without the detail
> 
> What do you think?

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Nov 2021 11:36:51 -0700

On 11/11/21 11:17 AM, Salz, Rich wrote:
> *>* I don't think any of them should be especially encoded
> 
> I strongly agree with this.  As in “this should not be written into this 
> document and our existing mechanisms suffice.”  Name of the predecessor 
> documents had this kind of thing.

s/Name/None/ :-)

I said the same thing in the meeting yesterday. What is driving the 
perceived need for a statement of RFC principles right now? Why do folks 
feel these need to be encoded into v3 of the RFC Editor Model when they 
were not encoded into v1 or v2? What problems will this solve? Is it 
worth the cost of trying to get consensus on principles now or should 
this be something that the RSWG/RSAB can debate once they're in place?

Peter

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 11 Nov 2021 11:05:45 -0800

I agree with Peter and Ekr here that this doesn’t seem like a list that belongs in this document.

I think the list is quite interesting as a set of things to discuss and agree upon within the new RSWG/RSAB bodies, and contains items that the IAB and IESG would be willing to help chime in on. However, this list doesn’t seem to be central to the definition of how the RFC editor model functions as a construct. If we believe that the model that’s being defined is the right model, we should trust that it can define the right guidelines for its operations. If we are concerned that the new model will “go rogue”, then the most that should be said here is that the new bodies should agree on a set of long-term principles as their first task upon formation. (I also think the current text in the document is sufficient, to be clear).

Best,
Tommy

> On Nov 11, 2021, at 10:36 AM, Peter Saint-Andre <[email-masked]> wrote:
> 
> I said the same thing in the meeting yesterday. What is driving the perceived need for a statement of RFC principles right now? Why do folks feel these need to be encoded into v3 of the RFC Editor Model when they were not encoded into v1 or v2? What problems will this solve? Is it worth the cost of trying to get consensus on principles now or should this be something that the RSWG/RSAB can debate once they're in place?
> 
> Peter
> 
> --

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Nov 2021 14:31:50 -0500

--On Thursday, November 11, 2021 11:36 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>> I strongly agree with this.  As in "this should not be
>> written into this  document and our existing mechanisms
>> suffice."  Name of the predecessor  documents had this
>> kind of thing.
> 
> s/Name/None/ :-)
> 
> I said the same thing in the meeting yesterday. What is
> driving the perceived need for a statement of RFC principles
> right now? Why do folks feel these need to be encoded into v3
> of the RFC Editor Model when they were not encoded into v1 or
> v2? What problems will this solve? Is it worth the cost of
> trying to get consensus on principles now or should this be
> something that the RSWG/RSAB can debate once they're in place?

I promised myself I was through posting for today but, since, as
Peter notes, this came up yesterday and now today...

Although I'm obviously not convinced, there may be sound
arguments for leaving this material out, but "none of the
predecessor documents included such statements" does not appear
to me to be one of them.  Those documents were all written as a
combination of explanations to the community of how things
worked and what the pieces were and how they fit together, plus
some fine-tuning to adjust for changes in the surrounding
structures.  They described a system that had worked, and was
perceived as having worked rather well, for, as RFC 8700 points
out, around a half-century.  That system was built around the
idea of a strong and skilled "editor" (sometimes a couple of
people, not just one) who felt responsible for both principles
and continuity _and_ who had near-absolute authority.  Those
documents did not explicitly identify principles because there
was no need to do so.

A really bad choice of RFC Editor/RSE could have been fatal to
that sort of system but, through what I think was a combination
of talent and luck, we never had one of those but, instead, got
highly skilled and committed people with no inclinations toward
risky and radical changes.

Now we are going down a different path, one that replaces the
central role and authority of the RFC [Series] Editor with a
rather complicated committee and decision structure.  While I
agree with the implicit assumption that we should make decisions
and move forward with confidence, there is no proof that it will
actually work and the subject matter and scope of the RFC Editor
function is such that analogies to IETF WGs cannot inspire great
confidence.   From that standpoint, we are carrying out a
high-stakes experiment.   And saying, as part of the description
and scope of the experiment, "these are principles and changes
to them are not ordinary, and, if they are to be changed at all,
need special consideration" seems both appropriate and wise ...
no matter what earlier documents, written in a very different
(and proven) environment and with very different assumptions,
might have not needed to include.

   john

---

From: Bob Hinden <[email-masked]>
Date: Thu, 11 Nov 2021 11:33:00 -0800

I like what Mike St.Johns wrote and think it should be part of the document.

As Adrian said, if there is disagreement on this text, then there is a bigger problem at hand.  I don’t see how it could harmful if it helps to build a consensus.

Bob

> On Nov 11, 2021, at 9:49 AM, Adrian Farrel <[email-masked]> wrote:
> 
> Thanks Mike,
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Nov 2021 20:00:08 +0000

> to capture our communal goals.

+1 - I think some of Mike's text needs work but I think the
draft needs this kind of text even more.

Cheers,
S.

>> principles.  I've passed this by 1/2dz or so folk and this 
>> incorporates their comments.
>>
>>
>>
>>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Nov 2021 21:13:53 +0100

> I agree with Peter and Ekr here that this doesn’t seem like a list that belongs in this document.

If the point of the document were to optimize the application of the Dewey Decimal Classification to our documents, I’d agree.

But this is not a philological exercise; the point is to guide future work in this space.

The discussion convinces me that we need this material as a backstop.

Instead of spending more time on trying to disprove this, we might use that time to fix the nits.

Grüße, Carsten

---

From: Scott Bradner <[email-masked]>
Date: Thu, 11 Nov 2021 15:41:13 -0500

I agree - useful guidance for  future work in this space

Scott

> On Nov 11, 2021, at 3:13 PM, Carsten Bormann <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Nov 2021 09:53:51 +1300

> Prior to working on specific wording, I would like to understand how many of us think we need something a lot like this in our document.

We need something a lot like this. Whether it's in *this* document or a companion document (#2 in the Editorial Stream) seems less important to me.
  
> 2. Something a whole lot smaller that gets at the idea but without the detail

Before we get to that, I think we need to know what disagreements *in principle* might exist.

I was not one of the people who saw this in advance, but I support all of 
it. I would also add a commitment to a robust and open peer review process.

Regards
    Brian C

>> I apologize for the delay in providing the following.  This is the aftermath of Stephen's question/comment about heritage and it morphed into a 
document that attempts to describe current RFC series principles.  I've passed this by 1/2dz or so folk and this incorporates their comments.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 11 Nov 2021 20:39:51 +0000

>   But this is not a philological exercise; the point is to guide future work in this space.

I am not convinced, but I do not object.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Nov 2021 21:04:11 +0000

Hiya,

On 11/11/2021 20:53, Brian E Carpenter wrote:
> Whether it's in 
> *this* document or a companion document (#2 in the Editorial Stream) seems less important to me. 

I'd argue it's better done here and now myself.

I think it'll be easier to relatively succinctly document
existing principles from "within" the existing system.

I think when the current draft is done, there'll be a
significant probability that many people will want a
break from this topic, e.g. until an rcse is appointed,
and good intentions now might get lost in such a gap.

If there are any serious disagreements on principles
like these then we'll be way better off if we know that
now rather than only discover it later.

Cheers,
S.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Nov 2021 10:32:13 +1300

>> *this* document or a companion document (#2 in the Editorial Stream) seems less important to me.

I was a bit unclear. I agree that it's timely to do it now. It just seems 
like a separate topic that could be a separate but simultaneous RFC. I'd certainly like to know the points of disagreement *now*.

    Brian

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 11 Nov 2021 13:50:01 -0800

> On Nov 11, 2021, at 1:32 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> I was a bit unclear. I agree that it's timely to do it now. It just seems like a separate topic that could be a separate but simultaneous RFC. I'd certainly like to know the points of disagreement *now*.

I agree that this can be a separate RFC on the Editorial Stream, which certainly could be done simultaneously—or at least adopted and worked on now.

If we think forward to a time when we’ll want to revise and create -bis documents, I imagine there will be a different cadence for changing “the administrative model” and updating “core principles and values”. Trying to lump these together going forward would likely be a disservice to both topics.

Tommy

> [email-masked] <mailto:[email-masked]>
> https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Nov 2021 22:04:55 -0000

I don’t know how far down a rabbit hole we are going by discussing this if there is resolute opposition, but…

How would people feel about a separate RFC that was a normative reference from the base document? That would allow the base document to be approved, but not published until we had agreed on both texts.

A

From: Rfced-future <[email-masked]> On Behalf Of Tommy Pauly
Sent: 11 November 2021 21:50
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked]; Stephen Farrell <[email-masked]>
Subject: Re: [Rfced-future] RFC Principles - long delayed

On Nov 11, 2021, at 1:32 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]> > wrote:

Hiya,

Whether it's in

Tommy

  Brian

-- 
Rfced-future mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.iab.org/mailman/listinfo/rfced-future> https://www.iab.org/mailman/listinfo/rfced-future

---

From: Jay Daley <[email-masked]>
Date: Fri, 12 Nov 2021 11:40:21 +1300

I don’t have a view on whether or not these principles are incorporated, but if they are to be incorporated, then I do have some significant issues with the way they are drafted and two content issues.

My first content issue is that "Commonality of purpose" and "Diversity of interests" contradict each other.  The former restricts the scope, the latter addresses the extraordinary breadth of the scope.  My recommendation would be to delete "Commonality of purpose" because I can only see it stopping things from happening, not protecting the series in any way.

My second content issue is that "Breadth of expression" does not properly balance the stated aim "individual expression" with the need for consistency, clarity, readability, etc.  Rather than express this in favour of one or another, it is better put as statement of the various things that must be balanced.

> consensus for such a change.

This change mechanism is the one piece of policy that is required and doesn’t need repeating below.

> ## Availability
> 
> The RFC series documents have been freely available digitally for more than 35 years.

Principle but better stated as "The RFC series documents shall be freely available digitally".

>   No change shall be made to the model which would

Policy.

> impaired. 

Principle.

> Proposals that might negatively impact accessibility shall

Policy.  Covered by the change mechanism above.

> content language of an RFC shall remain English.

Principles

> discussions on those topics.  Neither an expansion nor contraction of

As noted above, I would strike this.

> such expression we would probably be poorer for it.

Principle

> LLC Board, and with strong community consensus.

Policy.

> solely to apply to a single community of interest i.e., IETF

Principle.

> expected to account for individual expression where possible.

Principle but my preference would be "The RFC Series should balance the need for a defined brand and style to ensure consistency, clarity and readability, with the freedom of authors to express themselves individually."

> the RFC Editor System functions.

Principle.

> LLC in addition to RSAB approval.

Policy.

> speed of publication.  

Principle, though better worded as a statement of balance.

> Any RSWG proposals that promote speed at the

Policy.

I would simply strike all the policy parts except the change mechanism in the preamble.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Thu, 11 Nov 2021 14:58:01 -0800

> 2. Something a whole lot smaller that gets at the idea but without the detail

I observe that Jon Postel never bothered to write down these principles, 
and I am worried about making a definitive statement as part of this 
document. Mike is making an honest effort to write down what is largely 
oral history and culture, but it is inevitable that when doing so his 
personal preferences get written down. For example, the paragraphs about 
diversity of interest show a great preference for a strong distance 
between the RFC community and the IETF. This is a debate that we had 
last year, we found a consensus that is reflected in the structure of 
the WG and of the RSAB, and I would rather not reopen that debate now.

If we want to cite principles, I would rather cite the various already 
published RFC that make references to these principles, and leave it at 
that.

-- Christian Huitema

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Nov 2021 16:15:52 -0800

On Thu, Nov 11, 2021 at 9:49 AM Adrian Farrel <[email-masked]> wrote:
> Since I agree with this text, I find it hard to understand which
> points someone might disagree with. It would be helpful that if
> someone is made uncomfortable by this text, they could at least flag
> the high level what their concerns are so I can see the scale of the
> disagreement.

Well, my concern is fundamentally that the purpose and effect of this
text is to put certain matters outside the ordinary democratic RSWG
process and into some other process that is much harder to execute,
thus freezing them in their current configuration and not necessarily
in the configuration that best serves the community. So, it's not so
much that I necessarily agree or disagree with this text but rather
that I disagree with the entire premise of the text.

With that said, let me pick out two items, one of which I agree with
on substance and one of which I disagree with. These aren't exhaustive
but are merely designed to help lay out the nature of my objection.

> content language of an RFC shall remain English.

As I am a native English speaker and my command of other languages is
poor, I would be opposed to any change of the RFC series into some
other language. However, I think that if we got to the point where the
RSWG, the community, and the RSAB (which, note, in its current state,
effectively requires agreement from either the IAB or the IESG because
they collectively control 3 members) thought it was best to change to
some other language, that seems like it would be entirely
appropriate. For that reason, I am against a statement in this
document that biases against that change.

> approvals of the IESG, IAB and LLC in addition to that of the RSAB.

First, I don't really know what it would mean for the RFC Series to be
a "world-class publication series" (though, given the rather uneven
quality level, I suspect that under many definitions it would not
be). In any case, I don't think that this kind of patting ourselves on
the back belongs in this document. Second, the right set of editorial
procedures for documents is precisely the kind of issue which the RSWG
ought to be resolving--and indeed has been the topic of active
debate--so it's entirely inappropriate for this document to rule
it out of scope.

Finally, I'm quite surprised to see the LLC named as having to sign
off on any of this. When the LLC was first formed we took great pains
to ensure that it was subordinate to the community. This seems
entirely inconsistent with giving it a veto over community decisions,
and mostly functions to make change harder.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Nov 2021 16:16:48 -0800

On Thu, Nov 11, 2021 at 2:05 PM Adrian Farrel <[email-masked]> wrote:

> How would people feel about a separate RFC that was a normative reference
> from the base document? That would allow the base document to be approved,
> but not published until we had agreed on both texts.
>

I would object to this for the same reason as I object to it being
incorporated.

-Ekr

>
> A
>
>
>
> *From:* Rfced-future <[email-masked]> *On Behalf Of *Tommy
> Pauly
> *Sent:* 11 November 2021 21:50
> *To:* Brian E Carpenter <[email-masked]>
> *Cc:* [email-masked]; Stephen Farrell <[email-masked]>
> *Subject:* Re: [Rfced-future] RFC Principles - long delayed
>
>
>
>
>
>
>
> like a separate topic that could be a separate but simultaneous RFC. I'd
> certainly like to know the points of disagreement *now*.
>
>
>
> I agree that this can be a separate RFC on the Editorial Stream, which
> certainly could be done simultaneously—or at least adopted and worked on
> now.
>
>
>
> If we think forward to a time when we’ll want to revise and create -bis
> documents, I imagine there will be a different cadence for changing “the
> administrative model” and updating “core principles and values”. Trying to
> lump these together going forward would likely be a disservice to both
> topics.
>
>
>
> Tommy
>
>
>
>
>   Brian
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Nov 2021 13:58:11 +1300

Eric,

On 12-Nov-21 13:15, Eric Rescorla wrote:
> On Thu, Nov 11, 2021 at 9:49 AM Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:

 From that, and your other message, is it fair to conclude that you'd be
OK with a statement of principles that was *not* a normative reference
for the RFC Editor Model (Version 3) but *was* an Editorial Stream
document and hence subject to the RSWG/RSAB process?

(Incidentally, since RFC Editor Model (Version 3) is not by any means
a standards track document, the term "normative reference" is undefined
anyway.)

That said, I'll bite, with comments on your two items below.
  
> document that biases against that change.

So, if we strike "and shall remain", it's OK?

> a "world-class publication series"

You're right, it's a judgment word, but that's a wordsmithing issue.

(though, given the rather uneven
> debate--so it's entirely inappropriate for this document to rule

Here, I think that Jay is right that some of the points merge into
policy, although the boundary is fuzzy. (My fix for that is to rename
the text as "RFC Principles and General Policies".)

> and mostly functions to make change harder.

I agree, but the LLC has a resources veto over *implementation* of
community decisions, recognised elsewhere in RFC Editor Model
(Version 3).

I think it's mainly an academic point anyway, since publication
delays are rarely caused by the RPC. It's entirely a result of IETF
policy, for example, that we have documents stuck for years (literally)
in the RPC queue waiting for normative references.

     Brian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 12 Nov 2021 13:36:58 +1100

I largely agree with EKR here -- these may be perfectly appropriate principles, but the proper place to agree to them is in the RSWG process itself, not here. 

I.e., this is out of scope for this program.

Cheers,

> On 12 Nov 2021, at 4:20 am, Michael StJohns <[email-masked]> wrote:
> 

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

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 12 Nov 2021 14:15:34 +1100

So I'm going to join those who disagree with the premise of the text.

Alignment on principles is how we might - in the future - make good decisions.  However, if Mike's goal is to blow this entire enterprise up, forcing these specific principles upon the community is a really good way to go about it.

On Fri, Nov 12, 2021, at 06:33, Bob Hinden wrote:
> As Adrian said, if there is disagreement on this text, then there is a 
> bigger problem at hand.

Oh yes, we really do have a big problem.  There is a massive schism in the community on this topic, make no mistake.

We've been walking softly as a result.  That more than anything else, is why we've made so much progress so far.  We're carefully identifying those things we share and documenting them.

Mike's text is an attempt to force a particular set of views into a privileged position, by effectively writing it into the constitution.

We might never completely agree on some of these items, but it's possible that we don't have to.  Much of the work in the IETF proceeds despite some fairly fundamental disagreements between different parties.  I'm not sure that I subscribe to the philosophy that there are essentially contested concepts[1], but I'm willing to admit that the fights over some subjects are tenacious.

I propose that we instead allow these principles to be discussed, agreed, and documented according to the processes we have defined.  I propose that we do that as the need arises rather than preemptively.

Attempting to litigate this set of principles would destroy the progress we've made thus far.

Cheers,
Martin

[1] Gallie, W. B. (2019). Essentially contested concepts (pp. 121-146). Cornell University Press.

---

From: "John Levine" <[email-masked]>
Date: 11 Nov 2021 23:19:37 -0500

>introduce fees for access to any or all of the RFC series documents.

Oh, OK.  RFCs continue to be 100% free but to get access you have to log in with your Facebook account.

Trying to get this sort of stuff correct is surprisingly hard, and I don't think we should try to do it on the fly.

Perhaps the RSWG can take on as one of its early tasks to create a non-binding set of principles of the series.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Nov 2021 17:34:58 +1300

> Alignment on principles is how we might - in the future - make good decisions.  However, if Mike's goal is to blow this entire enterprise up, forcing these specific principles upon the community is…

Well, maybe, but suggesting that the community should try to agree on a set of principles and high level policies is not. Actually deciding on them is not exactly excluded by our charter, but not exactly included either:
"This program has no predetermined constraints on the decisions of the group.  Updates to or retention of the oversight model, management, and the roles involved in the RFC Editor function are all within scope."
I believe that our Chairs have discretion to determine whether *defining* principles and high level policies are in scope.

>> As Adrian said, if there is disagreement on this text, then there is a

It isn't yet clear to me that we have that problem, because I haven't yet understood properly which of Mike's principles and high level policies are objected to at a basic level, once the superficial drafting issues are resolved. But neither is it clear to me what we gain by stalling the RFC Editor Model (Version 3) until they are resolved. This model creates precisely the environment where we can debate the principles and high level policies.

> Oh yes, we really do have a big problem.  There is a massive schism in the community on this topic, make no mistake.

There isn't *one* topic. There are a whole lot of topics in Mike's text. There are far more thorny issues within the IETF standards process that might, if anybody seriously tackled them, completely transform the IETF Stream's requirements. That's a 20-year-old problem that I don't expect to see tackled soon.

> I propose that we instead allow these principles to be discussed, agreed, and documented according to the processes we have defined.  I propose that we do that as the need arises rather than preemp…

Do you also agree that if it ain't broke, don't fix it? One argument for documenting historical and current principles and high-level policies is precisely to avoid inadvertent damage by changing something without fully understanding the consequences. That's why I think that documenting them up front is valuable. It doesn't turn them into a sacred text. But on balance, I agree, this does not belong in the RFC Editor Model (Version 3).

Regards
    Brian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 12 Nov 2021 08:49:30 -0000

Thanks for engaging on this point, Eric.

If I understand you right, you are saying that you are concerned that decisions made now might serve to limit what the RSWG can do later as a “democratic” process.

Questions: Is what we are doing now not democratic? Is not the way we are shaping the future process putting limits on what the RSWG can do later?

I think it is helpful that you called out a couple of specifics in your text below. Funnily, I don’t find what you say there to be contentious at all: I’m sure we could easily find wording on those points to satisfy both sides (up to and including removing text).

Cheers,

Adrian

From: Eric Rescorla <[email-masked]> 
Sent: 12 November 2021 00:16
To: Adrian Farrel <[email-masked]>
Cc: Michael StJohns <[email-masked]>; [email-masked]
Subject: Re: [Rfced-future] RFC Principles - long delayed

-Ekr

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 12 Nov 2021 08:49:30 -0000

Thanks.

Good to know this opinion.

I think we can take “separate document with normative reference” off the table, then.

We can go back to discussing “include text in the base document.”

Cheers,

Adrian

From: Eric Rescorla <[email-masked]> 
Sent: 12 November 2021 00:17
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rfced-future] RFC Principles - long delayed

On Thu, Nov 11, 2021 at 2:05 PM Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

I would object to this for the same reason as I object to it being incorporated.

-Ekr

A

From: Rfced-future <[email-masked] <mailto:[email-masked]> > On Behalf Of Tommy Pauly
Sent: 11 November 2021 21:50
To: Brian E Carpenter <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; Stephen Farrell <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Rfced-future] RFC Principles - long delayed

Hiya,

Whether it's in

Tommy

  Brian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Nov 2021 10:24:54 +0100

> 
> “democratic” process.
>  
> Questions: Is what we are doing now not democratic? 

Since we are already using terms from a very different domain (government) here, let’s continue on that analogy:

This is the usual bootstrapping problem you run into when setting up a constitution.

One might note that constitutions typically have elements that require a qualified majority to change them.

It is not unheard of to have elements that cannot be changed at all (e.g., articles 1 and 20 in the German constitution).

I don’t think anyone can argue that the German constitution isn’t “democratic”  (*).

Grüße, Carsten

(*) Possibly more so than others that lay claim to this word.  We do understand the need for a “defensive democracy” [1], which may be less familiar to people living in countries that have not recently needed to rebuild after a takeover by enemies of the democracy.  More generally speaking, my hunch is that some of the differences in perspective in the current discourse stem from different levels of experience with these kinds of process abuse.

[1]: https://en.wikipedia.org/wiki/Defensive_democracy

---

From: Eliot Lear <[email-masked]>
Date: Fri, 12 Nov 2021 10:39:42 +0100

I would suggest that *nowhere* is the IETF intended to be democratic.  
We typically run by rough consensus, a much higher bar for decision 
processes.  But I don't think this changes the nature of the 
discussion.  The chairs will comment on that Soon.

---

From: John C Klensin <[email-masked]>
Date: Fri, 12 Nov 2021 07:53:14 -0500

--On Thursday, November 11, 2021 14:58 -0800 Christian Huitema
<[email-masked]> wrote:

> I observe that Jon Postel never bothered to write down these
> principles, and I am worried about making a definitive
> statement as part of this document. Mike is making an honest
> effort to write down what is largely oral history and culture,
> but it is inevitable that when doing so his personal
> preferences get written down. For example, the paragraphs
> about diversity of interest show a great preference for a
> strong distance between the RFC community and the IETF. This
> is a debate that we had last year, we found a consensus that
> is reflected in the structure of the WG and of the RSAB, and I
> would rather not reopen that debate now.

Just to the point of what Jon did or did not write down... I had
several conversations with him on a mostly unrelated topic in
the mid and late 1980s about why he had not written down the
principles he and Joyce were following.  Translated a bit into
the vocabulary we are using, the answer I got was,
approximately, that he understood the principles he was
following, that he was ultimately the sole interpreter of those
principles, and because unanticipated and edge cases came up
periodically, would be a lot of work and just provide an
invitation to flame wars.  FWIW, it took some effort to get RFC
1111 written (one might guess that from the time lag between
when he asked for comments about the series in RFC 825 in 1982
and the publication of RFC 1111 in 1989 and note that, in the
distinctions we are making now, RFC 1111 is entirely about
policy and not principles).  

As with my comments yesterday about why there were no statements
of principles in earlier version, the answer is that there was a
smoothly running system, one with a procedurally very simple
decision process, that worked rather than a situation in which
we are trying to invent a new (and very different and somewhat
experimental) system and doing it around a very complex decision
process.

There may be good reasons to avoid identifying the principles we
think are important and that are guiding us, but whatever Jon
did or did not do seems irrelevant to me.

    john

---

From: John C Klensin <[email-masked]>
Date: Fri, 12 Nov 2021 08:42:15 -0500

--On Friday, November 12, 2021 14:15 +1100 Martin Thomson
<[email-masked]> wrote:

>...
> Oh yes, we really do have a big problem.  There is a massive
> schism in the community on this topic, make no mistake.
> 
> We've been walking softly as a result.  That more than
> anything else, is why we've made so much progress so far.
> We're carefully identifying those things we share and
> documenting them.
>...

Martin,

While agreeing about the schism, I suggest there is a different
way of looking at "walking softly".  It is that, rather than
trying to reach agreement on the difficult issues, we have
walked around them, keeping a large distance, and concentrated
instead on procedures and rituals.  If there is so much
disagreement about principles that we can't write them down at
this point --and therefore need to kick them down the road to
the RSWG/RSAB-- I think we are setting ourselves and that
process up for either not being able to make significant
decisions in finite time or for having to declare an emergency
and then making those decisions by some process we are not
contemplating at all.  

My guess --YMMD-- is that this group and its discussions include
a broader spectrum of people and perspectives, with more
involvement, than we are going to see, long-term, in the RSWG.
Once the new process gets rolling, I expect (or at least hope)
that many of us will go back to concentrating on development of
technical specifications and their documentation.  However, that
implies that the RSWG is likely to be disproportionately
representative of people who are interested in process and
details rather than what we consider the mainstream of the
IETF's work (making the Internet better and all that).    I
think that would be fine as long as their task is to work out
details (including most policies) but very dangerous if it
involved making decisions about principles that we disagree
about and are avoiding or sweeping under the rug.

   john

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 12 Nov 2021 08:25:00 -0800

Yes, a separate document with a normative reference would be off the table, but as Brian pointed out, there can’t technically be normative/blocking references in an Editorial Stream document.

I would still urge people that a separate document on the Editorial Stream would make most sense here if you want to have text enumerating the values and principles of RFCs.

Tommy

> On Nov 12, 2021, at 12:49 AM, Adrian Farrel <[email-masked]> wrote:
> 
> Thanks.
>  
> From: Eric Rescorla <[email-masked] <mailto:[email-masked]>> 
> To: Adrian Farrel <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On Thu, Nov 11, 2021 at 2:05 PM Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:
>> From: Rfced-future <[email-masked] <mailto:[email-masked]>> On Behalf Of Tommy Pauly
>> To: Brian E Carpenter <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>; Stephen Farrell <[email-masked] <mailto:[email-masked]>>
>>> On Nov 11, 2021, at 1:32 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>>  
>> https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>--

---

From: Christian Huitema <[email-masked]>
Date: Fri, 12 Nov 2021 09:47:22 -0800

> did or did not do seems irrelevant to me.

My point was that in the absence of written history, attempts to 
reconstruct principles from oral history are fraught with peril. They 
will invariably incorporate opinions on present discussions under the 
guise of memory. That's why I would not want to incorporate Mike's text 
in the draft. I would be happy to incorporate citations of documents 
that predate the current discussion, such as the definitions of the RFC 
series in RFC 8729 or RFC 5741. Both documents use the same short text 
in their section 2:

    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.

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

That's as close as it gets to stated principles. I might add a citation 
of RFC 1796, which mentions principles like "not all RFC are standard", 
"A single archive" and "Rather document than ignore". But I don't think 
that we should elaborate much more than that in the draft.

The RSWG may well start working on a document on principles. I agree 
with you, John, that such work should not be thought of as an 
archeological dig of Jon Postel's supposed thoughts. It should probably 
have to components. On one hand, look at the past of the series, the 
guidelines that were followed, and how those guidelines contributed to 
past success. (Or not?) On the other hand, look at what might need to 
change in order to be successful in the future.

-- Christian Huitema

---

From: John C Klensin <[email-masked]>
Date: Sat, 13 Nov 2021 18:09:16 -0500

(Apologies for the length of this, but I want to point out that
almost half of it is quotation from Christian's note)

--On Friday, November 12, 2021 09:47 -0800 Christian Huitema
<[email-masked]> wrote:

>> There may be good reasons to avoid identifying the principles
>> we think are important and that are guiding us, but whatever
>> Jon did or did not do seems irrelevant to me.
> 
> My point was that in the absence of written history, attempts
> to reconstruct principles from oral history are fraught with
> peril. They will invariably incorporate opinions on present
> discussions under the guise of memory. That's why I would not
> want to incorporate Mike's text in the draft. I would be happy
> to incorporate citations of documents that predate the current
> discussion, such as the definitions of the RFC series in RFC
> 8729 or RFC 5741. Both documents use the same short text in
> their section 2:
> 
> That's as close as it gets to stated principles. I might add a
> citation of RFC 1796, which mentions principles like "not all
> RFC are standard", "A single archive" and "Rather document
> than ignore". But I don't think that we should elaborate much
> more than that in the draft.
> 
> The RSWG may well start working on a document on principles. I
> agree with you, John, that such work should not be thought of
> as an archeological dig of Jon Postel's supposed thoughts. It
> should probably have to components. On one hand, look at the
> past of the series, the guidelines that were followed, and how
> those guidelines contributed to past success. (Or not?) On the
> other hand, look at what might need to change in order to be
> successful in the future.

Christian,

While I think I understand your perspective, I would draw a
distinction between  "oral history" as a vague collection of
ideas shared, very imperfectly, among some group and
well-understood principles that have just never been written
down.  I think some of the things Mike included in his list
(even some of those I agree with) are debatable and should be
discussed carefully.  And I think Mike was clear that the
particular language he used and the details they imply are in no
sense immutable.  

Let me make a comparison to a metaphorical statement of
principle I have never really liked and don't know how well it
translates across cultural boundaries.  Suppose one has general
agreement that motherhood and apple pie are good.  That does not
imply agreement about the best age range for mothers when
children are born, best age for weaning, or conditions
surrounding marriage.  It also does not imply agreement about
types of apples, composition and thickness of the crust, or even
what is a "pie" relative to some other sorts of pastries.  But
"motherhood is bad and apple pies are worse" would be a radical
departure from tradition and worth careful examination.   More
seriously, I think there is general agreement in contemporary
human societies that indiscriminate killing of other humans is
bad and inappropriate.  Sadly, there is not universal agreement
about several of the words in that statement.

But those sorts of principles (and policies one would want to
change only with great care) are important and especially
important as guideposts to alert a community or society that a
boundary is about to be crossed, that the change may turn out to
be very significant, and that special consideration (and, in our
language, broader consensus) is needed.  Do they need to be
written down?  IMO, probably a good idea, but not necessary as
long as the decision-making and interpretation of those
principles is in the hands of a relatively small group with a
shared understanding of both the principles and the relevant
history.

However, that is where the situation we find ourselves in now
calls more strongly for getting those principles written down
then at any previous time in the history of the series since it
acquired an Editor who had (or was generally assumed to have)
real authority.  There are few people participating in this
process who saw or were aware of RFC 1 shortly after it was
published or who were involved in the decisions to separate the
IENs into a separate series and process and then give up and
merge the successors of that material back in.   Statistically,
I suggest that it is almost certain that there will be fewer ten
or twenty years from now.  Such people should not get special
authority (now or in the past) but the memories and the
principles should at least be considered when they imply "we
tried that, it didn't work out well, and you should understand
the reasons before trying it again".  Whether publicly
identified or not, there have been advisory groups appointed by
the RFC Editor (and then the RSE and ISE), since at least the
mid-1980s if not earlier.  For pragmatic reasons as well as how
the appointment process worked, someone whose position was that
we should burn the house down and start over might be listened
to carefully to see what could be learned, but did not end up
part of any of those advisory groups.  And, while the leadership
of the RFC Editor Function were encouraged to consult the
community (more explicitly in the last decade or two than
before), that function bore much the same authority relationship
to the IETF that the IAB and LLC do today: even where there is
an obligation to consult, they are still responsible for
decisions within their scope and based on their understanding
(of the subject matter and that scope) rather than having IETF
consensus determine those decisions.

We are in the process of making some very radical changes to
that long-established model.  Maybe they are long overdue (for
diversity considerations if nothing else).  Some of us have more
confidence that it will work well than others but I hope we can
all agree that, regardless of the analogies or inferences we
might draw from other processes, it is something of an untried
experiment.  It seems obvious to me (could be wrong-- ultimately
part of the experiment) that this group represents a broader
range of perspectives and a higher and more diverse level of
involvement than the RSWG will have a few years down the road.  

Two things seem clear to me even if the second is a bit
heretical.  One is that it is time to get the real principles
and fundamental policies written down and written down as part
of this group's work.  They should not be immutable positions
but should act as signposts for the RSWG and RSAG and as
warnings to them and the broader community that decisions that
would change them are different from ordinary operational policy
ones and need to be taken _very_ carefully and with broad
community awareness, opportunity to comment, and, ideally,
involvement.  The details of how the latter are accomplished
are, well, details.  The second is that, if we cannot agree on
what those principles are, the effort to focus on process and
procedures and kicking things we cannot agree about down the
road has gone too far and that we would be doing ourselves, and
the broader community and the Internet itself, a huge disservice
by pretending we actually have consensus about the future of the
RFC Series.

best,
   john

---

From: Michael StJohns <[email-masked]>
Date: Sat, 13 Nov 2021 18:30:31 -0500

Hi -

I'm responding to my original note on purpose.  I have read each of the 
comments and responses in this thread and I think this works better as a 
set of mostly general comments.

While drafting the text for the principles section, I realized that the 
current document had a few holes.   As a thought experiment, consider if 
all of the current people participating within this task group were 
struck dead, pulled off of IETF work by their employer, or other wise 
became unavailable to work on the RSWG once it is establish.  The 
questions are these: Does this document provide enough context and 
guidance for a randomly selected group of people to make useful 
contributions to the RFC system?  Does the model constrain the process 
enough to prevent the same group of randomly selected people from either 
accidentally or maliciously affecting the RFC system in a negative 
manner?   For the first question, I think the answer is an unqualified 
no.  For the second question, the discussion of the last few weeks has 
suggested that the answer is a qualified no - and really depends on the 
personalities involved.

In the present case, think of the Principles (and yes, Policies Jay...) 
as a combination of owner's manual, training wheels and guard rails for 
the RFC series which will allow the nascent RSWG to accomplish a few 
tasks while gaining experience with this unique and new role, AND which 
will give the community sufficient time to evaluate whether the new 
process is meeting their needs. In a year or two, with a few documents 
completed and accepted by the community, I would expect that the RSWG 
and the RSAB could propose modifications to the principles as they 
figure out what works and what doesn't and make a case to the community 
for changes.  We've got a half century of worked and working examples 
that make up the current RFC Series.  Providing time for the RSWG to 
prove that it can do as well as those who came before, and that the new 
system works at least as well as the system it replaces, is well in 
keeping with the "working code" model of the normal IETF-style process.

On to specific points.

Few if any organizations in human history have given up authorities once 
they've acquired them absent some external or superior impetus.   
Delaying the creation of a principles document until after the RSWG is 
chartered would likely result in no such document being created as it 
would be a voluntary constraint of the RSWG's prerogatives by the RSWG.

The chair's role for this group is to determine consensus on whether 
something is in or out of scope, rather than, as was suggested in one 
email I read, be able to rule on their own choice.  The question of 
consensus here appears to be whether or not the document should be 
published without a principles section and I think we currently lack 
consensus for publication *without* this section.  However, we also lack 
consensus for publication *with* this section.  This will require 
discussion and I expect will end up with rough consensus one way or the 
other at some point with some folk disappointed.

The text I wrote is cribbed from various sources and discussions going 
back 35 years, as well from discussions with folk that have been 
involved more recently in the RFC series process.  While this text has 
my own imprint, I believe it represents a broader view than just my 
personal opinions.

The text I submitted is obviously not written in stone, and I expect 
there will be a bit of word-smithing including trimming, rephrasing, and 
expansion prior to finalization.   Let's try to avoid comma parsing and 
adjective twiddling for a week or so and work more on the broader concepts.

Thanks - Mike

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 13 Nov 2021 23:30:39 +0000

Hi Tommy,

A comment and a question:-

On 12/11/2021 16:25, Tommy Pauly wrote:
> I would still urge people that a separate document on the Editorial
> Stream would make most sense here if you want to have text
> enumerating the values and principles of RFCs.
My comment: "principles of RFCs" seems an odd phrase to me.
IIUC, the set of principles Mike was trying to describe were
intended to be associated with the RFC series as an entity
and not with the text of every RFC or any specific RFC. (If
that's also what you meant that's fine but if you meant some
different thing, that might be interesting.)

My question: why would you (or others) urge us to punt on an
attempt to write down such principles? I honestly don't see
any net benefit in that but definitely do see risks. (I also
do see that it might involve some more possibly contentious
discussion when the group expected to be done but as already
said, maybe we're better off understanding the shape of the
rift rather than papering over what are not cracks.)

Thanks,
S.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Nov 2021 13:04:46 +1300

Stephen,

On 14-Nov-21 12:30, Stephen Farrell wrote:

Cutting to the chase:
  
> attempt to write down such principles? 

I can't speak for Tommy, but my view is that we (this particular
IAB Program) should finish our job, which includes proposing the
creation of the perfect forum to draft, debate, and reach rough
consensus on such principles.

> I honestly don't see
> any net benefit in that 

The benefit is that we finish the work we were asked to do and
bring to an end the present interim situation.

> but definitely do see risks. (I also

I expect that instead of finishing our work with a -06 version
of the draft, that would sentence us to many months of doing
the job that the RSWG will be constituted to do. And I also
suspect that whatever outcome we reached, assuming it was blessed
by the IAB (the only party with current authority to do so),
would immediately become a topic for the RSWG anyway.

None of this changes my personal opinion, which is that I broadly
agree with Mike's draft. It should probably have been written
years ago, and I'd still very much like to see the reasoned
counter-arguments. But why should this be on the critical path for
the RFC Editor Model (Version 3)?

    Brian

---

From: Christian Huitema <[email-masked]>
Date: Sat, 13 Nov 2021 16:14:08 -0800

> would immediately become a topic for the RSWG anyway.

Agree.

> the RFC Editor Model (Version 3)? 

It should not. RFC have been published for 50 years, and several RFC 
Editors have been hired during that time, yet nobody until now felt a 
urgent need to write more than the very simple statements in RFC 8729 or 
RFC 5741. There was no apparent urgency in tying up the possible 
decisions of the RFC editors in the past, there is no more urgency in 
tying up the decisions of the RSWG in the future.

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 14 Nov 2021 00:24:24 +0000

Hiya,

> would immediately become a topic for the RSWG anyway.

Ok, I think I kinda get that, but don't agree with you
about it. ISTM a bad plan to only try agree the next
set of bureaucratic rules while ignoring what seems like
a real set of differences of opinion as to the principles
we ought associate with the RFC series

> the RFC Editor Model (Version 3)?

Because we have real divergences of opinion among well
meaning significant contributors. (And I do not mean we
have "two sides" - there are more.)

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 14 Nov 2021 00:27:09 +0000

Hiya,

On 14/11/2021 00:14, Christian Huitema wrote:
>> till very much like to see the reasoned
> It should not. 

We disagree.

> RFC have been published for 50 years, and several RFC 

The above is true. But we've afaik only had one rfc editor
who resigned at least in part as a result of the effects of
the set of differences in opinion I mentioned in my last
mail. So without blaming anyone for that having happened,
I don't think business-as-usual describes the situation.

Cheers,
S.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Nov 2021 13:37:22 +1300

Stephen,

below...

> I don't think business-as-usual describes the situation.

It doesn't. But my understanding of our job here is to create
a forum in which such differences in opinion can be resolved,
rather than to resolve them.

    Brian

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 14 Nov 2021 00:51:17 +0000

Hiya,

On 14/11/2021 00:37, Brian E Carpenter wrote:
> 
> my understanding of our job here is to create

Fair enough. Having been on the IAB when this programme was
chartered, I can say that's not my impression. That said, it
is also true that I don't recall there being an explicitly
agreed take on the above (within the IAB or more broadly)
at that time.

I'd also note that I don't recall this programme having had
any discussion about enabling the RSWG to be successful in
such discussions. So if that were (part of) our purpose then
we've not yet considered that goal I think. (*)

Instead, I think we were expected to make progress on the
substance of resolving the various conflicting positions,
and work remains on that (that could be achieved if we had
a set of agreed, documented, principles for the series
perhaps).

Cheers,
S.

(*) I'm not disparaging what has been done by the programme
so far - figuring out a new and more sensible setup for the
RPC vis-a-vis the R(C)SE and community was absolutely
necessary and I think has mostly been well achieved without
so far having succeeded in reconciling the differing sets of
opinions that do seem to exist wrt principles.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 13 Nov 2021 20:00:57 -0500

From where I sit, the structure of the forum we are creating, and the 
restriction / permissions on the parts of it, assume some form of 
agreement on principles.

If, as now appears, we do not agree on those principles, then creating 
that forum seems to be counter-productive.

To take it a step further, having that forum decide anything other than 
these principles, once it is created without them, would appear to be a 
recipe for disaster and conversations based on differing unstated 
assumptions.

Claiming we have successfully completed our task here when we have 
created such a setup seems to be at best misleading to those who tasked us.

I happen to think that Mike's proposals are a good start.  I think it is 
even more important to actually face the issues.  Saying "but, but, we 
were almost done..." misses the point.

Yours,
Joel

---

From: Tommy Pauly <[email-masked]>
Date: Sat, 13 Nov 2021 18:30:51 -0800

Hello,

I agree with Brian and Christian’s point that this discussion about principles does not need to block the definition of the RFC Editor Model v3.

Speaking as a current IAB member, we have a purely practical matter at hand about how to organize the responsibilities of the RFC editor. We have an interim RFC editor whose time and service we need to respect by making good progress in this group. If we have any points here that will change substantially the requirements for how the various new bodies are organized, then we should tackle them in this document.

However, the topics being discussed here—while valuable to discuss—do not seem to change the structure of the RFC Editor Model. Instead, these principles are guidelines and advice that could be imparted upon and discussed with the bodies established by the v3 model document. This is something this program can choose to take on, or can be a task done with the newly formed bodies.

I would also note that this program does not need to reconcile all disagreements in perspectives on the RFC series. Rather, it is about coming to community consensus on the RFC editor model. If we can come to an agreement, as we have, on how to organize the RFC editor model, the program will have succeeded—even if there remain disagreements about how to describe the virtues and faults of the RFC series itself, or disagreements about how the series should evolve. We do not need to chart out the entire future of the series now. Instead, the task is to ensure that it has a structure in which it can continue effectively into the future. 

Best,
Tommy

> On Nov 13, 2021, at 4:51 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
>

---

From: John C Klensin <[email-masked]>
Date: Sat, 13 Nov 2021 21:35:31 -0500

--On Sunday, November 14, 2021 13:37 +1300 Brian E Carpenter
<[email-masked]> wrote:

>>>> counter-arguments. But why should this be on the cr
>>>> itical path for the RFC Editor Model (Version 3)?
>>> 
>>> It should not.
>> 
>> We disagree.
>> 
>>> Editors have been hired during that time, yet nobody until
>>> now felt a urgent need to write more than the very simple
>>> statements in RFC 8729 or RFC 5741. There was no apparent
>>> urgency in tying up the possible decisions of the RFC
>>> editors in the past, there is no more urgency in

Brian,

With the understanding that I think I am mostly, if not
entirely, in agreement with Stephen and I strongly agree with
Joel's conclusion:

	'I think it is even more important to actually face the
	issues.  Saying "but, but, we were almost done..."
	misses the point.'

let me address two of your comments.  

First, we've had lots of RFC Editors (title changes aside).
With the exception of Jon Postel, every one of them has taken
the job over from someone with similar authority and a very
similar role and has had advisors who could provide advice about
principles -- including criteria for success, which is not
explicitly on Mike's list-- and continuity with the previous
holder of the position.  With the exception of Bob Braden, each
of them had something of a transition period and/or some
opportunity to consult with their predecessors (in Bob's case,
he had Joyce Reynolds available and Joyce was a much larger part
of the Postel-era RFC Editor Function than most people then or
later have recognized [1].

If this group had concluded that the right path forward was to
stay with (but tune) the organizational structures and authority
relationships of the past, including retaining the principle of
a strong RSE, with more or less the same selection criteria that
led us to Heather (and vice versa), then, while Mike might
disagree, I wouldn't be feeling great urgency to write
principles down now either.  And, when the new RSE was in place,
I'd be in the front of the line begging Heather to talk with the
new appointee.

But we have made other decisions, decisions that are not only
not business as usual but that specify a catastrophic [2] set of
changes, with a very weak RSCE and the RSE function replaced by
two committees, increased autonomy and authority for the RPC,
and arguments about whether there is any ultimate authority and
who or what has it.   We also have not only failed to articulate
the principles about the Series (as distinct from principles
about openness and community participation and control) on which
we are making those decisions, we have not even articulated the
success criteria for the series and the new structures
(different from declaring ourselves done and hence successful).  

That worries me.  It interacts strongly with the questions of
how we determine that fundamental changes are needed to what we
have produced and then how to start a process that makes them.
Putting that back entirely onto the judgment of the IAB
contradicts one of the goals with which I thing this efforts was
started, i.e., getting the IAB out of the authority chain for
the Series except as a participating Stream. 

What would worry me even more would be our saying to the RSWG
"you get to determine whether you and/or the Series are
succeeding with no criteria other than who (or which faction)
can make the most noise" [3].  

>From a slightly different perspective, if we intend the RSWG to
be the forum in which decisions about the principles or success
criteria for the Series are to be developed and worked out, then
maybe we have serious overspecified many other things and should
just establish the RSWG and maybe the RSAB and let them sort
everything else out?  Should we, for example, really have spent
time concluding that there should be an RSCE and how that
position is defined rather than just telling the RSWG that maybe
the process might need some professional publications advice and
let them sort that out? I think we made the right decisions
there, but these principles and/or a clear definition of success
for the Series, are, IMO, actually more important so I think a
"kick it down the road and leave definitions of principle to the
future" decision would be a real failure on our part.

And, if the problem isn't that we don't want to spend time
writing principles down but that we have such profound
disagreements about what they are that we couldn't agree, then I
suggest there is no basis for reaching a conclusion about
whether this group has succeed and whether the draft(s) solve
the problem we set out to solve... and that the community should
reject them and us.  I don't think things are nearly that bad.
Do you?

 best,
   john

[1] IMO, for all the wrong reasons.

[2] I hope only in the mathematical sense.

[3] The history of working groups or equivalent saying,
especially when there are no success criteria going in, that
they have failed and need to be replaced is rather grim.

---

From: Martin J. Dürst <[email-masked]>
Date: Sun, 14 Nov 2021 17:49:11 +0900

> 2. Something a whole lot smaller that gets at the idea but without the detail

Having read everything in the thread up to now, my strong preference 
would be to have something like this, but a lot less verbose. The 
reasons have been pointed out in most detail by Carsten and John Klensin.

Without some kind of such principles, we essentially design process 
without a clear purpose. For some of the principles, such as English or 
Accessibility, I don't think there should be wide disagreement, and if 
ever the case comes that e.g. the language should be changed, I can't 
imagine that the okay needed from IAB and IESG (and LLC, but that should 
be restricted to funds issues) would actually create a higher barrier.

In my view, the situation is similar for the other principles. If we 
want to change the Diversity principle, then that would probably mean 
throwing out the IRE, IRTF, and possibly also the IAB stream(s). That 
won't happen very easily, because that would already mean we need IAB 
and IESG approval anyway.

Also, for speed vs. quality issues, if a change is desired, then quite 
surely if the IESG and the IETF isn't part of the deal, that won't 
happen, but if there's a consensus in the IESG and the IETF that that's 
needed, it will happen (at least for the IETF stream).

So either way (i.e. even without these principles), we should probably 
be able to keep things together.

But I'm quite definitely against the idea of the RSWG's first job being 
to write down such principles. If we can't manage to write them down 
now, we shouldn't think it would be easy for the RSWG. And it wouldn't 
be very easy to invite people to the RSWG by telling them their first 
job is to try to figure out why they are here.

Regards,   Martin.

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 14 Nov 2021 11:13:02 -0000

Thanks Martin, that's clear (to me).

I'm trying to imagine myself applying for the job of RSCE (for the avoidance of doubt, I will NOT be applying for that job). I would want to know the parameters of the job, and one of those would be "What is the RFC Series?" 

While it s possible to give high-level definitions such as those currently in draft-iab-rfcefdp-rfced-model-05, those descriptions are superficial. I don't mean that in any derogatory sense, but they are general scoping statements of which the most detailed is:

   The Request for Comments (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.

So, a cautious candidate would ask, perhaps at interview, "What are the guiding principles for the series, and where are these written down?" I'm not sure that we could provide and answer at the moment, and I would be very nervous about taking the job under those circumstances.

Yet, as I understand it, one of the roles of this program is to enable us to move on with recruiting an RSCE. I think it was Tommy who said that we should not presume on the time and energy of the iRSE, so surely we should get on with the tasks necessary to smooth the way.

And to pick up on what Nevil said, there should be no fear that writing this down makes it permanent. It is simply a statement of where we are today with the understanding that any changes can be effected by the RSWG. But if we don't write it down, we will fall immediately into arguments about whether any changes are, in fact, changes. If you want to see the RSWG fall at its first attempt to do anything, then I think not writing down the foundational principles would be a good way to go about it.

Cheers,
Adrian

-----Original Message-----
From: Rfced-future <[email-masked]> On Behalf Of Martin J. Dürst
Sent: 14 November 2021 08:49
To: Brian Rosen <[email-masked]>; Michael StJohns <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rfced-future] RFC Principles - long delayed

Regards,   Martin.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 14 Nov 2021 15:08:42 +0000

Hi Tommy,

On 14/11/2021 02:30, Tommy Pauly wrote:
> we have a purely practical matter at hand
> about how to organize the responsibilities of the RFC editor. We have an interim
> RFC editor whose time and service we need to respect by making good progress in
> this group

Just to note that Adrian's answer wrt this reflects what
I'd have said, so no need for me to repeat that:-)

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 14 Nov 2021 16:15:45 +0100

> Yet, as I understand it, one of the roles of this program is to enable us to move on with recruiting an RSCE. I think it was Tommy who said that we should not presume on the time and energy of the…

As a point of information, Jay has said here that he believes he will be 
able to hire an RSCE.

Again, the chairs will be commenting on this matter Soon.  Until then, 
we listening.

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 14 Nov 2021 15:33:35 -0000

>> Yet, as I understand it, one of the roles of this program is to enable us to
>> move on with recruiting an RSCE. I think it was Tommy who said that we
>> should not presume on the time and energy of the iRSE, so surely we
>> should get on with the tasks necessary to smooth the way.
>

I'm glad to hear it and I don't doubt Jay's ability to run the process.

My point was, however, that I would expect an external (i.e., not familiar with the IETF) applicant to need/demand the information. I suppose that I might also not that someone familiar with the IETF might want to understand whether they would be expected to continue with the established processes as they view them, as others view them, or not at all.

A

---

From: Jay Daley <[email-masked]>
Date: Mon, 15 Nov 2021 12:17:45 +1300

> On 15/11/2021, at 4:33 AM, Adrian Farrel <[email-masked]> wrote:
> 

Yes, the flipside is that a candidate might look at a long list of principles set in stone and wonder if there is any scope for them to develop the series.  From that I conclude that the inclusion/exclusion of principles should not be a factor in considering the likelihood of getting the right candidates for the RSCE role.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 14 Nov 2021 23:50:36 +0000

Hi Jay,

On 14/11/2021 23:17, Jay Daley wrote:
> Yes, the flipside is that a candidate might look at a long list of
> principles set in stone and wonder if there is any scope for them to
> develop the series.
Two things. First, if you find a candidate who thinks RFCs
are created via chisel, then I think the hiring decision in
that case will be easy:-)

Second and a bit more seriously, describing what some on
this list have proposed as resulting in something being
"a long list of principles set in stone" looks quite a lot
like taking a position in the debate. I'm guessing, as ED,
you didn't have that intent though.

Cheers,
S.

---

From: Jay Daley <[email-masked]>
Date: Mon, 15 Nov 2021 13:02:10 +1300

> On 15/11/2021, at 12:50 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Jay,
> 

No, as already stated I don’t think it’s appropriate for the LLC to have a view on this - This was intended to characterise how a candidate might take an adverse perspective so perhaps I could have used quotes to make that clearer.

Jay

> 
> Cheers,
> S.
> <OpenPGP_0x5AB2FAF17B172BEA.asc>

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

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

> I'm trying to imagine myself applying for the job of RSCE (for the avoidance of doubt, I will NOT be applying for that job). I would want to know the parameters of the job, and one of those would b…

I found myself wondering what we said when looking for the first external 
RSE in 2011. Not much, it turns out:

https://web.archive.org/web/20111006180950/https://www.rfc-editor.org/rse/RSE-Position-Description.html

Perhaps the candidates were given more details later in the process.

    Brian

> So, a cautious candidate would ask, perhaps at interview, "What are the 
guiding principles for the series, and where are these written down?" I'm 
not sure that we could provide and answer at the moment, and I would be very nervous about taking the job under those circumstances.
> 
> Yet, as I understand it, one of the roles of this program is to enable us to move on with recruiting an RSCE. I think it was Tommy who said that 
we should not presume on the time and energy of the iRSE, so surely we should get on with the tasks necessary to smooth the way.
> 
> And to pick up on what Nevil said, there should be no fear that writing 
this down makes it permanent. It is simply a statement of where we are today with the understanding that any changes can be effected by the RSWG. But if we don't write it down, we will fall immediately into arguments about whether any changes are, in fact, changes. If you want to see the RSWG fall at its first attempt to do anything, then I think not writing down 
the foundational principles would be a good way to go about it.
>>> I apologize for the delay in providing the following.  This is the aftermath of Stephen's question/comment about heritage and it morphed into a document that attempts to describe current RFC series principles.  I've

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Nov 2021 11:53:56 -0000

At the risk of going round and round, but hoping to clear some things before
the interim...

If our principles are set in stone, then surely documenting them will help
everyone.
If our principles are not set in stone then documenting them will not make
them more or less set in stone, only clearer.
In either case, documenting how the principles can be changed should help
candidates know (rather than guess) whether there is scope for developing
the series.

As Nevil pointed out, documenting principles does not mean that they cannot
be changed (indeed, the RSWG exists to do that as desired by the community),
but does document the starting point so that a change of principles is
properly considered and doesn't just drift through.

I appreciate that, as engineers (and would be lawyers ;-) we read a spec and
take it as a set of absolute rules. But we should have good understanding
that specs change, get revised, or get obsoleted as necessary and according
to agreement. We should not be afraid of writing down how things are today
so that we know what it is we want to change and recognise what changes we
are making.

It might be nice to see the push for a statement of the principles as a move
to be helpful, not a move to obstruct (I am not accusing anyone of thinking
anything). That is, if some people have a concern that recruitment might be
difficult or confused without the statement of principles, then see this as
a concern that needs to be addressed. Or, if other people see the absence of
a statement of principles as giving the RSWG unsound foundations because
they fear that the community will take a varied and conflicting set of
assumptions into the work, the consider that as a worry that also needs to
be addressed. It will not do to say, "I don't see that as an issue: move
on," or "You are worrying about nothing."

Cheers,
Adrian

-----Original Message-----
From: Jay Daley <[email-masked]> 
Sent: 14 November 2021 23:18
To: Adrian Farrel <[email-masked]>
Cc: Eliot Lear <[email-masked]>; [email-masked]
Subject: Re: [Rfced-future] RFC Principles - long delayed

> My point was, however, that I would expect an external (i.e., not familiar
with the IETF) applicant to need/demand the information. I suppose that I
might also not that someone familiar with the IETF might want to understand
whether they would be expected to continue with the established processes as
they view them, as others view them, or not at all.

Yes, the flipside is that a candidate might look at a long list of
principles set in stone and wonder if there is any scope for them to develop
the series.  From that I conclude that the inclusion/exclusion of principles
should not be a factor in considering the likelihood of getting the right
candidates for the RSCE role.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 15 Nov 2021 13:00:25 +0100

> properly considered and doesn't just drift through.

We are essentially setting up a charter for RSWG (and the gatekeeper body, RSAB).
Charters provide guide rails for a number of good reasons, the most important being to give chairs (and gatekeepers) a way to stop the group from wasting time.
If we can’t come up with consensus about those guide rails, we consider a BOF process failed.

Grüße, Carsten

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Nov 2021 04:21:02 -0800

> be changed (indeed, the RSWG exists to do that as desired by the

As I noted, the proposal Mike made had the purpose and effect of making
those
principles extremely hard to change; much harder than the other pieces of
the
series.

> so that we know what it is we want to change and recognise what changes we

There is a difference between how things are today as a descriptive matter
and how they ought to be as a prescriptive matter.  Mike's document
certainly
is of the latter type.

As MT noted, there are a number of deep divisions about how the RFC series
ought to evolve. The basic thrust of the work we have been doing is to
produce
a structure in which (1) we can discuss and potentially resolve those
differences
and (2) to make progress on topics where we do agree without those
differences
getting in the way. Requiring agreement  on a statement of principles --
which
will necessarily either be largely meaningless or require resolving those
differences --
does not seem likely to be successful.

-Ekr

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Nov 2021 12:27:56 -0000

Eric,

I don’t think you should ascribe motivations (purpose) from the end result (effect). I don’t find Mike’s text says that anything is extremely hard to change, only that making such changes requires conscious action.

I also don’t see how “evolution” can be conducted unless you know where you are starting from.

A

From: Eric Rescorla <[email-masked]> 
Sent: 15 November 2021 12:21
To: Adrian Farrel <[email-masked]>
Cc: Jay Daley <[email-masked]>; [email-masked]; Eliot Lear <[email-masked]>
Subject: Re: [Rfced-future] RFC Principles - long delayed

On Mon, Nov 15, 2021 at 3:54 AM Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

As I noted, the proposal Mike made had the purpose and effect of making those

principles extremely hard to change; much harder than the other pieces of the 

series.

and how they ought to be as a prescriptive matter.  Mike's document certainly

is of the latter type.

ought to evolve. The basic thrust of the work we have been doing is to produce

a structure in which (1) we can discuss and potentially resolve those differences

and (2) to make progress on topics where we do agree without those differences

getting in the way. Requiring agreement  on a statement of principles -- which

will necessarily either be largely meaningless or require resolving those differences --

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Nov 2021 04:33:06 -0800

On Mon, Nov 15, 2021 at 4:28 AM Adrian Farrel <[email-masked]> wrote:

> Eric,
>
>
>
> I don’t think you should ascribe motivations (purpose) from the end result
> (effect). I don’t find Mike’s text says that anything is extremely hard to
> change, only that making such changes requires conscious action.
>

Well, his text specifically prescribes a heightened process for making
these changes ("strong consensus" + assent from IESG/IAB/LLC), so I think
it's reasonable to infer that the intent was to make them harder to change.
Mike should of course feel free to correct me if I'm wrong.

I also don’t see how “evolution” can be conducted unless you know where you
> are starting from.

I'm not sure what you are getting at here. As I said before, there is a
distinction between descriptive and prescriptive. It's one thing to say
"RFCs are currently published in English" and quite another to say "RFCs
should be published in English and that should be hard to change"

-Ekr

>
> A
>
>
>
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* 15 November 2021 12:21
> *To:* Adrian Farrel <[email-masked]>
> *Cc:* Jay Daley <[email-masked]>; [email-masked]; Eliot
> Lear <[email-masked]>

---

From: John C Klensin <[email-masked]>
Date: Mon, 15 Nov 2021 12:17:07 -0500

--On Monday, November 15, 2021 13:53 +1300 Brian E Carpenter
<[email-masked]> wrote:

>> I'm trying to imagine myself applying for the job of RSCE
>> (for the avoidance of doubt, I will NOT be applying for that
>> job). I would want to know the parameters of the job, and one
>> of those would be "What is the RFC Series?"
> 
> 
> I found myself wondering what we said when looking for the
> first external RSE in 2011. Not much, it turns out:
> 
> https://web.archive.org/web/20111006180950/https://www.rfc-edi
> tor.org/rse/RSE-Position-Description.html
> 

Brian,

As you guessed, they were.  I can't remember how much of it was
spontaneous, but, in my capacity as a participant in the
recruiting and selection processes, I remember several people
I/we were trying to get to apply for the position asking
questions for which the sort of principles we are talking about
were the answer.  As I mentioned in one of my earlier notes, we
were able to answer those questions because the RSE was stepping
into a Series and system that had been running for many years
with the same general principles (oral or not and with
considerable evolution of procedures and policies).  I even got
a piece of free advice from someone who was nearing retirement
from the senior publications position at another SDO who I
thought might be talked into a part time position.  It was that
we should probably reject out of hand, or at least be very
suspicious of, anyone who applied who didn't ask those sorts of
questions.  

A decade ago, having the members of the group doing recruitment
and selection  just answer those questions made sense and was
fairly safe.  The new RSE was expected to maintain continuity
with a well-established way of doing things or to be sure there
was extraordinary community involvement and consensus about
major changes.  In retrospect, I wish we had written things
down, but the widely shared tradition seemed fine at the time.  

So, again, this effort is a disruptive change (or set of them).
We cannot rely on the years of experience and broadly shared
consensus we had (or thought we had) a decade or more ago for
answering candidate questions.  Getting principles written down
is likely to help in the RSCE recruitment and selection process
(assuming we care) and to provide the RSWG guidance about the
boundary between ordinary policy and decision-making and things
that are A Big Deal --not to prevent future changes but to
increase the odds that proposed major changes in direction will
be recognized by the RSWG and the community.

Finally, before writing this, I looked at Section 5 of
draft-iab-rfcefdp-rfced-model-05.  It is quite thorough about
what the RSCE is expected to do.  However, especially with the
cited material at
https://github.com/intarchboard/program-rfced-future/blob/master/Issue12-RSE-role.md
basically not saying anything (as well as being outdated), it is
rather thin on both qualifications for the position and
explanation of the fundamental nature of the Series.  If we are
satisfied that the members of the selection committee will have
enough publication experience themselves as well as the same
sort of understanding of the community consensus on these issues
we had a decade ago, that is probably ok ... but, if we don't
have enough consensus among ourselves to agree about principles,
the latter seems extremely unlikely and we had best reopen that
section and start writing.

best,
   john