I am not a co-author for the isis-sr-yang draft. I did just reply to the OSPF email thread - it's ok to keep my old affiliation.
Jeffrey -----Original Message----- From: Acee Lindem <[email protected]> Sent: Monday, December 8, 2025 6:50 PM To: Alanna Paloma <[email protected]>; Jeffrey (Zhaohui) Zhang <[email protected]>; Zhang, Zhaohui <[email protected]> Cc: <[email protected]> <[email protected]>; Yingzhen Qu <[email protected]>; Helen Chen <[email protected]>; Jeff Tantsura <[email protected]>; Gunter van de Velde (Nokia) <[email protected]>; Editor RFC <[email protected]>; [email protected]; [email protected]; Christian Hopps <[email protected]>; auth48archive <[email protected]> Subject: Re: AUTH48: RFC-to-be 9902 <draft-ietf-isis-sr-yang-31> for your review 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/auth > 48archive/AF0rJKKqn5DzpmJ_lCS2ZgoC66E/__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lI > JZd-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfs23otZQ$ > > 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://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc990 >>> 2__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX4LzR6_zp2KqDyWFN1skML >>> cwl0wQmOkt21BasStx2of16NOf3uBaJEY$ >>> >>> As this document is part of Cluster C542, you may track the progress of all >>> documents in this cluster through AUTH48 at: >>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/C542__ >>> ;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl >>> 0wQmOkt21BasStx2of16NOf62Hyy9Q$ >>> >>> 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://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc99 >>>> 02__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX4LzR6_zp2KqDyWFN1sk >>>> MLcwl0wQmOkt21BasStx2of16NOf3uBaJEY$ >>>> >>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/ >>>>>>>> rfc9902-auth48diff.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdm >>>>>>>> IfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfGX6HRCk$ >>>>>>>> >>>>>>>> >>>>>>>> Acee - Thank you for your replies. We have updated the files >>>>>>>> accordingly. >>>>>>>> >>>>>>>> The files have been posted here (please refresh): >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/ >>>>>>>> rfc9902.txt__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX4LzR6_ >>>>>>>> zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOffTv4Mqo$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/ >>>>>>>> rfc9902.pdf__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX4LzR6_ >>>>>>>> zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOf5iHNQwk$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/ >>>>>>>> rfc9902.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX4LzR6 >>>>>>>> _zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfomcZk1A$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/ >>>>>>>> rfc9902.xml__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX4LzR6_ >>>>>>>> zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfrSHxrog$ >>>>>>>> >>>>>>>> The relevant diff files are posted here: >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/ >>>>>>>> rfc9902-diff.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX >>>>>>>> 4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfCYeyBOI$ >>>>>>>> (comprehensive >>>>>>>> diff) >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/ >>>>>>>> rfc9902-auth48diff.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdm >>>>>>>> IfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfGX6HRCk$ >>>>>>>> (all AUTH48 changes) >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/ >>>>>>>> rfc9902-lastdiff.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIf >>>>>>>> JWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfLwv53OU$ >>>>>>>> (htmlwdiff diff between last version and this) >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/ >>>>>>>> rfc9902-lastrfcdiff.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOd >>>>>>>> mIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfQq2lKl8$ >>>>>>>> (rfcdiff between last version and this) >>>>>>>> >>>>>>>> Please see the AUTH48 status page for this document here: >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/r >>>>>>>> fc9902__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX4LzR6_zp2Kq >>>>>>>> DyWFN1skMLcwl0wQmOkt21BasStx2of16NOf3uBaJEY$ >>>>>>>> >>>>>>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/auth4 >>>>>>>>>>> 8/rfc9902__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX4LzR6 >>>>>>>>>>> _zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOf3uBaJEY$ >>>>>>>>>>> >>>>>>>>>>> We have also updated the files with the additional requested >>>>>>>>>>> changes. >>>>>>>>>>> >>>>>>>>>>> The files have been posted here (please refresh): >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/autho >>>>>>>>>>> rs/rfc9902.txt__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX >>>>>>>>>>> 4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOffTv4Mqo$ >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/autho >>>>>>>>>>> rs/rfc9902.pdf__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX >>>>>>>>>>> 4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOf5iHNQwk$ >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/autho >>>>>>>>>>> rs/rfc9902.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWH >>>>>>>>>>> X4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfomcZk1A$ >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/autho >>>>>>>>>>> rs/rfc9902.xml__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX >>>>>>>>>>> 4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfrSHxrog$ >>>>>>>>>>> >>>>>>>>>>> The relevant diff files are posted here: >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/autho >>>>>>>>>>> rs/rfc9902-diff.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdm >>>>>>>>>>> IfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfCYeyBOI >>>>>>>>>>> $ >>>>>>>>>>> (comprehensive diff) >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/autho >>>>>>>>>>> rs/rfc9902-auth48diff.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZ >>>>>>>>>>> d-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfG >>>>>>>>>>> X6HRCk$ (all >>>>>>>>>>> AUTH48 changes) >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/autho >>>>>>>>>>> rs/rfc9902-lastdiff.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd- >>>>>>>>>>> rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfLwv >>>>>>>>>>> 53OU$ (htmlwdiff diff between last version and this) >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/autho >>>>>>>>>>> rs/rfc9902-lastrfcdiff.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJ >>>>>>>>>>> Zd-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOf >>>>>>>>>>> Qq2lKl8$ (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://urldefense.com/v3/__https://www.rfc-editor.org/aut >>>>>>>>>>>>> hors/rfc9902-auth48diff.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86 >>>>>>>>>>>>> lIJZd-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of >>>>>>>>>>>>> 16NOfGX6HRCk$ >>>>>>>>>>>>> >>>>>>>>>>>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/aut >>>>>>>>>>>>> hors/rfc9902.txt__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIf >>>>>>>>>>>>> JWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOffTv4Mqo >>>>>>>>>>>>> $ >>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/aut >>>>>>>>>>>>> hors/rfc9902.pdf__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIf >>>>>>>>>>>>> JWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOf5iHNQwk >>>>>>>>>>>>> $ >>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/aut >>>>>>>>>>>>> hors/rfc9902.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmI >>>>>>>>>>>>> fJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfomcZk1 >>>>>>>>>>>>> A$ >>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/aut >>>>>>>>>>>>> hors/rfc9902.xml__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIf >>>>>>>>>>>>> JWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfrSHxrog >>>>>>>>>>>>> $ >>>>>>>>>>>>> >>>>>>>>>>>>> The relevant diff files are posted here: >>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/aut >>>>>>>>>>>>> hors/rfc9902-diff.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd- >>>>>>>>>>>>> rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfC >>>>>>>>>>>>> YeyBOI$ >>>>>>>>>>>>> (comprehensive diff) >>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/aut >>>>>>>>>>>>> hors/rfc9902-auth48diff.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86 >>>>>>>>>>>>> lIJZd-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of >>>>>>>>>>>>> 16NOfGX6HRCk$ >>>>>>>>>>>>> (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://urldefense.com/v3/__https://www.rfc-editor.org/aut >>>>>>>>>>>>> h48/rfc9902__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX4 >>>>>>>>>>>>> LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOf3uBaJEY$ >>>>>>>>>>>>> >>>>>>>>>>>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/se >>>>>>>>>>>>>> arch__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX4LzR6_z >>>>>>>>>>>>>> p2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfQWEZd10$ . --> >>>>>>>>>>>>>> [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://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc8402__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfu8j98l8$ >>>>>>>>>>>>>> >. >>>>>>>>>>>>>> --> >>>>>>>>>>>>>> >>>>>>>>>>>>>> [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://urldefense.com/v3/__https://www.rfc-editor.org/s >>>>>>>>>>>>>> tyleguide/part2/*inclusive_langu__;Iw!!NEt6yMaO-gk!CRRxPG >>>>>>>>>>>>>> bm0Vj86lIJZd-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21B >>>>>>>>>>>>>> asStx2of16NOfvXWEr24$ >>>>>>>>>>>>>> age> and let us know if any changes are needed. Updates >>>>>>>>>>>>>> age> 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfHWxqjNI$ >>>>>>>>>>>>>> ). >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfu_CXMnU$ >>>>>>>>>>>>>> ). >>>>>>>>>>>>>> >>>>>>>>>>>>>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfkOLQ5SM$ >>>>>>>>>>>>>> >. >>>>>>>>>>>>>> >>>>>>>>>>>>>> * 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://urldefense.com/v3/__https://mailarchive.ietf.org/ >>>>>>>>>>>>>> arch/msg/ietf-announce/yb6lpIGh-__;!!NEt6yMaO-gk!CRRxPGbm >>>>>>>>>>>>>> 0Vj86lIJZd-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21Bas >>>>>>>>>>>>>> Stx2of16NOfp0cE3TQ$ >>>>>>>>>>>>>> 4Q9l2USxI >>>>>>>>>>>>>> Ae6P8O4Zc >>>>>>>>>>>>>> >>>>>>>>>>>>>> * The archive itself: >>>>>>>>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/ >>>>>>>>>>>>>> arch/browse/auth48archive/__;!!NEt6yMaO-gk!CRRxPGbm0Vj86l >>>>>>>>>>>>>> IJZd-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of >>>>>>>>>>>>>> 16NOfMeQk40A$ >>>>>>>>>>>>>> >>>>>>>>>>>>>> * 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://urldefense.com/v3/__https://www.rfc-editor.org/au >>>>>>>>>>>>>> thors/rfc9902.xml__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdm >>>>>>>>>>>>>> IfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfrSHx >>>>>>>>>>>>>> rog$ >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/au >>>>>>>>>>>>>> thors/rfc9902.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOd >>>>>>>>>>>>>> mIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOfomc >>>>>>>>>>>>>> Zk1A$ >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/au >>>>>>>>>>>>>> thors/rfc9902.pdf__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdm >>>>>>>>>>>>>> IfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOf5iHN >>>>>>>>>>>>>> Qwk$ >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/au >>>>>>>>>>>>>> thors/rfc9902.txt__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdm >>>>>>>>>>>>>> IfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOffTv4 >>>>>>>>>>>>>> Mqo$ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Diff file of the text: >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/au >>>>>>>>>>>>>> thors/rfc9902-diff.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZ >>>>>>>>>>>>>> d-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16N >>>>>>>>>>>>>> OfCYeyBOI$ >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/au >>>>>>>>>>>>>> thors/rfc9902-rfcdiff.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86l >>>>>>>>>>>>>> IJZd-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of >>>>>>>>>>>>>> 16NOfKILDtUo$ (side by >>>>>>>>>>>>>> side) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Diff of the XML: >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/au >>>>>>>>>>>>>> thors/rfc9902-xmldiff1.html__;!!NEt6yMaO-gk!CRRxPGbm0Vj86 >>>>>>>>>>>>>> lIJZd-rOdmIfJWHX4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2o >>>>>>>>>>>>>> f16NOfB5YlJZM$ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tracking progress >>>>>>>>>>>>>> ----------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/au >>>>>>>>>>>>>> th48/rfc9902__;!!NEt6yMaO-gk!CRRxPGbm0Vj86lIJZd-rOdmIfJWH >>>>>>>>>>>>>> X4LzR6_zp2KqDyWFN1skMLcwl0wQmOkt21BasStx2of16NOf3uBaJEY$ >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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]
