[mpls] Éric Vyncke's Discuss on draft-ietf-mpls-msd-yang-10: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-mpls-msd-yang-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-msd-yang/



----------------------------------------------------------------------
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.


----------------------------------------------------------------------
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.