Hi Sarah, Also, please update Ravi's and Athanasios' Email addresses to the ones in the draft. The Email distribution list still contains the stale addresses (I have updated above).
Athanasios Kyparlis - [email protected] <mailto:[email protected]> Ravi Parikh - [email protected] <mailto:[email protected]> Thanks, Acee > On Jun 23, 2026, at 11:30 AM, Acee Lindem <[email protected]> wrote: > > Hi Sarah, > >> On Jun 23, 2026, at 11:03 AM, Sarah Tarrant <[email protected]> >> wrote: >> >> Hi Acee, >> >> Thank you for your reply. >> >> I have one followup question regarding the sourcecode in the XML. >> >>>> 5) This document appears to contain a formal language (or code / code >>>> snippets that will be marked with <sourcecode> in this document's >>>> XML file). See https://authors.ietf.org/formal-languages. >>>> >>>> * Does it validate? >>>> >>>> * Some formal languages (e.g., YANG) require certain reference entries >>>> and/or boilerplate in the Security Considerations section (see the link >>>> above for more information). Please confirm that this document matches >>>> the current guidance for the language type. >>>> >>>> * Unless already indicated in a submitted XML file for this document, >>>> please let us know what type should be used for the <sourcecode> element >>>> for each module/snippet/etc. (See information about <sourcecode> types >>>> at https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types.) >>> >>> This is taken care. >> >> >> It appears that the artwork elements in Sections 2.2, 2.3, 2.4, 2.5, 3, and >> 4 and Appendix A should be marked as sourcecode. Could you confirm if these >> need to be marked as sourcecode and, if so, which type (e.g., yang-tree, >> yang, etc.)? > > I don't see the value in marking. Can you enlighten me? > > Nevertheless: > > YANG-Tree: 2.2, 2.3, 2.4, 2.5, and 3 > YANG: 4 > YANG JSON Data Example: Appendix A > > Thanks, > Acee > > > > >> >> Thank you, >> Sarah Tarrant >> RFC Production Center >> >>> On Jun 23, 2026, at 5:11 AM, Acee Lindem <[email protected]> wrote: >>> >>> See inline. >>> >>>> On Jun 22, 2026, at 4:58 PM, [email protected] wrote: >>>> >>>> CC: [email protected] >>>> Subject: Document intake questions about draft-foo-00 >>>> >>>> Author(s), >>>> >>>> Congratulations, your document has been successfully added to the RFC >>>> Editor queue! >>>> The team at the RFC Production Center (RPC) is looking forward to working >>>> with you >>>> as your document moves forward toward publication. To help reduce >>>> processing time >>>> and improve editing accuracy, please respond to the questions below. >>>> Please confer >>>> with your coauthors (or authors of other documents if your document is in >>>> a >>>> cluster) as necessary prior to taking action in order to streamline >>>> communication. >>>> If your document has multiple authors, only one author needs to reply to >>>> this >>>> message. >>>> >>>> As you read through the rest of this email: >>>> >>>> * If you need/want to make updates to your document, we encourage you to >>>> make those >>>> changes and resubmit to the Datatracker. This allows for the easy creation >>>> of diffs, >>>> which facilitates review by interested parties (e.g., authors, ADs, doc >>>> shepherds). >>>> >>>> * If you feel no updates to the document are necessary, please reply with >>>> any >>>> applicable rationale/comments. >>>> >>>> >>>> Please note that the RPC team will not work on your document until we >>>> receive a >>>> reply. We require a reply, even if you don’t have guidance or don’t feel >>>> that you >>>> need to make any updates to the document. After we hear from you, your >>>> document >>>> will start moving through the queue. You will be able to review and >>>> approve our >>>> updates during Final Review (formerly AUTH48). >>>> >>>> Please feel free to contact us with any questions you may have at >>>> [email protected]. >>>> >>>> Thank you! >>>> The RPC Team >>>> >>>> -- >>>> >>>> 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? >>> >>> Yes. >>> >>> >>> >>>> >>>> >>>> 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, >>>> WG style guide, etc.? If so, please provide a pointer to that information >>>> (e.g., "This document's terminology should match DNS terminology in >>>> RFC 9499." or "This document uses the style info at >>>> <https://httpwg.org/admin/editors/style-guide>."). >>>> >>>> * Is there a general pattern of capitalization or formatting of terms that >>>> editors can follow (e.g., "Field names should have initial >>>> capitalization." >>>> or "Parameter names should be in double quotes." or "<tt/> should be used >>>> for token names." etc.)? >>> >>> Please follow style guidelines for YANG documents. >>> >>> >>>> >>>> >>>> 3) Please carefully review the entries and their URLs in the >>>> References section 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>. >>> >>> None. The document references [I-D.ietf-tls-rfc8446bis] which will need to >>> be updated to the RFC when published. >>> >>> >>>> >>>> >>>> 4) Is there any text that requires special handling? For example: >>>> >>>> * Are there any sections that were contentious when the document was >>>> drafted? >>>> >>>> * Are any sections that need to be removed before publication marked as >>>> such >>>> (e.g., Implementation Status sections (per RFC 7942))? >>>> >>>> * Are there any instances of repeated text/sections that should be edited >>>> the same way? >>> >>> No. >>> >>> >>>> >>>> >>>> 5) This document appears to contain a formal language (or code / code >>>> snippets that will be marked with <sourcecode> in this document's >>>> XML file). See https://authors.ietf.org/formal-languages. >>>> >>>> * Does it validate? >>>> >>>> * Some formal languages (e.g., YANG) require certain reference entries >>>> and/or boilerplate in the Security Considerations section (see the link >>>> above for more information). Please confirm that this document matches >>>> the current guidance for the language type. >>>> >>>> * Unless already indicated in a submitted XML file for this document, >>>> please let us know what type should be used for the <sourcecode> element >>>> for each module/snippet/etc. (See information about <sourcecode> types >>>> at https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types.) >>> >>> This is taken care. >>> >>> >>>> >>>> >>>> 6) Is there anything else that the RPC should be aware of while editing >>>> this >>>> document? >>> >>> No >>> >>> Thanks, >>> Acee >> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
