Hi Acee, There is one remaining question in RFC-to-be 9903 for Jeffrey Zhang. See here: https://mailarchive.ietf.org/arch/msg/auth48archive/AF0rJKKqn5DzpmJ_lCS2ZgoC66E/
Once that question is addressed, we will move both documents in C542 forward in the publication process. Thank you, Alanna Paloma RFC Production Center > On Dec 8, 2025, at 9:54 AM, Acee Lindem <[email protected]> wrote: > > > >> On Dec 8, 2025, at 11:53 AM, Alanna Paloma <[email protected]> >> wrote: >> >> 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. > > And what document is that? They seem to be all done. > > Thanks, > Acee > > >> >> 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]
