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

[Acee Lindem <[e-mail]>]

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