Hi Alanna, Approved, thanks! Jeff
> On Dec 3, 2025, at 09:38, Alanna Paloma <[email protected]> wrote: > > Hi Authors, > > Yingzhen sent additional updates for this document’s section titles in the > AUTH48 thread for RFC-to-be 9903. We have updated the files accordingly. > >> On Dec 2, 2025, at 11:03 AM, Yingzhen Qu <[email protected]> wrote: >> > >> The title of section 2 in 9903 is "2. OSPF Segment Routing over MPLS YANG >> Data Model Scope", while 9902 is "2. Design of the IS-IS MPLS Segment >> Routing Module". How about we change 9903 to "Design of the YANG Module for >> OSPF MPLS Segment Routing" and 9902 to "Design of the YANG Module for IS-IS >> MPLS Segment Routing"? >> >> The section 3 title for 9902 should be "IS-IS Segment Routing over MPLS >> YANG Module". Please remove the first "MPLS". > > 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) > > See the AUTH48 status of this document here: > https://www.rfc-editor.org/auth48/rfc9902 > > We will await any further changes you may have as well as approvals from > Stephane, Yingzhen, Helen, and Jeff prior to moving this document forward in > the publication process. > > Thank you, > Alanna Paloma > RFC Production Center > >> On Dec 2, 2025, at 8:48 AM, Alanna Paloma <[email protected]> >> wrote: >> >> Hi Gunter, >> >> Thank you for your approvals. They have been noted on the AUTH48 status page: >> https://www.rfc-editor.org/auth48/rfc9902 >> >> Best regards, >> Alanna Paloma >> RFC Production Center >> >>> On Dec 2, 2025, at 3: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_language> >>>>>>>>> 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]
