All, We have now received all necessary approvals and consider AUTH48 complete: https://www.rfc-editor.org/auth48/rfc9902
As this document is part of Cluster C542, you may track the progress of all documents in this cluster through AUTH48 at: https://www.rfc-editor.org/auth48/C542 We will move this document forward in the publication process once the other document in the cluster (RFC-to-be 9903) completes AUTH48 as well. Please let us know if you have any questions. Thank you, Alanna Paloma RFC Production Center > On Dec 5, 2025, at 1:05 AM, <[email protected]> > <[email protected]> wrote: > > Hi, > > I approve. > > Thanks > > > -----Original Message----- > From: Alanna Paloma <[email protected]> > Sent: Friday, December 5, 2025 12:56 AM > To: Helen Chen <[email protected]>; Yingzhen Qu <[email protected]> > Cc: Acee Lindem <[email protected]>; Gunter van de Velde (Nokia) > <[email protected]>; <[email protected]> > <[email protected]>; Jeff Tantsura <[email protected]>; Editor > RFC <[email protected]>; [email protected]; [email protected]; > [email protected]; auth48archive <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9902 <draft-ietf-isis-sr-yang-31> for your > review > Importance: High > > Hi Yingzhen and Helen, > > Thank you for sending your approvals. They have been noted here: > https://www.rfc-editor.org/auth48/rfc9902 > > Once we’ve received approval from Stephane, we will move this document > forward in the publication process. > > Best regards, > Alanna Paloma > RFC Production Center > >> On Dec 4, 2025, at 10:11 AM, Helen Chen <[email protected]> wrote: >> >> I approve. >> >> Thanks, >> Helen >> >>> On Dec 4, 2025, at 1:03 PM, Acee Lindem <[email protected]> wrote: >>> >>> Helen and Stephane - Please review and approve ASAP. >>> >>> Thanks, >>> Acee >>> >>>> On Dec 2, 2025, at 7:17 AM, Acee Lindem <[email protected]> wrote: >>>> >>>> Hi Yingzhen, Helen, Jeff, and Stephane, >>>> >>>> Please review and approve. >>>> >>>> Thanks, >>>> Acee >>>> >>>>> On Dec 2, 2025, at 6:08 AM, Gunter van de Velde (Nokia) >>>>> <[email protected]> wrote: >>>>> >>>>> Hi Alanna, >>>>> >>>>> Pleas see inline: GV> >>>>> >>>>> >>>>> From: Alanna Paloma <[email protected]> >>>>> Sent: Monday, December 01, 2025 6:55 PM >>>>> To: Acee Lindem <[email protected]>; Gunter van de Velde (Nokia) >>>>> <[email protected]> >>>>> Cc: Helen Chen <[email protected]>; <[email protected]> >>>>> <[email protected]>; Yingzhen Qu <[email protected]>; >>>>> Jeff Tantsura <[email protected]>; Editor RFC >>>>> <[email protected]>; [email protected] <[email protected]>; >>>>> [email protected] <[email protected]>; [email protected] >>>>> <[email protected]>; auth48archive <[email protected]> >>>>> Subject: Re: [AD] AUTH48: RFC-to-be 9902 >>>>> <draft-ietf-isis-sr-yang-31> for your review >>>>> >>>>> >>>>> CAUTION: This is an external email. Please be very careful when clicking >>>>> links or opening attachments. See the URL nok.it/ext for additional >>>>> information. >>>>> >>>>> >>>>> >>>>> Hi Acee and Gunter (AD)*, >>>>> >>>>> *Gunter - As the AD, please review and approve of the following updates: >>>>> - Section 1: removed text >>>>> GV> Approved >>>>> >>>>> - Section 3 (within the YANG module): removed text >>>>> GV> >>>>> >>>>> - Section 6.1: removed the normative reference entry for RFC 8342 >>>>> GV> Approved. The text referencing this was removed from the body during >>>>> the rfc editing process. >>>>> >>>>> Be well, >>>>> G/ >>>>> >>>>> See this diff file: >>>>> https://www.rfc-editor.org/authors/rfc9902-auth48diff.html >>>>> >>>>> >>>>> Acee - Thank you for your replies. We have updated the files accordingly. >>>>> >>>>> The files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9902.txt >>>>> https://www.rfc-editor.org/authors/rfc9902.pdf >>>>> https://www.rfc-editor.org/authors/rfc9902.html >>>>> https://www.rfc-editor.org/authors/rfc9902.xml >>>>> >>>>> The relevant diff files are posted here: >>>>> https://www.rfc-editor.org/authors/rfc9902-diff.html (comprehensive >>>>> diff) https://www.rfc-editor.org/authors/rfc9902-auth48diff.html >>>>> (all AUTH48 changes) >>>>> https://www.rfc-editor.org/authors/rfc9902-lastdiff.html (htmlwdiff >>>>> diff between last version and this) >>>>> https://www.rfc-editor.org/authors/rfc9902-lastrfcdiff.html >>>>> (rfcdiff between last version and this) >>>>> >>>>> Please see the AUTH48 status page for this document here: >>>>> https://www.rfc-editor.org/auth48/rfc9902 >>>>> >>>>> We will await any further changes you may have as well as approvals from >>>>> each author and *Gunter (AD) prior to moving this document forward in the >>>>> publication process. >>>>> >>>>> Thank you, >>>>> Alanna Paloma >>>>> RFC Production Center >>>>> >>>>>> On Dec 1, 2025, at 3:55 AM, Acee Lindem <[email protected]> wrote: >>>>>> >>>>>> Hi Alana, >>>>>> I've attached my editorial comments including removal of the reference >>>>>> to RFC 8342. >>>>>> >>>>>> Thanks, >>>>>> Acee >>>>>> <rfc9902.orig.diff.html> >>>>>> >>>>>>> On Nov 29, 2025, at 3:51 PM, Acee Lindem <[email protected]> wrote: >>>>>>> >>>>>>> Hi Alana, >>>>>>> >>>>>>> I just have a couple editorial comments. See attached diff. >>>>>>> >>>>>>> Thanks, >>>>>>> Acee >>>>>>> <rfc9902.orig.diff.html> >>>>>>> >>>>>>>> On Nov 25, 2025, at 3:51 PM, Alanna Paloma >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> Thank you for your replies. Gunter’s approval has bee noted on the >>>>>>>> AUTH48 status page: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9902 >>>>>>>> >>>>>>>> We have also updated the files with the additional requested changes. >>>>>>>> >>>>>>>> The files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9902.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9902.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9902.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9902.xml >>>>>>>> >>>>>>>> The relevant diff files are posted here: >>>>>>>> https://www.rfc-editor.org/authors/rfc9902-diff.html >>>>>>>> (comprehensive diff) >>>>>>>> https://www.rfc-editor.org/authors/rfc9902-auth48diff.html (all >>>>>>>> AUTH48 changes) >>>>>>>> https://www.rfc-editor.org/authors/rfc9902-lastdiff.html >>>>>>>> (htmlwdiff diff between last version and this) >>>>>>>> https://www.rfc-editor.org/authors/rfc9902-lastrfcdiff.html >>>>>>>> (rfcdiff between last version and this) >>>>>>>> >>>>>>>> We will await any further changes you may have as well as approvals >>>>>>>> from each author prior to moving this document forward in the >>>>>>>> publication process. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Alanna Paloma >>>>>>>> RFC Production Center >>>>>>>> >>>>>>>>> On Nov 25, 2025, at 8:48 AM, Helen Chen <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Hello RFCEditor, >>>>>>>>> >>>>>>>>> Yes, please update my (Ing-Wher Chen) email address and affiliation >>>>>>>>> if possible. Along with the affiliation change, please also remove >>>>>>>>> the last paragraph in the “Acknowledgments” section. That paragraph >>>>>>>>> currently states "Author affiliation with The MITRE Corporation…”. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Helen >>>>>>>>> >>>>>>>>>> On Nov 25, 2025, at 9:10 AM, Gunter van de Velde (Nokia) >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> Inline: GV> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Alanna Paloma <[email protected]> >>>>>>>>>> Sent: Monday, November 24, 2025 8:19 PM >>>>>>>>>> To: Gunter van de Velde (Nokia) >>>>>>>>>> <[email protected]>; Yingzhen Qu >>>>>>>>>> <[email protected]>; <[email protected]> >>>>>>>>>> <[email protected]>; Acee Lindem <[email protected]>; >>>>>>>>>> [email protected]; [email protected]; Jeff Tantsura >>>>>>>>>> <[email protected]> >>>>>>>>>> Cc: Editor RFC <[email protected]>; [email protected]; >>>>>>>>>> [email protected]; [email protected]; auth48archive >>>>>>>>>> <[email protected]> >>>>>>>>>> Subject: [AD] Re: AUTH48: RFC-to-be 9902 >>>>>>>>>> <draft-ietf-isis-sr-yang-31> for your review >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> CAUTION: This is an external email. Please be very careful when >>>>>>>>>> clicking links or opening attachments. See the URL nok.it/ext for >>>>>>>>>> additional information. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Authors and Gunter (AD)*, >>>>>>>>>> >>>>>>>>>> *Gunter - As the AD please review and approve of the following >>>>>>>>>> changes: >>>>>>>>>> - Section 2: deleted sentence of repetitive text >>>>>>>>>> >>>>>>>>>> GV> Approved >>>>>>>>>> >>>>>>>>>> - Section 6.1: added reference entry to RFC 8402 in the >>>>>>>>>> Normative References section >>>>>>>>>> >>>>>>>>>> GV> Approved >>>>>>>>>> >>>>>>>>>> Additionally, we asked the authors about the Security Considerations >>>>>>>>>> text, as it does not exactly match what appears in Section 3.7 of >>>>>>>>>> draft-ietf-netmod-rfc8407bis-28. Please review Section 4 and confirm >>>>>>>>>> that the missing sentence and added paragraphs are acceptable. >>>>>>>>>> >>>>>>>>>>> 7) <!--[rfced] FYI, we have made some updates to the Security >>>>>>>>>>> Considerations to match Section 3.7 of >>>>>>>>>>> draft-ietf-netmod-rfc8407bis-28. Please let us know if any further >>>>>>>>>>> updates are needed. We note some differences, specifically: >>>>>>>>>>> >>>>>>>>>>> a) Should this sentence from the template be added? "There are no >>>>>>>>>>> particularly sensitive RPC or action operations." >>>>>>>>>>> >>>>>>>>>>> [Yingzhen]: this should not be added as we have listed some >>>>>>>>>>> sensitive writable nodes. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> GV> Approved. There is a clause in draft-ietf-netmod-rfc8407bis-28 >>>>>>>>>> that approves this. >>>>>>>>>> >>>>>>>>>>> b) These paragraphs do not appear in the template. Please confirm >>>>>>>>>>> they should remain. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> The ability to disable or enable IS-IS Segment Routing >>>>>>>>>>> support and/or change Segment Routing configurations can >>>>>>>>>>> result in a Denial-of- Service (DoS) attack, as this may >>>>>>>>>>> cause traffic to be dropped or misrouted. Please refer to >>>>>>>>>>> Section 5 of [RFC8667] for more information on Segment Routing >>>>>>>>>>> extensions. >>>>>>>>>>> ... >>>>>>>>>>> Unauthorized access to any data node of these subtrees can >>>>>>>>>>> disclose the operational state information of IS-IS protocol on a >>>>>>>>>>> device. >>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [Yingzhen]: yes, they should remain. >>>>>>>>>> >>>>>>>>>> GV> Approved. The claim is valid and accurate >>>>>>>>>> >>>>>>>>>> See this diff file: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9902-auth48diff.html >>>>>>>>>> >>>>>>>>>> GV> Many thanks, >>>>>>>>>> >>>>>>>>>> G/ >>>>>>>>>> RTG AD >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Authors - Thank you for your reply. We have updated the files >>>>>>>>>> accordingly. >>>>>>>>>> >>>>>>>>>> ) We note that Yingzhen has added Helen’s new email address to this >>>>>>>>>> thread. Should her email address and affiliation be updated in the >>>>>>>>>> document? >>>>>>>>>> >>>>>>>>>> The files have been posted here (please refresh): >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9902.txt >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9902.pdf >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9902.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9902.xml >>>>>>>>>> >>>>>>>>>> The relevant diff files are posted here: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9902-diff.html >>>>>>>>>> (comprehensive diff) >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9902-auth48diff.html >>>>>>>>>> (all AUTH48 changes) >>>>>>>>>> >>>>>>>>>> Please review the document carefully as documents do not change once >>>>>>>>>> published as RFCs. >>>>>>>>>> >>>>>>>>>> We will await any further changes you may have and approvals from >>>>>>>>>> each author and *Gunter (AD) prior to moving forward in the >>>>>>>>>> publication process. >>>>>>>>>> >>>>>>>>>> Please see the AUTH48 status page for this document here: >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9902 >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Alanna Paloma >>>>>>>>>> RFC Production Center >>>>>>>>>> >>>>>>>>>>> On Nov 21, 2025, at 4:28 PM, Yingzhen Qu <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Thanks for working on this document. Please see my answers below >>>>>>>>>>> inline. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Yingzhen >>>>>>>>>>> >>>>>>>>>>> On Fri, Nov 21, 2025 at 10:57 AM <[email protected]> wrote: >>>>>>>>>>> Authors, >>>>>>>>>>> >>>>>>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>>>>>>> necessary) the following questions, which are also in the source >>>>>>>>>>> file. >>>>>>>>>>> >>>>>>>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that >>>>>>>>>>> appear in the title) for use on >>>>>>>>>>> https://www.rfc-editor.org/search. --> >>>>>>>>>>> [Yingzhen]: I don't think we need more than what's in the title. >>>>>>>>>>> >>>>>>>>>>> 2) <!--[rfced] We note that BCP 14 key words are not used in this >>>>>>>>>>> document. >>>>>>>>>>> Therefore, we have removed the keywords paragraph in Section >>>>>>>>>>> 1.1 and in the YANG module. We have also removed the references to >>>>>>>>>>> RFCs 2119 and 8174. >>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [Yingzhen]: ok. >>>>>>>>>>> >>>>>>>>>>> 3) <!--[rfced] This text in Section 2 reflects text in >>>>>>>>>>> Section 1. As it is repeating information, may we remove this text >>>>>>>>>>> from Section 2? >>>>>>>>>>> >>>>>>>>>>> Original (Section 1): >>>>>>>>>>> This document defines a device YANG data model [RFC7950] that >>>>>>>>>>> can be used to manage IS-IS Extensions for Segment Routing >>>>>>>>>>> [RFC8667] over the MPLS data plane. It is an augmentation to >>>>>>>>>>> the IS-IS YANG data model [RFC9130]. >>>>>>>>>>> >>>>>>>>>>> Original (Section 2): >>>>>>>>>>> This document defines a YANG data model for IS-IS Extensions >>>>>>>>>>> for Segment Routing over the MPLS data plane. It is an >>>>>>>>>>> augmentation of the IS-IS base model. >>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [ Yingzhen]: I'm ok with the suggested removal. >>>>>>>>>>> >>>>>>>>>>> 4) <!--[rfced] RFC 8402 is only cited in the YANG module. May >>>>>>>>>>> we add a citation to RFC 8402 to the this sentence preceding >>>>>>>>>>> the YANG module as well as add a reference in the Normative >>>>>>>>>>> References section? >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> [RFC6991], [RFC8102], [RFC8294], [RFC8349], [RFC8667], >>>>>>>>>>> [RFC9020], [RFC9130], and >>>>>>>>>>> [I-D.ietf-rtgwg-segment-routing-ti-lfa] are referenced in the YANG >>>>>>>>>>> module. >>>>>>>>>>> >>>>>>>>>>> Perhaps: >>>>>>>>>>> [RFC6991], [RFC8102], [RFC8294], [RFC8349], [RFC8402], >>>>>>>>>>> [RFC8667], [RFC9020], [RFC9130], and [RFC9855] are referenced >>>>>>>>>>> in the YANG module. >>>>>>>>>>> ... >>>>>>>>>>> [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., >>>>>>>>>>> Decraene, B., Litkowski, S., and R. Shakir, "Segment >>>>>>>>>>> Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, >>>>>>>>>>> July 2018, <https://www.rfc-editor.org/info/rfc8402>. >>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [Yingzhen]: Yes, please. >>>>>>>>>>> >>>>>>>>>>> 5) <!--[rfced] These two sentences in the description clauses >>>>>>>>>>> of the YANG module are phrased similarly. Should they be rephrased >>>>>>>>>>> to match? >>>>>>>>>>> If yes, should "IP" appear before "FRR" or before "interface"? >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> This augments ISIS interface level-1 IP FRR with TILFA. >>>>>>>>>>> ... >>>>>>>>>>> This augments ISIS IP interface level-2 FRR with TILFA. >>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [Yingzhen]: It should be "This augments ISIS interface level-1 IP >>>>>>>>>>> FRR with TILFA." and "This augments ISIS interface level-2 IP FRR >>>>>>>>>>> with TILFA." . >>>>>>>>>>> >>>>>>>>>>> 6) <!--[rfced] We have updated this description text in the >>>>>>>>>>> YANG module for clarity. Please review and confirm that the >>>>>>>>>>> intended meaning has not been altered. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> A path providing node a disjoint path for SRLG links from the >>>>>>>>>>> primary path will be selected over one that doesn't provide >>>>>>>>>>> an SRLG disjoint path. >>>>>>>>>>> >>>>>>>>>>> Current: >>>>>>>>>>> A path providing a node with a disjoint path for SRLG links >>>>>>>>>>> from the primary path will be selected over a path that >>>>>>>>>>> doesn't provide an SRLG disjoint path. >>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [Yingzhen]: The suggested change is fine. >>>>>>>>>>> >>>>>>>>>>> 7) <!--[rfced] FYI, we have made some updates to the Security >>>>>>>>>>> Considerations to match Section 3.7 of >>>>>>>>>>> draft-ietf-netmod-rfc8407bis-28. Please let us know if any further >>>>>>>>>>> updates are needed. We note some differences, specifically: >>>>>>>>>>> >>>>>>>>>>> a) Should this sentence from the template be added? "There are no >>>>>>>>>>> particularly sensitive RPC or action operations." >>>>>>>>>>> >>>>>>>>>>> [Yingzhen]: this should not be added as we have listed some >>>>>>>>>>> sensitive writable nodes. >>>>>>>>>>> >>>>>>>>>>> b) These paragraphs do not appear in the template. Please confirm >>>>>>>>>>> they should remain. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> The ability to disable or enable IS-IS Segment Routing >>>>>>>>>>> support and/or change Segment Routing configurations can >>>>>>>>>>> result in a Denial-of- Service (DoS) attack, as this may >>>>>>>>>>> cause traffic to be dropped or misrouted. Please refer to >>>>>>>>>>> Section 5 of [RFC8667] for more information on Segment Routing >>>>>>>>>>> extensions. >>>>>>>>>>> ... >>>>>>>>>>> Unauthorized access to any data node of these subtrees can >>>>>>>>>>> disclose the operational state information of IS-IS protocol on a >>>>>>>>>>> device. >>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [Yingzhen]: yes, they should remain. >>>>>>>>>>> >>>>>>>>>>> 8) <!--[rfced] Both the expansion and the acronym for the >>>>>>>>>>> following terms are used throughout the document. Would you >>>>>>>>>>> like to update to using the expansion upon first usage and the >>>>>>>>>>> acronym for the rest of the document? >>>>>>>>>>> >>>>>>>>>>> Adjacency Segment Identifier, adjacency SID, adjacency >>>>>>>>>>> Segment ID >>>>>>>>>>> (Adj-SID) Link State Database (LSDB) Remote LFA (RLFA) >>>>>>>>>>> Segment Routing (SR) >>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [Yingzhen]: We should use the acronym after the first use. >>>>>>>>>>> >>>>>>>>>>> 9) <!--[rfced] Please review the "Inclusive Language" portion >>>>>>>>>>> of the online Style Guide >>>>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_langu >>>>>>>>>>> age> 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. >>>>>>>>>>> >>>>>>>>>>> Alanna Paloma and Alice Russo RFC Production Center >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Nov 21, 2025, at 10:56 AM, [email protected] wrote: >>>>>>>>>>> >>>>>>>>>>> *****IMPORTANT***** >>>>>>>>>>> >>>>>>>>>>> Updated 2025/11/21 >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> * [email protected] (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). >>>>>>>>>>> >>>>>>>>>>> * [email protected], 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- >>>>>>>>>>> 4Q9l2USxI >>>>>>>>>>> Ae6P8O4Zc >>>>>>>>>>> >>>>>>>>>>> * 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, [email protected] 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/rfc9902.xml >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9902.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9902.pdf >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9902.txt >>>>>>>>>>> >>>>>>>>>>> Diff file of the text: >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9902-diff.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9902-rfcdiff.html (side >>>>>>>>>>> by >>>>>>>>>>> side) >>>>>>>>>>> >>>>>>>>>>> Diff of the XML: >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9902-xmldiff1.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Tracking progress >>>>>>>>>>> ----------------- >>>>>>>>>>> >>>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9902 >>>>>>>>>>> >>>>>>>>>>> Please let us know if you have any questions. >>>>>>>>>>> >>>>>>>>>>> Thank you for your cooperation, >>>>>>>>>>> >>>>>>>>>>> RFC Editor >>>>>>>>>>> >>>>>>>>>>> -------------------------------------- >>>>>>>>>>> RFC9902 (draft-ietf-isis-sr-yang-31) >>>>>>>>>>> >>>>>>>>>>> Title : A YANG Data Model for IS-IS Segment Routing over >>>>>>>>>>> the MPLS Data Plane >>>>>>>>>>> Author(s) : S. Litkowski, Y. Qu, A. Lindem, I. Chen, J. >>>>>>>>>>> Tantsura >>>>>>>>>>> WG Chair(s) : Acee Lindem, Christian Hopps, Yingzhen Qu >>>>>>>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van >>>>>>>>>>> de Velde >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>>> >>> >> > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
