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

[Dhruv Dhody <[e-mail]>]

Hi Med,

On Thu, Jun 6, 2024 at 8:24 AM <[e-mail]> wrote:

> Hi Dhruv,
>
>
>
> Yes, that would work assuming that we will have a new column to record
> explicitly the data plane name for each type.
>

Dhruv: What you are asking is not wrong "technically" but at the same time
I can't envision someone defining a MSD without being explicit on the data
plane it applies to. Can this be a guideline for designated experts
to verify without adding a new column?


>
>
> Some checks are worth though: Do we foresee cases where the same type can
> be used by multiple “data planes”?
>
>
>

Dhruv: Unlikely IMHO.

Thanks,
Dhruv



> Cheers,
>
> Med
>
>
>
> *De :* Dhruv Dhody <[e-mail]>
> *Envoyé :* jeudi 6 juin 2024 08:59
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> *Cc :* Yingzhen Qu <[e-mail]>; Acee Lindem <
> [e-mail]>; [e-mail];
> [e-mail]; Last Call <[e-mail]>;
> mpls <[e-mail]>
> *Objet :* [RTG-DIR]Re: Rtgdir last call review of
> draft-ietf-mpls-msd-yang-07
>
>
>
> Hi Med,
>
>
>
> How about this I-D adds some suitable guidance for designated experts (as
> the IANA registry is under 'Expert Review')? We can also make this I-D
> update RFC8491. Could that be a way forward?
>
>
>
> Thanks!
>
> Dhruv
>
>
>
> On Thu, Jun 6, 2024 at 6:05 AM <[e-mail]> wrote:
>
> Hi Yingzhen,
>
>
>
> Thank you for addressing the sec comment. I trust that you have also fixed
> the content mismatch between the module and the parent registry points.
>
>
>
> Thank you also for confirming that there are no such IANA considerations.
> The narrative text in 9352 does not change the rules set in 8491.
>
>
>
> I consider that the last comment is still valid and not addressed. Thank
> you.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Yingzhen Qu <[e-mail]>
> *Envoyé :* jeudi 6 juin 2024 01:05
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> *Cc :* Acee Lindem <[e-mail]>; Dhruv Dhody <[e-mail]>;
> [e-mail]; [e-mail]; Last Call <
> [e-mail]>; mpls <[e-mail]>
> *Objet :* Re: [RTG-DIR]Re: Rtgdir last call review of
> draft-ietf-mpls-msd-yang-07
>
>
>
> Hi Med,
>
>
>
> You're right, it is not explicitly stated in the IANA consideration
> section. However you can find "This document only defines one type
> of MSD: Base MPLS Imposition. " in the abstract of RFC 8491.
>
>
>
> And the following text is at the beginning of section 4 in RFC 9352 that
> defines the SRH MSDs:
>
> "
>
> *[RFC8491 <https://www.rfc-editor.org/rfc/rfc9352.html#RFC8491>] defines
> the means to advertise node-/link-specific values for MSDs of various
> types. Node MSDs are advertised in a sub-TLV of the Router Capability
> TLV [RFC7981 <https://www.rfc-editor.org/rfc/rfc9352.html#RFC7981>]. Link
> MSDs are advertised in a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223.¶
> <https://www.rfc-editor.org/rfc/rfc9352.html#section-4-1>*
>
> *This document defines the relevant SRv6 MSDs and requests MSD type
> assignments in the "IGP MSD-Types" registry created by [RFC8491
> <https://www.rfc-editor.org/rfc/rfc9352.html#RFC8491>].*
>
> "
>
> I've updated the security consideration in version -09. Please let us know
> whether this addressed your comments.
>
>
>
> Thanks,
>
> Yingzhen
>
>
>
>
>
>
>
> On Wed, Jun 5, 2024 at 9:27 AM <[e-mail]> wrote:
>
> Re-,
>
>
>
> I actually checked that before making the comment. There is no such
> requirement for new requests in
> https://www.rfc-editor.org/rfc/rfc8491.html#section-6.
>
>
>
> May be I’m not looking in the right place?!
>
>
>
> I would appreciate if you can point me to where I can find this
> requirement: “the document that defines the new entry should state what the
> MSD is for”
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Yingzhen Qu <[e-mail]>
> *Envoyé :* mercredi 5 juin 2024 18:02
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> *Cc :* Acee Lindem <[e-mail]>; Dhruv Dhody <[e-mail]>;
> [e-mail]; [e-mail]; Last Call <
> [e-mail]>; mpls <[e-mail]>
> *Objet :* [RTG-DIR]Re: Rtgdir last call review of
> draft-ietf-mpls-msd-yang-07
>
>
>
>
>
> 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.
>
> ____________________________________________________________________________________________________________
>
> 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.
>
>