Hi Alanna, Thanks for making the changes. I approve the document for publication.
Thanks, Yingzhen On Wed, Dec 3, 2025 at 9:41 AM Alanna Paloma <[email protected]> wrote: > Hi Authors, > > > RFC9903 includes section 1.1, "Requirements Language", while 9902 > doesn't have this. Should this be removed? > > " > > 1.1. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in BCP 14 > [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as > shown here. > > " > > RFC-to-be 9903 uses terms listed in that Requirements Language paragraph; > RFC-to-be 9902 included that paragraph but did not use any of those terms > within the document so we removed that text from the document (see question > #2 in the AUTH48 thread of that document). The Requirements Language > section should remain in RFC-to-be 9903. > > > 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 updated per your request. We have also sent mail in > the AUTH48 thread for RFC-to-be 9902 to note the updates made in that > document. > > 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) > > See the AUTH48 status of this document here: > https://www.rfc-editor.org/auth48/rfc9903 > > We will await any further changes you may have as well as approvals from > Yingzhen, Jeffrey, and Helen prior to moving this document forward in the > publication process. > > Thank you, > Alanna Paloma > RFC Production Center > > > On Dec 2, 2025, at 11:03 AM, Yingzhen Qu <[email protected]> > wrote: > > > > Hi Alanna, > > > > RFC9903 includes section 1.1, "Requirements Language", while 9902 > doesn't have this. Should this be removed? > > " > > 1.1. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in BCP 14 > [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as > shown here. > > " > > > > 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". > > " > > > > Thanks, > > Yingzhen > > > > On Mon, Dec 1, 2025 at 9:57 AM 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 <ichen= > [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]
