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

[Brian E Carpenter <[e-mail]>]

On 04-Mar-22 16:39, John C Klensin wrote:
> 
> 
> --On Thursday, March 3, 2022 19:30 -0700 Peter Saint-Andre
> <[e-mail]> wrote:
> 
>> ...
>>>>> (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
>> ...
>>> The term "conformance" is a bit odd in that context ("comply"
>>> even more so) and, IMO, "general", "intent" or some other term
>>> is helpful.  One could even say:
>> ...
> 
>> I propose:
>>
>> 1. Editing documents originating from all RFC streams to
>> ensure that
>>      they adhere to editorial standards specified in the RFC
>> Style Guide.
> 
> Still feels over-specific given the (IMO desirable) flexibility
> of the past.  Think about replacing "that they adhere to" with
> "consistent with" (the collective documents that make up the
> Style Guide actually allow more than enough flexibility).

Yes. The words "guide" and "must" do not sit well together.
I'm sure there will always be exceptions to any style rule,
and I think we need text here that allows for that.

    Brian

> 
>> And I propose to define the RFC Style Guide in the Working
>> Practices section of the document:
>>
>> * Maintenance of a style guide that defines editorial
>> standards to which RFCs must adhere;
> 
> But that is exactly what it does not do.  See previous rant
> about "Guidelines" versus "editorial standards" and other strong
> language.  If you wanted to change "defines" to "includes", I'd
> be ok with it, but that might convey a different meaning.
> 
>> the RFC Style Guide consists of
>> {{RFC7322}} and
>>     associated documents and resources listed at {{STYLEGUIDE}}.
>>
>> Where {{STYLEGUIDE}} points to
>> https://www.rfc-editor.org/styleguide/
> 
> That does the job.  However, there is no need for "and" because
> the first thing on the list at that link is RFC 7322.  So
> "consists of the associated documents..." would convey exactly
> the same information (and avoid a suggestion from me about "or
> its successor" wrt 7322).
> 
>>> Editorial suggestions inspired by the discussion:
>>
>>> Because the Style Guide is a two-part beast,
>>
>> Actually many-headed - it includes all the documents and
>> resources listed at https://www.rfc-editor.org/styleguide/
> 
> Right.   I plead exhaustion.
> 
>> The following paragraphs get into editorial implementation
>> details and I'm not sure we need to work out this level of
>> detail on list...
> 
> I don't think we do.  Most of that list was just intended to
> draw some things to your attention and I should probably have
> sent a private note.  Since you did respond on-list to parts of
> it, a few more comments below.
> 
>> ...
>>> (vi) Finally, because 4.2 and 4.3(1) apparently makes the
>>> Style Guide part of the RPC's job description and Section 6
>>> may make it part of the RSCE's, I suspect that [RFC7322] and
>>> [STYLEGUIDE] should be identified as normative references.
>>
>> To date we haven't had normative references in this document.
>> Although I don't have deep objections to changing some of the
>> informative references to normative, it's not completely clear
>> to me how we'd decide which need to be normative in a policy /
>> framework document like this.
> 
> :-)  However, the RFC 7322 part of the Style Guide, one of the
> "editorial standards" to which which your latest proposed text
> requires that the RPC make documents "adhere", in Section 4.8.6
> paragraph 5 says:
> 
> 	"Reference lists must indicate whether each reference is
> 	normative or informative, where normative references are
> 	essential to implementing or understanding the content
> 	of the RFC and informative references provide additional
> 	information."
> 
> You'd need to discuss it with the RPC, but I believe that
> requires either separate sections or a comment with each
> reference indicating its status.  Or you could seek an exception
> or clarification to the first paragraph of that section that
> prohibits introductory text :-).   And _that_ is a perfect
> example about why I've found language that requires adherence,
> conformance, of even consistency with specified rules
> objectionable.  The Style Guide is mostly, even when it says
> something "must" be done, is a target and set of guidelines, not
> an "editorial standard".
> 
>> ...
>>> Presumably it does not require changes but, based on the long
>>> thread on that subject, it appears to me that there is
>>> controversy on the list about whether they would be required
>>> to get permission from the RSAB/RSWG to make changes or
>>> whether the RSWG/RSAB could specify changes and require the
>>> RPC to incorporate them into practice.  Same questions about
>>> individual streams and the handling of their documents.
>>
>> Given the long thread, I don't see that we'll easily come to
>> consensus on the matter in *this* document and will likely
>> need to see how things shake out in the RSWG.
> 
> Ok as long as the document doesn't say anything that would
> require changes depending on how things work out.  It does,
> however, open the door to some considerable micromanagement by
> the RSWG.  What I was trying to do was to describe scope of
> authority, not suggest particular outcomes on the more detailed
> issues raised on that list.
> 
>>>>> (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.
>>>
>>> I see a difference in role and authority between the document
>>> shepherd and WG Chairs, IRTF RG Chairs, or the IESG ADs and
>>> some IAB variation.  In particular, which the other roles are
>>> fairly much fixed, the IESG could decide in the future that
>>> the Shepherd's job ends with IESG approval and take them off
>>> the AUTH48 list.   Suggestions (second one preferred):
>> ...
>   
>>> Principle: every place we can get rid of these explicit lists
>>> that might raise questions about who or what is not listed, we
>>> future-proof the document about plausible future change
>>> including additions to the list of Streams or changes in the
>>> role of existing ones.
>>
>> We currently cover the same material in three places - twice
>> under RPC Responsibilities and once under the section on
>> resolution of disagreements.
> 
> Yep.  I was a bit concerned about that too.
> 
>> To simplify, I suggest the following under RPC
>> Responsibilities:
>>
>> ###
>>
>> 4. Establishing the publication readiness of each document
>> through
>>      communication with the authors, IANA, or stream-specific
>> contacts,
>>      supplemented if needed by the RSAB and RSCE.
>>
>> ###
> 
> That is entirely consistent with where I was headed. Thanks.
> 
>> And then under Resolution of Disagreements between Authors and
>> the RPC:
>>
>> ###
>>
>> During the process of editorial preparation and publication,
>> disagreements can arise between the authors of an RFC-to-be
>> and the RPC. Where an existing policy clearly applies,
>> typically such disagreements are handled in a straightforward
>> manner through direct consultation between the authors and the
>> RPC, sometimes in collaboration with stream-specific contacts.
>>
>> ###
> 
> That too.
> 
>> I now think we don't need to list who these stream-specific
>> contacts might be because inevitably we'll leave someone out
>> (or a role like document shepherds might be obsoleted) and our
>> future selves might get confused. Let's leave it more generic.
> 
> Yes, exactly.
> 
> thanks,
>     john
>