Hi Amanda, Thank you for the quick reply! The change looks good.
Thank you, RFC Editor/mc > On Jan 3, 2025, at 11:59 AM, Amanda Baber via RT <iana-iss...@iana.org> wrote: > > Hi, > > We've removed the hyphen from "Data-Plane": > > https://www.iana.org/assignments/igp-parameters > > thanks, > > Amanda Baber > IANA Operations Manager > > On Fri Jan 03 15:14:41 2025, mchu...@amsl.com wrote: >> IANA, >> >> For the "Data-Plane" column header listed in the "IGP MSD-Types" >> registry (https://www.iana.org/assignments/igp-parameters/igp- >> parameters.xhtml#igp-msd-types), please remove the hyphen in "Data- >> Plane". >> >> Original: >> Data-Plane >> >> Updated: >> Data Plane >> >> Thank you, >> RFC Editor/mc >> >>> On Jan 3, 2025, at 9:07 AM, Madison Church <mchu...@amsl.com> wrote: >>> >>> Hi Stephane, >>> >>> Thank you for your reply! We have added your approval to the AUTH48 >>> status page (see https://www.rfc-editor.org/auth48/rfc9702). >>> >>> Now that we have all author approvals, we will now ask IANA to make >>> updates to the "IGP MSD-Types" registry. >>> >>> Thank you! >>> RFC Editor/mc >>> >>>> On Jan 3, 2025, at 3:53 AM, slitkows.i...@gmail.com wrote: >>>> >>>> Hi, >>>> >>>> Happy new year to all of you. >>>> >>>> I approve the publication. >>>> >>>> >>>> Brgds, >>>> >>>> Stephane >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Sandy Ginoza <sgin...@amsl.com> >>>> Sent: Monday, December 23, 2024 5:07 PM >>>> To: Jeff Tantsura <jefftant.i...@gmail.com> >>>> Cc: Madison Church <mchu...@amsl.com>; Acee Lindem >>>> <acee.i...@gmail.com>; Yingzhen Qu <yingzhen.i...@gmail.com>; >>>> Stephane Litkowski <slitkows.i...@gmail.com>; RFC Editor <rfc- >>>> edi...@rfc-editor.org>; mpls-...@ietf.org; mpls-cha...@ietf.org; >>>> ts...@cisco.com; James Guichard <james.n.guich...@futurewei.com>; >>>> auth48archive@rfc-editor.org >>>> Subject: Re: AUTH48: RFC-to-be 9702 <draft-ietf-mpls-msd-yang-12> >>>> for your review >>>> >>>> Hi Jeff, >>>> >>>> Thanks for your review. We have noted your approval on the AUTH48 >>>> page. We will wait to hear from your coauthors before continuing >>>> with the publication process. >>>> >>>> Happy holidays! >>>> RFC Editor/sg >>>> >>>> >>>> >>>>> On Dec 20, 2024, at 10:13 PM, Jeff Tantsura >>>>> <jefftant.i...@gmail.com> wrote: >>>>> >>>>> Hi Madison, >>>>> I approve the publication. >>>>> >>>>> Many thanks and happy holidays! >>>>> >>>>> Cheers, >>>>> Jeff >>>>> >>>>>> On Dec 20, 2024, at 08:08, Madison Church <mchu...@amsl.com> >>>>>> wrote: >>>>>> >>>>>> Hi Authors, >>>>>> >>>>>> Acee - Thank you for your reply! We have updated the files below >>>>>> to reflect your proposed changes. >>>>>> >>>>>> Please review the files carefully to ensure satisfaction as we do >>>>>> not make changes once the document has been published as an RFC. >>>>>> Contact us with any further updates or with your approval of the >>>>>> document in its current form. We will await approvals from each >>>>>> author prior to moving forward in the publication process. >>>>>> >>>>>> The files have been posted here (please refresh): >>>>>> https://www.rfc-editor.org/authors/rfc9702.txt >>>>>> https://www.rfc-editor.org/authors/rfc9702.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9702.html >>>>>> https://www.rfc-editor.org/authors/rfc9702.xml >>>>>> >>>>>> The relevant diff files have been posted here (please refresh): >>>>>> https://www.rfc-editor.org/authors/rfc9702-diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9702-rfcdiff.html >>>>>> https://www.rfc-editor.org/authors/rfc9702-auth48diff.html >>>>>> >>>>>> For the AUTH48 status of this document, please see: >>>>>> https://www.rfc-editor.org/auth48/rfc9702 >>>>>> >>>>>> Thank you, >>>>>> RFC Editor/mc >>>>>> >>>>>>> On Dec 19, 2024, at 1:54 PM, Acee Lindem <acee.i...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> Hi Madison, >>>>>>> >>>>>>> I only have a couple minor editorial changes. >>>>>>> >>>>>>> Acee-Lindems-iMac-2:Desktop acee$ diff -c rfc9702-orig.txt >>>>>>> rfc9702.txt >>>>>>> *** rfc9702-orig.txt Thu Dec 19 14:32:29 2024 >>>>>>> --- rfc9702.txt Thu Dec 19 14:49:03 2024 >>>>>>> *************** >>>>>>> *** 85,91 **** >>>>>>> the routing RIB data model [RFC8349] to provide operational state >>>>>>> for >>>>>>> various MSDs [RFC8662] for the MPLS data plane. The module >>>>>>> augments >>>>>>> the base MPLS model with a list of various types of Node MSDs as >>>>>>> well >>>>>>> ! as various types of MSDs on links. >>>>>>> >>>>>>> The YANG modules in this document conform to the Network >>>>>>> Management >>>>>>> Datastore Architecture (NMDA) [RFC8342]. >>>>>>> --- 85,91 ---- >>>>>>> the routing RIB data model [RFC8349] to provide operational state >>>>>>> for >>>>>>> various MSDs [RFC8662] for the MPLS data plane. The module >>>>>>> augments >>>>>>> the base MPLS model with a list of various types of Node MSDs as >>>>>>> well >>>>>>> ! as various types of Link MSDs. >>>>>>> >>>>>>> The YANG modules in this document conform to the Network >>>>>>> Management >>>>>>> Datastore Architecture (NMDA) [RFC8342]. >>>>>>> *************** >>>>>>> *** 116,124 **** >>>>>>> >>>>>>> As defined in [RFC8491], a Link MSD is the number of SIDs >>>>>>> supported >>>>>>> by a node's link, while a Node MSD is the smallest MSD supported >>>>>>> by >>>>>>> ! the node across all its interfaces. The module defines >>>>>>> lists of MSDs >>>>>>> ! with different MSD Types for a node and links. Please note >>>>>>> that >>>>>>> ! these are read-only data as per the node's hardware >>>>>>> capability. >>>>>>> >>>>>>> 3. Tree for IETF MPLS MSD Types YANG Module >>>>>>> >>>>>>> --- 116,124 ---- >>>>>>> >>>>>>> As defined in [RFC8491], a Link MSD is the number of SIDs >>>>>>> supported >>>>>>> by a node's link, while a Node MSD is the smallest MSD supported >>>>>>> by >>>>>>> ! the node across all its links. The module defines lists of >>>>>>> MSDs >>>>>>> ! and their MSD Types for a node and its links. Please note >>>>>>> that >>>>>>> ! these are read-only data nodes exposing a node's hardware >>>>>>> capability. >>>>>>> >>>>>>> 3. Tree for IETF MPLS MSD Types YANG Module >>>>>>> >>>>>>> *************** >>>>>>> *** 246,252 **** >>>>>>> identity srh-max-sl { >>>>>>> base msd-base-srh; >>>>>>> description >>>>>>> ! "The Maximum Segment Left MSD type."; >>>>>>> reference >>>>>>> "RFC 9352: IS-IS Extensions to Support Segment Routing >>>>>>> over the IPv6 Data Plane"; >>>>>>> --- 246,252 ---- >>>>>>> identity srh-max-sl { >>>>>>> base msd-base-srh; >>>>>>> description >>>>>>> ! "The Maximum Segments Left MSD type."; >>>>>>> reference >>>>>>> "RFC 9352: IS-IS Extensions to Support Segment Routing >>>>>>> over the IPv6 Data Plane"; >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Acee >>>>>>> >>>>>>> >>>>>>>>> On Dec 16, 2024, at 9:52 AM, Madison Church <mchu...@amsl.com> >>>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Yingzhen and Acee, >>>>>>>> >>>>>>>> Thank you both for your replies! We have updated the files and >>>>>>>> posted them below. All of our questions have been addressed. >>>>>>>> Please see one followup comment in this thread under question 3. >>>>>>>> >>>>>>>> Please review the document carefully to ensure satisfaction as >>>>>>>> we do not make changes once it has been published as an RFC. >>>>>>>> Contact us with any further updates or with your approval of the >>>>>>>> document in its current form. We will await approvals from each >>>>>>>> author prior to moving forward in the publication process. >>>>>>>> >>>>>>>> The files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9702.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9702.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9702.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9702.xml >>>>>>>> >>>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9702-diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9702-rfcdiff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9702-auth48diff.html >>>>>>>> >>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9702 >>>>>>>> >>>>>>>> Thank you, >>>>>>>> RFC Editor/mc >>>>>>>> >>>>>>>>> On Dec 16, 2024, at 6:57 AM, Acee Lindem <acee.i...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi RFC Editor, >>>>>>>>> >>>>>>>>> See a couple places where a response is needed. >>>>>>>>> >>>>>>>>>> On Dec 13, 2024, at 12:40 AM, Yingzhen Qu >>>>>>>>>> <yingzhen.i...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Thanks for working on this document. Please see my reply below >>>>>>>>>> inline. >>>>>>>>>> >>>>>>>>>> For the Abstract, I'm thinking of a few minor changes: >>>>>>>>>> old: >>>>>>>>>> This document defines two YANG data modules. The first is the >>>>>>>>>> initial version of the IANA-maintained YANG module for >>>>>>>>>> Maximum >>>>>>>>>> Segment Identifier (SID) Depth (MSD) Types, which includes >>>>>>>>>> identities for both the MPLS data plane and Segment Routing >>>>>>>>>> over >>>>>>>>>> IPv6 (SRv6) data plane. The second augments the IETF MPLS >>>>>>>>>> YANG >>>>>>>>>> model to provide support for MPLS MSDs as defined in RFCs 8476 >>>>>>>>>> and 8491. >>>>>>>>>> new: >>>>>>>>>> This document defines two YANG modules. The first module is >>>>>>>>>> the >>>>>>>>>> initial version of the IANA-maintained YANG module for >>>>>>>>>> Maximum >>>>>>>>>> Segment Identifier (SID) Depth (MSD) Types, which includes >>>>>>>>>> identities for both the MPLS data plane and Segment Routing >>>>>>>>>> over >>>>>>>>>> IPv6 (SRv6) data plane. The second module augments the IETF >>>>>>>>>> MPLS >>>>>>>>>> YANG model to provide support for MPLS MSDs as defined in RFCs >>>>>>>>>> 8476 and 8491. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Yingzhen >>>>>>>>>> >>>>>>>>>> On Wed, Dec 11, 2024 at 6:00 PM <rfc-edi...@rfc-editor.org> >>>>>>>>>> wrote: >>>>>>>>>> Authors, >>>>>>>>>> >>>>>>>>>> While reviewing this document during AUTH48, please resolve >>>>>>>>>> (as necessary) the following questions, which are also in the >>>>>>>>>> XML file. >>>>>>>>>> >>>>>>>>>> 1) <!-- [rfced] Please note that the title of the document has >>>>>>>>>> been updated to expand abbreviations per Section 3.6 of RFC >>>>>>>>>> 7322 >>>>>>>>>> ("RFC Style Guide"). Please let us know if you prefer >>>>>>>>>> otherwise. >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> YANG Data Model for Maximum SID Depth Types and MPLS Maximum >>>>>>>>>> SID >>>>>>>>>> Depth >>>>>>>>>> >>>>>>>>>> Current: >>>>>>>>>> YANG Data Model for Maximum Segment Identifier (SID) Depth >>>>>>>>>> Types >>>>>>>>>> and MPLS Maximum SID Depth >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> [Yingzhen]: How about: >>>>>>>>>> YANG Data Model for Maximum Segment Identifier (SID) Depth >>>>>>>>>> (MSD) >>>>>>>>>> Types and MPLS MSD >>>>>>>>> >>>>>>>>> I like Yingzhen's suggestion better. >>>>>>>>> >>>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that >>>>>>>>>> appear in the title) for use on >>>>>>>>>> https://www.rfc-editor.org/search. --> >>>>>>>>>> >>>>>>>>>> [Yingzhen]: how about "MSD Types"? >>>>>>>>>> >>>>>>>>>> 3) <!--[rfced] We note that two RFCs in the reference clauses >>>>>>>>>> in >>>>>>>>>> the iana-msd-types module do not appear in the reference >>>>>>>>>> section of the RFC. >>>>>>>>>> May a sentence be added before the YANG module stating that it >>>>>>>>>> refers to the following RFCs? For example: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> (where [RFC8664] and [RFC8814] would be added as Informative >>>>>>>>>> References) >>>>>>>>>> >>>>>>>>>> Alternatively, you could let us know a different place to cite >>>>>>>>>> [RFC8664] and [RFC8814] in this document. >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> [Yingzhen]: The proposed text is fine. Should it be added to >>>>>>>>>> Section 4 before section 4.1? >>>>>>>>> >>>>>>>>> RFC Editor? >>>>>>>> >>>>>>>> [rfced] We have added the sentence to Section 4.1 (IANA- >>>>>>>> Maintained Module for MSD-Types). >>>>>>>> >>>>>>>>>> 4) <!--[rfced] FYI, the Security Considerations section has >>>>>>>>>> been >>>>>>>>>> updated to match https://wiki.ietf.org/group/ops/yang- >>>>>>>>>> security-guidelines. >>>>>>>>>> If the differences from the approved template should be >>>>>>>>>> reinstated, please let us know. >>>>>>>>>> >>>>>>>>>> Specifically, this text is no longer present: >>>>>>>>>> ... without the "none" authentication option, Transport Layer >>>>>>>>>> Security (TLS) [RFC8446] with mutual X.509 authentication, >>>>>>>>>> and >>>>>>>>>> HTTPS with HTTP authentication (Section 11 of [RFC9110]). >>>>>>>>>> >>>>>>>>>> The normative reference [RFC9110] has been removed, as it was >>>>>>>>>> not >>>>>>>>>> cited elsewhere in the document. >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> [Yingzhen]: this is ok. >>>>>>>>>> 5) <!--[rfced] We suggest naming the column "Data Plane" no >>>>>>>>>> hyphen, as the hyphen seems unnecessary. If you agree, we >>>>>>>>>> will >>>>>>>>>> ask IANA to update the registry accordingly. >>>>>>>>>> >>>>>>>>>> Current: IANA has added a "Data-Plane" column >>>>>>>>>> Suggested: IANA has added a "Data Plane" column [and other >>>>>>>>>> instances] >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> [Yingzhen]: this is fine. >>>>>>>>>> >>>>>>>>>> 6) <!--[rfced] FYI, "N/A" has been removed from Table 1 in >>>>>>>>>> order >>>>>>>>>> to match the IANA registry, which does not use "N/A" for empty >>>>>>>>>> fields. >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> [Yingzhen]: ok. >>>>>>>>>> >>>>>>>>>> 7) <!-- [rfced] RFC 7950 is not cited anywhere in this >>>>>>>>>> document. >>>>>>>>>> Please let us know where it should be cited; otherwise, this >>>>>>>>>> reference will be removed from the Normative References. >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling >>>>>>>>>> Language", >>>>>>>>>> RFC 7950, DOI 10.17487/RFC7950, August 2016, >>>>>>>>>> <https://www.rfc-editor.org/info/rfc7950>. --> >>>>>>>>>> >>>>>>>>>> [Yingzhen]: the reference to RFC 7950 can be added to Section >>>>>>>>>> 1. >>>>>>>>>> Old: >>>>>>>>>> There are two YANG modules defined in this document. >>>>>>>>>> New: >>>>>>>>>> There are two YANG modules [RFC7950 ]defined in this >>>>>>>>>> document. >>>>>>>>> >>>>>>>>> Spacing: >>>>>>>>> There are two YANG modules [RFC7950] defined in this document. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Acee >>>>>>>>> >>>>>>>>> >>>>>>>>>> 8) <!-- [rfced] Terminology >>>>>>>>>> >>>>>>>>>> a) We have received guidance from Benoît Claise and the YANG >>>>>>>>>> Doctors that the terms "YANG module" and "YANG data model" are >>>>>>>>>> preferred. Please review the usage in this document. For >>>>>>>>>> example, should text be updated as follows or otherwise? >>>>>>>>>> >>>>>>>>>> Abstract >>>>>>>>>> Original: This document defines two YANG data modules. >>>>>>>>>> Perhaps: This document defines two YANG modules. >>>>>>>>>> [Section 1 already uses the latter.] >>>>>>>>>> >>>>>>>>>> Original: The second augments the IETF MPLS YANG model to >>>>>>>>>> provide ... >>>>>>>>>> Perhaps: The second augments the IETF MPLS YANG data model to >>>>>>>>>> provide ... >>>>>>>>>> [And the same for similar text in Section 1.] >>>>>>>>>> >>>>>>>>>> Acknowledgements >>>>>>>>>> Original: The YANG model was developed ... >>>>>>>>>> Perhaps: The YANG data model was developed ... >>>>>>>>>> >>>>>>>>>> [Yingzhen]: I'm ok with the proposed changes. >>>>>>>>>> >>>>>>>>>> b) FYI, we have updated the terms below to use the form on the >>>>>>>>>> right, as this is how they appear in the referenced documents >>>>>>>>>> (e.g., RFC 8491). >>>>>>>>>> >>>>>>>>>> node MSD vs. Node MSD >>>>>>>>>> link MSD vs. Link MSD >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> [Yingzhen]: Thanks for making them consistent. >>>>>>>>>> >>>>>>>>>> 9) <!-- [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. >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> [Yingzhen]: I think we're good here. >>>>>>>>>> >>>>>>>>>> 10) <!-- [rfced] FYI - We have added expansions for >>>>>>>>>> abbreviations >>>>>>>>>> upon first use per Section 3.6 of RFC 7322 ("RFC Style >>>>>>>>>> Guide"). >>>>>>>>>> Please review each expansion in the document carefully to >>>>>>>>>> ensure correctness. >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> [Yingzhen]: they look good to me. >>>>>>>>>> >>>>>>>>>> Thank you. >>>>>>>>>> >>>>>>>>>> RFC Editor/mc/ar >>>>>>>>>> >>>>>>>>>> On Dec 11, 2024, rfc-edi...@rfc-editor.org wrote: >>>>>>>>>> >>>>>>>>>> *****IMPORTANT***** >>>>>>>>>> >>>>>>>>>> Updated 2024/12/11 >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> * rfc-edi...@rfc-editor.org (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). >>>>>>>>>> >>>>>>>>>> * auth48archive@rfc-editor.org, 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- >>>>>>>>>> 4Q9l >>>>>>>>>> 2USxIAe6P8O4Zc >>>>>>>>>> >>>>>>>>>> * 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, >>>>>>>>>> auth48archive@rfc-editor.org 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/rfc9702.xml >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9702.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9702.pdf >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9702.txt >>>>>>>>>> >>>>>>>>>> Diff file of the text: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9702-diff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9702-rfcdiff.html (side >>>>>>>>>> by >>>>>>>>>> side) >>>>>>>>>> >>>>>>>>>> Diff of the XML: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9702-xmldiff1.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Tracking progress >>>>>>>>>> ----------------- >>>>>>>>>> >>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9702 >>>>>>>>>> >>>>>>>>>> Please let us know if you have any questions. >>>>>>>>>> >>>>>>>>>> Thank you for your cooperation, >>>>>>>>>> >>>>>>>>>> RFC Editor >>>>>>>>>> >>>>>>>>>> -------------------------------------- >>>>>>>>>> RFC9702 (draft-ietf-mpls-msd-yang-12) >>>>>>>>>> >>>>>>>>>> Title : YANG Data Model for Maximum SID Depth Types >>>>>>>>>> and MPLS Maximum SID Depth >>>>>>>>>> Author(s) : Y. Qu, A. Lindem, S. Litkowski, J. Tantsura >>>>>>>>>> WG Chair(s) : Nicolai Leymann, Tarek Saad, Tony Li >>>>>>>>>> Area Director(s) : Jim Guichard, John Scudder, Gunter Van de >>>>>>>>>> Velde >>>>>> >>>>> >>>> >>>> >>> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
