Hi Alanna, This looks good to me.
Thanks, Acee > On Dec 1, 2025, at 12:56 PM, Alanna Paloma <[email protected]> > wrote: > > Hi Acee and Gunter (AD)*, > > *Gunter - As the AD, please review and approve of the following updates: > - Section 1: removed text > - Section 3 (within the YANG module): added text > - Section 6.2: removed informative reference entry for RFC 8342 > > See this diff file: > https://www.rfc-editor.org/authors/rfc9903-auth48diff.html > > > Acee - Thank you for your replies. We’ve updated the files accordingly. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9903.txt > https://www.rfc-editor.org/authors/rfc9903.pdf > https://www.rfc-editor.org/authors/rfc9903.html > https://www.rfc-editor.org/authors/rfc9903.xml > > The relevant diff files are posted here: > https://www.rfc-editor.org/authors/rfc9903-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9903-auth48diff.html (all AUTH48 > changes) > https://www.rfc-editor.org/authors/rfc9903-lastdiff.html (htmlwdiff diff > between last version and this) > https://www.rfc-editor.org/authors/rfc9903-lastrfcdiff.html (rfcdiff between > last version and this) > > 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:53 AM, Acee Lindem <[email protected]> wrote: >> >> Hi Alana, >> >> Removed RFC 8342 reference as well. Complete set of editorial diffs >> attached. >> >> Thanks, >> Acee >> <rfc9903.orig.diff.html> >> >>> On Nov 29, 2025, at 4:08 PM, Acee Lindem <[email protected]> wrote: >>> >>> Hi Alana, >>> >>> Here is my complete set of editorial comments in RFC diff format. >>> >>> Thanks, >>> Acee >>> <rfc9903.orig.diff.html> >>> >>>> On Nov 29, 2025, at 3:20 PM, Acee Lindem <[email protected]> wrote: >>>> >>>> Hi Alana, >>>> >>>>> On Nov 28, 2025, at 5:28 PM, Acee Lindem <[email protected]> wrote: >>>>> >>>>> Hi Alana, >>>>> >>>>> I have the following editorial comments on the current version. None of >>>>> these suggested changes should require AD approval. >>>>> >>>>> Note that I'm keeping my former LabN affiliation in the draft since I did >>>>> much of the work while working there. >>>>> >>>>> I have one question, does the YANG model itself need to have the first >>>>> instance of non-well-known acronyms expanded >>>>> on the first usage? If so, there are some that need to be expanded (e.g., >>>>> SRMS, IP-FRR, and RLFA). >>>> >>>> SRMS seems to be the only one needed. Please add the first-use expansion >>>> to the YANG model as well. >>>> >>>> *** 694,703 **** >>>> >>>> grouping srms-preference-tlv { >>>> description >>>> ! "The SRMS Preference TLV is used to advertise a preference >>>> ! associated with the node that acts as an SRMS. SRMS >>>> ! advertisements with a higher preference value are preferred >>>> ! over those with a lower preference value."; >>>> reference >>>> "RFC 8665: OSPF Extensions for Segment Routing, Section 3.4"; >>>> container srms-preference-tlv { >>>> --- 692,702 ---- >>>> >>>> grouping srms-preference-tlv { >>>> description >>>> ! "The Segment Routing Mapping Server (SRMS) Preference TLV is >>>> ! used to advertise a preference associated with the node that >>>> ! acts as an SRMS. SRMS advertisements with a higher >>>> ! preference value are preferred over those with a lower >>>> ! preference value."; >>>> reference >>>> "RFC 8665: OSPF Extensions for Segment Routing, Section 3.4"; >>>> container srms-preference-tlv { >>>> *************** >>>> >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>>> >>>>> For the first change, note that we have been removing this statement from >>>>> the abstract in other RFCs (e.g., RFC 9020). >>>>> >>>>> *************** >>>>> *** 74,82 **** >>>>> MPLS data plane. The defined YANG data model is an augmentation to >>>>> the OSPF YANG data model [RFC9129]. >>>>> >>>>> - The YANG data model in this document conforms to the Network >>>>> - Management Datastore Architecture (NMDA) [RFC8342]. >>>>> - >>>>> 1.1. Requirements Language >>>>> >>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>>>> --- 74,79 ---- >>>>> *************** >>>>> *** 105,111 **** >>>>> >>>>> The "ietf-ospf-sr-mpls" module defines both the data nodes to >>>>> configure OSPF Segment Routing MPLS extensions and the additions to >>>>> ! the OSPF Link State Advertisements (LSAs) necessary to support >>>>> Segment Routing over MPLS (SR-MPLS). The OSPF configuration >>>>> includes: >>>>> >>>>> --- 102,108 ---- >>>>> >>>>> The "ietf-ospf-sr-mpls" module defines both the data nodes to >>>>> configure OSPF Segment Routing MPLS extensions and the additions to >>>>> ! OSPF Link State Advertisements (LSAs) necessary to support >>>>> Segment Routing over MPLS (SR-MPLS). The OSPF configuration >>>>> includes: >>>>> >>>>> *************** >>>>> *** 348,354 **** >>>>> base extended-prefix-range-flag; >>>>> description >>>>> "Inter-Area flag. Note that this is only applicable to OSPFv2 >>>>> ! since OSPFv3 advertises separate Inter-Area extended-LSA."; >>>>> reference >>>>> "RFC 8665: OSPF Extensions for Segment Routing, Section 4"; >>>>> } >>>>> --- 345,351 ---- >>>>> base extended-prefix-range-flag; >>>>> description >>>>> "Inter-Area flag. Note that this is only applicable to OSPFv2 >>>>> ! since OSPFv3 advertises separate Inter-Area extended-LSAs."; >>>>> reference >>>>> "RFC 8665: OSPF Extensions for Segment Routing, Section 4"; >>>>> } >>>>> *************** >>>>> *** 500,506 **** >>>>> "RFC 8665: OSPF Extensions for Segment Routing, Section 4"; >>>>> container extended-prefix-range-tlvs { >>>>> description >>>>> ! "List of range of prefixes."; >>>>> list extended-prefix-range-tlv { >>>>> description >>>>> "Range of prefixes."; >>>>> --- 497,503 ---- >>>>> "RFC 8665: OSPF Extensions for Segment Routing, Section 4"; >>>>> container extended-prefix-range-tlvs { >>>>> description >>>>> ! "List of prefix ranges."; >>>>> list extended-prefix-range-tlv { >>>>> description >>>>> "Range of prefixes."; >>>>> *************** >>>>> *** 662,668 **** >>>>> leaf range-size { >>>>> type rt-types:uint24; >>>>> description >>>>> ! "SID range."; >>>>> } >>>>> uses sid-tlv-encoding; >>>>> } >>>>> --- 659,666 ---- >>>>> leaf range-size { >>>>> type rt-types:uint24; >>>>> description >>>>> ! "SID range. The return of a zero value would indicate >>>>> ! an error."; >>>>> } >>>>> uses sid-tlv-encoding; >>>>> } >>>>> *************** >>>>> *** 869,875 **** >>>>> "This augments the OSPF protocol configuration with Segment >>>>> Routing over the MPLS data plane. The following semantic >>>>> validation is to be performed for the configuration data: >>>>> ! - Assure the binding policies prefixes do not overlap."; >>>>> reference >>>>> "RFC 9020: YANG Data Model for Segment Routing"; >>>>> uses sr-mpls:sr-control-plane; >>>>> --- 868,875 ---- >>>>> "This augments the OSPF protocol configuration with Segment >>>>> Routing over the MPLS data plane. The following semantic >>>>> validation is to be performed for the configuration data: >>>>> ! - Assure prefixes specified in binding policies do not >>>>> ! overlap."; >>>>> reference >>>>> "RFC 9020: YANG Data Model for Segment Routing"; >>>>> uses sr-mpls:sr-control-plane; >>>>> *************** >>>>> *** 934,940 **** >>>>> configuration."; >>>>> } >>>>> description >>>>> ! "This augments LAN interface adj-sid with neighbor-id."; >>>>> leaf neighbor-id { >>>>> type inet:ip-address; >>>>> mandatory true; >>>>> --- 934,941 ---- >>>>> configuration."; >>>>> } >>>>> description >>>>> ! "This augments multi-access interface adj-sids with a >>>>> ! neighbor-id."; >>>>> leaf neighbor-id { >>>>> type inet:ip-address; >>>>> mandatory true; >>>>> *************** >>>>> *** 1072,1078 **** >>>>> leaf protection-requested { >>>>> type boolean; >>>>> description >>>>> ! "Describe if the Adj-SID is protected."; >>>>> } >>>>> } >>>>> } >>>>> --- 1073,1079 ---- >>>>> leaf protection-requested { >>>>> type boolean; >>>>> description >>>>> ! "Indicate if the Adj-SID is protected."; >>>>> } >>>>> } >>>>> } >>>>> *************** >>>>> *** 1414,1420 **** >>>>> "This augmentation is only valid for OSPFv3."; >>>>> } >>>>> description >>>>> ! "SR Prefix-SID Sub-TLV in OSPFv3 Link-Scoped Intra-Area-Prefix >>>>> TLV for OSPFv3 E-Inter-Area-Prefix LSAs."; >>>>> reference >>>>> "RFC 8666: OSPFv3 Extensions for Segment Routing, Section 6"; >>>>> --- 1415,1421 ---- >>>>> "This augmentation is only valid for OSPFv3."; >>>>> } >>>>> description >>>>> ! "SR Prefix-SID Sub-TLV in OSPFv3 Intra-Area-Prefix >>>>> TLV for OSPFv3 E-Inter-Area-Prefix LSAs."; >>>>> reference >>>>> "RFC 8666: OSPFv3 Extensions for Segment Routing, Section 6"; >>>>> *************** >>>>> *** 1480,1486 **** >>>>> E-Router LSAs."; >>>>> } >>>>> description >>>>> ! "SR Sub-TLVs in OSPFv3 link-tlv for OSPFv3 E-Router LSAs."; >>>>> reference >>>>> "RFC 8666: OSPFv3 Extensions for Segment Routing, Section 7"; >>>>> uses ospfv3-adj-sid-sub-tlvs; >>>>> --- 1481,1488 ---- >>>>> E-Router LSAs."; >>>>> } >>>>> description >>>>> ! "SR Sub-TLVs in OSPFv3 Router-Link TLV for OSPFv3 E-Router >>>>> ! LSAs."; >>>>> reference >>>>> "RFC 8666: OSPFv3 Extensions for Segment Routing, Section 7"; >>>>> uses ospfv3-adj-sid-sub-tlvs; >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>>> On Nov 25, 2025, at 3:58 PM, Alanna Paloma >>>>>> <[email protected]> wrote: >>>>>> >>>>>> Hi Authors, >>>>>> >>>>>> Thank you for your replies. We have updated as requested. >>>>>> >>>>>> ) FYI - We have moved Derek Yeung’s name out of the YANG module and into >>>>>> this sentence in the Acknowledgements section. Please review and let us >>>>>> know if any further updates are needed. >>>>>> >>>>>> Original: >>>>>> The authors wish to thank Dean Bogdanovic and Kiran Koushik Agrahara >>>>>> Sreenivasa for their YANG module discussions. >>>>>> >>>>>> Current: >>>>>> The authors wish to thank Dean Bogdanovic, Kiran Koushik Agrahara >>>>>> Sreenivasa, and Derek Yeung for their YANG module discussions. >>>>>> >>>>>>> 9) <!--[rfced] We note that Derek Yeung is listed as an author in the >>>>>>> YANG module but is not listed as an author of this document. Should >>>>>>> we remove his name from the YANG module and add it to the >>>>>>> Acknowledgements section? >>>>>>> >>>>>>> Original: >>>>>>> Author: Derek Yeung >>>>>>> <mailto:[email protected]> >>>>>>> --> >>>>>>> >>>>>>> [Yingzhen]: Yes, please add Derek to the acknowledgements. >>>>>> >>>>>> >>>>>> >>>>>> The files have been posted here (please refresh): >>>>>> https://www.rfc-editor.org/authors/rfc9903.txt >>>>>> https://www.rfc-editor.org/authors/rfc9903.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9903.html >>>>>> https://www.rfc-editor.org/authors/rfc9903.xml >>>>>> >>>>>> The relevant diff files are posted here: >>>>>> https://www.rfc-editor.org/authors/rfc9903-diff.html (comprehensive diff) >>>>>> https://www.rfc-editor.org/authors/rfc9903-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 prior to moving forward in the publication process. >>>>>> >>>>>> Please see the AUTH48 status page for this document here: >>>>>> https://www.rfc-editor.org/auth48/rfc9903 >>>>>> >>>>>> Thank you, >>>>>> Alanna Paloma >>>>>> RFC Production Center >>>>>> >>>>>> >>>>>>> On Nov 25, 2025, at 8:55 AM, Helen Chen >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Thanks to Yingzhen for adding my new email address. >>>>>>> >>>>>>> Hello RFC Editor, >>>>>>> >>>>>>> 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 21, 2025, at 2:30 PM, Yingzhen Qu <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Adding Helen's new email address. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Yingzhen >>>>>>>> >>>>>>>> On Fri, Nov 21, 2025 at 10:58 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. --> >>>>>>>> >>>>>>>> >>>>>>>> 2) <!-- [rfced] We note that there is no mention of an "sr-protocol >>>>>>>> grouping" >>>>>>>> in RFC 9020, but it does use "'sr-control-plane' grouping". Should the >>>>>>>> parenthetical text below be updated to match what appears in RFC 9020? >>>>>>>> >>>>>>>> Original: >>>>>>>> * OSPF instance level configuration imported from the ietf-segment- >>>>>>>> routing-mpls YANG module including the mapping server bindings and >>>>>>>> the per-protocol Segment Routing Global Block (SRGB) (refer to the >>>>>>>> sr-protocol grouping [RFC9020]). >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> * OSPF instance level configuration imported from the ietf-segment- >>>>>>>> routing-mpls YANG module including the mapping server bindings and >>>>>>>> the per-protocol Segment Routing Global Block (SRGB) (refer to the >>>>>>>> "sr-control-plane" grouping [RFC9020]). >>>>>>>> --> >>>>>>>> >>>>>>>> >>>>>>>> 3) <!-- [rfced] We note that RFCs 8665 and 8666 use "Extended Prefix >>>>>>>> Range TLV" >>>>>>>> rather than "extended range TLV". May we update the two list items >>>>>>>> below >>>>>>>> to match the corresponding RFCs? >>>>>>>> >>>>>>>> Original: >>>>>>>> * OSPFv2 extended range TLV encodings [RFC8665] in the OSPF >>>>>>>> Extended-Prefix Opaque LSA [RFC7684]. >>>>>>>> ... >>>>>>>> * OSPFv3 extended range TLV encodings [RFC8666] in the OSPFv3 E- >>>>>>>> Intra-Area-Prefix-LSA, E-Inter-Area-Prefix-LSA, E-AS-External-LSA, >>>>>>>> and E-Type-7-LSA [RFC8362]. >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> * OSPFv2 Extended Prefix Range TLV encodings [RFC8665] in the OSPF >>>>>>>> Extended-Prefix Opaque LSA [RFC7684]. >>>>>>>> ... >>>>>>>> * OSPFv3 Extended Prefix Range TLV encodings [RFC8666] in the OSPFv3 >>>>>>>> E- >>>>>>>> Intra-Area-Prefix-LSA, E-Inter-Area-Prefix-LSA, E-AS-External-LSA, >>>>>>>> and E-Type-7-LSA [RFC8362]. >>>>>>>> --> >>>>>>>> >>>>>>>> >>>>>>>> 4) <!--[rfced] FYI - We have removed the following items from their >>>>>>>> corresponding lists in Section 2 as they were each listed twice. >>>>>>>> >>>>>>>> Original: >>>>>>>> * OSPFv2 Prefix SID Sub-TLV encodings [RFC8665] included the OSPF >>>>>>>> Extended Prefix TLV which is advertised in the OSPF Extended >>>>>>>> Prefix Opaque LSA [RFC7684]. >>>>>>>> ... >>>>>>>> * OSPFv3 extended range TLV encodings [RFC8666] in the OSPFv3 E- >>>>>>>> Intra-Area-Prefix-LSA, E-Inter-Area-Prefix-LSA, E-AS-External-LSA, >>>>>>>> and E-Type-7-LSA [RFC8362]. >>>>>>>> ... >>>>>>>> * OSPFv3 Adj-SID Sub-TLV [RFC8666] in the OSPFv3 Router-Link TLV >>>>>>>> [RFC8362]. >>>>>>>> --> >>>>>>>> >>>>>>>> >>>>>>>> 5) <!--[rfced] We note that there is no mention of "Extended Prefix >>>>>>>> Range TLV" >>>>>>>> in RFC 8362, but it is defined in RFC 8666 (note that >>>>>>>> "Intra-Area-Prefix TLV", >>>>>>>> "Inter-Area-Prefix TLV", and "External-Prefix TLV" are defined in RFC >>>>>>>> 8362). >>>>>>>> Please review and let us know if/how the text or citation should be >>>>>>>> updated for >>>>>>>> correctness. >>>>>>>> >>>>>>>> Original: >>>>>>>> * OSPFv3 Prefix-SID Sub-TLV encodings [RFC8666] in the OSPFv3 Intra- >>>>>>>> Area Prefix TLV, Inter-Area Prefix TLV, External Prefix TLV, and >>>>>>>> OSPFv3 Extended Prefix Range TLV [RFC8362]. >>>>>>>> --> >>>>>>>> >>>>>>>> >>>>>>>> 6) <!-- [rfced] We note that [RFC2328] and [RFC5340] are not >>>>>>>> referenced in the >>>>>>>> YANG module but are listed in the introductory text for the YANG >>>>>>>> module. >>>>>>>> Additionally, [RFC8665], [RFC8666], [RFC9020], and [RFC9129] are >>>>>>>> referenced >>>>>>>> in the YANG module but are not listed in the introductory text. May we >>>>>>>> update >>>>>>>> the introductory text as follows? Note that, if yes, we will also >>>>>>>> remove the >>>>>>>> references for [RFC2328] and [RFC5340] from the Normative References >>>>>>>> section. >>>>>>>> >>>>>>>> Original: >>>>>>>> [RFC2328], [RFC4915], [RFC5340], [RFC6991], [RFC8102], [RFC8294], >>>>>>>> [RFC8349], [RFC9587], and [I-D.ietf-rtgwg-segment-routing-ti-lfa] are >>>>>>>> referenced in the YANG module. >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> [RFC4915], [RFC6991], [RFC8102], [RFC8294], [RFC8349], [RFC8665], >>>>>>>> [RFC8666], [RFC9020]. [RFC9129], [RFC9587], and [RFC9855] are >>>>>>>> referenced in the YANG module. >>>>>>>> --> >>>>>>>> >>>>>>>> >>>>>>>> 7) <!--[rfced] We are having some difficulty parsing this description >>>>>>>> text >>>>>>>> in the YANG module, particularly with "interface" repeated. Please >>>>>>>> review >>>>>>>> and let us know how it should be updated for clarity. >>>>>>>> >>>>>>>> Original: >>>>>>>> This augments broadcast and non-broadcast multi-access >>>>>>>> interface segment routing interface configuration. >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> This augments broadcast and non-broadcast multi-access >>>>>>>> interface Segment Routing and interface configuration. >>>>>>>> --> >>>>>>>> >>>>>>>> >>>>>>>> 8) <!--[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. >>>>>>>> --> >>>>>>>> >>>>>>>> >>>>>>>> 9) <!--[rfced] We note that Derek Yeung is listed as an author in the >>>>>>>> YANG module but is not listed as an author of this document. Should >>>>>>>> we remove his name from the YANG module and add it to the >>>>>>>> Acknowledgements section? >>>>>>>> >>>>>>>> Original: >>>>>>>> Author: Derek Yeung >>>>>>>> <mailto:[email protected]> >>>>>>>> --> >>>>>>>> >>>>>>>> >>>>>>>> 10) <!--[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. Specifically: >>>>>>>> >>>>>>>> - Should this sentence from the template be added? "There are no >>>>>>>> particularly sensitive RPC or action operations." >>>>>>>> >>>>>>>> --> >>>>>>>> >>>>>>>> >>>>>>>> 11) <!--[rfced] Abbreviations >>>>>>>> >>>>>>>> a) FYI - We have added expansions for the following abbreviations >>>>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >>>>>>>> expansion in the document carefully to ensure correctness. >>>>>>>> >>>>>>>> IP Fast Reroute (IP-FRR) >>>>>>>> No Penultimate Hop-Popping) (No-PHP) >>>>>>>> Remote Loop-Free Alternate (RLFA) >>>>>>>> Segment Routing Local Block (SRLB) >>>>>>>> >>>>>>>> >>>>>>>> b) 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 for >>>>>>>> consistency? >>>>>>>> >>>>>>>> Adjacency Segment Identifier, adjacency Segment ID, adjacency SID >>>>>>>> (Adj-SID) >>>>>>>> Denial-of-Service (DoS) >>>>>>>> Remote LFA (RLFA) >>>>>>>> Segment ID, Segment Identifier (SID) >>>>>>>> Segment Routing Mapping Server, SR Mapping Server (SRMS) >>>>>>>> Segment Routing over MPLS (SR-MPLS) >>>>>>>> >>>>>>>> >>>>>>>> c) FYI, we updated the expansion of "SRLG" from "Shared Resource Link >>>>>>>> Group" to "Shared Risk Link Group" to match how it is expanded in >>>>>>>> past RFCs. >>>>>>>> >>>>>>>> d) FYI, we updated one instance of "SRBG" to "SRGB" (Section 4) to >>>>>>>> match usage in the rest of the document. >>>>>>>> --> >>>>>>>> >>>>>>>> >>>>>>>> 12) <!-- [rfced] Terminology >>>>>>>> >>>>>>>> a) Throughout the text, the following terminology appears to be used >>>>>>>> inconsistently. Please review these occurrences and let us know if/how >>>>>>>> they >>>>>>>> may be made consistent. >>>>>>>> >>>>>>>> Segment Routing vs. segment routing >>>>>>>> >>>>>>>> >>>>>>>> b) For consistency and to reflect how they appear in previously >>>>>>>> published >>>>>>>> RFCs, we have updated the terminology to the form on the right. Please >>>>>>>> review >>>>>>>> and let us know if any further updates are needed. >>>>>>>> >>>>>>>> Adj-SID sub-TLV, Adj-SID sub-tlv, Adj-sid sub-tlv > Adj-SID Sub-TLV >>>>>>>> >>>>>>>> Prefix SID Sub-TLV, prefix SID sub-TLV, Prefix SID sub-TLV > >>>>>>>> Prefix-SID Sub-TLV >>>>>>>> --> >>>>>>>> >>>>>>>> >>>>>>>> 13) <!-- [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:57 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-4Q9l2USxIAe6P8O4Zc >>>>>>>> >>>>>>>> * 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/rfc9903.xml >>>>>>>> https://www.rfc-editor.org/authors/rfc9903.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9903.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9903.txt >>>>>>>> >>>>>>>> Diff file of the text: >>>>>>>> https://www.rfc-editor.org/authors/rfc9903-diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9903-rfcdiff.html (side by side) >>>>>>>> >>>>>>>> Diff of the XML: >>>>>>>> https://www.rfc-editor.org/authors/rfc9903-xmldiff1.html >>>>>>>> >>>>>>>> >>>>>>>> Tracking progress >>>>>>>> ----------------- >>>>>>>> >>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9903 >>>>>>>> >>>>>>>> Please let us know if you have any questions. >>>>>>>> >>>>>>>> Thank you for your cooperation, >>>>>>>> >>>>>>>> RFC Editor >>>>>>>> >>>>>>>> -------------------------------------- >>>>>>>> RFC9903 (draft-ietf-ospf-sr-yang-50) >>>>>>>> >>>>>>>> Title : A YANG Data Model for OSPF Segment Routing over the >>>>>>>> MPLS Data Plane >>>>>>>> Author(s) : Y. Qu, A. Lindem, Z. Zhang, I. Chen >>>>>>>> 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]
