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:
>
> This module references [RFC8476], [RFC8491], [RFC8662], [RFC8664],
> [RFC8814], [RFC9088], and [RFC9352].
>
> (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?
>
> 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
