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

[Brian Rosen <[e-mail]>]

I am fine with all these changes. The document is looking good.

Brian

On Sat, Jun 25, 2022 at 1:22 AM Rebecca VanRheenen <[e-mail]>
wrote:

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