> 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]
