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

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

Oh, I like "email discussion list". If you would be so kind as to make 
that change, I'll then review the complete document.

Thanks, Rebecca!

Peter

On 6/21/22 11:14 PM, Rebecca VanRheenen wrote:
> Hi Peter,
> 
> Thank you for including the correct email address for Eliot.
> 
> We updated the document per your responses to our followup questions. While making the change from “email list” to “discussion list”, we noted that the document includes several instances of “email discussion list”. Are these okay as is, or do you prefer “discussion list” for these as well? Aside from this, the only other open issue is the possible IAB note. We’ll wait to hear what the IAB decides on this.
> 
> 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 21, 2022, at 1:53 PM, Peter Saint-Andre <[e-mail]> wrote:
>>
>> Thanks, Rebecca. Comments inline.
>>
>> (Also adding the correct email address for Eliot...)
>>
>> On 6/21/22 9:16 AM, Rebecca VanRheenen wrote:
>>> Peter,
>>> Thank you for your reply. We have updated the document and added the keywords to our database. We have a few followup questions:
>>> 1)
>>>>> 1) <!-- [rfced] Please review the guidance for IAB documents
>>>>> <https://www.rfc-editor.org/materials/iab-format.txt>.
>>>>> Based on this, we believe that this document should include a section titled
>>>>> "IAB Members at the Time of Approval". Is this correct? Are any additional
>>>>> changes needed?  -->
>>>>
>>>> Eliot -
>>>> Yes.  That is the rule of the stream, and the IAB did approve the document.  The IAB may wish to add a note indicating that the document was approved based on the rough consensus of an open program.
>>>> Peter-
>>>> I agree with Eliot's assessment.
>>> We added the section titled "IAB Members at the Time of Approval” and included the names that currently appear at https://www.iab.org/about/iab-members/. Please confirm that this is correct.
>>> If the IAB chooses to include a note as Eliot mentions, please provide text for that and indicate where to place it in the document.
>>> 2)
>>>>> 7) <!-- [rfced] Would it be helpful to include the address for the
>>>>> "rfc-interest" email list? Or do you prefer not to in case it is replaced in
>>>>> the future?
>>>>> Original:
>>>>>     The RSAB seeks
>>>>>     such input by, at a minimum, sending a notice to the "rfc-interest"
>>>>>     email list or to its successor or future equivalent.
>>>>> -->
>>>>
>>>> Yes, let's change it to:
>>>>
>>>>    The RSAB seeks such input by, at a minimum, sending a notice to the
>>>>    [e-mail] email list or to its successor or future
>>>>    equivalent.
>>>>
>>>> Do we have a convention on "email list" vs. "discussion list"? I recall that, for instance, in RFC 8141 we refer to "the [e-mail] discussion list".
>>> We updated this sentence to include [e-mail]. Note that we used <eref> with “mailto:” as was done elsewhere in the document for [e-mail]. The output looks different in the txt vs the html/pdf outputs, so please review.
>>> Both "email list” and "discussion list” have been used in published RFCs. We will go with your preference.
>>
>> Thanks. I have a slight preference for "discussion list".
>>
>>> 3)
>>>>> b) We note inconsistencies in the terms below throughout the text.  Should
>>>>> these be uniform? If so, please let us know which form is preferred.
>>>>> "RFC Editor" vs. RFC Editor
>>>>> "RFC Editor Function" vs. RFC Editor Function
>>>>> "YES" vs. YES
>>>>> "CONCERN" vs. CONCERN
>>>>>    Note: Decision for YES and CONCERN will also be applied
>>>>>    to RECUSE (only one instance in document).
>>>>
>>>> Those are all good.
>>>>
>>>>> RFC Series Policy Definition process vs. policy definition process
>>>>
>>>> I would prefer not to make that change.
>>>>
>>>>> IETF LLC Executive Director vs. IETF Executive Director
>>>>
>>>> Good catch.
>>> For the terms above, which form do you prefer? The form on the right, except for "RFC Series Policy Definition process vs. policy definition process”? Are any updates need for "RFC Series Policy Definition process vs. policy definition process”?
>>
>> For the sake of consistency, let's change the one instance of "policy definition process" (in step 3 of Section 3.2.2) to "RFC Series Policy Definition process".
>>
>>> 4) Please review "reserved to” in the following sentence. Would one of the following options improve this sentence?
>>> Original:
>>>     (Note that the Editorial Stream is not authorized to
>>>     publish RFCs that are Standards Track or Best Current Practice, since
>>>     such RFCs are reserved to the IETF Stream [RFC8729].)
>>> Perhaps:
>>>    (Note that the Editorial Stream is not authorized to
>>>     publish RFCs that are Standards Track or Best Current Practice, since
>>>     such RFCs are only published in the IETF Stream [RFC8729].)
>>> Or:
>>>    (Note that the Editorial Stream is not authorized to
>>>     publish RFCs that are Standards Track or Best Current Practice, since
>>>     such statuses are reserved for the IETF Stream [RFC8729].)
>>
>> Let's change "reserved to" to "reserved for".
>>
>> Peter
>>
>>> ____________________
>>> 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 18, 2022, at 12:30 PM, Peter Saint-Andre <[e-mail]> wrote:
>>>>
>>>> Hi, see comments inline.
>>>>
>>>> On 6/17/22 9:58 PM, [e-mail] wrote:
>>>>> [resending to CC [e-mail]]
>>>>> Peter,
>>>>> While reviewing this document during AUTH48, please resolve (as necessary)
>>>>> the following questions, which are also in the XML file.
>>>>> 1) <!-- [rfced] Please review the guidance for IAB documents
>>>>> <https://www.rfc-editor.org/materials/iab-format.txt>.
>>>>> Based on this, we believe that this document should include a section titled
>>>>> "IAB Members at the Time of Approval". Is this correct? Are any additional
>>>>> changes needed?  -->
>>>>
>>>> I agree with Eliot's assessment.
>>>>
>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
>>>>> title) for use on https://www.rfc-editor.org/search. -->
>>>>
>>>> Perhaps:
>>>>
>>>> editorial
>>>> publication
>>>> RFC
>>>> series
>>>> streams
>>>>
>>>>> 3) <!-- [rfced] For clarity, we suggest the following update:
>>>>> Original:
>>>>>     All interested individuals are welcome to participate in the RSWG
>>>>>     (subject to anti-harassment policies as described under
>>>>>     Section 3.2.5).
>>>>> Perhaps:
>>>>>     All interested individuals are welcome to participate in the RSWG;
>>>>>     participants are subject to anti-harassment policies as described
>>>>>     in Section 3.2.5.
>>>>> -->
>>>>
>>>> Yes - especially because Eliot dislikes parentheses. ;-)
>>>>
>>>>> 4) <!-- [rfced] Would revising the first four bullet points as follows make
>>>>> this list easier to read? Or do you prefer the original?
>>>>> Original:
>>>>>     The RSAB consists primarily of the following voting members:
>>>>>     *  As the stream representative for the IETF stream, an IESG member
>>>>>        or other person appointed by the IESG
>>>>>     *  As the stream representative for the IAB stream, an IAB member or
>>>>>        other person appointed by the IAB
>>>>>     *  As the stream representative for the IRTF stream, the IRTF chair
>>>>>        or other person appointed by the IRTF Chair
>>>>>     *  As the stream representative for the Independent stream, the
>>>>>        Independent Submissions Editor (ISE) [RFC8730] or other person
>>>>>        appointed by the ISE
>>>>>     *  The RFC Series Consulting Editor (RSCE)
>>>>> Perhaps:
>>>>>     The RSAB consists primarily of the following voting members:
>>>>>     *  A stream representative for the IETF Stream (an IESG member
>>>>>        or other person appointed by the IESG)
>>>>>     *  A stream representative for the IAB Stream (an IAB member or
>>>>>        other person appointed by the IAB)
>>>>>     *  A stream representative for the IRTF Stream (the IRTF Chair
>>>>>        or other person appointed by the IRTF Chair)
>>>>>     *  A stream representative for the Independent Stream (the
>>>>>        Independent Submissions Editor (ISE) [RFC8730] or other person
>>>>>        appointed by the ISE)
>>>>>     *  The RFC Series Consulting Editor (RSCE)
>>>>> -->
>>>>
>>>> Or perhaps:
>>>>
>>>>    The RSAB consists primarily of the following voting members:
>>>>
>>>>    *  A stream representative for the IETF Stream: either an IESG member
>>>>       or someone appointed by the IESG
>>>>
>>>>    *  A stream representative for the IAB Stream: either an IAB member
>>>>       or someone appointed by the IAB
>>>>
>>>>    *  A stream representative for the IRTF Stream: either the IRTF Chair
>>>>       or someone appointed by the IRTF Chair
>>>>
>>>>    *  A stream representative for the Independent Stream: either the
>>>>       Independent Submissions Editor (ISE) [RFC8730] or someone
>>>>       appointed by the ISE
>>>>
>>>>    *  The RFC Series Consulting Editor (RSCE)
>>>>
>>>>> 5) <!-- [rfced] Would it be helpful to add a section reference here?
>>>>> Also, may we revise this sentence as shown below for clarity?
>>>>> Original:
>>>>>     Note: this method of
>>>>>     handling vacancies does not apply to a vacancy of the RSCE role,
>>>>>     only of the stream representatives enumerated above.
>>>>> Perhaps:
>>>>>     Note that this method of
>>>>>     handling vacancies does not apply to a vacancy of the RSCE role; it only
>>>>>     applies to vacancies of the stream representatives enumerated in Section
>>>>>     3.1.2.2.
>>>>> -->
>>>>
>>>> That's better, thanks.
>>>>
>>>>> 6) <!-- [rfced] Please review "The RSWG may adopt the proposal as a draft
>>>>> proposal of the RSWG". Should this read "The RSWG may adopt the proposal
>>>>> as a working group item" (similar to preceding bullet point)?
>>>>
>>>> This consistency of terminology seems preferable.
>>>>
>>>>> Also,
>>>>> should "draft" in the second sentence be updated to either "proposal" or
>>>>> "document", both of which are also used in this section?
>>>>
>>>> I assume you refer here to step 6 of the workflow.
>>>>
>>>> Therefore I think you are suggesting as follows (which seems good to me)...
>>>>
>>>>> Original:
>>>>>     2.   The RSWG may adopt the proposal as a draft proposal of the RSWG,
>>>>
>>>> s/draft proposal of the RSWG/working group item/
>>>>
>>>>>          if the chairs determine (by following working group procedures
>>>>>          for rough consensus) that there is sufficient interest in the
>>>>>          proposal; this is similar to the way a working group of the IETF
>>>>>          would operate (see [RFC2418])
>>>>>     ...
>>>>>     If substantial comments are received in response
>>>>>     to the community call for comments, the RSAB may return the
>>>>>     draft to the RSWG to consider those comments and make revisions
>>>>
>>>> s/draft/proposal/
>>>>
>>>>>     to address the feedback received.  	
>>>>> -->
>>>>> 7) <!-- [rfced] Would it be helpful to include the address for the
>>>>> "rfc-interest" email list? Or do you prefer not to in case it is replaced in
>>>>> the future?
>>>>> Original:
>>>>>     The RSAB seeks
>>>>>     such input by, at a minimum, sending a notice to the "rfc-interest"
>>>>>     email list or to its successor or future equivalent.
>>>>> -->
>>>>
>>>> Yes, let's change it to:
>>>>
>>>>    The RSAB seeks such input by, at a minimum, sending a notice to the
>>>>    [e-mail] email list or to its successor or future
>>>>    equivalent.
>>>>
>>>> Do we have a convention on "email list" vs. "discussion list"? I recall that, for instance, in RFC 8141 we refer to "the [e-mail] discussion list".
>>>>
>>>>> 8) <!-- [rfced] Please confirm that "in its charter [RFC8711]" is correct. We
>>>>> ask because we do not see "charter" in general text in RFC 8711.
>>>>> Original:
>>>>>     The IETF LLC is ultimately answerable to the
>>>>>     community via the mechanisms outlined in its charter [RFC8711].
>>>>> Perhaps:
>>>>>     The IETF LLC is ultimately answerable to the
>>>>>     community via the mechanisms outlined in [RFC8711].
>>>>> -->
>>>>
>>>> Yes, let's make your proposed change.
>>>>
>>>>> 9) <!-- [rfced] Would it be helpful to add a section number here? Perhaps
>>>>> "specified in Section 3 of this document"?
>>>>
>>>> That seems fine.
>>>>
>>>>> Original:
>>>>>     Any changes
>>>>>     to this boilerplate must be made through the RFC Series Policy
>>>>>     Definition process specified in this document.
>>>>> -->
>>>>> 10) <!-- [rfced] FYI - The long list of names in the Acknowledgments is mostly
>>>>> in alphabetical order. We made one change to ensure this order.
>>>>> -->
>>>>
>>>> Thanks - I might have missed one.
>>>>
>>>>> 11) <!-- [rfced] XML formatting
>>>>> a) We added <eref> to the URL used in this sentence. Please review
>>>>> both the hmtl/pdf and txt outputs to ensure that this appears correctly. In
>>>>> the html/pdf output, the text "IETF's IPR disclosure mechanism" is linked.
>>>>> Original:
>>>>>     The Editorial
>>>>>     Stream has chosen to use the IETF's IPR disclosure mechanism,
>>>>>     https://www.ietf.org/ipr/, for this purpose.
>>>>
>>>> LGTM.
>>>>
>>>>> b) FYI - We removed two instances of <br/>.
>>>>
>>>> I suppose that the Markdown tooling added those? In any case, that's fine.
>>>>
>>>>> -->
>>>>> 12) <!-- [rfced] Terminology
>>>>> a) We note inconsistencies in the term listed below. We chose the form on the
>>>>> right.  Please let us know any objections.
>>>>> "Informational" vs. Informational
>>>>
>>>> Fine.
>>>>
>>>>> b) We note inconsistencies in the terms below throughout the text.  Should
>>>>> these be uniform? If so, please let us know which form is preferred.
>>>>> "RFC Editor" vs. RFC Editor
>>>>> "RFC Editor Function" vs. RFC Editor Function
>>>>> "YES" vs. YES
>>>>> "CONCERN" vs. CONCERN
>>>>>    Note: Decision for YES and CONCERN will also be applied
>>>>>    to RECUSE (only one instance in document).
>>>>
>>>> Those are all good.
>>>>
>>>>> RFC Series Policy Definition process vs. policy definition process
>>>>
>>>> I would prefer not to make that change.
>>>>
>>>>> IETF LLC Executive Director vs. IETF Executive Director
>>>>
>>>> Good catch.
>>>>
>>>>> c) May we lowercase "Patent" and "Trademark" here?
>>>>> Original:
>>>>>     This includes the disclosure of Patent and Trademark issues that are
>>>>>     known, or can be reasonably expected to be known, to the contributor.
>>>>
>>>> I copied that text from another RFC and I'm not sure if there was any meaning to the initial capitalization, but I don't see the need for it.
>>>>
>>>>> d) Would it be helpful to readers to expand the acronym RFP? If so, may we use
>>>>> the expansion "Request for Proposal"?
>>>>
>>>> Yes, please.
>>>>
>>>>> Original:
>>>>>     *  The IETF LLC establishes the contract process, including the steps
>>>>>        necessary to issue an RFP when necessary, the timing, and the
>>>>>        contracting procedures.
>>>>>        e) We would like to update "the Model" to "the model" in the first sentence
>>>>> below and to "the RFC Editor Model" in the rest of the sentences. Please
>>>>> let us know any concerns.
>>>>
>>>> In RFC 8728, the authors used "the model" so I think that's appropriate here, as well.
>>>>
>>>>> Original:
>>>>>     The Model
>>>>>     defines two high-level tasks related to the RFC Series.
>>>>>     ...
>>>>>     More detailed information about changes from version 2 of the Model
>>>>>     can be found under Section 9.
>>>>>     ...
>>>>>     More specifically, the responsibilities of the RFC
>>>>>     Series Consulting Editor (RSCE) under version 3 of the RFC Editor
>>>>>     Model differ in many ways from the responsibilities of the RFC Series
>>>>>     Editor under version 2 of the Model.
>>>>>     ...
>>>>>     Under version 2
>>>>>     of the Model, the IAB delegated some of its authority to the RFC
>>>>>     Series Oversight Committee (see Section 9.5).
>>>>>     ...
>>>>>     Under version 3 of the
>>>>>     Model, authority for policy definition resides with the RSWG as an
>>>>>     independent venue for work by members of the community (with approval
>>>>>     of policy proposals as the responsibility of the RSAB, representing
>>>>>     the streams and including the RSCE), whereas authority for policy
>>>>>     implementation resides with the IETF LLC.
>>>>>     ...
>>>>>     Version 1 of the RFC Editor Model [RFC5620] specified the existence
>>>>>     of the RFC Series Advisory Group (RSAG), which was no longer
>>>>>     specified in version 2 of the Model.
>>>>> f) We updated the numeral to the word form here. Please let us know if you
>>>>> would like to add the numeral in parentheses after the first instance as we
>>>>> see this was done elsewhere in the document.
>>>>> Original:
>>>>>     *  Voting on approval of policy documents produced by the RSWG shall
>>>>>        be delayed until the vacancy or vacancies have been filled, up to
>>>>>        a maximum of 3 months.  If during this 3-month period a further
>>>>>        vacancy arises, the delay should be extended by up to another 3
>>>>>        months.  After the delay period expires, the RSAB should continue
>>>>>        to process documents as described below.
>>>>> Updated:
>>>>>     *  Voting on approval of policy documents produced by the RSWG shall
>>>>>        be delayed until the vacancy or vacancies have been filled, up to
>>>>>        a maximum of three months.  If a further vacancy arises during
>>>>>        this three-month period, the delay should be extended by up to
>>>>>        another three months.
>>>>> -->
>>>>
>>>> WFM.
>>>>
>>>>> 13) <!-- [rfced] Please review the "Inclusive Language" portion of the online
>>>>> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>>>>> and let us know if any changes are needed. Note that our script did not flag any terms or phrases.
>>>>> -->
>>>>
>>>> I didn't see anything there, either.
>>>>
>>>> Peter
>>>>
>>
>