Subject: Re: [Rfced-future] Creation/dissolution

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Sep 2021 16:02:40 -0600

With my editor hat on, I'm not yet seeing actionable agreement on the
problem to be solved and therefore on the need for text (or specific
proposed text). Feel free to correct me if I'm wrong.

On Sat, Aug 28, 2021 at 5:03 PM John C Klensin <[email-masked]> wrote:

>
>
> --On Sunday, August 29, 2021 10:25 +1200 Brian E Carpenter
> <[email-masked]> wrote:
>
> >> (1) Rather than working on dissolution mechanisms, let's think
> >> of a periodic (or at least one-time) review model.
> >
> > Or do both, but certainly a review mechanism after N years
> > seems very useful.
>
> Ack.  But, in case it was not clear from the longer note, my
> concern about dissolution mechanisms is that the long discussion
> leaves me with the strong feeling that we will take a lot of
> time getting the details pinned down and then, if we ever
> discover the mechanism is needed, that it won't work.  The most
> obvious case is that, if N bodies have to agree that something
> should be dissolved, and one of those bodies was part of the
> problem...
>
> > (I agree about the recall mechanism needing review, but that
> > should probably be kicked over the fence to the IETF.)
>
> Indeed.  Relevant to this group only insofar as, if we had a
> working one of those, it might provide a useful model for
> dealing with a seriously disfunctional collection of RFC Editor
> function bodies.  For example, if there were a problem for which
> the right solution was to fire the membership of some particular
> body and reconstitute the membership from scratch, dissolving
> the body may be unnecessarily complex and destructive overkill.
>
>     john
>
> --
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Sep 2021 10:29:07 +1200

Hi,

If we were proposing the new structure as an experiment, we'd definitely have to require review after a set period of time followed by a decision whether to continue or revert to the previous system. But that isn't what 
we're proposing, and I don't see why we'd want to include a self-destruct 
mechanism.

However, a review after a few years does seem like a good idea. The IETF LLC has one, and it seems to be working. (https://www.rfc-editor.org/rfc/rfc8711.html#name-three-year-assessment)

How about:

# Three-Year Assessment

The RSAB, with the involvement of the community, shall conduct and complete an assessment of the structure, processes, and operation of the RFC strategy process. This should be presented to the community after a period of roughly three years of operation. The assessment may potentially include recommendations for improvements or changes to the process.

(I intentionally excluded the RPC and its contract, because that is LLC business.)

Regards
   Brian

On 14-Sep-21 10:02, Peter Saint-Andre wrote:
> With my editor hat on, I'm not yet seeing actionable agreement on the problem to be solved and therefore on the need for text (or specific proposed text). Feel free to correct me if I'm wrong.
> 
> On Sat, Aug 28, 2021 at 5:03 PM John C Klensin <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     [email-masked] <mailto:[email-masked]>
>     https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Sep 2021 19:16:34 -0400

I'd be much happier with two years than three, but, otherwise,
Brian's suggestion seems right.

   john

--On Tuesday, September 14, 2021 10:29 +1200 Brian E Carpenter
<[email-masked]> wrote:

> Hi,
> 
> If we were proposing the new structure as an experiment, we'd
> definitely have to require review after a set period of time
> followed by a decision whether to continue or revert to the
> previous system. But that isn't what  we're proposing, and I
> don't see why we'd want to include a self-destruct  mechanism.
> 
> However, a review after a few years does seem like a good
> idea. The IETF LLC has one, and it seems to be working.
> (https://www.rfc-editor.org/rfc/rfc8711.html#name-three-year-a
> ssessment)
> 
> How about:
> 
># Three-Year Assessment
> 
> The RSAB, with the involvement of the community, shall conduct
> and complete an assessment of the structure, processes, and
> operation of the RFC strategy process. This should be
> presented to the community after a period of roughly three
> years of operation. The assessment may potentially include
> recommendations for improvements or changes to the process.
> 
>> With my editor hat on, I'm not yet seeing actionable
>> agreement on the problem to be solved and therefore on the
>> need for text (or specific proposed text). Feel free to
>> correct me if I'm wrong.
>> 
>> On Sat, Aug 28, 2021 at 5:03 PM John C Klensin
>> <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>> 
>>     >> (1) Rather than working on dissolution mechanisms,
>>     >> let's think of a periodic (or at least one-time)
>>     >> review model.
>>     > 
>>     > Or do both, but certainly a review mechanism after N
>>     > years seems very useful.
>> 
>>     Ack.  But, in case it was not clear from the longer
>>     note, my concern about dissolution mechanisms is that the
>>     long discussion leaves me with the strong feeling that we
>>     will take a lot of time getting the details pinned down
>>     and then, if we ever discover the mechanism is needed,
>>     that it won't work.  The most obvious case is that, if N
>>     bodies have to agree that something should be dissolved,
>>     and one of those bodies was part of the problem...
>> 
>>     > (I agree about the recall mechanism needing review, but
>>     > that should probably be kicked over the fence to the
>>     > IETF.)
>> 
>>     Indeed.  Relevant to this group only insofar as, if we
>>     had a working one of those, it might provide a useful
>>     model for dealing with a seriously disfunctional
>>     collection of RFC Editor function bodies.  For example,
>>     if there were a problem for which the right solution was
>>     to fire the membership of some particular body and
>>     reconstitute the membership from scratch, dissolving the
>>     body may be unnecessarily complex and destructive
>>     overkill.
>> 
>>         john
>> 
>>     -- 
>>     <https://www.iab.org/mailman/listinfo/rfced-future>
>> 
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 14 Sep 2021 07:39:28 +0200

And just to remind people, some of this is covered by the text I 
proposed to cover Issues 35 and 63:

> Peter would make a change to the text that states that the new series, 
> and only the new series, will only be used to specify and update the 
> strategy, policy, and procedures of the RFC series itself.  No other 
> use of the stream is authorized by this memo. *This policy may only be 
> changed by agreement of the IAB, IESG, and IETF LLC. *

(Emphasis added)

There were really three points to this text:

1.  The new group should stick to its prescribed mandate and not exceed it.

2.  Other streams shouldn't monkey with series policy.

3.  If things really flop, the IAB, IESG, and LLC can step in if they 
can agree.

It's that last point that intersects the text below.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Tue, 14 Sep 2021 10:26:15 -0400

Eliot,

I think you text and the suggestion about a scheduled review are
complementary, not overlapping or conflicting.  The difficulty
with the IAB, IESG, and IETF LLC stepping in is that all three
groups are busy, they easily might not agree on how important an
intervention is, etc.  In other words, it might turn out to be a
bit like the recall provisions for Nomcom appointees:if there is
a major, obvious, and work-blocking problem, it is a good
provision to have and perhaps it would work.   It would probably
also require assigning blame, something that we, as a community,
are good at sometimes and very bad at other times.   For less
significant problems, or ones in which the positions of the
"leadership" and the community are at variance (we might
disagree on whether that has ever happened), it is a plausible
hypothesis that they would fail to agree and act.  By contract,
the scheduled review permits having a look at what is working
well and what might need tuning without requiring getting to
"severely broken" or anything close to it.

Put differently, we are establishing a rather complex process
with multiple actors and organizations and many moving parts.  A
large fraction of those participating in the discussions and
designs lack either the formal background for such design work
or real-world experience at the appropriate management and
coordination levels.  Doing a "did that work and how, if at all,
should it be tweaked" review would be an appropriate way to see
if we got things right or they could be improved.  And that is
rather different from a mechanism for fixing a disastrous
probably.

best,
   john

--On Tuesday, September 14, 2021 07:39 +0200 Eliot Lear
<[email-masked]> wrote:

> And just to remind people, some of this is covered by the text
> I proposed to cover Issues 35 and 63:
> 
>> Peter would make a change to the text that states that the
>> new series,  and only the new series, will only be used to
>> specify and update the  strategy, policy, and procedures of
>> the RFC series itself.  No other  use of the stream is
>> authorized by this memo. *This policy may only be  changed by
>> agreement of the IAB, IESG, and IETF LLC. *
> 
> (Emphasis added)
> 
> 3.  If things really flop, the IAB, IESG, and LLC can step in
> if they can agree.
> 
>> (https://www.rfc-editor.org/rfc/rfc8711.html#name-three-year-
>> assessment)
>> 
>> How about:
>> 
>> # Three-Year Assessment
>> 
>> The RSAB, with the involvement of the community, shall
>> conduct and complete an assessment of the structure,
>> processes, and operation of the RFC strategy process. This
>> should be presented to the community after a period of
>> roughly three years of operation. The assessment may
>> potentially include recommendations for improvements or
>> changes to the process.
>> 
>>>      --On Sunday, August 29, 2021 10:25 +1200 Brian E
>>>      Carpenter <[email-masked]
>>>      note, my concern about dissolution mechanisms is that
>>>      the long discussion leaves me with the strong feeling
>>>      that we will take a lot of time getting the details
>>>      pinned down and then, if we ever discover the mechanism
>>>      is needed, that it won't work.  The most obvious case
>>>      is that, if N bodies have to agree that something
>>>      should be dissolved, and one of those bodies was part
>>>      of the problem...
>>> 
>>>      > (I agree about the recall mechanism needing review,
>>>      > but that should probably be kicked over the fence to
>>>      > the IETF.)
>>> 
>>>      collection of RFC Editor function bodies.  For
>>>      example, if there were a problem for which the right
>>>      solution was to fire the membership of some particular
>>>      body and reconstitute the membership from scratch,
>>>      dissolving the body may be unnecessarily complex and
>>>      destructive overkill.
>>> 
>>>          john
>>> 
>>>      --

---

From: Michael StJohns <[email-masked]>
Date: Tue, 14 Sep 2021 10:41:52 -0400

On 9/14/2021 1:39 AM, Eliot Lear wrote:
>> Peter would make a change to the text that states that the new 
>> series, and only the new series, will only be used to specify and 
>> update the strategy, policy, and procedures of the RFC series 
>> itself.  No other use of the stream is authorized by this memo. *This 
>> policy may only be changed by agreement of the IAB, IESG, and IETF LLC. *
>
> (Emphasis added)
>

But.  All that covers is the use of the stream.  My question is - if 
things go terribly wrong, what is the reset mechanism? Terribly wrong 
being either a moribund RSWG or one exceeding its mandate repeatedly and 
yelling at the RSAB when it does its job and pushes back.

Right now what we're doing is a permanent delegation of IAB authority to 
the RSAB/RSWG with no way to reverse that without the cooperation of the 
RSWG.   That seems imprudent and shortsighted.

Mike

ps - happy with the review plans, but this is orthogonal to that.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Sep 2021 10:43:09 +1200

On 15-Sep-21 02:41, Michael StJohns wrote:
...
 
> But.  All that covers is the use of the stream.  My question is - if things go terribly wrong, what is the reset mechanism?   
Terribly wrong being either a moribund RSWG or one exceeding its mandate repeatedly and yelling at the RSAB when it does its job and pushes back. 
> 
> Right now what we're doing is a permanent delegation of IAB authority to the RSAB/RSWG with no way to reverse that without the cooperation of the RSWG.   That seems imprudent and shortsighted.

I don't mean to sound flippant, but the community found a way in Kobe in 1992, and we found a way to express displeasure with the current RFC Editor setup, although it needed an unfortunate resignation. Assuming the current plan is formally approved by the IAB, there is surely a way for the IAB to undo it.

In that respect, please review draft-carpenter-rfced-iab-charter-01, which is intended to be a BCP. A few words there could make all the difference. For example:

ORIGINAL:
The IAB must approve the appointment of an organization to act as RFC Editor and the general policy followed by the RFC Editor.

CURRENT PROPOSAL:
The RFC Editor model is defined by [I-D.iab-rfcefdp-rfced-model].

POSSIBLE PROPOSAL:
The RFC Editor model is defined under the authority of the IAB by [I-D.iab-rfcefdp-rfced-model].

   Brian

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Sep 2021 19:42:43 -0700

On Tue, Sep 14, 2021 at 3:43 PM Brian E Carpenter <
[email-masked]> wrote:

> things go terribly wrong, what is the reset mechanism?
> Terribly wrong being either a moribund RSWG or one exceeding its mandate
> repeatedly and yelling at the RSAB when it does its job and pushes back.
> >
> I don't mean to sound flippant, but the community found a way in Kobe in
> 1992, and we found a way to express displeasure with the current RFC Editor
> setup, although it needed an unfortunate resignation. Assuming the current
> plan is formally approved by the IAB, there is surely a way for the IAB to
> undo it.
>
> In that respect, please review draft-carpenter-rfced-iab-charter-01, which
> is intended to be a BCP. A few words there could make all the difference.
> For example:
>
> ORIGINAL:
> The IAB must approve the appointment of an organization to act as RFC
> Editor and the general policy followed by the RFC Editor.
>
> CURRENT PROPOSAL:
This seems like a sensible change that doesn't require us to invent a bunch
of new process.

-Ekr

   Brian

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 15 Sep 2021 15:20:13 +0900

Hello Everybody,

> rather different from a mechanism for fixing a disastrous

I'm somewhat worried by "should it be tweaked?". It comes with a 
bikesheding smell. I'd rather prefer this be worded somewhat closer to 
"Did that work and can we continue to live with it".

Regards,   Martin.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 15 Sep 2021 12:11:09 -0600

> The RFC Editor model is defined under the authority of the IAB by [I-D.iab-rfcefdp-rfced-model].

In the latest version of our document (based on list discussion over a
month ago), I stopped using the phrase "RFC Editor Model". We might want
to add back one mention to tie in with your proposal and with existing
nomenclature.

Peter

---

From: John C Klensin <[email-masked]>
Date: Wed, 15 Sep 2021 14:44:51 -0400

--On Wednesday, September 15, 2021 12:11 -0600 Peter Saint-Andre
<[email-masked]> wrote:

>>> But.  All that covers is the use of the stream.  My
>>> question is - if things go terribly wrong, what is the reset
>>> mechanism?   
>> Terribly wrong being either a moribund RSWG or one exceeding
>> its mandate repeatedly and yelling at the RSAB when it does
>> its job and pushes back. 
>>> 
>>> Right now what we're doing is a permanent delegation of IAB
>>> authority to the RSAB/RSWG with no way to reverse that
>>> without the cooperation of the RSWG.   That seems
>>> imprudent and shortsighted.
>> 
>> I don't mean to sound flippant, but the community found a way
>> in Kobe in 1992, and we found a way to express displeasure
>> with the current RFC Editor setup, although it needed an
>> unfortunate resignation. Assuming the current plan is
>> formally approved by the IAB, there is surely a way for the
>> IAB to undo it.
>> 
>> In that respect, please review
>> draft-carpenter-rfced-iab-charter-01, which is intended to be
>> a BCP. A few words there could make all the difference. For
>> example:
>> 
>> ORIGINAL:
>> The IAB must approve the appointment of an organization to
>> act as RFC Editor and the general policy followed by the RFC
>> Editor.
>> 
>> CURRENT PROPOSAL:
> In the latest version of our document (based on list
> discussion over a month ago), I stopped using the phrase "RFC
> Editor Model". We might want to add back one mention to tie in
> with your proposal and with existing nomenclature.

Partially for historical reasons and partially because things
have gotten much too far into specific relationship and
operational details to really be a "model", may I suggest you
and others consider going back to the terminology we started
using around the time we moved away from one "editor" (which was
actually two people) and a small support staff.   We then
started using "Function", as in "RFC Editor Function" to
describe the whole operation and could then talk about
components, roles, and relationships as needed.

Nothing I'm going to fall on my sword about (or even try to
debate at length) but, if we are looking for a good match
between the terms we use and the things they describe, "model"
may have outlived its usefulness.

best,
    john

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Sep 2021 10:29:51 +1200

> may have outlived its usefulness.

Yes, "function" is probably better. Happy to change that, but are there
further thoughts on this for the IAB charter?

POSSIBLE PROPOSAL:
The RFC Editor function is defined under the authority of the
IAB by [I-D.iab-rfcefdp-rfced-model].

   Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 16 Sep 2021 12:32:27 -0600

> IAB by [I-D.iab-rfcefdp-rfced-model].

That seems fine, although per feedback from Martin Thomson I got rid of
the phrase "RPC function". Here, however, "function" seems appropriate.

Peter