[auth48] Re: Document intake questions about draft-ietf-lsr-isis-flex-algo-yang

[Sarah Tarrant <[e-mail]>]

Hi Acee,

Thank you for your reply!

Sincerely,
Sarah Tarrant
RFC Production Center

> On Jul 22, 2026, at 1:51 PM, Acee Lindem <[e-mail]> wrote:
> 
> Hi RFC Editor, 
> 
>> On Jul 20, 2026, at 10:07 AM, [e-mail] wrote:
>> 
>> 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 
>> [e-mail].
>> 
>> 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?
> 
> Added Ketan and Les to acknowledgements.  
>> 
>> 
>> 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 adhere to RFC 9907. 
> 
> 
>> 
>> 
>> 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>.
> 
> Looks good. 
> 
>> 
>> 
>> 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.)
> 
> All source code segments are YANG module source. 
> 
> 
>> 
>> 
>> 6) This document is part of Cluster 581:
>> https://queue.rfc-editor.org/clusters/581/ 
>> 
>> * 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://authors.ietf.org/en/rfc-publication-process#clusters
>> 
>> * For a list of all current clusters, see: 
>> https://queue.rfc-editor.org/clusters/
> 
> Ok. 
> 
>> 
>> 
>> 7) Is there anything else that the RPC should be aware of while editing this 
>> document?
> 
> No. 
> 
> Thanks,
> Acee