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

From: John C Klensin <[email-masked]>
Date: Tue, 01 Mar 2022 23:14:02 -0500

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.

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

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

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

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

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

best,
    john

p.s. I trust it is clear that I have not be able to do a review
in this much depth of the rest of the document.  I probably
won't have time to even try.  Sorry about that -- too much going
on at once.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 3 Mar 2022 14:16:46 +0100

Hi John,

> we intended to change that?  If not, that statement might need

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

?

> 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

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

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

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

> rather than making a procedural drama out of the appointment

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 3 Mar 2022 08:36:04 -0700

>> studied Section 4.3 (and the first part of 4.4) more closely

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.

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

WFM

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

+1

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

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

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

> 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

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Mar 2022 16:28:43 -0500

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
<[email-masked]> 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.
> 
> 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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 3 Mar 2022 19:30:44 -0700

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

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

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.

> including additions to the list of Streams or changes in the

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Mar 2022 22:39:29 -0500

--On Thursday, March 3, 2022 19:30 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>>>> documents into conformance with the Style Guide.  That may
>>>> be inconsistent with other points that imply other reasons
>...

>     they adhere to editorial standards specified in the RFC

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

> 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

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

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

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

>> 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):
>...
 
> 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.

>     supplemented if needed by the RSAB and RSCE.

That is entirely consistent with where I was headed. Thanks.

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Mar 2022 16:53:46 +1300

> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 4 Mar 2022 16:51:30 -0700

> and I think we need text here that allows for that.

I see your point. So (under Working Practices):

* Maintenance of a style guide that defines editorial standards for
   RFCs; specifically, the RFC Style Guide consists of {{RFC7322}} and
   associated documents and resources listed at {{STYLEGUIDE}}.

and (under RPC Responsibilities):

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

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 4 Mar 2022 17:09:11 -0700

> Style Guide actually allow more than enough flexibility).

Yes, that seems fine.

Note that RFC 8728 said:

    1.   Editing inputs from all RFC streams to comply with the RFC Style
         Manual, under the direction of the RSE;

RFC 5620 said:

    5.  Developing, maintaining, and publishing the RFC Style Manual for
        use by authors, editors, the stream managers, the RFC Production
        Center, and the RFC Publisher;

...

    8.  Overseeing consistency of RFCs with the RFC Series and RFC Style
        Manual.

So we've had text about consistency and compliance for quite a while.

> be ok with it, but that might convey a different meaning.

I'd prefer "Maintenance of a style guide that defines editorial 
standards for RFCs" - that doesn't say anything about conformance, 
mandatory adherence, etc.

I'm not afraid of calling these standards because we're trying to ensure 
quality here and editorial standards help in that respect.

But if folks don't like "editorial standards" we could use a softer word 
such as "guidelines" or "principles".

> its successor" wrt 7322).

Or:

   specifically, the RFC Style Guide consists of {{RFC7322}} and
   the other documents and resources listed at {{STYLEGUIDE}}.

Perhaps RPC editors can help us with this level of polish when the time 
comes. ;-)

> something "must" be done, is a target and set of guidelines, not

Normative references might include:

RFC 2418
RFC 7154
RFC 7322
RFC 7766
RFC 7841
RFC 8716
RFC 8729

But I haven't taken a close look at this yet.

> issues raised on that list.

Even these "scope of authority" topics have been contentious in this 
Program.

>> future selves might get confused. Let's leave it more generic.

Thanks, John!

Peter

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Mar 2022 13:13:53 +1300

>      they are consistent with the editorial standards specified in the

Yes, that sounds reasonable to me - firm, but does not read like a mandate.

    Brian

---

From: Jay Daley <[email-masked]>
Date: Tue, 8 Mar 2022 08:31:06 +1300

> On 5/03/2022, at 1:13 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I agree.  

(fwiw, I am commenting here because i want to ensure the role of the RPC as defined here is clear, consistent and achievable).

Jay

> 
>   Brian
> 
> 
> 
> -- 
> Rfced-future mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 8 Mar 2022 09:08:44 +0900

>> Yes, that sounds reasonable to me - firm, but does not read like a mandate.

I agree, but shouldn't it be "{{RFC7322}} or its successor"?

Regards,   Martin.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 7 Mar 2022 19:11:33 -0700

> I agree, but shouldn't it be "{{RFC7322}} or its successor"?

I'm not a big fan of saying "or its successor" everywhere because the 
point of specifying that a new RFC updates or obsoletes an old RFC is 
that the reader should be able to follow the trail and find the new one.

Peter

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 8 Mar 2022 11:59:39 +0000

Strongly agree.

Otherwise we could (and by this reasoning, should) add "or its successor" to almost every cross-reference.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 8 Mar 2022 09:13:59 -0700

> Otherwise we could (and by this reasoning, should) add "or its successor" to almost every cross-reference.

FWIW email lists are a different story because we have no formal way to 
know that, say, the hypothetical discuss-rfc list is the successor to 
the rfc-interest list. (But note that I didn't think we had consensus to 
deprecate the rfc-interest list so I didn't change that text in -12.)

Peter