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

[Benjamin Kaduk <[e-mail]>]

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