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

[Rebecca VanRheenen <[e-mail]>]

Hi Peter,

As you requested, we will wait to make changes per your proposed edits until you receive input from the Program chairs and IAB. Please let us know when you are ready for us to make updates.

We did want to address these two questions:

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

We can use &nbhy; to prevent these from breaking across lines. We added &nbhy; in both instances and reposted the files so that you can see what the output looks like. We believe this does improve the txt and pdf outputs; let us know if you agree.

Updated files:
  https://www.rfc-editor.org/authors/rfc9280.txt
  https://www.rfc-editor.org/authors/rfc9280.pdf
  https://www.rfc-editor.org/authors/rfc9280.html
  https://www.rfc-editor.org/authors/rfc9280.xml

Diff files: 
  https://www.rfc-editor.org/authors/rfc9280-diff.html (comprehensive diff)
  https://www.rfc-editor.org/authors/rfc9280-rfcdiff.html (side-by-side comprehensive diff)
  https://www.rfc-editor.org/authors/rfc9280-auth48diff.html (shows AUTH48 changes)

For the AUTH48 status of this document, please see:
  https://www.rfc-editor.org/auth48/rfc9280

Thank you!
RFC Editor/rv




> On Jun 23, 2022, at 11:33 AM, Peter Saint-Andre <[e-mail]> wrote:
> 
> 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
>