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

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Acee,

As written in my original ballot, I will clear my DISCUSS once the discussions with the AD and the authors have been done.

Having a correct and meaningful title & abstract are an integral part of having a sensible and useful RFC. Hence, a suggestion to use something like “YANG Data Models for Maximum SID depth types and for MPLS” and mentioning MPLS & SRH in the abstract.

Regards

-éric


From: Acee Lindem <[e-mail]>
Date: Monday, 1 July 2024 at 17:57
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, MPLS Working Chairs <[e-mail]>, mpls <[e-mail]>, Tarek Saad (tsaad) <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-mpls-msd-yang-10: (with DISCUSS and COMMENT)
Eric,


On Jul 1, 2024, at 10:57, Éric Vyncke via Datatracker <[e-mail]> wrote:

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

You probably don’t subscribe to the MPLS list but there has already been a lot discussion on how to move forward with. The only SRv6 specific items are defined identities in the IANA maintained which does NOT have mpls it its name specifically because it be an IANA maintained module based on the "IANA IGP MSD-Types registry”. We split out this module in -03.

You say this is “not really a DISCUSS criteria” so I’d hope to leave the name and YANG module split as is. I’d really hate to have to remove the SRv6 MSD types due to a caprious DICUSS.

Acee








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.