Hi Madison, Thanks for the quick update! I approve this version for publication.
Thanks, Acee > On Dec 20, 2024, at 11: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-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, >>>>> 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
