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]
