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

[Eliot Lear <[e-mail]>]

Hi John,

On 02.03.22 05:14, John C Klensin wrote:
> 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.

How about:

OLD:

> Editing inputs from all RFC streams to comply with the RFC Style
>         Guide.

NEW:

> Editing inputs from all RFC streams in general conformance to the RFC 
> Sytle Guide

?


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

I would suggest leaving this one in place. It's an OR, and I think it 
makes clear where


>
> (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)),

I think this is covered by (i).  AUTH48 is part of the overall editing 
responsibility.


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

One thing I think the RPC can do is just document the existing 
interfaces to the streams.  I don't know if that requires either changes 
here or any approval from the RSWG.


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

That seems like a good idea.  Another would simply be to combine 19 and 
20 and talk about facilitating processing and display of errata.

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

The shepherd term is mostly an IETF thing.  Again, because it's an OR, I 
worry less about that.  I like the idea of adding the IAB.

Eliot