Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in GitHub issues (see https://github.com/rfc-editor/AUTH48-rfc9920/issues).
1) <!--[rfced] FYI: We updated the abbreviated title as follows to align with the title of the document. Note that the abbreviated title only appears in the PDF output (in the header at the top of each page). It does not appear in the TXT or HTML outputs. Original: RFC 9280 updates Updated: RFC Editor Model --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!-- [rfced] Because this document updates RFCs 7991, 7996, and 7997, please review the errata reported for these RFCs and let us know if you confirm our opinion that none of them are relevant to the content of this document. Links to errata: https://www.rfc-editor.org/errata/rfc7991 https://www.rfc-editor.org/errata/rfc7996 https://www.rfc-editor.org/errata/rfc7997 --> 4) <!-- [rfced] FYI: We have removed the following text from the Abstract as this document is no longer a draft. Original: This draft is part of the RFC Series Working Group (RSWG); see <https://datatracker.ietf.org/edwg/rswg/documents/>. There is a repository for this draft at <https://github.com/paulehoffman/9280-updates>. --> 5) <!--[rfced] We note that this document says it "establishes", "specifies", and "creates" the Editorial Stream. Should any of these instances be updated for consistency (perhaps use "specifies")? Current: (Abstract): Finally, this document establishes the Editorial Stream for publication of future policy definition documents produced through the processes defined herein. (Introduction): This document specifies a fifth stream, the Editorial Stream, for publication of policies governing the RFC Series as a whole. (Section 6): This document creates the Editorial Stream as a separate space for publication of policies, procedures, guidelines, rules, and related information regarding the RFC Series as a whole. (Section 9.7) This document specifies the Editorial Stream in addition to the streams already described in [RFC8729]. --> 6) <!--[rfced] Paragraphs 3 and 4 of Section 1 both state that this document "defines version 3 of the RFC Editor Model". Should this sentence in paragraph 4 be removed to avoid repetition? 3rd paragraph (for reference): The overall framework for the RFC Series and the RFC Editor function is described in [RFC8729] and is updated by this document, which defines version 3 of the RFC Editor Model. Under this version ... Original (4th paragraph): This document defines version 3 of the RFC Editor Model. This document updates [RFC7841] by defining boilerplate text for the Editorial Stream... Perhaps (4th paragraph): This document updates [RFC7841] by defining boilerplate text for the Editorial Stream... --> 7) <!--[rfced] We note that both the header and the Abstract list the RFCs that this document updates (i.e., RFCs 7991, 7992, 7993, 7994, 7995, 7996, 7997, 8729, and 9720). However, the last paragraph of the Introduction says that this document updates RFCs 7841, 8729, and 8730. Note that RFCs 7841 and 8730 are not included in the header's update list and the other documents in the header's update list are not mentioned in this paragraph. (RFCs 7841, 8729, and 8730 were updated by RFC 9280.) Please review and let us know if any changes are needed. Current: This document updates [RFC7841] by defining boilerplate text for the Editorial Stream. This document updates [RFC8729] by replacing the RFC Editor role with the RSWG, RSAB, and RSCE. This document updates [RFC8730] by removing the dependency on certain policies specified by the IAB and RFC Series Editor (RSE). --> 8) <!-- [rfced] This document contains key words, so we included the 2119/8174 boilerplate at the end of Section 1 (immediately before Section 1.1) and added RFCs 2119 and 8174 as normative references. Please let us know if you prefer that this boilerplate be placed in a different location in the document (e.g., as Section 1.1). --> 9) <!-- [rfced] FYI - We added quote tagging in the .md file in a few places (notably in Sections 1.2-1.4). This produces <blockquote> in the XML file, which is used for direct quotes as well as OLD/NEW text. --> 10) <!-- [rfced] Sections 1.2.3 and 1.3.2 are both about entire new sections that have been added in this document. Instead of repeating the entire section in two places in the document, would you like to include a summary in these sections with pointers to the body of the document? Perhaps: 1.2.3. RFC Consumers Section 3.3 was added to define the term "consumers of RFCs" and set relevant policy in respect to consumers of RFCs. Perhaps: 1.3.2. Consistency Policy Section 7.8 was added to define the policy reissuing an RFC to maintain a consistent presentation. --> 11) <!--[rfced] Should "might" be updated to "can" in this sentence? Original: As these structures and processes have been exercised, the community has found places where they might be improved. Perhaps: As these structures and processes have been exercised, the community has found places where they can be improved. --> 12) <!-- [rfced] The parentheticals below appear in the body of the document. Because the new text is defined and explained earlier in the document, may we remove these parentheticals? It improves readability. Section 3: (The text in the next paragraph is added by Section 1.4.) Section 3.3: (The text in this section is added by Section 1.2.3.) Section 4.3: (The text in the next two paragraphs is added by Section 1.2.1.) Section 4.4: (The text in the next paragraph is added by Section 1.2.2.) Section 7.6: (The text in this section is updated by Section 1.3.1.) Section 7.8: (The text in this section is added by Section 1.3.2.) Note that if these parentheticals are removed, the following sentence in Section 1.1 will need to be updated. Original: The rest of this introduction is a list of changes to RFC 9280. Those changes are instantiated in the rest of the document, with cross-references between the list of changes and the main body. Perhaps: The rest of this introduction is a list of changes to RFC 9280, which are instantiated in the rest of the document. --> 13) <!-- [rfced] FYI: In Section 1.2.1, we added "[RFC8711]" to the end of this sentence to match the text in Section 2 of this document and RFC 9280. Current: Section 2 states: | Policy implementation through publication of RFCs in all of the | streams that form the RFC Series. This is primarily the | responsibility of the RFC Production Center (RPC) as contractually | overseen by the IETF Administration Limited Liability Company | (IETF LLC) [RFC8711]. --> 14) <!-- [rfced] References to Sections a) In Section 1.2.1, per the context, we believe that Sections 3.1.1.2 and 3.2.1 are referring to RFC 9280, so we have updated the text as shown below for clarity. If this is not correct, please let us know. Original: RFC 9280 mentions tool developers twice. In Section 3.1.1.2, it encourages "developers of tools used to author or edit RFCs and Internet-Drafts" to participate in the RSWG. Section 3.2.1 says that "RSAB members should consult with their constituent stakeholders (e.g., authors, editors, tool developers, and consumers of RFCs) on an ongoing basis". Current: [RFC9280] mentions tool developers twice. Section 3.1.1.2 of [RFC9280] encourages "developers of tools used to author or edit RFCs and Internet-Drafts" to participate in the RSWG. Section 3.2.1 of [RFC9280] says that "RSAB members should consult with their constituent stakeholders (e.g., authors, editors, tool developers, and consumers of RFCs) on an ongoing basis". b) Please review the following section pointers in Sections 1.2.1, 1.2.2, and 1.4. Would updating to either "Section X of this document" or "Section X of [RFC9280]" improve clarity and be more precise? Note that currently, these section pointers link to the section in this document in the HTML and PDF outputs. Current: Section 2 states: ... Section 4.4 provides a pathway for resolution of conflicts between the RPC and the author(s) of a specific document. ... Section 3 says: --> 15) <!-- [rfced] Will readers understand what "text and graphical formats" means here? Does "graphical formats" refer to the HTML and PDF outputs or to something else? Also, we suggest using "and" rather than "or" in this sentence. Original: The RPC is responsible for detailed technical specifications, for example specific details of text or graphical formats or XML grammar. Perhaps: The RPC is responsible for detailed technical specifications, for example, specific details of the publication formats and XML grammar. --> 16) <!--[rfced] This document updates RFC 9720. Will this sentence be clear to readers as is, or should the "updates" text be restated here for clarity? Also, we updated the section title as shown below (i.e., we used "to" rather than "from" and the RFC number rather than title) to align with other section titles in the document. Let us know any concerns. Current: 1.3. Updates from "RFC Formats and Versions" [RFC9720], "RFC Formats and Versions", updated [RFC9280]. Perhaps: 1.3. Updates to RFC 9720 [RFC9720], "RFC Formats and Versions", updates [RFC9280]. This document updates [RFC9720]. --> 17) <!-- [rfced] FYI: Since RFC 7990 has been removed from this document, we have updated the title of Section 1.5 accordingly. Original: 1.5 Updates to RFCs 7990 through 7997 Current: 1.5 Updates to RFCs 7991 through 7997 --> 18) <!-- [rfced] The URL in this paragraph redirects to this URL: https://datatracker.ietf.org/group/iesg/statements/. Is this the intended page this URL is meant to point to or is an update needed? Note that there are four links titled "Guidance on Face-to-Face and Virtual Interim Meetings" at the redirected URL, but they have all been superseded. Current: The RSWG is empowered to hold in-person, online-only, or hybrid meetings, which should be announced with sufficient notice to enable broad participation; the IESG Guidance on Face-to-Face and Virtual Interim Meetings (https://www.ietf.org/about/groups/iesg/statements/interim-meetings-guidance-2016-01-16/) provides a reasonable baseline. In-person meetings should include provision for effective online participation for those unable to attend in person. --> 19) <!-- [rfced] Is "RFC Editor" correct here, or should it be updated to "RFC Editor function" or something else? Original: The policy to be followed by the RFC publication streams and RFC Editor in respect of consumers of RFCs is as follows: --> 20) <!--[rfced] Although this sentence appeared in RFC 9280, perhaps the readability could be improved by including parentheses as shown below. Let us know your thoughts. Original: Several responsibilities previously assigned to the RFC Editor or, more precisely, the RFC Editor function, are now performed by the RSWG, RSAB, RPC, RSCE, and IETF LLC (alone or in combination). Perhaps: Several responsibilities previously assigned to the RFC Editor (or more precisely, the RFC Editor function) are now performed by the RSWG, RSAB, RPC, RSCE, and IETF LLC (alone or in combination). --> 21) <!--[rfced] In the second sentence, it is correct that this document "establishes" the RSAB, or should it be "describes" or "specifies"? Original: (The RSAG is not to be confused with the RFC Series Approval Board (RSAB), which this document establishes.) Perhaps: (The RSAG is not to be confused with the RFC Series Approval Board (RSAB), which this document specifies.) --> 22) <!--[rfced] We updated the following terms to the form on the right for consistency with RFC 9280. Please let us know if that is not desired. Acknowledgement(s) -> Acknowledgment(s) Editorial stream and editorial stream -> Editorial Stream --> 23) <!--[rfced] Abbreviations a) We note that "IAB", "IRTF", "IESG", and "IRSG" are the only acronyms not expanded. We assume that this is intentional because they are well known; however, since other well-known abbreviations have been expanded, please confirm whether or not these should be expanded on their first mention for consistency. First mentions: IAB (Section 1) IRTF (Section 1.2.3) IESG (Section 3.1.1.2) IRSG (Section 4.4) b) We note that "RPC", "RSWG", and "RSAB" appear both in the expanded form with the abbreviation and as the abbreviation only, and there doesn't seem to be a pattern. Is this intentional, or would you like to use the abbreviated forms after the first expansion in the document? --> 24) <!-- [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. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. Karen Moore and Rebecca VanRheenen RFC Production Center On Dec 24, 2025, at 11:44 AM, [email protected] wrote: *****IMPORTANT***** Updated 2025/12/24 RFC Author(s): -------------- Your document has now entered AUTH48. The document was edited in kramdown-rfc as part of the RPC pilot test (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). AUTH48 is being handled in GitHub as part of the GitHub pilot test (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test). Your document is available for review at: https://github.com/rfc-editor/AUTH48-rfc9920 Please see the README for details on the AUTH48 process: https://github.com/rfc-editor/AUTH48-rfc9920/blob/Approved/README.md Once the content of the .md file is stable, we will convert it to .xml and provide the .html, .pdf, .txt, and .xml files for review. You and your coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Once the document has been reviewed and approved by all of the authors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
