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
