Hi Gunter, Thank you for your approvals. They have been noted on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9903
Best regards, Alanna Paloma RFC Production Center > On Dec 2, 2025, at 2:07 AM, Gunter van de Velde (Nokia) > <[email protected]> wrote: > > Hi Alanna, > > Please see inline: GV> > > > From: Alanna Paloma <[email protected]> > Sent: Monday, December 01, 2025 6:56 PM > To: Acee Lindem <[email protected]>; Gunter van de Velde (Nokia) > <[email protected]> > Cc: Yingzhen Qu <[email protected]>; Jeffrey (Zhaohui) Zhang > <[email protected]>; Editor RFC <[email protected]>; > [email protected] <[email protected]>; [email protected] > <[email protected]>; [email protected]<[email protected]>; auth48archive > <[email protected]>; Helen Chen <[email protected]> > Subject: [AD] Re: AUTH48: RFC-to-be 9903 <draft-ietf-ospf-sr-yang-50> 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): added text > GV> approved. The added text makes the document more clear. > > - Section 6.2: removed informative reference entry for RFC 8342 > GV> Approved. The line mentioning this was removed, so indeed no more need. > > 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]
