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 >>>>>> <[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]
