Subject: [Rfced-future] Comment on draft-iab-rfcefdp-rfced-model-12

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 10 Mar 2022 10:41:35 +0000

Changing the title to help ensure that this comment is tracked against draft-iab-rfcefdp-rfced-model.

Still suffering from Covid, and I'm now way behind on email, so perhaps this has already been resolved, but I think that the issue below needs to be resolved before the document is published.

Regards,
Rob

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: 07 March 2022 19:40
To: Rob Wilton (rwilton) <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Robert Wilton's No Objection on draft-carpenter-rfced-iab-charter-06: (with COMMENT)

Rob,

On 07-Mar-22 23:58, Robert Wilton via Datatracker wrote:
...
  
> Hi,
> 
>     Note that RFC 2850 states that the RFC Editor appoints a liaison
>     member to the IAB.  This does not change, but refers to the RFC
>     Editor function as described in [I-D.iab-rfcefdp-rfced-model].
> 
> It isn't entirely clear to me exactly who (as in which person or body) is
> actually responsible for appointing a liaison member to the IAB (given, as per
> draft-iab-rfcefdp-rfced-model, the RFC editor function responsibilities are
> split up into multiple entities).  My assumption is that this would be RSAB,
> but perhaps I mistaken.  Would it be helpful to clarify this - perhaps in
> draft-iab-rfcefdp-rfced-model?

Indeed, I don't think it belongs in the IAB charter. Hence I suggest that this
is really a comment that the IAB Program (in Cc:) should look at.

    Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 Mar 2022 13:13:32 -0700

> is really a comment that the IAB Program (in Cc:) should look at.

This is a good question.

One key assumption underlying version 3 of the RFC Editor Model is that 
the process for policy definition and implementation is no longer under 
the purview of the IAB. Therefore, I question whether the IAB still 
needs a liaison from the RFC Editor Function (whose responsibilities are 
now spread across multiple entities) and I would defer to the IAB (cc'd) 
on whether they think this is needed. (If so, we'll need to figure out 
who does the appointing, but one step at a time.)

Peter

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 10 Mar 2022 21:57:15 +0100

This is indeed a good question. Thanks Rob for bring this up!

I actually think there are two options here: either the IAB could have a liaison from the RPC or, if the RPC thinks this is not needed, we probably just don’t need a liaison in the new model. This seems like the only two option to me, given we definitely don’t need a liaison from the RSAB as the IAB is sending one of the representatives and I don’t think it practically makes sense to have liaison from the RSWG. Or maybe having the RSCE as a liaison to the IAB could be another option but I don’t think that would be of real interest for the new RSCE role…?

It seems like this is actually something we might also want to update as well in draft-carpenter-rfced-iab-charter. Brian? Lars?

> On 10. Mar 2022, at 21:13, Peter Saint-Andre <[email-masked]> wrote:
> 
> One key assumption underlying version 3 of the RFC Editor Model is that the process for policy definition and implementation is no longer under the purview of the IAB. Therefore, I question whether the IAB still needs a liaison from the RFC Editor Function (whose responsibilities are now spread across multiple entities) and I would defer to the IAB (cc'd) on whether they think this is needed. (If so, we'll need to figure out who does the appointing, but one step at a time.)
> 
> Peter
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Mar 2022 10:13:24 +1300

>> Still suffering from Covid, and I'm now way behind on email, so perhaps this has already been resolved, but I think that the issue below needs to be resolved before the document is published.

Rob, I hope you feel better soon.

Peter may be right that this liaison will be of lesser importance in
future, but if that proves to be true, then the IAB can decide later
that it's no longer necessary. But if we don't specify it now,
where is the harm? The new RSWG/RSAB structure will be capable of
defining it for themselves.

otoh I don't care if we add a sentence defining this as an RSAB duty.
Again, it can be changed or abolished later.

    Brian C

---

From: Lars Eggert <[email-masked]>
Date: Thu, 10 Mar 2022 23:13:56 +0200

Hi,

> It seems like this is actually something we might also want to update as well in draft-carpenter-rfced-iab-charter. Brian? Lars?

I agree that any changes, if the community or the IAB desires them, should be added to draft-carpenter-rfced-iab-charter. This would probably entail another IETF LC, but so be it.

Thanks,
Lars

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Mar 2022 10:16:03 +1300

> It seems like this is actually something we might also want to update as well in draft-carpenter-rfced-iab-charter. Brian? Lars?

IMHO, no. The IAB asks for a liaison *from* the RFC Editor function,
so the IAB charter is the wrong place to define who appoints that
liaison. See my previous message...

    Brian
>>> Still suffering from Covid, and I'm now way behind on email, so perhaps this has already been resolved, but I think that the issue below needs 
to be resolved before the document is published.
>> One key assumption underlying version 3 of the RFC Editor Model is that the process for policy definition and implementation is no longer under 
the purview of the IAB. Therefore, I question whether the IAB still needs 
a liaison from the RFC Editor Function (whose responsibilities are now spread across multiple entities) and I would defer to the IAB (cc'd) on whether they think this is needed. (If so, we'll need to figure out who does 
the appointing, but one step at a time.)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Mar 2022 10:20:52 +1300

> I agree that any changes, if the community or the IAB desires them, should be added to draft-carpenter-rfced-iab-charter. This would probably entail another IETF LC, but so be it.

No, I disagree. It's not the receiver of a liaison that specifies how the liaison is appointed, it's the sender.

    Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 Mar 2022 14:24:00 -0700

On 3/10/22 2:20 PM, Brian E Carpenter wrote:
>>> It seems like this is actually something we might also want to update 
>>> as well in draft-carpenter-rfced-iab-charter. Brian? Lars?
>>
>> I agree that any changes, if the community or the IAB desires them, 
>> should be added to draft-carpenter-rfced-iab-charter. This would 
>> probably entail another IETF LC, but so be it.
> 
> No, I disagree. It's not the receiver of a liaison that specifies how 
> the liaison is appointed, it's the sender.

Right. So I think the question is, as Mirja said, whether the IAB and 
RPC feel that the RPC needs to have a liaison to the IAB (if so, the RPC 
would be the ones to appoint that liaison). [1]

Peter

[1] Because the IAB appoints a member to RSAB and appoints a chair of 
the RSWG, I don't think the IAB needs a liaison *from* those bodies.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 10 Mar 2022 23:29:46 +0200

Hi,

> No, I disagree. It's not the receiver of a liaison that specifies how the liaison is appointed, it's the sender.

RFC2850 says in Section 1.2:

   The Internet Society, the RFC Editor, the IANA and the IESG each
   appoints a liaison member to the IAB. These liaison positions may not
   be held by a full member of the IAB.

Irrespective of whether it's the IAB or the RFC Editor that does the appointing or asking for a liaison, if there is a change, that text would need an update, no?

Thanks,
Lars

---

From: Jay Daley <[email-masked]>
Date: Fri, 11 Mar 2022 10:32:21 +1300

> On 11/03/2022, at 10:16 AM, Brian E Carpenter <[email-masked]> wrote:
> 

Asking the function for a liaison made sense when there was a single point of control that could make that decision.  Under the new model, there isn’t that point of control.  As the draft text proposed by Peter puts it:

> Under version 3 of the RFC Editor Model, various
> responsibilities of the RFC Editor Function are now performed
> alone or in combination by the RSWG, RSAB, RPC, RFC Series
> Consulting Editor (RSCE), and IETF LLC, which collectively
> comprise the essence of the RFC Editor Function.

We’re going to need a whole new complex process just to sort out how these individuals parts are to agree on a single liaison, if "asking the function" continues to be the way forward.  

Jay

> the purview of the IAB. Therefore, I question whether the IAB still needs a liaison from the RFC Editor Function (whose responsibilities are now spread across multiple entities) and I would defer to the IAB (cc'd) on whether they think this is needed. (If so, we'll need to figure out who does the appointing, but one step at a time.)
>>> 
>>> Peter
>>> 
>>> 
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 Mar 2022 15:12:58 -0700

> We’re going to need a whole new complex process just to sort out how these individuals parts are to agree on a single liaison, if "asking the function" continues to be the way forward.

Right, and I suggest that we avoid that complex process by not having a 
liaison to the IAB from the "RFC Editor Function" (if the IAB and RPC 
etc. feel that we need a liaison from the RPC then that's much easier to 
arrange).

Peter

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Mar 2022 11:17:53 +1300

On 11-Mar-22 10:32, Jay Daley wrote:
>>> I actually think there are two options here: either the IAB could have a liaison from the RPC or, if the RPC thinks this is not needed, we probably just don’t need a liaison in the new model. This seems like 
the only two option to me, given we definitely don’t need a liaison from the RSAB as the IAB is sending one of the representatives and I don’t think it practically makes sense to have liaison from the RSWG. Or maybe having the RSCE as a liaison to the IAB could be another option but I don’t think that would be of real interest for the new RSCE role…?
> Asking the function for a liaison made sense when there was a single point of control that could make that decision.  Under the new model, there 
isn’t that point of control.  As the draft text proposed by Peter 
> We’re going to need a whole new complex process just to sort out how these individuals parts are to agree on a single liaison, if "asking the function" continues to be the way forward.

Which is exactly why I would not attempt to bolt this onto draft-iab-rfcefdp-rfced-model. Let it slide and fix it later.

    Brian
  
>> the purview of the IAB. Therefore, I question whether the IAB still needs a liaison from the RFC Editor Function (whose responsibilities are now spread across multiple entities) and I would defer to the IAB (cc'd) on 
whether they think this is needed. (If so, we'll need to figure out who does the appointing, but one step at a time.)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Mar 2022 11:19:50 +1300

> Irrespective of whether it's the IAB or the RFC Editor that does the appointing or asking for a liaison, if there is a change, that text would need an update, no?

That's why draft-carpenter-rfced-iab-charter has always said:

Note that RFC 2850 states that the RFC Editor appoints a liaison member
to the IAB. This does not change, but refers to the RFC Editor function
as described in {{I-D.iab-rfcefdp-rfced-model}}.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Mar 2022 11:22:54 +1300

On 11-Mar-22 11:12, Peter Saint-Andre wrote:
>>>> I actually think there are two options here: either the IAB could have a liaison from the RPC or, if the RPC thinks this is not needed, we probably just don’t need a liaison in the new model. This seems like the only two option to me, given we definitely don’t need a liaison from the RSAB as the IAB is sending one of the representatives and I 
don’t think it practically makes sense to have liaison from the RSWG. Or maybe having the RSCE as a liaison to the IAB could be another option but I don’t think that would be of real interest for the new 
RSCE role…?
> etc. feel that we need a liaison from the RPC then that's much easier to

Again, fix it later. The language in draft-carpenter-rfced-iab-charter
allows for it to be fixed later (that was intentional). If the RFC Editor
function decides not to appoint a liaison, that's fine too.

    Brian

     Brian

---

From: Jay Daley <[email-masked]>
Date: Fri, 11 Mar 2022 11:57:03 +1300

> On 11/03/2022, at 11:22 AM, Brian E Carpenter <[email-masked]> wrote:
> 
> don’t think it practically makes sense to have liaison from the RSWG. Or maybe having the RSCE as a liaison to the IAB could be another option but I don’t think that would be of real interest for the new RSCE role…?

My point was that I don’t think this can be fixed later - trying to construct a process by which the components of the new RFC Editor Function can choose a liaison, is unworkable.  The only workable solutions are those that either specify who the liaison is or specify a single point of control for the choice, as Mirja said right at the top of this thread.

Jay

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

---

From: Jean Mahoney <[email-masked]>
Date: Thu, 10 Mar 2022 18:00:01 -0600

Hi all,

(with my RPC hat on)

On 3/10/22 2:57 PM, Mirja Kuehlewind wrote:
> I actually think there are two options here: either the IAB could have a liaison from the RPC or, if the RPC thinks this is not needed, we probably just don’t need a liaison in the new model.

[JM] The RPC doesn't feel that a liaison to the IAB is necessary; 
however, we hope the IAB will invite the RPC to participate in meetings 
as needed.

Best regards,

Jean

> This seems like the only two option to me, given we definitely don’t need a liaison from the RSAB as the IAB is sending one of the representatives and I don’t think it practically makes sense to have liaison from the RSWG. Or maybe having the RSCE as a liaison to the IAB could be another option but I don’t think that would be of real interest for the new RSCE role…?
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Mar 2022 13:26:32 +1300

On 11-Mar-22 13:00, Jean Mahoney wrote:
>> I actually think there are two options here: either the IAB could have 
a liaison from the RPC or, if the RPC thinks this is not needed, we probably just don’t need a liaison in the new model.
> however, we hope the IAB will invite the RPC to participate in meetings

That makes sense to me and there is no text in any of the drafts that
suggests an RPC liaison. I'll reply to Jay's message on the more general
question.

     Brian

>>> One key assumption underlying version 3 of the RFC Editor Model is that the process for policy definition and implementation is no longer under the purview of the IAB. Therefore, I question whether the IAB still needs a liaison from the RFC Editor Function (whose responsibilities are now 
spread across multiple entities) and I would defer to the IAB (cc'd) on whether they think this is needed. (If so, we'll need to figure out who does the appointing, but one step at a time.)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Mar 2022 13:38:25 +1300

Jay,

This is getting a bit lengthy, but my response is below, to preserve context.

On 11-Mar-22 11:57, Jay Daley wrote:
> 
> 
>> On 11/03/2022, at 11:22 AM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>>> On 11/03/2022, at 10:16 AM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>
>> don’t think it practically makes sense to have liaison from the RSWG. Or maybe having the RSCE as a liaison to the IAB could be another 
option but I don’t think that would be of real interest for the new RSCE role…?
>>>> Asking the function for a liaison made sense when there was a single 
point of control that could make that decision.  Under the new model, there isn’t that point of control.  As the draft text proposed by Peter puts it:
>>>> We’re going to need a whole new complex process just to sort 
out how these individuals parts are to agree on a single liaison, if "asking the function" continues to be the way forward.
> My point was that I don’t think this can be fixed later - trying to construct a process by which the components of the new RFC Editor Function can choose a liaison, is unworkable.  The only workable solutions are those that either specify who the liaison is or specify a single 
point of control for the choice, as Mirja said right at the top of this thread.

Well, I cordially disagree; I think the RSWG/RSAB mechanism will be quite 
capable of specifying this, or of changing it if we get it wrong now.

However, I would have no problem if we specify now that the RSAB may (not 
will) designate a liaison to the IAB. If the IAB or the RSAB concludes that such a liaison is not needed, the post can be left vacant. This approach is consistent with the drafts as approved this week, so should not delay the documents.

That's my opinion. As document editor, of course I will update draft-carpenter-rfced-iab-charter-07 again if so directed by Lars (and Mirja).

Regards
    Brian

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Mar 2022 07:10:45 +0100

I don't think the liaison is needed in the new model.  Jean indicates 
the the RPC doesn't need it, and the IAB can always invite them onto a 
call when needed.  I do think there are some status reporting 
requirements that should be drawn up in the RSWG, but that's for later.

Since this is a change to 2850, I suggest it be tackled in 2850bis.

Eliot

---

From: Brian Carpenter <[email-masked]>
Date: Fri, 11 Mar 2022 20:06:16 +1300

I think Lars as the sponsoring AD has to make the call on this. It would be
a substantive change to an approved I-D.

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Fri, 11 Mar 2022, 19:11 Eliot Lear, <[email-masked]> wrote:

> > I actually think there are two options here: either the IAB could have a
> liaison from the RPC or, if the RPC thinks this is not needed, we probably
> just don’t need a liaison in the new model.
>

---

From: Lars Eggert <[email-masked]>
Date: Fri, 11 Mar 2022 09:21:06 +0200

Hi,

On 2022-3-11, at 2:38, Brian E Carpenter <[email-masked]> wrote:
> However, I would have no problem if we specify now that the RSAB may (not will) designate a liaison to the IAB. If the IAB or the RSAB concludes that such a liaison is not needed, the post can be left vacant. This approach is consistent with the drafts as approved this week, so should not delay the documents.

so I think the issue remains that RFC2850 says in Section 1.2:

Even with this current text in draft-carpenter

it sounds like some part of the new RFC Editor function is expected to have a liaison with the IAB.

I think we're hearing that both the IAB and the RPC feel that may not be necessary anymore with the new model. So that would argue for changes to RFC2850 and draft-carpenter.

If the community believes that the RFC Editor function and the IAB should still be required to have a direct liaison, I'd prefer if we say a bit more about which part of the RFC Editor function should hold that role, esp. given that the RPC indicates it need not be them. That would again argue for changes to RFC2850 and hence draft-carpenter.

Thanks,
Lars

PS: The IESG has indicated that it will keep requesting a liaison from the RPC, given that we often have discussion about document processing details.

---

From: Brian Carpenter <[email-masked]>
Date: Fri, 11 Mar 2022 22:29:00 +1300

I have no problem if there's consensus to remove the liaison, but will that
need another last call? Awaiting instructions...

Regards,
    Brian Carpenter

On Fri, 11 Mar 2022, 20:21 Lars Eggert, <[email-masked]> wrote:

> > However, I would have no problem if we specify now that the RSAB may
> (not will) designate a liaison to the IAB. If the IAB or the RSAB concludes
> that such a liaison is not needed, the post can be left vacant. This
> approach is consistent with the drafts as approved this week, so should not
> delay the documents.
>
> I think we're hearing that both the IAB and the RPC feel that may not be
> necessary anymore with the new model. So that would argue for changes to
> RFC2850 and draft-carpenter.
>
> If the community believes that the RFC Editor function and the IAB should
> still be required to have a direct liaison, I'd prefer if we say a bit more
> about which part of the RFC Editor function should hold that role, esp.
> given that the RPC indicates it need not be them. That would again argue
> for changes to RFC2850 and hence draft-carpenter.
>
> Thanks,
> Lars
>
> PS: The IESG has indicated that it will keep requesting a liaison from the
> RPC, given that we often have discussion about document processing details.
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Mar 2022 10:33:53 +0100

It would also be good for IAB members to comment.

On 11.03.22 10:29, Brian Carpenter wrote:
> I have no problem if there's consensus to remove the liaison, but will 
> that need another last call? Awaiting instructions...
>
> Regards,
>     Brian Carpenter
>     > However, I would have no problem if we specify now that the RSAB
>     may (not will) designate a liaison to the IAB. If the IAB or the
>     RSAB concludes that such a liaison is not needed, the post can be
>     left vacant. This approach is consistent with the drafts as
>     approved this week, so should not delay the documents.
>
>     member
>     I think we're hearing that both the IAB and the RPC feel that may
>     not be necessary anymore with the new model. So that would argue
>     for changes to RFC2850 and draft-carpenter.
>
>     If the community believes that the RFC Editor function and the IAB
>     should still be required to have a direct liaison, I'd prefer if
>     we say a bit more about which part of the RFC Editor function
>     should hold that role, esp. given that the RPC indicates it need
>     not be them. That would again argue for changes to RFC2850 and
>     hence draft-carpenter.
>
>     Thanks,
>     Lars
>
>     PS: The IESG has indicated that it will keep requesting a liaison
>     from the RPC, given that we often have discussion about document
>     processing details.
>
>

---

From: Lars Eggert <[email-masked]>
Date: Fri, 11 Mar 2022 11:34:34 +0200

Hi,

On 2022-3-11, at 11:29, Brian Carpenter <[email-masked]> wrote:
> I have no problem if there's consensus to remove the liaison,

I think it would be good if others in the program spoke up on this, so the chairs can take consensus.

> but will that need another last call? Awaiting instructions...

I think - but would not mind to be convinced otherwise - that change would better be last-called. I can't recall of the top of my head whether a two-week repeated last call would be possible, or if it needs to be four weeks again.

Thanks,
Lars

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Mar 2022 09:08:19 +1300

*If* there is consensus to remove the liaison, here is is my proposed
update to draft-carpenter-rfced-iab-charter.

OLD:

NEW:
RFC 2850 states that the RFC Editor appoints a liaison member
to the IAB. This is no longer necessary.

ADD to the "Changed text" section:
In section 1.2 of RFC 2850, entitled "Ex-Officio and Liaison members"
the phrase "the RFC Editor," is deleted.

Regards
    Brian Carpenter

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 11 Mar 2022 13:40:37 -0700

+1 to removing the liaison (no one seems to think it's needed) and +1 to 
the proposed text.

On 3/11/22 1:08 PM, Brian E Carpenter wrote:
>> I think - but would not mind to be convinced otherwise - that change 
>> would better be last-called. I can't recall of the top of my head 
>> whether a two-week repeated last call would be possible, or if it 
>> needs to be four weeks again.
>>
>> Thanks,
>> Lars
>>

---

From: Jean Mahoney <[email-masked]>
Date: Fri, 11 Mar 2022 15:55:14 -0600

Brian,

> the phrase "the RFC Editor," is deleted.

[JM] The new text looks good to me.

Thanks!

Jean

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 Mar 2022 18:19:33 -0500

Brian,

I would not presume to guess where the consensus lies but, I am
concerned about backing ourselves into corners if things don't
work out the way we (or, in the case, the RPC, anticipates) and
requiring large amounts of effort to dig back out.  So, at the
risk of giving the IAB a little more authority over its own
activities (something that should be no risk at all) and noting
the liaisons to the IAB have to power to vote or otherwise make
decisions as a consequence of those role, I suggest:

(1) Using the text you suggest above.

(2) Adding, as a new fourth paragraph to Section 1 of RFC 2850,
something like:

	The IAB may, from time to time and by a procedure of its
	choosing, request that other bodies provide liaisons to
	the IAB.  Such liaisons may be discontinued at the IAB's
	discretion by the same process.  Liaisons requested and
	seated in this way will have the same status as those
	explicitly identified in this document.

That way, should either the IAB or the RPC conclude at some
point in the future that a liaison is needed (either long-term
or temporarily), they just sort that out without the need to
revise either your current document or RFC 2850.  And, should
the Internet evolve in ways we cannot anticipate today, we give
the IAB the added flexibility to establish new liaisons as
needed.

I don't think it is necessary, but I would rather have this I-D
(and hence 2850 revised) establish a place where the IAB keeps a
record on incoming liaisons, what entities they represent and
who the current representative is than to need to adjust the
Charter any time a change might be appropriate.

best,
   john

---

From: Martin J. Dürst <[email-masked]>
Date: Sat, 12 Mar 2022 09:21:20 +0900

> +1 to removing the liaison (no one seems to think it's needed) and +1 to 

+1 from me, too. I'm also okay if John Klensin's text gets included, but 
I don't really think that text is necessary. The IAB can talk to anybody 
they like at any time anyway.

Regards,   Martin.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Mar 2022 13:40:59 +1300

> they like at any time anyway.

Another point is that the rfcefdp program would be stepping outside its
role to propose a generic change to the IAB charter. I'd expect that sort
of change to be proposed by the IAB itself.

Rgds
    Brian

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 Mar 2022 20:58:57 -0500

--On Saturday, March 12, 2022 13:40 +1300 Brian E Carpenter
<[email-masked]> wrote:

>>> +1 to removing the liaison (no one seems to think it's
>>> needed) and +1 to the proposed text.
>> 
>> +1 from me, too. I'm also okay if John Klensin's text gets
>> included, but I don't really think that text is necessary.
>> The IAB can talk to anybody they like at any time anyway.
> 

And I would like to hear from the IAB, or IAB members on this
subject.   If I am the only one who would like to leave that
door open, so be it.  If making the change that way seems
reasonable and noting that this is the first time the charter
document has been modified in more than 21 years in spite of far
greater changes to the IAB than the liaison list, why not put it
here and avoid extra work.  But the decision should definitely
be in the IAB's hands.

    john

---

From: Eliot Lear <[email-masked]>
Date: Sun, 13 Mar 2022 14:46:08 +0100

At the moment, I am not hearing any objections.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Mar 2022 14:53:32 -0400

Eliot,

I have posted an objection, not to removing the liaison, but to
prevent reinstating some variation on it without going through a
long and time-consuming process of document revision. 

More explanation in a note I hope to finish and get posted
within the next several hours, but the amount of uncertainty
about details and implications of the new model -- uncertainty
that seems to have been illustrated by questions or comments
within the last week or so -- strongly suggests that, where
there are not strong arguments to the contrary, we should build
flexibility for efficient small corrections to the documents or
their interpretation rather than locking options out.

   john

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Mar 2022 08:28:24 +1300

John,

But you're proposing an addition to the IAB charter that is not
concerned with the RFC Editor model. Regardless of whether this
is a good idea, surely it is out of rfced-future's scope to
decide that? So I think Eliot is correct *as far as his remit
goes*.

Lars, instructions please.

Regards
    Brian

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Mar 2022 18:30:49 -0400

Brian,

There are two ways to look at this.  One is, as you suggest,
that I'm proposing an unrelated addition to the IAB Charter.
The other is that, rather than unequivocally removing the
liaison from the RFC Editor Function, the IAB wants to leave the
door open to a new version of that relationship should it be
needed in the future.  If one narrowly adopted the latter
version, rather than the slightly broader one I have suggested,
the text would take a bit more effort to write but I would know
how to write it and assume you and Peter would too.

What I don't know is whether, while we quibble about scope (see
below), either the active participants in this Program or the
broader community have any serious objections to the IAB and the
RFC Editor Function (presumably involving action by the RSWG and
RSAB and, if the plan was to involved them, agreement by the RPC
and LLC) restoring a liaison relationship by agreement among
those bodies or would require that the Model document and the
IAB Charter be revised.

Independent of the above, I see nothing in either RFC 2850 or
the foundational POISED documents that prevent the IAB from
considering changes to its charter at any time and proposing
them to the community.  If those changes appeared to have rough
community consensus, I cannot imagine the IESG saying "no you
can't do that because we will not approve of BCP publication"
but, if they did --and noting that none of those documents make
the IAB subsidiary to the IESG-- I assume we would have an
interesting constitutional crisis.  Perhaps less drastically, I
note that the rfced-future activity (including its scope) are
formally an IAB Program (which is why the Model document is
draft-iab-rfcfdp... and not draft-iesg-... or something else and
the community call for comment was issued by Mirja for the IAB).
In principle, nothing prevents the IAB from adjusting the
Program's scope if they concluded that such an adjustment was in
the community's best interest.  I'd hope they would be careful
about such an action at this late stage and, at least
informally, query the community first but it appears to me that
they could, procedurally, do that without any consultation at
all (following precedents established by adjustments to the
scope of other Programs).

Presumably, if they asked you and Peter to incorporate the more
flexible text in your documents and you refused, we would have
an interesting discussion about whether they would have the
authority to rearrange editor responsibilities for an IAB
Program, but I assume it would not come to that.

So, I'd like to hear from the IAB about whether they would
prefer a more restrictive or less restrictive change to their
charter.  And, if they prefer the less restriction option, can
we focus on doing The Right Thing rather than discussions of
scope?

And, of course, if the IAB concludes that the greater
flexibility I propose is not worth the trouble of asking
/directing you to change a sentence (or, of course, that it is
just a bad idea), I'll happily drop the idea.  I am just trying
to avoid having that idea go away without consideration because
of assertions about scope.

  best,
    john

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 13 Mar 2022 23:41:23 +0000

If we are proposing a new model, and we are, then remove all vestiges of the previous model.  The liaison should go.

If the new model doesn't work, then the appropriate parties can make the appropriate changes.

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 14 Mar 2022 08:56:04 +0900

I have already said yesterday that I don't think the additional text 
allowing the IAB to engage in liaisons is necessary. The IAB can talk to 
anyone at any time, whether this is informally, or whether it's called a 
"liaison".

My understanding of the current text (the one we are working on 
replacing) is that it *requires* the IAB and the RFC Editor to have a 
liaison. This is no longer necessary, because in the new model:
a) The IAB's responsibility for the RFC Editor function is reduced, and
b) The IAB is represented on the RSAG

So my understanding is that the new text that Brian currently has is 
exactly what's needed.

Regards,   Martin.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 13 Mar 2022 18:00:51 -0600

> So my understanding is that the new text that Brian currently has is 

Agreed on all points.

Peter

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 14 Mar 2022 11:29:06 +0100

Hi John,

While I think it’s a good idea to probably document who is liaising with the IAB at each point of time, I don’t think we need to add the text you proposed to do that. For me the liaison that are listed in RFC2850 are the ones that are mandatory to accept for the IAB (as the community thinks that close interaction of these groups is important). However, I don’t think RFC2850 restricts the IAB in anyway to add additional liaisons (given liaisons don’t really have any special right in the process).

Mirja

> On 12. Mar 2022, at 02:58, John C Klensin <[email-masked]> wrote:
> 
> 
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Mar 2022 10:54:57 -0400

Mirja,

Thanks.  If that is the IAB's current and future interpretation
of the liaisons text in 2850, it works for me and my suggestion
is unnecessary.

Just as an observation that I don't think affects any document
now under discussion, a (different?) general understanding of
the "liaison" terminology combines with the text in 2850 to make
liaisons different from random actors the IAB might ask to
participate in one or more of its discussions.  The difference
is that there is a presumption that liaisons are entitled and
presumably expected to attend all meetings unless there is a
reason to exclude them while others are attending in response to
specific invitations.  I don't know that implies "special
rights".  

However, it has one particular bit of historical relevancy to
these discussions, which is that, at least as I understood it,
Heather's perception that she was excluded from some IAB
discussions that involved RFC strategy and RFC Editor functions
(without reasonable explanation and, in particular, without
those discussions being about identifiable personnel matters)
was one of the contributing causes to her deciding the RSE
position had become untenable for her.  Because of the semantics
people attach to them, the terms that are chosen do carry
implications (even if not "rights") [1] and I'd encourage the
IAB to be careful about vocabulary and terminology even if it
means some future tuning of existing documents.

best,
   john

[1] It may be worth observing that ISO and most of its member
bodies carefully distinguish between "Observers" and "Liaisons"
and that the difference does imply some differences in rights
and obligations.  There are other examples too, but that one may
be specifically relevant.

--On Monday, March 14, 2022 11:29 +0100 Mirja Kuehlewind
<[email-masked]> wrote:

> Hi John,
> 
> While I think it's a good idea to probably document who is
> liaising with the IAB at each point of time, I don't think
> we need to add the text you proposed to do that. For me the
> liaison that are listed in RFC2850 are the ones that are
> mandatory to accept for the IAB (as the community thinks that
> close interaction of these groups is important). However, I
> don't think RFC2850 restricts the IAB in anyway to add
> additional liaisons (given liaisons don't really have any
> special right in the process).

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 14 Mar 2022 11:24:33 +0100

Hi John,

Mirja

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 14 Mar 2022 16:45:50 +0100

Hi John,

I on purpose wrote below “special rights in the process” and was mainly having voting rights in my head. But I agree that expression wasn’t very clear.

Mirja

> On 14. Mar 2022, at 15:54, John C Klensin <[email-masked]> wrote:
> 
> Mirja,
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Mar 2022 12:12:35 -0400

Rich (and Martin and Peter),

This is partially OBE given Mirja's note and my response, but...

To the best of my knowledge, no one has proposed keeping the
liaison.  Certainly neither Brian nor I have.

The concern was precisely about allowing appropriate parties to
make appropriate changes and being sure that the appropriate
parties are sufficiently identified and empowered to do so.   To
use a metaphor that once was popular in the IETF, "changing the
engines of an airplane in flight" is difficult business and
often catastrophic, at least unless careful pre-flight design
provisions were made to make those things possible.  

I've been working on a longer note on this subject, but maybe
the above and a few more comments are an adequate (and shorter)
substitute.  I've said bits of this before but not drawn things
together and, frankly, I think so many of us are anxious to be
done with this process that I am pessimistic about this note
getting any serious attention.  Nonetheless..  

Several recent discussions have left me concerned that we have
not had a sufficient appreciation of the degree to which the new
Model is an experiment without much precedent.   The previous
Model documents were descriptive of then-current practices plus
or minus a few minor tweaks.  This one, by contrast, is arguably
the largest change to the public-facing side of the IETF and its
work since the Kobe affair and POISED.   Unlike this one, even
those changes did not involve creating new institutions, only
radically redefining the roles (and appointment structure, etc.)
of existing ones.  

So, now we are creating an RSWG that is sort of like an IETF WG
except where it isn't and an RSAB that is sort of like -- well,
I don't know what it is sort of like unless it is IAB-lite.  We
are eliminating a key (even if sometimes problematic) role and
oversight authority in the RSE -- a role that was based in
technical publications knowledge and experience -- replacing
part of it with committees, the majority of whose participants
are unlikely to have that knowledge and experience, an advisory
function whose parameters will have to be sorted out over time,
and giving vastly more authority to the LLC and its leadership.
Every one of those changes may be desirable and reflect the need
to solve real problems but, because of the extent of the changes
and the degree to which we are going into territory we think we
understand (but may not), it is an experiment and the other old
IETF metaphor is a question: "what could possibly go wrong?". 

Good practice, especially good engineering practice, suggests
that, if we design experiments that involve radical changes to
existing systems, we should either figure out a way to run those
experiments while those existing systems remain in place (not an
option in this case because the existing systems had already
broken) or to be sure that, if something fails, we have adequate
mechanisms for discovering the failure before too much damage is
done and then changing course as needed.  AFAICT, we have not
done that.  We have said several variations of 
"let the RSWG sort it out" which is fine as long as the RSWG --
despite risks that have been mentioned but, IMO, not really
considered -- does not work as expected/hoped.   Similarly,
while the rearrangement of reporting/oversight of the RPC is,
IMO, a tweak, what would happen in the unlikely event of a
future RPC and a future LLC and ExecDir failing to meet the
community's needs?  Does the RSWG/RSAB have the authority to
change that relationship despite any conceivable RPC having to
be either a contractor or a set of employees of the LLC?  Is the
ability of the RSWG/RSAB to offer advice that the LLC is
expected to follow unless they have what they consider good
reason not to sufficient for all conceivable cases?

The risks I cannot guess at are an equally large concern.
Different people with different perspectives and experience spot
different things.  Active participation in this Program has
included a very small fraction of the community of active IETF
participants and a tiny fraction of the population that might be
affected.   In normal IETF review of a technical specification,
the Last Call process often identifies issues that were not
adequately considered earlier.  But when the community Last Call
was issued this time, AFAICT, zero people commented who had not
actively participated in the Program earlier.   Is that a
problem?  Don't know, but it should at least argue for caution
and/or contingency plans.

I don't know the answer to any of those questions.  I do not
believe that we need to delay any of the current documents or
plans long enough to get answers to them and incorporate them
into the documents.   However, I believe that some effort to
figure out what we do if things do not work as expected and fail
in a non-trivial way would be worthwhile.  Whether that were
done by an extension of the Program, as an activity within the
IAB and/or IESG, or in some other way may be less important than
getting enough of a contingency plan (or framework for one) in
place that, if something does go seriously wrong, we just live
with it because the alternative of trying to figure out how to
start over once the problem is in front of us would be much
worse.

With such a plan, or a plan about how to develop one, in place,
I think we could all relax a bit more and spend less time
worrying about fine details and whether they need to be
addressed now... whether those be the IAB's liaison structure;
the scope of AUTH48; RSAB "CONCERNS"; the finer points of
interactions among the IETF, the RFC Editor Function, and IANA;
or other issues not yet raised.  IMO, each of those conversation
threads has been worthwhile, but I suspect that, absent good
contingency plans, similar ones will keep coming up with no
obvious and fair stopping rule.  To me and at this point, that
is a good reason for leaving as much as possible to the RSWG but
only if we have a plan about what to do if that does not work.

thanks,
    john

(and, yes, that was the short version :-( )

--On Sunday, March 13, 2022 23:41 +0000 "Salz, Rich"
<[email-masked]> wrote:

> If we are proposing a new model, and we are, then remove all
> vestiges of the previous model.  The liaison should go.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Mar 2022 08:42:10 +1300

OK, I will take that as settling this point. I will submit draft-carpenter-rfced-iab-charter-08 with the liaison removed, for Lars to approve the posting if he agrees.

He still has to decide if that needs a 2nd last call, because it's a bit of a stretch to call it an editorial change.

Regards
    Brian Carpenter

On 14-Mar-22 23:24, Mirja Kuehlewind wrote:
> Hi John,
> 
> While I think it’s a good idea to probably document who is liaising with the IAB at each point of time, I don’t think we need to 
add the text you proposed to do that. For me the liaison that are listed in RFC2850 are the ones that are mandatory to accept for the IAB (as the community thinks that close interaction of these groups is important). However, I don’t think RFC2850 restricts the IAB in anyway to add additional liaisons (given liaisons don’t really have any special right in the process).
> .

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Mar 2022 08:29:52 +1300

-------- Forwarded Message --------
Subject: I-D Action: draft-carpenter-rfced-iab-charter-08.txt
Date: Tue, 15 Mar 2022 07:17:11 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

         Title           : IAB Charter Update for RFC Editor Model
         Author          : Brian E. Carpenter
	Filename        : draft-carpenter-rfced-iab-charter-08.txt
	Pages           : 4
	Date            : 2022-03-15

Abstract:
    This document updates the IAB Charter (RFC 2850) to be consistent
    with version 3 of the RFC Editor Model (draft-iab-rfcefdp-rfced-
    model).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-rfced-iab-charter/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-carpenter-rfced-iab-charter-08.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-carpenter-rfced-iab-charter-08

On 15-Mar-22 08:42, Brian E Carpenter wrote:
> add the text you proposed to do that. For me the liaison that are listed in RFC2850 are the ones that are mandatory to accept for the IAB (as the community thinks that close interaction of these groups is important). However, I don’t think RFC2850 restricts the IAB in anyway to add 
additional liaisons (given liaisons don’t really have any special 
right in the process).

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 16 Mar 2022 09:48:20 +0900

Hello John, others,

Towards the end of this mail, John raises the question "What will we be 
able to do if the new Version 3 of the RFC Editor model fails. (The rest 
of John's mail is really just a slow buildup to this question.)

Just for the record, I want to list the stopgaps that are built into the 
new process.

- The RSWG is open to anybody. As long as things work fine, it is indeed 
possible that not too many people participate. But if there's a 
fundamental problem developing (or after it developed, in need of 
correction), more people can participate.

- The RSWG chairs can be replaced by the IAB/IESG at any time.

- The representatives on the RSAB can be replaced at any time.

- Updates to the process are possible through the RSWG and RSAB,
   but require the agreement of the IAB and IESG.

- The RPC and the RSCE serve by contract, with the assumption that these
   contracts contain the necessary clauses for what happens in bad times.

- The IETF Executive Director also is employed by contract, for which
   I guess similar considerations apply.

- The LLC Board, the IAB, and the IESG's members are selected by the
   Nomcom.

I may have forgotten a piece or two, but I think all the necessary 
provisions for "emergency measures" are available. Also, these 
provisions (and the provisions for day-to-day work) are based on 
experience made over decades in the wider IETF community (e.g. WG　process).

It may not be particularly easy or quick to fix the direction of the 
ship if it is sailing in a wrong direction, but it's definitely 
possible. After all, neither what happened after Kobe nor the current 
move from Model 2 to Model 3 were particularly quick, either.

So overall, yes, we are threading new ground, and at least in my 
opinion, that means we should thread carefully, at least at the start. 
But the ground is similar to other ground that we know, and we have all 
the means in place to get out of quicksand (or whatever other problem) 
if and when we discover it.

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: John C Klensin <[email-masked]>
Date: Wed, 16 Mar 2022 22:52:23 -0400

Martin,

I think all I can say at this point is that I hope you are right.

   john

--On Wednesday, March 16, 2022 09:48 +0900 "Martin J. Dürst"
<[email-masked]> wrote:

> Hello John, others,
> 
> Towards the end of this mail, John raises the question "What
> will we be able to do if the new Version 3 of the RFC Editor
> model fails. (The rest of John's mail is really just a slow
> buildup to this question.)
> 
> Just for the record, I want to list the stopgaps that are
> built into the new process.
> 
> - The RSWG is open to anybody. As long as things work fine, it
> is indeed possible that not too many people participate. But
> if there's a fundamental problem developing (or after it
> developed, in need of correction), more people can participate.
> 
> I may have forgotten a piece or two, but I think all the
> necessary provisions for "emergency measures" are available.
> Also, these provisions (and the provisions for day-to-day
> work) are based on experience made over decades in the wider
> IETF community (e.g. WG　process).
> 
> It may not be particularly easy or quick to fix the direction
> of the ship if it is sailing in a wrong direction, but it's
> definitely possible. After all, neither what happened after
> Kobe nor the current move from Model 2 to Model 3 were
> particularly quick, either.
> 
> So overall, yes, we are threading new ground, and at least in
> my opinion, that means we should thread carefully, at least at
> the start. But the ground is similar to other ground that we
> know, and we have all the means in place to get out of
> quicksand (or whatever other problem) if and when we discover
> it.
> 
> Regards,   Martin.
> 
> 
>> The concern was precisely about allowing appropriate parties
>> to make appropriate changes and being sure that the
>> appropriate parties are sufficiently identified and empowered
>> to do so.   To use a metaphor that once was popular in the
>> IETF, "changing the engines of an airplane in flight" is
>> difficult business and often catastrophic, at least unless
>> careful pre-flight design provisions were made to make those
>> things possible.
>> 
>> the above and a few more comments are an adequate (and
>> shorter) substitute.  I've said bits of this before but not
>> drawn things together and, frankly, I think so many of us are
>> anxious to be done with this process that I am pessimistic
>> about this note getting any serious attention.  Nonetheless..
>> 
>> not had a sufficient appreciation of the degree to which the
>> new Model is an experiment without much precedent.   The
>> previous Model documents were descriptive of then-current
>> practices plus or minus a few minor tweaks.  This one, by
>> contrast, is arguably the largest change to the public-facing
>> side of the IETF and its work since the Kobe affair and
>> POISED.   Unlike this one, even those changes did not involve
>> creating new institutions, only radically redefining the
>> roles (and appointment structure, etc.) of existing ones.
>> 
>> So, now we are creating an RSWG that is sort of like an IETF
>> WG except where it isn't and an RSAB that is sort of like --
>> well, I don't know what it is sort of like unless it is
>> IAB-lite.  We are eliminating a key (even if sometimes
>> problematic) role and oversight authority in the RSE -- a
>> role that was based in technical publications knowledge and
>> experience -- replacing part of it with committees, the
>> majority of whose participants are unlikely to have that
>> knowledge and experience, an advisory function whose
>> parameters will have to be sorted out over time, and giving
>> vastly more authority to the LLC and its leadership. Every
>> one of those changes may be desirable and reflect the need to
>> solve real problems but, because of the extent of the changes
>> and the degree to which we are going into territory we think
>> we understand (but may not), it is an experiment and the
>> other old IETF metaphor is a question: "what could possibly
>> go wrong?".
>> 
>> existing systems, we should either figure out a way to run
>> those experiments while those existing systems remain in
>> place (not an option in this case because the existing
>> systems had already broken) or to be sure that, if something
>> fails, we have adequate mechanisms for discovering the
>> failure before too much damage is done and then changing
>> course as needed.  AFAICT, we have not done that.  We have
>> said several variations of
>> "let the RSWG sort it out" which is fine as long as the RSWG
>> -- despite risks that have been mentioned but, IMO, not really
>> be either a contractor or a set of employees of the LLC?  Is
>> the ability of the RSWG/RSAB to offer advice that the LLC is
>> Different people with different perspectives and experience
>> spot different things.  Active participation in this Program
>> has included a very small fraction of the community of active
>> IETF participants and a tiny fraction of the population that
>> might be affected.   In normal IETF review of a technical
>> specification, the Last Call process often identifies issues
>> that were not adequately considered earlier.  But when the
>> community Last Call was issued this time, AFAICT, zero people
>> commented who had not actively participated in the Program
>> earlier.   Is that a problem?  Don't know, but it should at
>> least argue for caution and/or contingency plans.
>> 
>> figure out what we do if things do not work as expected and
>> fail in a non-trivial way would be worthwhile.  Whether that
>> were done by an extension of the Program, as an activity
>> within the IAB and/or IESG, or in some other way may be less
>> important than getting enough of a contingency plan (or
>> framework for one) in place that, if something does go
>> seriously wrong, we just live with it because the alternative
>> of trying to figure out how to start over once the problem is
>> in front of us would be much worse.
>> 
>> With such a plan, or a plan about how to develop one, in
>> place, I think we could all relax a bit more and spend less
>> time worrying about fine details and whether they need to be
>> interactions among the IETF, the RFC Editor Function, and
>> IANA; or other issues not yet raised.  IMO, each of those
>> conversation threads has been worthwhile, but I suspect that,
>> absent good contingency plans, similar ones will keep coming
>> up with no obvious and fair stopping rule.  To me and at this
>> point, that is a good reason for leaving as much as possible
>> to the RSWG but only if we have a plan about what to do if
>> that does not work.
>> 
>> thanks,
>>      john
>>

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 17 Mar 2022 14:05:15 +0900

Hello John,

> I think all I can say at this point is that I hope you are right.

Thanks. I can only add to this that I hope I don't have to be right
(i.e., I hope we won't need all the checks and balances and safety 
valves that I described below).

Regards,   Martin.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Mar 2022 07:53:21 +0100

On 14. Mar 2022, at 17:12, John C Klensin <[email-masked]> wrote:
> Model is an experiment without much precedent. 

And it is all waterfall design.

With a lot of wishful thinking (process confabulation, i.e., based on what some people think they and other people *should* be doing as opposed to what they are or will be actually doing).

Software projects that are set up this way usually fail spectacularly.
Fortunately, the new process will be run by humans, so we still have a chance that we will iterate out of the tarpits (and/or that people simply will ignore pieces of process to instead do the right thing).

This is all water under the bridge.
But we really have to be careful that we don’t ossify in a failed designed-in-a-vacuum state without a chance to get back to a process of continuous improvement.
The fact that the AUTH48 tweak (as just one placeholder for recent attempts to continue doing continuous improvement) was all but shouted down when subjected to unstructured discussion does not make me very hopeful, though.

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Mar 2022 08:44:20 +0100

Hi Carston

> And it is all waterfall design.

*Everything* is waterfall design until you establish a system that 
allows for more ... agile... flexibility.  The RSWG / RSAB could do that 
by delegating certain aspects of authority into certain places to make 
things happen faster.  For instance, it would be the height of silliness 
for the RSWG to have to approve all RFC Editor web site pages, but the 
scope of the authority of the RPC to make changes has to be clear.  
Similarly, I see no reason why the RSWG should have to make decisions 
around each and every commit relating to tooling that supports the RPC 
function, but again the scope of authority for checkins to be approved 
has to be clear.  To take that a step further, if the output of tool 
causes material changes to the RFC structure or format, clearly that 
would be something that would at least require heightened review, but 
one that creates new representations or RFCs or takes in new input forms 
for the RPC might require less review.

To me the RSWG and RSAB should be focused in establishing those scaling 
forms so that there is *less* waterfall, more delegation, andmore 
community participation, ably facilitated with the help of the RSCE).

I realize that's a mouthful of a vision, but I don't think it's an 
original concept on my part.

Eliot

---

From: S Moonesamy <[email-masked]>
Date: Thu, 17 Mar 2022 15:52:32 -0700

Hi John,

I trimmed the Cc.

>IETF metaphor is a question: "what could possibly go wrong?".

The current (soon to be obsoleted) model was described as "running 
code".  The proposal which came out of this Internet Architecture 
Board program is a mishmash of ideas borrowed from the IETF 
model.  The authority given to the IETF Administration LLC is a side 
effect of a previous decision taken by the IETF.

If the proposal is an experiment, shouldn't it be categorized as 
"experimental" instead of "informational"?

Regards,
S. Moonesamy

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Mar 2022 23:06:59 -0400

> The current (soon to be obsoleted) model was described as
> "running code".  The proposal which came out of this Internet
> Architecture Board program is a mishmash of ideas borrowed
> from the IETF model.  The authority given to the IETF
> Administration LLC is a side effect of a previous decision
> taken by the IETF.

> If the proposal is an experiment, shouldn't it be categorized
> as "experimental" instead of "informational"?

SM,

I had promised myself I wasn't going to say more about this
on-list and the postings from Martin, Eliot, and Carsten (I
think in that order) covered several perspectives on the issue.
But I want to respond specifically (and I hope narrowly and
briefly) to your question:  Normally, when we write an
experimental spec, there is a fallback plan if the experiment
fails or has undesirable side effects. Usually that involves
reverting to the status quo ante.  Here, the status quo was
dead: one could have imagined the Program coming up with a model
that more closely resembled the old system than the new model
does, but it would not have been much closer to long-established
"running code" than the new model.  While this is an
"experiment" in the sense that many of the ideas in the model
are untested, I don't see that there would be any value in
labeling the document as "Experimental" other than to create
confusion.  There is no status quo to which to return: the only
path is ahead and we just need to hope that it turns out to be
forward and work.   If it does not, we have to hope that Martin
is correct and the new arrangements and a good dose of goodwill
will be sufficient to make any needed changes and adjustments).

   john

> 
> If the proposal is an experiment, shouldn't it be categorized
> as "experimental" instead of "informational"?