Hi Kent, Thank you for your reply! Once I get AD approval, I'll be able to move this draft forward.
Sincerely, Sarah Tarrant RFC Production Center > On Feb 4, 2026, at 9:01 AM, Kent Watsen <[email protected]> wrote: > > Hi Sarah, > > >> On Feb 3, 2026, at 1:08 PM, Sarah Tarrant <[email protected]> >> wrote: >> >> Hi Kent, >> >> Very good! We're just waiting on AD approval. >> >> In the meantime, could you answer the questions we had on the intake form? > > Please see responses below. > > Kent > > >>> 1) As there may have been multiple updates made to the document during Last >>> Call, >>> please review the current version of the document: >>> >>> * Is the text in the Abstract still accurate? >>> * Are the Authors' Addresses, Contributors, and Acknowledgments >>> sections current? > > I found a typo in the Abstract (the entire last sentence was redundant). > Also, > I thought it best to align the Abstract with the Introduction. For these > reasons, > there is now a -33. > > Everything you ask about looks okay. > > >>> 2) Please share any style information that could help us with editing your >>> document. For example: >>> >>> * Is your document's format or its terminology based on another document? >>> If so, please provide a pointer to that document (e.g., this document's >>> terminology should match DNS terminology in RFC 9499). >>> * Is there a pattern of capitalization or formatting of terms? (e.g., field >>> names >>> should have initial capitalization; parameter names should be in double >>> quotes; >>> <tt/> should be used for token names; etc.) > > The document is part of a set of documents described in the section "Relation > to other RFCs", and thus follows conventions used by them. Otherwise, the > document uses YANG, which defines a number of conventions in RFC 8407 and > rfc8407bis. > > I tend to put some terms in double quotes, e.g., the YANG "grouping" > statement. If this were Markdown, I might make these "code", i.e., > `grouping`. In any case, I (likely) used the same convention by the whole > set of draft, some of which have already been published, i.e., RFCs 9640 > thru 9645. > > >>> 3) Please review the entries in the References section carefully with >>> the following in mind. Note that we will update as follows unless we >>> hear otherwise at this time: >>> >>> * References to obsoleted RFCs will be updated to point to the current >>> RFC on the topic in accordance with Section 4.8.6 of RFC 7322 >>> (RFC Style Guide). >>> >>> * References to I-Ds that have been replaced by another I-D will be >>> updated to point to the replacement I-D. >>> >>> * References to documents from other organizations that have been >>> superseded will be updated to their superseding version. >>> >>> Note: To check for outdated RFC and I-D references, you can use >>> idnits <https://author-tools.ietf.org/idnits>. You can also help the >>> IETF Tools Team by testing idnits3 <https://author-tools.ietf.org/idnits3/> >>> with your document and reporting any issues to them. > > Everything looks okay. idnits has a NON_ASCII_UTF8 complaint which I refuse > to fix, because it is only used in someone's name in the Acknowledgements > section. > > >>> 4) Is there any text that should be handled extra cautiously? For example, >>> are >>> there any sections that were contentious when the document was drafted? > > Not really. The bulk of the document is YANG, which is rather mechanical. > > But note that the Abstract/Introduction sections had "loose" language that > was refined, e.g., from "FOO defines config for BAR" to "FOO defines config > for a BAR's BAZ". This text was/is rather sensitive. > > >>> 5) Is there anything else that the RPC should be aware of while editing >>> this >>> document? > > Nothing comes to mind. > > >>> 6) This document is part of Cluster 463. >>> >>> * To help the reader understand the content of the cluster, is there a >>> document in the cluster that should be read first? Next? If so, please >>> provide >>> the order and we will provide RFC numbers for the documents accordingly. >>> If order is not important, please let us know. >>> * Is there any text that has been repeated within the cluster document that >>> should be edited in the same way (for instance, parallel introductory text >>> or >>> Security Considerations)? >>> * For more information about clusters, see >>> https://www.rfc-editor.org/about/clusters/ >>> * For a list of all current clusters, see: >>> http://www.rfc-editor.org/all_clusters.php > > The "Relation to other RFCs" section in the draft covers all this. > > >> Thank you, >> Sarah Tarrant >> RFC Production Center > > > Thanks again! > Kent -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
