Jeffrey and Helen - Please review and approve ASAP. Jeffrey - I can't look at my IETF Email without seeing copious Emails from your esteemed colleagues - Now I'm just asking to see one from you 😎
Thanks, Acee > On Dec 2, 2025, at 7:16 AM, Acee Lindem <[email protected]> wrote: > > Hi Yingzhen, Jeffrey, and Helen, > > Please review and approve. > > Thanks, > Acee > >> On Dec 2, 2025, at 5: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]
