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

[Yingzhen Qu <[e-mail]>]

Hi Med,

When a new entry is added to the "IGP MSD-Type" registry, the document that
defines the new entry should state what the MSD is for.

I'll update the security consideration.

Thanks,
Yingzhen

On Wed, Jun 5, 2024 at 7:06 AM <[e-mail]> wrote:

> Hi Acee,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
>
>
> Orange Restricted
>
> *De :* Acee Lindem <[e-mail]>
> *Envoyé :* mercredi 5 juin 2024 15:35
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> *Cc :* Yingzhen Qu <[e-mail]>; Dhruv Dhody <
> [e-mail]>; [e-mail];
> [e-mail]; Last Call <[e-mail]>;
> mpls <[e-mail]>
> *Objet :* Re: [RTG-DIR]Rtgdir last call review of
> draft-ietf-mpls-msd-yang-07
>
>
>
>
> Hi Med,
>
>
>
> See inline.
>
>
>
> On Jun 5, 2024, at 04:16, [e-mail] wrote:
>
>
>
> Hi Yingzhen,
>
>
>
> Thanks for taking care of this. The new version looks better.
>
>
>
> Still, I don’t see how the hierarchical identity structure can be
> automatically inferred from the current flat registry structure. I’m afraid
> that the instructions in the 3rd para of 6.2 are not sufficient as I
> don’t think that we can trust the presence of SRH or some magic words in
> the description to decide which identity to use, and more generally if “a
> new data plane” is used.
>
>
>
> Both the description and references listed in the IANA module diverge from
> the actual content of the registry. I would avoid that. Please refer to
> this clarification in the 8407bis (see the last sentence, in particular):
>
>
>
>    The content of these registries are usually available using various
>
>    formats (e.g., plain text, XML).  However, there were some confusion
>
>    in the past about whether the content of some registries is dependent
>
>    on a specific representation format.  For example, Section 5 of
>
>    [RFC8892] was published to clarify that MIB and YANG modules are
>
>    merely additional formats in which the "Interface Types (ifType)" and
>
>    "Tunnel Types (tunnelType)" registries are available.  The MIB
>
>    [RFC2863] and YANG modules [RFC7224][RFC8675] are not separate
>
>    registries, and the same values are always present in all formats of
>
>    the same registry.
>
>
>
> I disagree. The fact that we have a hierarchy of identities wouldn’t
> confuse anyone. They are all part of the
>
> iana-msd-types.yang model and all have “msd-base” as the root identity. We
> are rejecting this rather
>
>  subjective comment.
>
>
>
> *[Med] Hmm…this is not subjective :-) Let’s consider that I registered a
> new entry in *Interior Gateway Protocol (IGP) Parameters (iana.org)
> <https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml>
>
>
>
> 115
>
> My own type
>
> [MyREF <https://www.iana.org/go/rfc8491>]
>
>
>
> *How IANA will follow the following guidance? How IANA will know this is
> about an existing “data plane” or a new one? How it will decide to mirror
> it using existing one msd-base or msd-base-srh? How to infer a data plane
> from a registration? Etc.*
>
>
>
>    The identities defined in the iana-msd-types YANG module are
>
>    organized hierarchically based on the data plane.  In this initial
>
>    version, only MPLS and SRv6 data planes are supported, hence "msd-
>
>    base-mpls" and "msd-base-srh" are defined.  *When a new data plane is*
>
> *   added to the "IGP MSD-Types" registry*, a new "identity" statement
>
>    should be added to the "iana-msd-types" YANG module.  The name of the
>
>    "identity" is the prefix "msd-base-" plus a lower-case version of the
>
>    data plane name .  The identity statement should have the following
>
>    sub-statements defined:
>
>
>
>
>
> If you want to suggest further text to explain this, we’ll consider
> inclusion.
>
>
>
> Some other misc. comments:
>
>
>
> (1) “lower-case version of the data plane name”: you may also indicate
> that the space is replaced with “-“, not trimmed.
>
>
>
> (2)    "description":  Replicates the description from the registry.
>
>
>
> I guess you meant replicate the “name” from the registry. There is no
> description in the IGP MSD Type reg.
>
>
>
> (3)
>
>
>
> OLD:
>
>       name: iana-msd-types
>
>       namespace: urn:ietf:params:xml:ns:yang:iana-msd-types
>
>       prefix: iana-msd-types
>
>       reference: RFC XXXX
>
>
>
>       name: ietf-mpls-msd
>
>       namespace: urn:ietf:params:xml:ns:yang:ietf-mpls-msd
>
>       prefix: mpls-msd
>
>      reference: RFC XXXX
>
>
>
> NEW:
>
>       name: iana-msd-types
>
>       namespace: urn:ietf:params:xml:ns:yang:iana-msd-types
>
>       prefix: iana-msd-types
>
>       maintained by IANA? Y
>
>       reference: RFC XXXX
>
>
>
>       name: ietf-mpls-msd
>
>       namespace: urn:ietf:params:xml:ns:yang:ietf-mpls-msd
>
>       prefix: mpls-msd
>
>       maintained by IANA? N
>
>      reference: RFC XXXX
>
>
>
> (4) the security section does not follow the template + does not cover the
> IANA module. Please refer to
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name-security-considerations-sect
> .
>
>
>
> The iana-msd-types.yang modules doesn’t include any data leafs so there
> are no associated security considerations. We could state this.
>
> We’ll check the latest template in the draft.
>
>
>
> *[Med] There is a para in the template for that as well.*
>
>
>
> Thanks,
>
> Acee
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Yingzhen Qu <[e-mail]>
> *Envoyé :* mercredi 5 juin 2024 07:55
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> *Cc :* Dhruv Dhody <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Objet :* Re: [RTG-DIR]Rtgdir last call review of
> draft-ietf-mpls-msd-yang-07
>
>
>
> 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
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%252>
> > Fwiki.ietf.org <http://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.
>
> ____________________________________________________________________________________________________________
>
> 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.
>
>
>
> ____________________________________________________________________________________________________________
> 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.
>
>