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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 9 Mar 2022 22:00:16 -0800

I read this document since the IESG is being asked to approve it, and have
some comments.  Overall, I have not structural objections, but there may
be some details to give attention to, where errors might have significant
impact.

I'll divide my notes into things that might qualify as "edge cases" (a
security AD is highly attuned to such things) and "everything else"; the
"edge cases" might be presumed to be more likely to be substantive or
require discussion

(A handful of editorial stuff, including the doubled words that John
Scudder noted, at
https://github.com/intarchboard/program-rfced-future/pull/157)

Edge Cases
----------

Section 3.1.2.2

   If and when a new stream is created, the document that creates the
   stream shall specify if a voting member representing that stream
   shall also be added to the RSAB, along with any rules and processes
   related to that representative (e.g., whether the representative is a
   member of the body responsible for the stream or an appointed
   delegate thereof).

This document itself is creating a new stream.  Shouldn't we provide this
information for the Editorial stream, just to avoid any ambiguity?
In particular, is the RSCE supposed to represent the Editorial stream on
the RSAB or play an independent role?

Section 3.1.2.5

   The RSAB shall annually choose a chair from among its members using a
   method of its choosing.  If the chair position is vacated during the

Is majority approval implied for the choice of chair, or might "method of
its choosing" imply a requirement for unanimity (which might be impossible
to meet)?

Section 3.2.2

        There are three reasons why an RSAB member may file a position
        of CONCERN:

The IESG DISCUSS criteria document
(https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/)
includes things like "impossible to implement due to technical or clarity
issues", "not properly vetted against the I-D checklist", etc.  Are we
confident that the three listed reasons cover all possible concerns?

   12.  If, after a suitable period of time, any CONCERN positions
        remain, a vote of the RSAB is taken.  If at least three voting
        members vote YES, the proposal is approved.

Is this (three YESes versus a three fifths supermajority) what we want even
in a world where additional streams are added?

Section 3.2.4

   misinterpreted an approved policy.  Aside from these two cases,
   disagreements about the conduct of the RSAB are not subject to
   appeal.  Appeals of RSAB decisions shall be made to the IAB and

Does this mean that (e.g.) the IESG rep on the RSAB acts on the RSAB
solely in the RSAB capacity, and there is no grounds for appeal to the
IESG?

Section 4.4

   *  The disagreement might raise a new issue that is not covered by an
      existing policy or that cannot be resolved through consultation
      between the RPC and other relevant individuals and bodies, as
      described above.  In this case, the RSAB is responsible for (a)
      resolving the disagreement in a timely manner if necessary so that
      the relevant stream document(s) can be published before a new
      policy is defined and (b) bringing the issue to the RSWG so that a
      new policy can be defined.

I don't have to squint very hard for this to look like the RSAB setting
policy, even though per §3.1.2.1 the RSAB "shall have no independent
authority to formulate policy on its own".

Section 8

   Updates, amendments, and refinements to this document can be produced
   using the process documented herein, but shall be operative only
   after (a) obtaining the agreement of the IAB and the IESG, and (b)
   ensuring that the IETF LLC has no objections regarding its ability to
   implement any proposed changes.

This sounds like we can end up in a situation where a new RFC updating
this one has been published but is not operative, which seems really bad.
Can we make the gating function apply at a different point in time, i.e.,
before publishing an RFC that is not implementable?

Section 11

   This document places responsibility for coordination of registry
   value assignments with the RPC.  [...]

I see §4.3 talking about "coordinating ... to ensure *correct
documentation* of IANA-performed protocol registry actions" (emphasis
mind), which seems very distinct from "registry value assignments" (which
sounds more like solely IANA's turf).

Everything Else
---------------

Section 3.1.1.4

   Absent specific guidance in this document regarding the operation of
   the RSWG, the general guidance provided in Section 6 of [RFC2418]
   should be considered appropriate.

(I feel like I saw some previous mention of this go by, but couldn't find
it quickly just now.)  The generic 2418 procedures include a role for
"Area Director", which presumably doesn't have a real analogue for the
RSWG.  It seems okay to just accept that and not do anything, but I wanted
to make sure it got noted before publication.

Section 3.1.2.1

   on its own.  It is expected that the RSAB will respect the rough
   consensus of the RSWG wherever possible, without ceding its
   responsibility to provide appropriate review of RSWG proposals.

This "appropriate review" can only result in kicking proposals back to
the RSWG, right?  Since the term "appropriate" is really vague and
subjective, is there further guidance that could be given?  Perhaps just
noting that it's limited to the set of things that are allowed for a
CONCERN?

Section 3.2.3

   The RSAB is responsible for considering comments received during a
   community call for comments.  [...]

I thought that up in items 6-8 of §3.2.2, we said that there would be some
RSWG/RSWG chair involvement in considering comments.  I guess the
responsibility would still ultimately lie with the RSAB, per this?

Section 7.2

   RFC Series documents have been published in a format that was
   intended to be as accessible as possible to those with special needs,
   e.g., for those with impaired sight.

My understanding is that the current preference is to use the term
"disabilities" rather than "special needs".

Section 12.2

If we're going with "Updates: 8030", then don't you need to read 8030 to
know what is being updated (i.e., it is properly classified as normative)?

-Ben

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Mar 2022 07:56:18 +0100

Hi Ben,

> Edge Cases

The working group did discuss this and we had earlier versions that said 
exactly that the RSCE represents the Editorial Stream, but we removed 
that for other structural reasons involving the role and purpose of the 
RSCE.

> its choosing" imply a requirement for unanimity (which might be impossible

Up to the RSAB.  They're grown-ups, though if they chose to have a "Last 
Person Standing Wrestling Match" to choose, I'm sure many would buy tickets.

> in a world where additional streams are added?

This was also something that I think John touched on.  We did indeed 
discuss this very sentence quite a lot.  The group was mostly of the 
opinion, “cross that bridge when we come to it”.  I don't think anyone 
supported the notion of a super-majority to pass; rather the arguments 
were around what should happen in a tie.  As you point out, this is an 
edge case, because streams are rarely added.  For context, the editorial 
stream is the first stream added since the concept was articulated.

> solely in the RSAB capacity, and there is no grounds for appeal to the

That is correct.  Choose your person wisely.  The IESG may at any time 
replace that person, at their discretion, following whatever processes 
they define.  You can also require that individual to inform you and the 
IETF community in a manner that the IESG and IETF community choose, and 
if they don't, you can replace that person.

> authority to formulate policy on its own".

There is formulating and interpreting; the former is proscribed, and the 
latter is circumscribed to operational necessity. Consider this: the 
RSWG operates by rough consensus.  If that consensus is not forthcoming, 
without such a means to resolve ambiguities, drafts would sit and rot.  
That is not fair to those who put the time in to write those documents.  
Again, this was discussed at some length.

> before publishing an RFC that is not implementable?

I think the best way to address this is to simply say- "... shall be 
operative *and published* only after..."

> sounds more like solely IANA's turf).

I agree that this text is problematic, and it should be reworded as follows:

"This document requires that the RPC coordinate registry of value 
assignments with IANA."

> Everything Else

Yes, we went a few rounds on that point.

The review criteria are explicitly laid out in Step 9 in Section 3.2.2:

>         *  The RSAB member believes that the proposal represents a
>            serious problem for one or more of the individual streams.
>
>         *  The RSAB member believes that the proposal would cause
>            serious harm to the overall Series, including harm to the
>            long-term health and viability of the Series.
>
>         *  The RSAB member believes, based on the results of the
>            community call(s) for comment Section 3.2.3, that rough
>            consensus to advance the proposal is lacking.

> responsibility would still ultimately lie with the RSAB, per this?

I think you are mostly referring to Step 8 here, which takes place when 
the RSAB feels that substantial comments have been received by the 
community.  This offers the RSWG the opportunity to make what changes 
they desire to make in response to review. This is a little different 
than how IETF last call works, because these are policy documents and 
the document truly has to belong to the RSWG.

I think you mean 8730; and the document states:

> This document updates [RFC8730] by removing the dependency on
>    certain policies specified by the IAB and RSE.  More detailed
>    information about changes from version 2 of the Model can be found
>    under under Section 8.

Regards,

Eliot

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 9 Mar 2022 23:12:51 -0800

Hi Eliot,

> that for other structural reasons involving the role and purpose of the 

Okay, I'm happy to hear it was considered.
I strongly suggest documenting the decision by clearly stating that the
Editorial stream does not have a voting member representing it on the RSAB.

> Person Standing Wrestling Match" to choose, I'm sure many would buy tickets.

I just mention it as a potential route to process deadlock.  Can the RSAB
function with no chair?  I would like to assume that streams would pull and
replace their reps that behave badly, but when designing systems try to
remove classes of failure scenarios by construction, when possible.

> stream is the first stream added since the concept was articulated.

Indeed, definitely an edge case.  And being a rare event increases the risk
that the humans involved would forget about the need to look at this bit
when (if?) adding a new stream and thereby inadvertently trigger the edge
case.  But I have no desire to retread ground already covered by the
program.

> operative *and published* only after..."

I might swap the order, for "published and operative", but that sounds good
in principle.

> "This document requires that the RPC coordinate registry of value 

It's getting late here, so maybe I'm just missing things, but while this
does seem to be an improvement, it still seems to have somewhat of a
mismatch with §4.3's depiction.  If I understand correctly, the RPC only
cares about value assignments insamuch as the values being assigned get
recorded in the RFCs being produced, and your new proposal doesn't mention
documents/RFCs (other than this one) at all.

> The review criteria are explicitly laid out in Step 9 in Section 3.2.2:

It looks like we might be able to forward-reference 3.2.2, then (e.g.,
"appropriate review of RSWG proposals, as described in Section 3.2.2").

> > "disabilities" rather than "special needs".

Please don't forget this one.

> I think you mean 8730; and the document states:

Oops, 8730, yes.

> >    information about changes from version 2 of the Model can be found

I was trying to say that 8730 is currently listed as only an informative
reference, but it seems like it would be more properly classified as a
normative reference.

Thanks for the super-fast and comprehensive response!

-Ben

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Mar 2022 09:28:09 +0100

Hi Ben,

I'm only addressing points on which I have a view here:

> remove classes of failure scenarios by construction, when possible.

It's really not necessary to worry about this.  Because the streams 
themselves require the proper functioning of the RFC editor, they're not 
likely to argue much over this, and just pick someone. The RSAB chair 
function is relatively weak, it's primary function being to convene 
meetings.  I would worry more about the IESG selecting someone to serve, 
quite frankly.

> documents/RFCs (other than this one) at all.

"This document requires that the RPC document registry value
assignments made by IANA."

> Please don't forget this one.

I leave it to Peter to address this point.  I have no special knowledge 
or wisdom here.

> Thanks for the super-fast and comprehensive response!

Ah!  Ok.

Eliot

---

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

Working my way from the end of the thread to the beginning...

On 3/10/22 1:28 AM, Eliot Lear wrote:
>> function with no chair?

Probably. As Eliot says, the RSAB chair mainly coordinates meetings of 
the RSAB.

>> I would like to assume that streams would 
>> pull and
> meetings. 

Agreed.

> assignments made by IANA."

That's pretty much what it said before, no? ;-)

I suggest this in the "RPC Responsibilities" section:

14. Ensuring that RFCs accurately document registry value assignments
     made by IANA.

For the avoidance of doubt, we could also say the same thing under the 
IANA considerations.

> I leave it to Peter to address this point.  I have no special knowledge 

Further research indicates to me that "people with disabilities" is 
indeed the term of art these days.

>> reference, but it seems like it would be more properly classified as a

I'll move RFC 8730 from informative to normative.

Peter

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Mar 2022 13:40:41 -0800

Hi Peter,

I see we're keeping you quite busy this week; thanks for all you're doing.

> Probably. As Eliot says, the RSAB chair mainly coordinates meetings of 

Ah.  That would probably turn this into not really much of a concern, then.

> For the avoidance of doubt, we could also say the same thing under the 

That does remove the bits I was confused about, but to me it also seems to
change the semantics somewhat.  Namely, now the RPC is just consuming
things produced by IANA, which could be seen as removing the possibility to
coordinate on which allocations are actually to be made, from what
range(s), etc., that the previous text seems to have implied.  I think I
have seen the RPC notice things in editing that would affect what IANA
does, and thus am not confident that describing this as a unidirectional
flow would be entirely accurate.  (Whether such coordination could occur
between RPC and IANA in an informal manner so as to get the right thing to
happen anyway, is another question.)

> I'll move RFC 8730 from informative to normative.

Thanks for both of these.

-Ben

---

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

On 3/10/22 2:40 PM, Benjamin Kaduk wrote:

>>> On 10.03.22 08:12, Benjamin Kaduk wrote

Ah, I see, you were originally concerned about the text in Section 11, 
not the text in Section 4.3.

I wonder if something like this would be more accurate in §11:

"The RPC is responsible for coordinating with IANA to ensure that RFCs
accurately document registration processes and assigned values for IANA 
registries."

Peter

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Mar 2022 14:25:01 -0800

> not the text in Section 4.3.

Ah, yes.  I guess that got lost as the thread evolved.

> accurately document registration processes and assigned values for IANA 

That looks good to me on first read, thanks.

-Ben

---

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

> Editorial stream does not have a voting member representing it on the RSAB.

Good point.

I suggest adding the following sentence to Section 3.1.2.2:

"The RFC Series Consulting Editor (RSCE) is a voting member of the
RSAB but does not act as a representative of the Editorial Stream."

>>> authority to formulate policy on its own".

I'm curious why you think so - the text seems clear to me that this is 
not a new policy but a one-off, temporary workaround to get the relevant 
IETF/IAB/IRTF/ISE RFC published before a new policy is defined in the RSWG.

> I might swap the order, for "published and operative", but that sounds good

WFM.

>>> Section 11

See elsewhere in this thread.

>> Yes, we went a few rounds on that point.

We trust that RSWG chairs and participants will use their common sense 
in such matters.

> "appropriate review of RSWG proposals, as described in Section 3.2.2").

Right. I suggest:

OLD

  appropriate review of RSWG proposals

NEW

  appropriate review of RSWG proposals as further described under 
{{workflow}}.

>> the document truly has to belong to the RSWG.

To clarify even further, there are two stages here: RSWG review and 
community call for comments. The RSWG chairs manage the first of these, 
the RSAB manages the second.

Peter

---

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

> That looks good to me on first read, thanks.

Great. This and other changes-in-progress can be tracked in the 
following pull request:

https://github.com/intarchboard/program-rfced-future/pull/158

Peter

---

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

--On Thursday, March 10, 2022 13:40 -0800 Benjamin Kaduk
<[email-masked]> wrote:

>> 14. Ensuring that RFCs accurately document registry value
>> assignments made by IANA.
>> 
>> For the avoidance of doubt, we could also say the same thing
>> under the  IANA considerations.
> 
> That does remove the bits I was confused about, but to me it
> also seems to change the semantics somewhat.  Namely, now the
> RPC is just consuming things produced by IANA, which could be
> seen as removing the possibility to coordinate on which
> allocations are actually to be made, from what range(s), etc.,
> that the previous text seems to have implied.  I think I have
> seen the RPC notice things in editing that would affect what
> IANA does, and thus am not confident that describing this as a
> unidirectional flow would be entirely accurate.  (Whether such
> coordination could occur between RPC and IANA in an informal
> manner so as to get the right thing to happen anyway, is
> another question.)

In practice, it has always been a two-way flow, even when the
RFC Editor and IANA held discussions by looking into a mirror.
And even with that level of coordination, it has often been a
bit of a dance because of the long-standing principle that RFCs
do not direct IANA to assign, or even request, particular code
points.  So please try to write the text along the lines Ben
suggests, e.g., as something more like "Coordinate with IANA as
necessary to ensure that any registry value assignments that
actually appear RFCs are consistent with the registries."

   john

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 12 Mar 2022 12:07:22 -0700

> actually appear RFCs are consistent with the registries."

What I suggested most recently was:

14. Coordinating with IANA to ensure that RFCs accurately document
     registration processes and assigned values for IANA registries.

Note that this mentions registration processes in addition to assigned 
values, because many RFCs establish registries and the processes for 
registering values in those registries need to be correct, too.

Peter

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 Mar 2022 14:10:09 -0500

--On Saturday, March 12, 2022 12:07 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>...
>> bit of a dance because of the long-standing principle that
>> RFCs do not direct IANA to assign, or even request,
>> particular code points.  So please try to write the text
>> along the lines Ben suggests, e.g., as something more like
>> "Coordinate with IANA as necessary to ensure that any
>> registry value assignments that actually appear RFCs are
>> consistent with the registries."
> 
> 14. Coordinating with IANA to ensure that RFCs accurately
> document registration processes and assigned values for IANA
> registries.
 
> Note that this mentions registration processes in addition to
> assigned values, because many RFCs establish registries and
> the processes for registering values in those registries need
> to be correct, too.

Yes.  Entirely correct.  Sorry I did not see that suggestion
before writing my note.

thanks,
   john

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 12 Mar 2022 11:37:30 -0800

> registering values in those registries need to be correct, too.

Mentioning registration procedures as well is a good catch!
I know that I am behind on the thread, but since I hadn't seen this
specific proposal yet either (like John), let me note here that it looks
good to me.

Thanks,

Ben

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 12 Mar 2022 13:30:35 -0700

On 3/12/22 12:37 PM, Benjamin Kaduk wrote:
> specific proposal yet either (like John), 

I *thought* I had posted it to the list, but perhaps not.

> let me note here that it looks
> good to me.

Great, thanks!

Peter