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]

Reply via email to