Re: [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]>]

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.


Editorial suggestions inspired by the discussion: 

Because the Style Guide is a two-part beast, 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.  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.

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

   john

[1] http://www.rfc-editor.org/rfc-style-guide/part2.html

[2] RFC 7322, Section 2, describes one version of that principle.