Hi Madison, Thanks for the update. I've reviewed the latest version and I approve this version for publication.
Thanks, Yingzhen On Fri, Dec 20, 2024 at 8:24 AM Madison Church <mchu...@amsl.com> wrote: > Hi Acee, > > Thank you for your quick reply! We have added your approval to the AUTH48 > status page (please see https://www.rfc-editor.org/auth48/rfc9702). > > Once we receive approvals from Yingzhen, Stephane, and Jeff, we will move > this document forward in the publication process. > > Thank you! > RFC Editor/mc > > > On Dec 20, 2024, at 10:13 AM, Acee Lindem <acee.i...@gmail.com> wrote: > > > > 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
