YANG Data Model for Maximum SID Depth Types and MPLS Maximum SID Depth
draft-ietf-mpls-msd-yang-12

[Ballot comment]
I reviewed version draft-ietf-mpls-msd-yang-12

My main observation is that the MSD leaf is read-only instead of read-write.

A consideration for making the leaf read-write instead of read-only is that future MSDs may emerge that benefit more significantly from write capabilities, unlike existing ERLD and BMI. With the currently proposed yang model, updating would be necessary. While this change appears to be backward compatible and should not pose major issues, it will nonetheless require processing.

I agree with you that my observation pertains more to the current MSD drafts than to the proposed YANG model.

My believe is that RW seems more future proof, but that is a discussion i'll leave in the hands of the WG and document authors.

[Ballot comment]
I reviewed version draft-ietf-mpls-msd-yang-12

The draft is clear and in general i see no big issues with the yang model proposed.

Currently, my ballot is explicitly set to a 'No Record' position as I am unclear on the history behind why the MSD (Maximum SID Depth) leaves only provide read-only operational information. I'll update once i understand the philosophy of MSD model intent better.

Allow me to explain my concern. One might assume that a hardware device supports, for instance, the most optimal setup where Ethernet encapsulation can impose 10 MPLS segment SIDs. However, if such an interface is configured with a more complex L2 encapsulation (such as 802.1q combined with EVPN service SIDs and Entropy SIDs), the value that controllers can use might be reduced to 8, or even less, depending on the encoding and encapsulation complexity. In such scenarios, an operator may wish to adjust the most optimal MSD values to something less optimal but supported by the hardware when attempting to program a segment routing policy on a data packet

[Ballot comment]
I reviewed version draft-ietf-mpls-msd-yang-12

The draft is clear and in general i see no big issues with the yang model proposed.

Currently, my ballot is explicitly set to a 'No Record' position as I am unclear on the history behind why the MSD (Maximum SID Depth) leaves only provide read-only operational information.

Allow me to explain my concern. One might assume that a hardware device supports, for instance, the most optimal setup where Ethernet encapsulation can impose 10 MPLS segment SIDs. However, if such an interface is configured with a more complex L2 encapsulation (such as 802.1q combined with EVPN service SIDs and Entropy SIDs), the value that controllers can use might be reduced to 8, or even less, depending on the encoding and encapsulation complexity. In such scenarios, an operator may wish to adjust the most optimal MSD values to something less optimal but supported by the hardware when attempting to program a segment routing policy on a data packet

[Ballot comment]

"MPLS", paragraph 0
>  YANG Data Model for MPLS Maximum Segment Identifier (SID) Depth (MSD)
>                      draft-ietf-mpls-msd-yang-10
I support Eric's DISCUSS on the naming of the draft. If the draft is defining identities for both MPLS and SRH, shouldn't the title reflect it?

Section 1, paragraph 1
>    YANG [RFC7950] is a data modeling language used to define the
>    contents of a conceptual data store that allows networked devices to
>    be managed using NETCONF [RFC6241] or RESTCONF [RFC8040].

A redundant paragraph. Do you really need it?

Section 4.1, paragraph 17
>      identity msd-base-mpls {
>        base msd-base;
>        description
>          "Identity for MSD types for MPLS data plane.";
>      }

Would it help to say in the description "Base identity of MSD types for MPLS data plane"?

Section 4.1, paragraph 18
>      identity erld-mpls {
>        base msd-base-mpls;
>        description
>          "msd-erld is defined to advertise the Entropy Readable
>          Label Depth (ERLD).";
>        reference
>          "RFC 8662: Entropy Label for Source Packet Routing in
>                    Networking (SPRING) Tunnels
>          RFC 9088: Signaling Entropy Label Capability and Entropy
>                    Readable Label Depth Using IS-IS";
>      }

I agree with Med that the name of the identity does not match the description. Can this be fixed?

Section 4.1, paragraph 18
>      identity msd-base-srh {
>        base msd-base;
>        description
>          "Identity for MSD types for Segment Routing Header (SRH).";
>      }

Much like above, would it help to say in the description "Base identity of MSD types for SRH"?

Section 4.1, paragraph 18
>      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";
>      }

I know that you had a discussion with Med about these identities.

My observation is slightly different. identity 'srh-max-sl' is derived from an identity 'msd-base-srh', which in turn is derived from 'msd-base'. You are suggesting that identity 'srh-max-sl' is a transitive identity of 'msd-base'. This would make sense if there is a need to compare an identity to 'msd-base' without regard to whether the identity is used in MPLS or SRH data planes. The naming of identities suggests otherwise. Is there such a use case?

Section 4.2, paragraph 12
>      grouping msd-type-value {
>        description
>          "Grouping for MSD type and value.";
>        leaf msd-type {
>          type identityref {
>            base iana-msd-types:msd-base-mpls;
>          }
>          mandatory true;
>          description
>            "MSD types. The MSD type is defined in IANA IGP
>            MSD-Types registry.";
>        }

If the nodes defined here are read-only nodes, why the 'mandatory true' statement? Note, if you do decide to drop the mandatory keyword, remember to update the tree diagram.

Section 6.1, paragraph 2
>      URI: urn:ietf:params:xml:ns:yang:iana-msd-types
>      Registrant Contact: IANA.
>      XML: N/A, the requested URI is an XML namespace.

rfc8407bis, Section 5.1 example seems to indicate that when the module is an IANA module, the registrant contact is still "The IESG".

The IANA review of this document seems to not have concluded yet.

No reference entries found for these items, which were mentioned in the text:
[RFC9088], and [RFC9352].

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 1
>    There are two YANG modules defined in this document.  Module iana-
>    msd-types defines the identities for Maximum SID Depth (MSD) Types as
>    per the IANA the IGP MSD-Types registry [IANA-IGP-MSD-Types].  This
>    document also defines module ietf-mpls-msd augmenting the IETF MPLS
>    YANG model [RFC8960], which itself augments the routing RIB data
>    model [RFC8349], to provide operational state for various
>    MSDs[RFC8662].  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.

s/per the IANA the IGP/per the IANA IGP/

Section 2.2, paragraph 2
>    As defined in [RFC8491], MSD is the number of SIDs supported by a
>    node or a link on a node.  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.

s/read-only data/read-only nodes/

Section 4.2, paragraph 11
>        leaf msd-value {
>          type uint8;
>          mandatory true;
>          description
>            "MSD value, in the range of 0-255. 0 represents the lack
>            of ability to support a SID statck of any depth.";
>        }

s/statck/stack/

Uncited references: [RFC2119] and [RFC8174].

Section 4.2, paragraph 13
> RFC3688], the following registrations is requested to be made: COMMENT: URI:
>                                      ^^
The verb form "is" does not seem to match the subject "registrations".

Section 5, paragraph 6
> he title of the document added. When a MSD type is added to the "IGP MSD-Typ
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-mpls-msd-yang-10

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Tarek Saad for the shepherd's detailed write-up including the WG consensus *BUT* it lacks the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## SRH content while the title is about MPLS

While not really a DISCUSS criteria, the title is only about MPLS while some identities are about SRH, i.e., SR over an IPv6 dataplane => please remove MPLS from the title or add SRH/SRv6 to the title.

I understand the catch 22 situation here but having 2 I-D would have been cleaner, so, at least adapt the title and the abstract to mention SRH as well. I also intend to clear this DISCUSS during the IESG telechat if the title is not changed before.

[Ballot comment]

# COMMENTS (non-blocking)

## Title

Suggest to remove all acronyms in the title as they are only adding confusion.

## Section 1

Even if "SID" is a well-known acronym per RFC editor, suggest to expand SID at first use.

## Section 2.2

Unsure what is a "link on a node" ? Should it rather be "link attached to an interface of a node" ?

## Section 4.1

Identities sometimes end with "srh" (e.g., "msd-base-srh") or start with "srh" (e.g., "srh-max-end-pop"), suggest to be consistent and use "srh" always at the beginning or at the end of the identities.

Avoid the nits issue by a leading text in this section mentioning RFC 9352 and 9088.

## Section 4.2

In `The MSD type is defined in IANA IGP MSD-Types registry.`, should it rather be the YANG module of section 4.1 ?

## Section 5

Suggest using the order of section 4.1 then section 4.2 for the listed security considerations.

## Normative references

Should the IANA registry for "IGP MSD-types" include the URI fragment ? I.e., https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-msd-types

Please remove RFC 2119 and 8174 as BCP 14 template is not used in this document.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-mpls-msd-yang-07. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete. We also have a question about the IANA-maintained module, iana-msd-types.

First, in the ns registry in the IETF XML Registry group located at:

https://www.iana.org/assignments/xml-registry/

two new namespaces will be registered as follows:

ID: yang:iana-msd-types
URI: urn:ietf:params:xml:ns:yang:iana-msd-types
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-mpls-msd
URI: urn:ietf:params:xml:ns:yang:ietf-mpls-msd
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request.

Second, in the YANG Module Names registry in the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

two new YANG modules will be registered as follows:

Name: iana-msd-types
File: [ TBD-at-Registration ]
Maintained by IANA? Y
Namespace: urn:ietf:params:xml:ns:yang:iana-msd-types
Prefix: iana-msd-types
Module:
Reference: [ RFC-to-be ]

Name: ietf-mpls-msd
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-mpls-msd
Prefix: mpls-msd
Module:
Reference: [ RFC-to-be ]

Question -> What should we put as "Notes" for iana-msd-types? Please see: https://www.iana.org/assignments/yang-parameters/. Additionally, could the authors clarify how we should maintain this module; does this module mirror the IGP MSD-Types registry?

While the YANG module names will be registered after the IESG approves the document, the YANG module files will be posted after the RFC Editor notifies us that the document has been published.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-06-04):

From: The IESG
To: IETF-Announce
CC: draft-ietf-mpls-msd-yang@ietf.org, james.n.guichard@futurewei.com, mpls-chairs@ietf.org, mpls@ietf.org, tsaad@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A YANG Model for MPLS MSD) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'A YANG Model for MPLS MSD'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-06-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a YANG data model augmenting the IETF MPLS YANG
  model to provide support for MPLS Maximum SID Depths (MSDs) as
  defined in RFC 8476 and RFC 8491.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-msd-yang/



No IPR declarations have been submitted directly on this I-D.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
[Ans]: The WG consensus represents broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
[Ans]:
The document includes a YANG module containing various MSD types in iana-msd-types.yang that will be maintained in a registry by IANA. This module currently includes MPLS and some SRv6 specific MSD types. It was discussed whether to move the SRv6 types out of the module (or augmented in another module/document). The WG converged on keeping all types in the same module.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
[Ans]: No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
[Ans]: no known implementations so far.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
[Ans]: The SPRING WG was involved and they reviewed the document during WG LC.
The respective WGs were involved during the progress of the document
and during the WGLC.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
[Ans]: Yes, MPLS review team members reviewed before adoption by the WG. Further reviews by the RTGDIR members and all comments were addressed. The YANG doctor was completed on 2023-12-19.


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
[Ans]: The YANG model conforms to NMDA. The tools were run and no errors/warnings reported.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
[Ans]: not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
[Ans]: this document defines a YANG data model that augments the IETF MPLS YANG model to support MPLS Maximum SID Depths (MSDs) as defined in RFC 8476 and RFC 8491.
The shepherd believes this is a useful and well written document that is ready to be handed off to the AD.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
[Ans]: The RTGDIR was engaged to perform early review. The YANG doctors have also reviewed the document.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
[Ans]: Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
[Ans]: A first IPR poll was done before adoption of the document. A second IPR poll was
done before WGLC -
https://mailarchive.ietf.org/arch/browse/mpls/?q=IPR%20poll%20for%20draft-ietf-mpls-msd-yang

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
[Ans]: Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
[Ans]: No nits reported.

idnits 2.17.00 (12 Aug 2021)

/a/www/www6s/staging/draft-ietf-mpls-msd-yang-05.txt:

  Showing Errors (**), Flaws (~~), Warnings (==), and Comments (--).
  Errors MUST be fixed before draft submission.  Flaws SHOULD be fixed before draft submission.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Running in submission checking mode -- *not* checking nits according to
  https://www.ietf.org/id-info/checklist .
  ----------------------------------------------------------------------------


    No nits found.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
[Ans]: None identified.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
[Ans]: None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
[Ans]: None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
[Ans]: None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
[Ans]: No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
[Ans]: the IANA section registers two URIs in the IETF XML registry for each module defined in this document:

  URI: urn:ietf:params:xml:ns:yang:iana-msd-types
  Registrant Contact: IANA.
  XML: N/A, the requested URI is an XML namespace.
 
  URI: urn:ietf:params:xml:ns:yang:ietf-mpls-msd
  Registrant Contact: The IESG.
  XML: N/A, the requested URI is an XML namespace.

The IANA section also registers the two YANG modules in the YANG Module Names registry.

  name: iana-msd-types
  namespace: urn:ietf:params:xml:ns:yang:iana-msd-types
  prefix: iana-msd-types
  reference: RFC XXXX
 
  name: ietf-mpls-msd
  namespace: urn:ietf:params:xml:ns:yang:ietf-mpls-msd
  prefix: mpls-msd
  reference: RFC XXXX


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
[Ans]: None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
[Ans]: The WG consensus represents broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
[Ans]:
The document includes a YANG module containing various MSD types in iana-msd-types.yang that will be maintained in a registry by IANA. This module currently includes MPLS and some SRv6 specific MSD types. It was discussed whether to move the SRv6 types out of the module (or augmented in another module/document). The WG converged on keeping all types in the same module.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
[Ans]: No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
[Ans]: no known implementations so far.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
[Ans]: The SPRING WG was involved and they reviewed the document during WG LC.
The respective WGs were involved during the progress of the document
and during the WGLC.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
[Ans]: Yes, MPLS review team members reviewed before adoption by the WG. Further reviews by the RTGDIR members and all comments were addressed. The YANG doctor was completed on 2023-12-19.


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
[Ans]: The YANG model conforms to NMDA. The tools were run and no errors/warnings reported.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
[Ans]: not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
[Ans]: this document defines a YANG data model that augments the IETF MPLS YANG model to support MPLS Maximum SID Depths (MSDs) as defined in RFC 8476 and RFC 8491.
The shepherd believes this is a useful and well written document that is ready to be handed off to the AD.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
[Ans]: The RTGDIR was engaged to perform early review. The YANG doctors have also reviewed the document.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
[Ans]: Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
[Ans]: A first IPR poll was done before adoption of the document. A second IPR poll was
done before WGLC -
https://mailarchive.ietf.org/arch/browse/mpls/?q=IPR%20poll%20for%20draft-ietf-mpls-msd-yang

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
[Ans]: Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
[Ans]: No nits reported.

idnits 2.17.00 (12 Aug 2021)

/a/www/www6s/staging/draft-ietf-mpls-msd-yang-05.txt:

  Showing Errors (**), Flaws (~~), Warnings (==), and Comments (--).
  Errors MUST be fixed before draft submission.  Flaws SHOULD be fixed before draft submission.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Running in submission checking mode -- *not* checking nits according to
  https://www.ietf.org/id-info/checklist .
  ----------------------------------------------------------------------------


    No nits found.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
[Ans]: None identified.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
[Ans]: None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
[Ans]: None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
[Ans]: None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
[Ans]: No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
[Ans]: the IANA section registers two URIs in the IETF XML registry for each module defined in this document:

  URI: urn:ietf:params:xml:ns:yang:iana-msd-types
  Registrant Contact: IANA.
  XML: N/A, the requested URI is an XML namespace.
 
  URI: urn:ietf:params:xml:ns:yang:ietf-mpls-msd
  Registrant Contact: The IESG.
  XML: N/A, the requested URI is an XML namespace.

The IANA section also registers the two YANG modules in the YANG Module Names registry.

  name: iana-msd-types
  namespace: urn:ietf:params:xml:ns:yang:iana-msd-types
  prefix: iana-msd-types
  reference: RFC XXXX
 
  name: ietf-mpls-msd
  namespace: urn:ietf:params:xml:ns:yang:ietf-mpls-msd
  prefix: mpls-msd
  reference: RFC XXXX


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
[Ans]: None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/