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
