Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!-- [rfced] We wonder about trimming this sentence down for simplicity. Original: [RFC7990] defined a framework for how RFCs would be published after that document was published, including new formats and a new "canonical format" for archiving RFCs. Perhaps A: [RFC7990] defined a framework for how RFCs would be published. Or perhaps B: [RFC7990] defined a framework for how RFCs would be published, including new "publication formats" and a new "canonical format". --> 3) <!-- [rfced] If no objections, we will use a definition list under the first bullet in Section 1.1. Original: * It defines four terms that replace the use of the term "canonical" and clarifies "format": - The "definitive format", which is RFCXML - The "definitive version", which is a published RFC in the definitive format - A "publication format", which is currently one of PDF, plain text, or HTML - A "publication version", which is a published RFC in one of the publication formats Perhaps: * It defines four terms that replace the use of the term "canonical" and clarifies "format": definitive format: RFCXML definitive version: a published RFC in the definitive format publication format: currently one of PDF, plain text, or HTML publication version: a published RFC in one of the publication formats --> 4) <!-- [rfced] Does "to maintain a consistent presentation" apply to all verbs (in which case, "published" seems odd)? Please review. Original: 7.8. Consistency RFCs are copyedited, formatted, published, and may be reissued to maintain a consistent presentation. Perhaps A (two sentences): RFCs are copyedited, formatted, and then published. They may be reissued to maintain a consistent presentation. Perhaps B (remove "published"): RFCs are copyedited and formatted and may be reissued to maintain a consistent presentation. --> 5) <!-- [rfced] Should "updated policy" here be updated to "new policy"? Original: Section 2.1 and Section 3 in this document are based on this updated policy in [RFC9280]. Perhaps: Sections 2.1 and 3 in this document are based on this new policy in [RFC9280]. --> 6) <!-- [rfced] Please review "following the guidance of the group of RFCs described in [RFC7990]". Are any updates needed for clarity? Original: The first RFC to be published following the guidance of the group of RFCs described in [RFC7990] was [RFC8651], published in October 2019. Perhaps: The first RFC to be published following the guidance in [RFC7990] was [RFC8651], published in October 2019. --> 7) <!-- [rfced] Is "publication formats" correct here? We ask because Section 3 is titled "Publication Versions". Also, would it be helpful to include references for the other RFCs that specify these? Original: The publication formats are described in Section 3 and fully specified in other RFCs. --> 8) <!-- [rfced] Please review "The definitive version...is the publication version". Should this be updated as follows? Original: The definitive version produced by the RPC is the publication version that holds all the information intended for an RFC. Perhaps: The definitive version produced by the RPC holds all the information intended for an RFC. --> 9) <!-- [rfced] Should "HTML publication versions" be singular? Original: That SVG will also appear in the HTML publication versions. --> 10) <!-- [rfced] To avoid personifying "updates" (updates consider, take steps, limit), we suggest the following. Original: Instead, it only requires that such updates consider the potential for semantic changes, take steps to understand the risk of a semantic change (either deliberate or inadvertent), and to limit those risks. Original: Instead, considering the potential for semantic changes, taking steps to understand the risk of a semantic change (either deliberate or inadvertent), and limiting associated risks are the only requirements. --> 11) <!-- [rfced] Should "definitive versions" here be singular (i.e., "definitive version")? Original: Allowing changes to the definitive versions and publication versions of RFCs introduces risks. Perhaps: Allowing changes to the definitive version and publication versions of RFCs introduces risks. --> 12) <!-- [rfced] Would it be helpful to either add numbers or use two sentences here to improve clarity? Original: A significant risk is that unintended changes could occur in either the definitive version or publication versions of an RFC as a result of an editing error, or may be introduced into a publication version when it is regenerated from the definitive version. Perhaps (add numbers): A significant risk is that unintended changes could 1) occur in either the definitive version or publication versions of an RFC as a result of an editing error or 2) be introduced into a publication version when it is regenerated from the definitive version. Or (split into two sentences): A significant risk is that unintended changes could occur in either the definitive version or publication versions of an RFC as a result of an editing error. In addition, unintended changes may be introduced into a publication version when it is regenerated from the definitive version. --> 13) <!-- [rfced] To improve clarity, may we update the text starting with "and harm" as follows? Original: This may result in the corruption of a standard, practice, or critical piece of information about a protocol, and harm to the reputation of the RFC series. Perhaps: This may result in the corruption of a standard, practice, or critical piece of information about a protocol, which may harm the reputation of the RFC Series. --> 14) <!-- [rfced] Would you like to use a consistent ordering when referring to the publication formats? We see the following (also note "text" and "plain text"): HTML, text, and PDF PDF, plain text, or HTML HTML, PDF, and plain text --> 15) <!-- [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. RFC Editor On Jan 10, 2025, at 3:53 PM, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/01/10 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, 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/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-edi...@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9720.xml https://www.rfc-editor.org/authors/rfc9720.html https://www.rfc-editor.org/authors/rfc9720.pdf https://www.rfc-editor.org/authors/rfc9720.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9720-diff.html https://www.rfc-editor.org/authors/rfc9720-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9720-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9720 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9720 (draft-rswg-rfc7990-updates-12) Title : RFC Formats and Versions Author(s) : P. Hoffman, H. Flanagan WG Chair(s) : Area Director(s) : -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
