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

[[e-mail]]

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.