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
