Re: [auth48] AUTH48: RFC-to-be 9280 <draft-iab-rfcefdp-rfced-model-13> for your review

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

Hi Rebecca,

Thanks for your work on this important document.

Here are a few proposed edits. I would like the Program chairs and the 
IAB to make sure they are comfortable with these changes before you make 
these edits.

SECTION 3.1.1.2

OLD
    software or hardware systems that implement RFCs, authors of RFCs and
    Internet-Drafts, developers of tools used to author or edit RFCs,

NEW
    software or hardware systems that implement RFCs, authors of RFCs and
    Internet-Drafts, developers of tools used to author or edit RFCs and
    Internet-Drafts,

RATIONALE: I don't think it was deliberate for us to leave out 
developers of tools used to author Internet-Drafts, however there *is* a 
difference (many tools are used to author Internet-Drafts but a smaller 
set of tools is used by the RPC to edit RFCs for publication).

SECTION 3.1.2.3

The following two sentences are in potential conflict:

3.1.2.3

    The appointing bodies, i.e., the stream approving bodies (IESG, IAB,
    IRTF Chair, and ISE), shall determine their own processes for
    appointing RSAB members (note that processes related to the RSCE are
    described in Section 5).

4.4

    *  If there is a conflict with a policy for a particular stream, to
       help achieve a resolution, the RPC should consult with the
       relevant stream approving body (such as the IESG or IRSG) and
       other representatives of the relevant stream as appropriate.

In 3.1.2.3, the IRTF Chair is described as a stream approving body (!), 
whereas in 4.4 the IRSG is described as a stream approving body. I 
suggest that we remove mention of stream approving bodies in 3.1.2.3 and 
make the following change.

OLD

    The appointing bodies, i.e., the stream approving bodies (IESG, IAB,
    IRTF Chair, and ISE), shall determine their own processes for
    appointing RSAB members (note that processes related to the RSCE are
    described in Section 5).

NEW

    The appointing bodies (i.e., IESG, IAB, IRTF Chair, and ISE), shall
    determine their own processes for appointing RSAB members (note that
    processes related to the RSCE are described in Section 5).

SECTION 3.2.3

This line break in the TXT and PDF formats seems unfortunate:

TXT

    such input by, at a minimum, sending a notice to the rfc-
    [e-mail] (mailto:[e-mail]) email

PDF

    ... sending a notice to the rfc-interest@rfc-
    editor.org email discussion list

Perhaps we could structure the text such that the email address does not 
break across lines?

SECTION 4.1

OLD

    Such
    performance targets are set based on the RPC's publication load and
    additional efforts required to implement policies specified in the
    Editorial Stream, in existing RFCs that apply to the RPC and have not
    yet been superseded by Editorial Stream RFCs, and in the requisite
    contracts.

NEW

    Such
    performance targets are set based on the RPC's publication load and
    additional efforts required to implement policies specified in
    Editorial Stream RFCs, in existing RFCs that apply to the RPC and
    have not yet been superseded by Editorial Stream RFCs, and in the
    requisite contracts.

RATIONALE: changing "the Editorial Stream" to "Editorial Stream RFCs" is 
slightly clearer.

SECTION 4.5

Here again we have an unfortunate line break for an email address:

TXT

    Series.  Such inquiries should be directed to the rfc-editor@rfc-
    editor.org (mailto:[e-mail]) email alias or to its

PDF

    Such inquiries should be directed to the rfc-
    [e-mail] email alias

Perhaps these can be adjusted?

ACKNOWLEDGEMENTS

Let's please alphabetize the following names:

OLD

    and earlier proposals submitted within the IAB's RFC Editor
    Future Development Program by Martin Thomson, Brian Carpenter, and
    Michael StJohns.

NEW

    and earlier proposals submitted within the IAB's RFC Editor
    Future Development Program by Brian Carpenter, Michael StJohns, and
    Martin Thomson.

(BTW, thanks for fixing Dürst and Kühlewind.)

Finally, I've thought further about the following:

>>>>>>> RFC Series Policy Definition process vs. policy definition process
>>>>>>
>>>>>> I would prefer not to make that change.

I would prefer "RFC Series Policy Definition Process" (with an uppercase 
"P") in all instances, because this is a "thing" that will be referenced 
in the boilerplace of all future Editorial Stream RFCs.

For the avoidance of doubt, I suggest that we add the following sentence 
to Section 3.2 (before Section 3.2.1):

    This section specifies the RFC Series Policy Definition Process,
    which shall be followed in producing all Editorial Stream RFCs.

Just so you know, I have reviewed all formats including the XML.

Thanks again!

Peter