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).
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]
