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]
