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

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

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