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
