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

[Peter Saint-Andre <[e-mail]>]

On 3/3/22 6:16 AM, Eliot Lear wrote:
> 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.

Before we go too far down the path, I'll note that most of this text was 
copied from other places (primarily, RFC 8728). That doesn't mean it 
shouldn't be changed, of course.

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

WFM

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

+1

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

Agreed, and we might not want to bake AUTH48 into this document because 
perhaps that process will change in the future.

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

Perhaps:

    Providing an online system to facilitate the submission, management,
    and display of errata to RFCs.

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

The IAB is not an individual, but we could add "IAB chair". Also, do 
note "such as" in that sentnence - this is not meant to be complete.

Peter