Subject: [Rfced-future] Poll: next steps

From: Eliot Lear <[email-masked]>
Date: Fri, 19 Nov 2021 17:58:27 +0100

Dear Colleagues,

The chairs would like to make clear the following points:

 1.

    There is no consensus to include in the draft the principles that
    have been proposed.

 2.

    There is no consensus for the document as it stands to move forward.

 3.

    There are a lot of entrenched views, and rough consensus is the
    basis of our decision making.

 4.

    For the document to go forward, some compromise will be required.

The question for us now is what sort of text to include.  Joel’s 
proposal is interesting.   Some people who do not want principles in the 
document have indicated that they do not have strong objections to this 
text. Do others agree that this text is a good place to start?

If people agree, we note that Joel’s text would need to be accompanied 
by someprinciples, and the discussion would then turn to what those 
would be.

If people disagree, we would invite other approaches as a next step.

Could you please respond by Tuesday?

Brian and Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Nov 2021 17:05:28 +0000

Hiya,

> text. Do others agree that this text is a good place to start?

Yes.

> If people disagree, we would invite other approaches as a next step.

I do agree that if we started with Joel's text, then
formulating a short, minimal set of very briefly
described principles would be a good next step. I'd
hope we'd aim for all of that to be something like a
half-page long or so.

> Could you please respond by Tuesday?

Sure:-)

Cheers,
S.

PS: I also like the text Christian suggested (other than
"lightly" which seemed a bit weak) so if that text were to
accompanied by a short list of principles, that could work
for me too.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 19 Nov 2021 18:21:07 +0100

Just for information, Joel's text now at the bottom.

On 19.11.21 17:58, Eliot Lear wrote:
> proposal is interesting.   Some people who do not want principles in 
> the document have indicated that they do not have strong objections to 
> this text. Do others agree that this text is a good place to start?
>
>
Joel's text:

>     The following principles are understood to be important to
>     the RFC series.  When reviewing documents from the RSWG that
>     either change these principles, or significantly change the
>     way they are realized, the RSAB members are expected to pay
>     particular attention to
>     a) whether the changes adversely affect the long term health
>         of the RFC series; and
>     b) whether the changes have received sufficient review and
>         comment in the larger community affected by the RFC Series

---

From: Christian Huitema <[email-masked]>
Date: Fri, 19 Nov 2021 10:30:17 -0800

On 11/19/2021 9:21 AM, Eliot Lear wrote:
>> the document have indicated that they do not have strong objections 
>> to this text. Do others agree that this text is a good place to start?
>>
>>
>> If people agree, we note that Joel’s text would need to be 
>> accompanied by someprinciples, and the discussion would then turn to 
>> what those would be.
>>
>>

I would propose an amendment. Instead of "The following principles are 
understood to be important to the RFC series" I would insert a variant 
of the text that I proposed before:

The basic principles of the series are listed in the first paragraph of 
{{#introduction}} and have been followed for 50 years. When reviewing 
documents from the RSWG that  either change these principles, or 
significantly change the  way they are realized, the RSAB members are 
expected to pay  particular attention to

     a) whether the changes adversely affect the long term health of the 
RFC series; and
     b) whether the changes have received sufficient review and comment 
in the larger community affected by the RFC Series

-- Christian Huitema

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 19 Nov 2021 14:18:04 -0500

This wording assumes that the answer to "what principles" is only the 
ones we adopted in passing earlier.  While that may be the answer we end 
u with, it seems a stretch to assume that before we discuss them.

Yours,
Joel

---

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

Below...

On 20-Nov-21 05:58, Eliot Lear wrote:
>     There is no consensus to include in the draft the principles that have been proposed.
> 
>  2.
> 
>     There are a lot of entrenched views, and rough consensus is the basis of our decision making.
> 
>  4.
> 
> The question for us now is what sort of text to include.  Joel’s proposal is interesting.   Some people who do not want principles in the document have indicated that they do not have strong objections 
> 
> 
> If people agree, we note that Joel’s text would need to be accompanied by someprinciples, and the discussion would then turn to what those would be.

If there is some compromise between Joel's and Christian's text, I would have no objection to proceeding in this way.

    Brian C

---

From: Michael StJohns <[email-masked]>
Date: Mon, 22 Nov 2021 12:57:09 -0500

On 11/19/2021 1:30 PM, Christian Huitema wrote:
> The basic principles of the series are listed in the first paragraph 
> of {{#introduction}} and have been followed for 50 years. When 
> reviewing documents from the RSWG that  either change these 
> principles, or significantly change the  way they are realized, the 
> RSAB members are expected to pay  particular attention to
>
>     a) whether the changes adversely affect the long term health of 
> the RFC series; and

The text you keep referring to taken as a limit would severely constrain 
the independent series ability to publish non-technical commentary.  It 
might also prevent publication of documents from various RGs that are 
more sociological than technical specification.  E.g. GAIA, HRPC are 
probably not publishing "internet technical specifications", nor are 
most of the various documents we use to manage ourselves in any way 
technical specifications.    So this formulation is wrong or at least 
incomplete.

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

---

From: Michael StJohns <[email-masked]>
Date: Mon, 22 Nov 2021 13:02:44 -0500

> this text. Do others agree that this text is a good place to start?
This is a place to start, not to end, and needs strengthening. As a 
minimum, the RSAB needs to be able to "reject" based on principles, 
simply not "pay particular attention to them" as his text reads.

E.g. RSAB: "We've paid particular attention and we believe this document 
harms the principles" RSWG:  "That's good, but we followed the process, 
so approve the document already".

> by someprinciples, and the discussion would then turn to what those 
One of the key items in my formulation (and I think hidden a bit in 
Joel's) is that principles are meta laws that are not generally subject 
to change within this process.  To use a fairly weak analogy, this 
document we're working on is a constitution, while the RSWG/RSAB will be 
writing laws subject to that constitution. Unlike say the process in 
California, changing the constitution should require a bit more work 
than a simple consensus of a small group of people, and the work of this 
group should not be able to be undone by the RSWG saying "we're 
replacing ED 1 with a new document and we followed the process".

> Could you please respond by Tuesday?

I went back and reviewed the bidding and I don't think that anyone 
adequately responded to either of Joel's or Stephens questions about how 
changes they want to make would brush up against principles.  I'm 
unlikely to get to even rough consensus without someone stepping up and 
answering those questions.

Later, Mike

---

From: Christian Huitema <[email-masked]>
Date: Mon, 22 Nov 2021 13:17:41 -0800

On 11/22/2021 9:57 AM, Michael StJohns wrote:
>>>> <snip>
Joel's text:
>> I would propose an amendment. Instead of "The following principles 
>> are understood to be important to the RFC series" I would insert a 
>> variant of the text that I proposed before:
>>
> The text you keep referring to taken as a limit would severely 
> constrain the independent series ability to publish non-technical 
> commentary.  It might also prevent publication of documents from 
> various RGs that are more sociological than technical specification.  
> E.g. GAIA, HRPC are probably not publishing "internet technical 
> specifications", nor are most of the various documents we use to 
> manage ourselves in any way technical specifications.    So this 
> formulation is wrong or at least incomplete.
>
Mike, I am not trying to put restrictions the independent series or the 
IRTF. On the other hand, I am trying to avoid writing up an essay on RFC 
principles, and as much as possible stick to text that was already 
agreed upon and published in previous RFC. The text in the draft's 
introduction was directly copied from RFC 8729, which itself copied it 
from RFC 5741, and is as close as possible to "already agreed upon 
principles."

I understand the fear that the RFC would evolve towards only publishing 
agreed upon standards, to the detriment of dissenting opinions and other 
sources of documents. This is not a new issue, and was in fact the 
motivation for RFC 1796 many years ago. I believe that the current draft 
provides specific guidelines against that, by embracing the current set 
of streams and ensuring their representation in the RSAB.

To your specific point, the definition of the RFC series as publishing 
as providing "Internet technical specifications" is ancient and, in my 
opinion, desirable. It is probably quite central to the state of the 
series. The April 1st RFC may be jokes, but they are specific kind of 
jokes, very much related to Internet specifications. The HRPC is not 
just about human rights in general, but about human right aspects of 
protocol considerations -- the charter says that its productions will 
include "internet drafts some of which may be put on IRTF RFC stream. 
These will concern progress of the project, methodology, and will define 
any possible protocol considerations." That seems well within the scope 
of "Internet technical specifications". The same can be said of pretty 
much every IRTF research group, including GAIA, whose potential 
recommendation on the energy footprint of Internet protocols fall very 
much within the scope of Internet technical specifications.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Nov 2021 10:58:45 +1300

On 23-Nov-21 07:02, Michael StJohns wrote:
>> The question for us now is what sort of text to include.  Joel’s proposal is interesting.   Some people who do not want principles in the document have indicated that they do not have strong objections to this text. Do others agree that this text is a good place to start?
>>
> This is a place to start, not to end, and needs strengthening. As a minimum, the RSAB needs to be able to "reject" based on principles, simply not "pay particular attention to them" as his text reads.

If the community, at some point in the future, wants to overturn a basic principle, they will do so. If they have to, they'll do so by abolishing the RSAB, just as the community of today has effectively decided to abolish the RSE, RSAG (again) and RSOC (like the IETF did in 1992, by drastically reducing the authority of the IAB). I don't see what we gain by setting the RSAB up for a fall.

> 
> E.g. RSAB: "We've paid particular attention and we believe this document harms the principles" RSWG:  "That's good, but we followed the process, so approve the document already".
> 
>>
> One of the key items in my formulation (and I think hidden a bit in Joel's) is that principles are meta laws that are not generally subject to change within this process.  To use a fairly weak analogy, this document we're working on is a constitution, while the RSWG/RSAB will be writing laws subject to that constitution. Unlike say the process in California, changing the constitution should require a bit more work than a simple 
consensus of a small group of people, and the work of this group should not be able to be undone by the RSWG saying "we're replacing ED 1 with a new document and we followed the process".

The analogy to the US concept of a constitution has been obvious to me for some time. That doesn't mean it's the right way to go. A constitution that is too hard to change can easily become a liability.

      Brian

> I went back and reviewed the bidding and I don't think that anyone adequately responded to either of Joel's or Stephens questions about how changes they want to make would brush up against principles.  I'm unlikely to get to even rough consensus without someone stepping up and answering those questions.
> 
> Later, Mike
> 
> 
>>
>>
>> Brian and Eliot

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Nov 2021 16:54:17 -0700

On 11/19/21 12:18 PM, Joel M. Halpern wrote:
> ones we adopted in passing earlier. 

Clarifying question: what are "the ones we adopted in passing earlier"?

Peter

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 22 Nov 2021 19:10:46 -0500

I am sorry if my phrasing suggested something other than my intent.
We adopted introductory text, and you captured it.  We did not discuss 
whether those were principles, descriptions, complete or incomplete, or ...
Now, some folks are saying those are the principles, and we should not 
discuss adding any others.
That seems to me an odd sequence of argumentation.

Yours,
Joel

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Nov 2021 17:30:32 -0700

Thanks for the clarification.

> That seems to me an odd sequence of argumentation.

I'll reiterate what I've said before: I think it is safest and best to 
incorporate only those "principles" (if we want to call them that) which 
were present in previous versions of the RFC Editor Model (RFC 5620, RFC 
6635, RFC 8729) and related documents (e.g., RFC 8729). By adding new 
principles, we're going beyond what was deemed necessary for previous 
versions of the RFC Editor Model and, I believe, beyond the remit of 
this Program. Personally I don't think the advocates for adding more 
principles at this time have provided great arguments for doing so, and 
I think that adding more principles should be done following the process 
we're setting up (RSWG/RSAB/etc.), not as a precondition to establishing 
that process.

Peter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Nov 2021 19:57:01 -0500

I would disagree.  There are significant principles that were accepted 
and assumed, but not written into those documents.  Maybe they should 
have been, but changing history is outside our capabilities.

I expect that some of those principles are things that people want to 
change.   But that does not mean they were not accepted principles of 
the series.

 From a more pragmatic perspective, there are a number of us taht feel 
that discussing those principles, and writing down the ones we can agree 
on, would be helpful for the resulting RSWG process.   There are others 
who disagree.
I do not see that pointing to "what we wrote before" helps find equity.

Yours,
Joel

On 11/22/2021 7:30 PM, Peter Saint-Andre wrote:
>>>> This wording assumes that the answer to "what principles" is only 
>>>> the ones we adopted in passing earlier. 
>>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Nov 2021 18:23:17 -0700

> change.   But that does not mean they were not accepted principles of 

Unfortunately, we have no way, post facto, to determine what was an 
implicitly accepted principle of the series at some point or points in 
the past, nor by whom (I'd assume that there might have been just as 
much disagreement in the past as there is now).

> I do not see that pointing to "what we wrote before" helps find equity.

Although I'm not sure what "equity" means in this context, I would posit 
that "what we wrote before" at least gets us closer to what was accepted 
at that time than a post-facto mind-reading exercise - and also gets us 
closer to consensus in the here and now (regarding the process issues 
that are clearly within the remit of this Program) than trying to reach 
agreement on a set of policy-guiding principles that are a source of 
significant contention and show no sign of becoming less contentious.

 From an even more pragmatic perspective, we don't have forever here: 
the current arrangement (with a Temporary RFC Series Project Manager 
whose contract expires in March 2022, not to mention a lame-duck RSOC 
and an IAB that could lose patience with us if progress grinds to a 
halt) is unsustainable and I think it's incumbent upon us to proceed 
with all due speed to concluding our work on the process definition, 
leaving policy definition to the RSWG/RSAB.

But I repeat myself.

Peter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Nov 2021 20:38:59 -0500

I wonder if the time argument is misleading.

If we do not agree on the principles, I have trouble seeing how the 
interview process can actually describe what the series being advised by 
the RSCE actually is.    To take an extreme example, an advisor advising 
a wiki-based dynamic description of ongoing work is a very different 
task than an advisor advising the historic RFC series.

So it seems likely even if we declare ourselves "done" (which I hope we 
don't) that we will promptly have to have the debate in the RSWG before 
we can begin searching for the RSCE.

Yours,
Joel

On 11/22/2021 8:23 PM, Peter Saint-Andre wrote:
>> that discussing those principles, and writing down the ones we can 
>> agree on, would be helpful for the resulting RSWG process.   There are 
>> others who disagree.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 23 Nov 2021 12:38:40 +1100

On Tue, Nov 23, 2021, at 12:23, Peter Saint-Andre wrote:
> I would posit that "what we wrote before" at least gets us closer to what was accepted 
> at that time than a post-facto mind-reading exercise 

I would be comfortable with taking existing text (such as what we already have) on the basis that it is "agreed", provided that we recognize that any previous agreement does not constrain the execution of this process aside from it being necessary to ensure that changes are purposeful.  It's OK to emphasize that these are things we believe to be important and that particular attention be paid to them.  It's OK to insist that changes that relate to principles be explicitly acknowledged as such, so that we are sure that the choice is deliberate and not accidental.  It's not OK to further protect things behind unspecified processes.

No matter what might have been agreed at some time in the past, if we (collectively as a community) deliberately and explicitly decide to change a principle, then that change needs to follow the process we've defined in this document.  Not some as-yet-unspecified process.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Nov 2021 20:43:10 -0500

I can not tell from your wording whether the description I provided for 
extra attention to changes of principle does or does not fall within 
what you consider acceptable.

Yours,
Joel

---

From: Jay Daley <[email-masked]>
Date: Tue, 23 Nov 2021 14:48:26 +1300

> On 23/11/2021, at 2:38 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> If we do not agree on the principles, I have trouble seeing how the interview process can actually describe what the series being advised by the RSCE actually is.    To take an extreme example, an advisor advising a wiki-based dynamic description of ongoing work is a very different task than an advisor advising the historic RFC series.
> 
> So it seems likely even if we declare ourselves "done" (which I hope we don't) that we will promptly have to have the debate in the RSWG before we can begin searching for the RSCE.

I don’t see this as relevant to the RSCE employment process.  There are multiple de facto characteristics of the RFC series that can be explained to candidates whether or not they are encoded as de jure principles.  

Jay

>>> I would disagree.  There are significant principles that were accepted and assumed, but not written into those documents.  Maybe they should have been, but changing history is outside our capabilities.
>>> 
>>> I expect that some of those principles are things that people want to change.   But that does not mean they were not accepted principles of the series.
>> Unfortunately, we have no way, post facto, to determine what was an implicitly accepted principle of the series at some point or points in the past, nor by whom (I'd assume that there might have been just as much disagreement in the past as there is now).
>>>  From a more pragmatic perspective, there are a number of us taht feel that discussing those principles, and writing down the ones we can agree on, would be helpful for the resulting RSWG process.   There are others who disagree.
>> Although I'm not sure what "equity" means in this context, I would posit that "what we wrote before" at least gets us closer to what was accepted at that time than a post-facto mind-reading exercise - and also gets us closer to consensus in the here and now (regarding the process issues that are clearly within the remit of this Program) than trying to reach agreement on a set of policy-guiding principles that are a source of significant contention and show no sign of becoming less contentious.
>> From an even more pragmatic perspective, we don't have forever here: the current arrangement (with a Temporary RFC Series Project Manager whose contract expires in March 2022, not to mention a lame-duck RSOC and an IAB that could lose patience with us if progress grinds to a halt) is unsustainable and I think it's incumbent upon us to proceed with all due speed to concluding our work on the process definition, leaving policy definition to the RSWG/RSAB.
>> But I repeat myself.
>> Peter
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Nov 2021 14:54:14 +1300

On 23-Nov-21 14:38, Joel M. Halpern wrote:
> If we do not agree on the principles, 

I haven't seen any concrete evidence of that. I've seen evidence
that we don't agree on burning a specific set of principles into
a document about the organization of the RFC Editor function.

> I have trouble seeing how the

Why? We have the role description already, and it includes advising
the RSWG as well as the RPC. On the contrary, some advice from outside
our little world might greatly assist discussing and formulating the
principles.

     Brian

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 23 Nov 2021 14:06:37 +1100

> what you consider acceptable.

If you refer to https://mailarchive.ietf.org/arch/msg/rfced-future/4P2gFwXDMO8jD6r-RoQb1kvVSW4/ then that text is fine iff we accept that we need a statement of principles.  I've seen a lot of different emails on this subject and a number of them invoke undefined processes.  I have a problem with that.  As I have a problem with attempting to define principles that are not substantially a restatement of what has been documented previously.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 23 Nov 2021 09:43:21 +0100

Just as a point of information...

On 22.11.21 22:58, Brian E Carpenter wrote:
>
> The analogy to the US concept of a constitution has been obvious to me 
> for some time. That doesn't mean it's the right way to go. A 
> constitution that is too hard to change can easily become a liability. 

There are other analogies available, as well.  Articles of 
incorporation/bylaws is the obvious one.  The former change only due to 
paperwork snafus (apparently a not uncommon occurrence) or when the 
underlying purpose of an entity changes.  The latter tend to get 
reviewed more regularly.

And maybe that's a good way forward: agree on what can be agreed now, 
and then regularly review whether there is more to agree on.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Nov 2021 10:26:02 -0500

--On Tuesday, November 23, 2021 14:48 +1300 Jay Daley
<[email-masked]> wrote:

>> So it seems likely even if we declare ourselves "done" (which
>> I hope we don't) that we will promptly have to have the
>> debate in the RSWG before we can begin searching for the RSCE.
> 
> I don't see this as relevant to the RSCE employment process.
> There are multiple de facto characteristics of the RFC series
> that can be explained to candidates whether or not they are
> encoded as de jure principles.  

Jay,

Having gone through the RSE selection process and been involved
in even earlier discussions about "permanent" and interim RFC
Editors, I share Joel's concern.  I would also agree with you
about de facto characteristics, but many (perhaps most) of what
would be on my list of those are precisely ones I'd like to see
identified now as "if you considering changing these,
extraordinary attention and review is required" (note that I
avoided the term "principle" -- the term itself seems to prompt
too much controversy.

So, for the benefit of those of us who think such guidance is
needed, because it might be an alternate starting point from
Mike's list, and to help me figure out whether I should drop my
concerns about the RSCE recruiting process, could you enumerate
what de facto characteristics to which you refer?

thanks,
    john

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Nov 2021 11:25:59 -0500

--On Tuesday, November 23, 2021 09:43 +0100 Eliot Lear
<[email-masked]> wrote:

>...
> And maybe that's a good way forward: agree on what can be
> agreed now, and then regularly review whether there is more to
> agree on.

Eliot,

If the later "regular review" remains within the duration of
this Program, I would have no problem with that... at least as
long as we don't put off things that are key to apparent
present-time agreement.

But that is close to a concern I've expressed before.   I don't
want the new process to fail, whether in the RSWG/RSAG setup or
in getting issues addressed and getting new RFCs out the door.
I hope we are all in agreement about that.  But should it fail,
I want that to be an efficient and obvious as possible rather
than a long downhill slide in which things gradually go more and
more wrong and people argue that we should just keep doing
whatever we have been doing because we have been doing it for a
year or more.  In the latter case, because the sky didn't fall
and this process of starting from scratch --apparently without
even agreement about first principles about the Series--  is
very painful, it is easy to predict arguments that we should
just adjust to the pain and keep going.

I also note the combination of the deadline imposed by the
expiration date for John Levine's contract and that he has has
been prohibited by that agreement from making strategic
decisions.   I hope he is compiling a list of things that need
resolution as soon as there is a mechanism for doing so and
assume that list is not zero-length.

>From that perspective, one of the worst things we could do to
both the Series and the RSWG would be to say "well, we know
there are a long list of tactical/ operational issues that need
attention but first you should go off an try to establish
principles, principles about which there is evidence of deep
divisions in the community".  

So, whether the foundation is Mike's proposal, something derived
from Joel's, an attempt to write down the oral tradition
accepted by more than two decades of editorial/operational
advisory groups, something built on Jay's "de facto
characteristics", or something else, I think it would be better
to tell the RSWG (in some vocabulary) "this is the accepted
wisdom, please try to make decisions within those guidelines,
and, if you conclude changes are needed to it, do that very
carefully and with the understanding that you are entering at
least partially uncharted territory with which the community has
little experience.

   john

---

From: Eliot Lear <[email-masked]>
Date: Tue, 23 Nov 2021 17:38:25 +0100

Hi John,

Two points:

> long as we don't put off things that are key to apparent

Without going into contortions about how this program would exist if the 
remit shifts from the IAB, I'll just clarify that I meant that somehow 
some review would get performed from time to time, once the RSWG/RSAB 
kicked off.  I believe you yourself suggested something akin to this 
some time ago, if I'm not very much mistaken.

> assume that list is not zero-length.

One thing that I believe is outside the scope of our charter is worrying 
about John's contract.  I think we all understand the situation and 
would like to be finished sooner rather than later, so that we can have 
a permanent situation.  But like all other processes in this 
organization, it will complete in its own time.

Given these two points, does that change your views one way or another?

Eliot

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Nov 2021 09:54:03 -0700

> we can begin searching for the RSCE.

In the past we conducted searches for an RSE - which was a much broader, 
more policy-making role than the RSCE - without having a set of 
principles beyond what's in previous versions of the RFC Editor Model 
(RFC 5620, RFC 6635) and related documents (e.g., RFC 8729). And in this 
Program we've designed a process model that has many more checks and 
balances (community consensus via the RSWG, stream consensus via RSAB, 
etc.). Thus I remain confused as to why some folks feel the need for a 
set of principles right now. Do they think that there are greater risks 
(and for what?) under our proposed version 3 of the RFC Editor Model 
than under version 1 and version 2? There have been an awful lot of 
messages in these threads so perhaps I've missed the ones containing a 
risk assessment - pointers welcome.

Peter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Nov 2021 12:04:50 -0500

When we hired the RSE, a noticeable part of the interview process was 
answering quesitons about the RFC Series and our hsitory with it.  We 
could do this based on the goal that the hirign was to continue the 
series as it had been.

In contrast, a number of folks have made it quite clear that they do not 
want things to simply continue as they have been.  If they were happy 
with the current practices, we could write down the principles, agree 
that they need a higher bar to change, and be off to the races.

Yours,
Joel

On 11/23/2021 11:54 AM, Peter Saint-Andre wrote:
>> interview process can actually describe what the series being advised 
>> by the RSCE actually is.    To take an extreme example, an advisor 
>> advising a wiki-based dynamic description of ongoing work is a very 
>> different task than an advisor advising the historic RFC series.
>>
>> So it seems likely even if we declare ourselves "done" (which I hope 
>> we don't) that we will promptly have to have the debate in the RSWG 
>> before we can begin searching for the RSCE.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 Nov 2021 17:08:34 +0000

>    In contrast, a number of folks have made it quite clear that they do not 
    want things to simply continue as they have been.

That is very different from my impression. Which is, a number of folks are quiet clear that they want the current principles written down so that we don't stray from them.

Changing things -- or, "not simply continue as they have been" -- is a much bigger issue.  I know this is a difficult ask, but could you link to any examples of that?

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Nov 2021 10:19:32 -0700

On 11/23/21 10:04 AM, Joel M. Halpern wrote:
> answering quesitons about the RFC Series and our hsitory with it. 

Of course. We can't capture everything in a document and I'd expect 
someone coming in fresh to our community to have plenty of questions 
about the RFC Series and our history with it, even if we write down all 
the principles.

But in general I feel that you haven't answered my questions.

What are the risks that people have in mind within the context of the 
model and process we've defined, and how will writing down a set of 
principles help us manage those risks?

Peter

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Nov 2021 18:50:19 -0500

--On Tuesday, November 23, 2021 09:54 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>> If we do not agree on the principles, I have trouble seeing
>> how the  interview process can actually describe what the
>> series being advised by  the RSCE actually is.    To take
>> an extreme example, an advisor advising  a wiki-based dynamic
>> description of ongoing work is a very different  task than an
>> advisor advising the historic RFC series.
>> 
> In the past we conducted searches for an RSE - which was a
> much broader, more policy-making role than the RSCE - without
> having a set of principles beyond what's in previous versions
> of the RFC Editor Model (RFC 5620, RFC 6635) and related
> documents (e.g., RFC 8729).

Peter,

That would be a very strong argument if it were true, but it is
not.  The search and selection process that led to Heather's
appointment0 was conducted by a committee, all, or almost all,
of whose members had long experience with the RFC Editor process
including serving in an advisory role to previous RFC Editors.
My recollection --Joel can check me on this -- is that the IAB
was quite explicitly aware of those backgrounds and expected us
to use them.  Candidates were asked questions, and questions
they asked were answered, on the basic of that knowledge ("oral
tradition" if you like that term) and the actual selection
criteria included them.

To the extent to which the "Editor Model" RFCs were useful, only
RFC 5620 counts -- the others were prepared after she (and for
that matter, Glen Kowack) were selected.  In the case of Olaf
(before Heather) and John Levine (now), the job description was,
more or less "we have an existing and working system, keep the
train moving and on the tracks".   I don't remember the details
of Glen Kowack's selection, but I am quite sure that the same
case of characters were heavily involved and drawing on the same
experience and skills.   And Bob Braden was more or less
selected by USC-ISI after Jon Postel (who was more or less
self-selected) passed away, long before any of the "Model"
documents, or even RFC 4844, were published.

> And in this Program we've designed
> a process model that has many more checks and balances
> (community consensus via the RSWG, stream consensus via RSAB,
> etc.).

Sticking to the "appoint an RSCE" question, AFAICT, none of
those checks and balances apply because the procedure is, more
or less, that the LLC will carry out a process of its choosing
and hire or contract with someone.  That is another reason I'm
curious about Jay's list of "de facto characteristics", since
that list may determine whether we need to say more in that
section of the document.

> Thus I remain confused as to why some folks feel the
> need for a set of principles right now. Do they think that
> there are greater risks (and for what?) under our proposed
> version 3 of the RFC Editor Model than under version 1 and
> version 2?

In a word, "Yes".  As I have tried to say before, the
interpretation and actions under the previous versions were,
until things broke down, informed by a long-established and
working process, one that was well-understood by key people
advising the RFC Editor/ RSE as well as by that officeholder.
Unlike RFCs 4844 and 4846 (which actually made a few significant
changes consequent of the move from ISI the the IETF community),
Model versions 1 and 2 (and RFC 4845) were largely descriptions
of existing practice, not significant innovations.  

By contrast, no matter how much consensus there is that it is
the right thing to do (or try), version 3 takes us out into
untested territory.  The RSWG and RSAB are new and we have no
experience with either, especially with a working group that
makes nearly final decisions but that lies outside the usual
IETF process.  The IESG rarely (I hope never) charters a WG,
especially a technical WG expected to produce standards track
document, without having a clear idea about how its work will be
evaluated and a conviction that the community has the expertise
needed to do so.   Along with many others, I personally believe
that the model outlined in your v3 Model document will work, but
that does not mean we have adequate experience for that to be a
prediction made with great confidence, so much confidence as to
believe that the RSWG will be able to sort out issues this
Program has tried to ignore... or said "we never needed XYZ
before" when, before, circumstances were significantly different.

> There have been an awful lot of messages in these
> threads so perhaps I've missed the ones containing a risk
> assessment - pointers welcome.

The above is not exactly a risk assessment, but maybe it will
help.

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Nov 2021 21:45:47 -0500

> Without going into contortions about how this program would
> exist if the remit shifts from the IAB, I'll just clarify that
> I meant that somehow some review would get performed from time
> to time, once the RSWG/RSAB kicked off.  I believe you
> yourself suggested something akin to this some time ago, if
> I'm not very much mistaken.

I did and I still believe that.  But I think the present issue
is about something different.   

First, let me draw a distinction using an analogy that isn't
very good but that might be helpful.  In the IETF, if something
or someone appears to be going off the rails, we have three
different types of review mechanisms.  One is a "regular review"
known as "tell it to the Nomcom".  Opinions differ about how
effective that is under different circumstances, with the recent
discussions of term limits and special procedures or guidelines
about incumbents as symptoms.  There is, by definition, no such
review for RSWG participants and I suggest that mechanism would
not work in practice for RSWG members, even those appointed by
the Nomcom (can you imagine an AD who has done a good job in
that role being involuntarily retired because of unhappiness
about the RSAG?).  

It is for that purpose that I favor a periodic, but not too
frequent, review of the process. I'd rather settle, before we
declare ourselves finished, how the process for conducting such
reviews works _and_ require a special process for the RSWG/RSAG
to change it.  The reasons are not unlike changes to
"principles" although not directly related: unless the  review
is intended to start from the assumption that everything is fine
although fine tuning improvements are always possible and be
limited to that, having the RSWG/RSAB define the review process
is akin to allowing people to appoint the judges who will hear
their cases (especially if they also select the reviewers.

The second is a "did you mean that and did you really consider
all of the issues review about one or more particular decisions
which we, possibly incorrectly, call an appeal.  We have a
parallel mechanism in the RSAB sending something back to the
RSWG for further consideration.  Individual community member
cannot initiate such an "appeal".  I thing that is ok, but
wonder if enough people have thought about that analogy to make
agreement and consensus meaningful.

And the third is the notorious recall procedure which, IMO, has
ended up in a state in which it is almost possible to run to
conclusion.  Even if it worked as originally intended, it
presumably would not be invoked unless some very large lines (or
several little ones) had been crossed.  Although things are set
up so that, if the early stages of the process do not prompt a
resignation, it is nearly impossible to run it to conclusion
before someone's term runs out, I think the community would have
rough consensus about the lines that should not be crossed...
even if most of them are not explicitly written down.  That
presumed consensus, no matter how dependent on oral tradition
about the IETF and how it works, is, much like the RFC Editor
function until somewhat over two years ago, reasonably well
understood.  

I believe that the "regular review", at least in the first
iteration or two, needs to start from "is this working or did we
make some fundamental errors in RFC Edition V3?" and not from
the assumption  that, at most, some minor tuning is needed.  And
that is why I said "within the duration of this Program" rather
than, e.g., leaving it up to to the RSWG and/or RSAB to design
the review process.

_And_ I think it is important that we try to define the rails
such that, if things go off them, there is an effective (and
ideally efficient) way to detect and respond to that.   Again
making a comparison to history, we had that halfway through 2019
when the RSOC decided to conduct an early re-compete review of
Heather and her position and did so after (at least from
Heather's perspective) the IAB had systematically excluded her
from discussions that affected the RFC Editor Function that she
was supposed to be leading.  While not stated this way at the
time, she essentially turned around and said "principles are
being violated and it is impossible for me to continue to do the
job for which I was hired under these circumstances, so I will
step down rather than applying for the position again.   The
reactions by the community led to this process.  Presumably,
without those reactions, the RSOC would have recruited someone
new who liked working with the environment that Heather would
not accept and we would be moving forward with the RSOC as the
"ultimate authority".  We have eliminated "ultimate authorities"
unless one counts the ability of the LLC to make decisions by
controlling the contractual process and evaluation of
performance under contracts.  But that should not imply that the
lines that should not be crossed without wide community
participation and review no longer exist ... or that they should
be left to the discretion of the RSWG to figure out as if there
were no history.

> One thing that I believe is outside the scope of our charter
> is worrying about John's contract.  I think we all understand
> the situation and would like to be finished sooner rather than
> later, so that we can have a permanent situation.  But like
> all other processes in this organization, it will complete in
> its own time.

Strongly agree.  I was commenting on the observation by someone
else that we had a firm deadline in March and am pleased to have
you refute that notion.

> Given these two points, does that change your views one way or

It clarified my thinking about the first somewhat.  We were and
are in complete agreement about the second, so nothing needed
changing.

best,
   john

---

From: Jay Daley <[email-masked]>
Date: Wed, 24 Nov 2021 18:28:46 +1300

> On 24/11/2021, at 4:26 AM, John C Klensin <[email-masked]> wrote:
> 
> 
> 

Off the top of my head:
- written  in English 
- freely available
- immutable
- canonical format is intended for long term archive

One important thing for you to note, which I’ve mentioned before but I suspect the implication was lost, is that I will ask the recruiters to interview 10+ community members on their views about this role. The synthesis of these views will form part of the conversation the recruiters will have with possible candidates. 

Jay 

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

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 26 Nov 2021 18:56:48 +0900

> divisions in the community".

Very much so. I have repeatedly argued for including some 'principles'. 
But even if we end not to include them, or actually all the more if we 
end up not to include them, it would be a really really bad idea to see 
writing such principles as the first job of the newly created RSWG. It 
would probably lead to endless discussions without any productive 
outcome, and would block other important work.

(If you wonder why I still advocate that we write down some 'principles' now, the  
difference is that we now can word the 'principles' based on history, 
whereas the RSWG won't do it for history.)

Regards,   Martin.

---

From: Adam Roach <[email-masked]>
Date: Sat, 27 Nov 2021 17:54:54 -0600

> a document about the organization of the RFC Editor function. 

Just now catching up on this thread after having taken the week off...

I think we now have concrete evidence of disagreement on the practical 
implications of one of the principles that has been proposed in a couple 
of different forms. Brian's proposal includes "strong community 
consensus including... the user community of each RFC stream," which he 
later reformulates as "broad discussion" rather than "strong community 
consensus." Joel's included a check on whether any changes "have 
received sufficient review and comment in the larger community affected 
by the RFC Series".

This is an excellent sentiment, from the perspective of "principles we 
consider to be very good and important in a feel-good kind of way."

Mark asks a question that astutely highlights the *practical* problem 
with including these statements in our current work: "As we've discussed 
ad nauseam, how does one gauge the consensus of the user community of a 
stream?"

This question arises nearly every time there is a proposal to make a 
change to the series. The result is that people correctly observe that 
the "user community" for RFCs is unquantifiably large: it includes every 
engineer on the planet who implements or analyzes protocols for the 
Internet. Based on this observation, we then get reactions that are -- 
if we ascribe the most generous motives possible -- well-meaning 
attempts to watch out for these users' hypothesized interests, with the 
result being a complete paralysis of the conversation.

Over two years ago, Brian himself made the keen observation: "How to 
reach out to this community is in itself a big question." [1] Given that 
we don't appear to be any closer to answering that question today than 
we were back then, adding text to our current document that even 
implicitly requires the RSWG to know that answer before making progress 
seems a non-starter. I can't see any tenable conclusion other than than: 
*if* we include language in our document that relies on knowing the 
answer to this question, *then* we must also include the answer itself. 
I do not relish rolling the work of developing that answer into this effort.

/a

___
[1] https://tools.ietf.org/id/draft-carpenter-request-for-comments-01.html

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 27 Nov 2021 23:12:28 -0500

If we simultaneously say that it is important that the RSWG / RSAB check 
with the larger community,
and we have no idea how to tell them what that means,
how can we say we have written a clear description of tehe process, or 
we know how it will work.

It seems like a reasonable conclusion from the content of your message 
might well be "we need to figure this out" rather than "leave it to the 
RSWG".

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 28 Nov 2021 17:33:07 +1300

> might well be "we need to figure this out" rather than "leave it to the

The only reason that we could reach that point is because of a desire
to embed principles in some form in our draft. If we stick to our
knitting (i.e. don't do that), the problem does not arise.

However, I don't agree. Telling the RSWG/RSAB, a collection of intelligent
adults, to be assiduous in consulting the wider community does not seem
underdefined to me. (I agree with my 2-years-younger self, of course, that
it isn't trivial, but that's why we invented the RSWG in the first place.)

Regards
    Brian

    Brian

---

From: Adam Roach <[email-masked]>
Date: Sat, 27 Nov 2021 22:41:53 -0600

On 11/27/2021 10:12 PM, Joel M. Halpern wrote:
> If we simultaneously say that it is important that the RSWG / RSAB 
> check with the larger community,
> might well be "we need to figure this out" rather than "leave it to 
> the RSWG".

Yes, that's one of the logical conclusions you can draw. The other is to 
sidestep the issue altogether by not writing this principle into our 
document, and thereby avoiding the need to figure it out right here 
right now. Both make sense, but I fear one will take a very long time.

/a

---

From: Adam Roach <[email-masked]>
Date: Sat, 27 Nov 2021 22:53:35 -0600

On 11/27/2021 10:33 PM, Brian E Carpenter wrote:
> Telling the RSWG/RSAB, a collection of intelligent

The top-level issue here is that by saying "X is an important principle" 
without defining what "X" means leads to the situation where this 
current group of people -- those of us participating in this 
rfced-future endeavor -- are signing up for something as a "meta law 
that [is] not generally subject to change within [the RSWG] process", 
but we don't know what that something is. Given the way the issue of 
community consultation has been treated in the past, I have severe 
trepidation moving forward with a principle that has historically meant, 
for some people who are nearly guaranteed to be part of the RSWG, that 
nothing substantial about the series can ever be changed because "the 
community" can never be adequately consulted.

/a

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 28 Nov 2021 17:13:44 +1100

> On 28 Nov 2021, at 3:33 pm, Brian E Carpenter <[email-masked]> wrote:
> 

Yes. Again, I think the issue here is where the text can be read as a requirement with an ill-defined measure for success. If the language is creating an *expectation* of consultation, rather than a requirement, and the RSAB is clearly nominated as being the appropriate body to judge whether that expectation is met, I think we can thread this needle.

And I agree that the result of our two years of deliberation is a body and process that is designed for this purpose. It isn't perfect, and by nature it can't operate in a vacuum, but it can, if properly seen through, form the basis of that consultation. 

Cheers,

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