Authors, We have now received all necessary approvals and consider AUTH48 complete (see https://www.rfc-editor.org/auth48/rfc9702).
Thank you for your time and attention during the AUTH48 process! We will prepare the document for publication at this time. Best, RFC Editor/mc > On Jan 6, 2025, at 10:10 AM, Madison Church <mchu...@amsl.com> wrote: > > Hi Amanda, > > Thank you for the quick reply! The change looks good. > > Thank you, > RFC Editor/mc > >> On Jan 3, 2025, at 11:59 AM, Amanda Baber via RT <iana-iss...@iana.org> >> wrote: >> >> Hi, >> >> We've removed the hyphen from "Data-Plane": >> >> https://www.iana.org/assignments/igp-parameters >> >> thanks, >> >> Amanda Baber >> IANA Operations Manager >> >> On Fri Jan 03 15:14:41 2025, mchu...@amsl.com wrote: >>> 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
