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 <[email protected]> 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 <[email protected]> wrote:
>>
>> Hi RFC Editor,
>>
>> See a couple places where a response is needed.
>>
>>> On Dec 13, 2024, at 12:40 AM, Yingzhen Qu <[email protected]> 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 <[email protected]> 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, [email protected] 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
>>>
>>> * [email protected] (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).
>>>
>>> * [email protected], 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,
>>> [email protected] 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 -- [email protected]
To unsubscribe send an email to [email protected]
