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 2:28 PM, John C Klensin wrote:
> Eliot,
> 
> Have elided things in which either I think your comments are
> fine or that should be left to editorial discretion....
> 
> --On Thursday, March 3, 2022 14:16 +0100 Eliot Lear
> <[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 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
> 
> Or (ALTERNATE NEW):
> 
> 	Editing input from all RFC streams in conformance with
> 	the intent of the RFC Style Guide.
> 
> I'm ok with either that or my earlier suggestion, but should
> explain and then hope Peter can sort things out.  The case that
> might differentiate those alternatives or suggest something yet
> different is a combination of two things:
> 
>    (i) The Style Guide, at least through RFC 7322 and today's
> version of the "Web portion" [1], is mostly about common cases
> and issues that have arisen in the past and that seemed to be
> worth writing down.
>    (ii) There has always been a philosophy about giving authors
> considerable latitude as long as they are consistent within a
> document and do not violate a relatively firm rule [2].  It is
> perhaps not an accident that it is called "Style Guide" and not
> "Style Manual", "Style Rules", or the like.
> 
> 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:
> 
> 
> SECOND ALTERNATE NEW
> 
> 	Editing input from all RFC streams in conformance with
> 	the intent of the RFC Style Guide, including the
> 	Principles expressed therein.

I propose:

1. Editing documents originating from all RFC streams to ensure that
    they adhere to editorial standards specified in the RFC Style Guide.

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

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

The following paragraphs get into editorial implementation details and 
I'm not sure we need to work out this level of detail on list...

> if Section 4.3(1)
> is going to make it a requirement of the RPC's definition and
> job, the document might be a tad more clear about both parts
> being included.  The least intrusive way to do that would be to:
> 
> (i) In Section 3.2.6, first paragraph change "(see [RFC7322]..."
> to "specifically [RFC7322]..." or words to that effect, turning
> that into a definition, not just a "you might look there"
> citation.
> 
> (ii) Maybe drop "(see the style guide web page
> (https://www.rfc-editor.org/styleguide/), which extends
> [RFC7322])" from the first bullet of Section 4.2 and replace it
> by a cross-reference to Section 3.2.6.
> 
> (iii) Maybe tune Section 7.5 accordingly, being sure that either
> the adjusted definition is referenced, both the RFC and the web
> page are cited, or whatever else Peter thinks appropriate.
> While I am guessing it would be unlikely, nothing would prevent
> the web page (or a successor to 7322) from acquiring test that
> discusses the tradeoffs among those three goals.
> 
> (iv) Maybe put a cross-reference into 4.3(1) pointing back to
> the definition.
> 
> (v) I hope we can avoid going there at this late date but the
> amount of special terminology and alphabet soup in this document
> is starting to approach the point at which document clarity
> would be improved by adding a glossary of those terms or index
> to where they are defined.  Of course, if that were done;
> several of the comments above would be moot.
> 
> (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.

> More important,
> to avoid confusion with the two-part beast, we should have
> either one [STYLEGUIDE] reference that includes both 7322 and
> the web page or we should change the anchor name for the latter
> to "[STYLEGUIDE2]", "[STYLEGUIDEWEB]", or equivalent.   In
> either case, the document title for the latter is not "Style
> Guide" as shown in the reference but "Web Portion of the Style
> Guide".  The latter, in addition to being correct, is far more
> clear about what is going on.
> 
>> ...
> 
>>> (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.
> 
> 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.

> 
>> ...
>   
>>> (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):
> 
> 	(i) Preserve the existing list, add IAB somehow, but
> 	move "document shepherd" to the end rather than making
> 	it the first example.
> 	
> 	(ii) Shorten, clarify, and future-proof this by changing
> 	"other individuals such as a document shepherd, IETF
> 	working group chair, IRTF research group chair, or IETF
> 	Area Director" to "other individuals such as those
> 	designated by the relevant stream".
> 
> 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.

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.

###

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.

###

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.

Peter