Hi Alana, Here is my complete set of editorial comments in RFC diff format.
Thanks, Acee
<<< text/html; x-unix-mode=0644; name="rfc9903.orig.diff.html": Unrecognized >>>
> 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]
