Hi Acee, We apologize for the length of processing time. Both documents have now completed AUTH48 and are actively being prepped for publication. We expect them to be announced later today.
You will receive an invite for the post-publication survey in early January. We understand one of your comments to be that processing times are too long; if you have other comments you’d like share with us now, please feel free. Thank you, Alanna Paloma RFC Production Center > On Dec 8, 2025, at 3:50 PM, Acee Lindem <[email protected]> wrote: > > Alanna, > > I guess you are talking about an affiliation update? People's Email address > and affiliation changing after a document is published is not a rare > occurrence and if it were important, he would have responded. > > Do you realize that these IS-IS and OSPF SR YANG documents have been on the > RFC Editor queue for 221 days? I hope I get an RFC Editor survey... > > Acee > >> On Dec 8, 2025, at 1:28 PM, Alanna Paloma <[email protected]> >> wrote: >> >> 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]
