[Rfced-future] Sectiion 4.3 on RPC Responsibilities (was: Re: Fwd: [I18ndir] I18ndir last call review of draft-iab-rfcefdp-rfced-model-11_

[John C Klensin <[e-mail]>]

Peter,

In writing the note I just posted about the i18n review, I
studied Section 4.3 (and the first part of 4.4) more closely
than I had before.

Apologies if others have already spotted these but, as I looked
carefully at 4.3, I noticed:

(i) 4.3(1) implies that editing it done only to bring documents
into conformance with the Style Guide.  That may be inconsistent
with other points that imply other reasons for making changes.
More important, the Style Guide (and even the previous
"Instructions to RFC Authors" documents), have always been a
soft target, with good sense and agreement between the RPC (and
is predecessors) and authors (and sometimes streams) overriding
some of its provisions for particular documents when that is
necessary.  Put differently, if one wants to deviate from  the
Style Guide, one better have a good reason, but the RPC (and
predecessors) have always been willing to listen to those
reasons and make per-document exceptions when appropriate.  Do
we intended to change that?  If not, that statement might need
some softening.

(ii) In 4.3(4), "document shepherds" are, as far as I know,
specific to a minority of streams and, when they exist, their
authority is often limited.  You may want to either drop them
and assume "stream-specific contacts" covers them or move them
to that parenthetical list of examples.

(iii) Section 4.3 does not appear to provide for AUTH48, i.e., a
final prepublication check that no problems have been introduced
in editing.  In the context of the current list, AUTH48 is
intended to catch changes that have unintended consequences but
that are not been picked up (presumably earlier) as "technical
impact" (4.3(3)) or the "needed clarifications" (4.3(4)), 

(iv) Also on the subject of AUTH48 and given the recent on-list
discussion, when I read through that section and scan other
sections of the I-D, I wonder if the RPC could unilaterally
eliminate (or drastically reform) AUTH48.  I think there is no
question that the RSAB/RSWG could direct them to make changes in
that area but, if they (the RPC) decided changes were needed,
are they required to ask permission and, if so, of whom?  I
think we can rely on good judgment and good sense (see previous
note) but, if people feels a need to nail things down, requiring
that at least the relevant stream or RSAG be consulted about any
major procedural changes might be wise.

(v) 4.3(20) requires online access only for "approved" errata.
Not only am I not sure what that means, but, traditionally (and
currently) there is online access to substantially all errata.
That is especially important for errata in "hold for document
update" state (which I do not believe constitutes "approval")
and authors or WGs of potential successor documents.  Did we
intend to change that and allow hiding the non-approved ones?
If not, would dropping "approved" work?

(vi) 4.4, first paragraph: the list of "other individuals", like
the list in 4.3(2) and (ii) above, is a tad stream specific.  In
particular, did you intend  to leave the IAB out?  Also, in my
most recent experience with IETF Stream documents, document
shepherds have authority to sort out disagreements only by
delegation from ADs or WG Chairs.  It is not clear such
delegations are wise (since Shepherds are, AFACT, accountable
only to the relevant ADs).   As in (ii) above, the list may need
some rethinking and editing.  You could get around the problem
in this section by saying something like "someone delegated by
the Stream to oversee editorial processing of that particular
document" as long as the Streams did what they normally do
rather than making a procedural drama out of the appointment
process.


best,
    john

p.s. I trust it is clear that I have not be able to do a review
in this much depth of the rest of the document.  I probably
won't have time to even try.  Sorry about that -- too much going
on at once.