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

[Eliot Lear <[e-mail]>]

Hi Ben,

On 10.03.22 07:00, Benjamin Kaduk wrote:
>
> 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?

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.

>
> 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)?

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.

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

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.

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

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.

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

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.


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

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

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

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


Yes, we went a few rounds on that point.


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

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

>         There are three reasons why an RSAB member may file a position
>         of CONCERN:
>
>         *  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.

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

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.


>
> 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)?

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


>
> -Ben
>