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

[Benjamin Kaduk <[e-mail]>]

Hi Eliot,

On Thu, Mar 10, 2022 at 07:56:18AM +0100, Eliot Lear wrote:
> 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.

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.

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

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.

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

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.

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

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

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

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.

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

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

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

Please don't forget this one.

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

Oops, 8730, yes.

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

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