[RTG-DIR]Re: Rtgdir last call review of draft-ietf-mpls-msd-yang-07

[Yingzhen Qu <[e-mail]>]

Hi Mohamed,

Thanks for the review and pointer. I've uploaded version -08 to address
your comments, please review and let me know your comments,
especially about the hierarchical identities.

Thanks,
Yingzhen

On Tue, Jun 4, 2024 at 12:18 AM <[e-mail]> wrote:

> Hi all,
>
> In addition to the comments raised by Dhruv, the authors may look at the
> guidance at
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name-iana-maintained-modules
> for the required details for IANA-maintained modules.
>
> ## Lack of the details to maintain the module
>
> There is currently no guidance in draft-ietf-mpls-msd-yang about how the
> module will be maintained. For example, given that there is no label but
> only a description field in the authoritative IANA registry, the doc should
> explain how names will be echoed in the module.
>
> ## Mirror the content of the authoritative registry
>
> The content of the IANA module does not mirror the details in the
> registry. For example, there are many refs that are listed in
> draft-ietf-mpls-msd-yang, but those are not present in the parent registry.
>
> ## Hierarchy
>
> The IANA module defines this hierarchy, while there is no such hierarchy
> in the IANA registry. I understand that the authors want to structure the
> types, but is this really required here? Absent guidance about how new
> entries will be echoed from the registry, I don't think this structure is
> easily maintainable. Please keep in mind that registrants of new types are
> not even aware that an IANA-maintained module exists. So, they cannot be
> involved in the process of maintaining the module.
>
> ==
>      identity msd-base-srh {
>        base msd-base;
>        description
>          "Identity for MSD types for Segment Routing Header (SRH).";
>      }
>
>      identity msd-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";
>      }
>
>      identity msd-srh-max-end-pop {
>        base msd-base-srh;
>        description
>          "The Maximum End Pop MSD Type.";
>        reference
>          "RFC 9352: IS-IS Extensions to Support Segment Routing
>                     over the IPv6 Data Plane";
>      }
> ==
>
> Hope this helps.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Dhruv Dhody via Datatracker <[e-mail]>
> > Envoyé : lundi 3 juin 2024 20:06
> > À : [e-mail]
> > Cc : [e-mail]; [e-mail];
> > [e-mail]
> > Objet : [RTG-DIR]Rtgdir last call review of draft-ietf-mpls-msd-
> > yang-07
> >
> >
> > Reviewer: Dhruv Dhody
> > Review result: Has Issues
> >
> > Hello,
> >
> > I have been selected as the Routing Directorate reviewer for this
> > draft. The Routing Directorate seeks to review all routing or
> > routing-related drafts as they pass through the IETF last call
> > and IESG review, and sometimes on special request. The purpose of
> > the review is to assist the Routing ADs. For more information
> > about the Routing Directorate, please see
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fwiki.ietf.org%2Fen%2Fgroup%2Frtg%2FRtgDir&data=05%7C02%7Cmohamed
> > .boucadair%40orange.com%7C6ecf264db0bb43052c3b08dc83f8121b%7C90c7
> > a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638530348673738183%7CUnkno
> > wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> > aWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=vfo%2F%2BxP9zc3YIrI1b9RjmRl
> > XL3MicMrirSECkDHfM3c%3D&reserved=0
> >
> > Although these comments are primarily for the use of the Routing
> > ADs, it would be helpful if you could consider them along with
> > any other IETF Last Call comments that you receive, and strive to
> > resolve them through discussion or by updating the draft.
> >
> > Document: draft-ietf-mpls-msd-yang-07
> > Reviewer: Dhruv Dhody
> > Review Date: 2024-06-03
> > IETF LC End Date: 2024-06-04
> > Intended Status: Proposed Standard
> >
> > ## Summary:
> >
> > * I have some minor concerns about this document that I think
> > should be resolved before publication.
> >
> > ## Comment:
> >
> > * This draft defines 2 YANG models one is IANA-maintained to
> > mirror the msd-type registry and the other is augmenting base
> > MPLS to include MSD values.
> >
> > ### Major Issues:
> >
> > - Please remove the BCP14 boilerplate (Section 1.1) as you are
> > not using any of those keywords. Also, remove from the ietf-mpls-
> > msd YANG model.
> >
> > - You should explicitly state that this is an initial version of
> > "iana-msd-types" YANG model - "This document defines the initial
> > version of the IANA-maintained 'iana-msd-types' YANG module."
> >
> > ### Minor Issues:
> >
> > - Title: Please change to "A YANG Data Model for MPLS Maximum
> > Segment Identifier (SID) Depth (MSD)". Also, update the reference
> > in the YANG model around RFC XXXX.
> >
> > - The abstract suggests that only one YANG model is defined in
> > this I-D.
> > Consider rephrasing or adding some hints about the IANA model as
> > well.
> >
> > - Section 1, "YANG [RFC7950] is a data definition language.."; I
> > suggest changing it to data modeling as that is the term used in
> > the referenced RFC.
> >
> > - Section 1, I am unsure about the text "The augmentation defined
> > in this document requires support..."; isn't it obvious that one
> > needs to support the model one is augmenting...
> >
> > - Section 4, please add this text in the description inside the
> > YANG module - "This YANG module is maintained by IANA and
> > reflects the 'IGP MSD-Types'
> > registry."
> >
> > - identity msd-erld, should also have a reference to RFC9088.
> >
> > - In "ietf-mpls-msd", please remove the reference "RFC XXXX: A
> > YANG Data Model for MPLS MSD." immediately after the module
> > description. The revision statement is the correct place to have
> > this reference.
> >
> > - leaf msd-value should also include text for "0 represents the
> > lack of ability to support a SID stack of any depth".
> >
> > - I can not parse "A type of Node MSD is the smallest same type
> > link MSD supported by the node.";"
> >
> > - RFC8340 should be normatively referenced.
> >
> > ### Nits:
> >
> > - s/(MSD) Types as the IANA the IGP MSD-Types registry/(MSD)
> > Types as per the IANA IGP MSD-Types registry/
> >
> > - s/which itself augments [RFC8349]/which itself augments routing
> > RIB data model [RFC8349]/
> >
> > - s/IANA maintained module/IANA-maintained module/
> >
> > - s/This module will be maintained by IANA if more MSD types are
> > added to the registry./This module will be maintained by IANA and
> > updated if and when there is any change in the registry./
> >
> > - s/and it is to provide support of different types of MSDs in
> > MPLS data plane./and it provides support for different types of
> > MSDs in the MPLS data plane./
> >
> > - s/read-only data decided by/read-only data as per/
> >
> > - Section 4, expand SID on first use in the YANG model.
> >
> > Thanks,
> > Dhruv
> >
> >
>
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>