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

[[e-mail]]

Hi Yingzhen,

Thank you very much for taking care of the comments. This looks much more better. Thank you.

Below some pending comments, fwiw:


  *   I’m neutral on whether you need to add an update tag to rfc8491. However, you need at least to ask IANA to update the reference clause of IGP MSD-Types to also list the RFC number to be assigned to your document.
  *   I do still see divergence between the content of the IANA module and IGP MSD-Types. Please use consistent content. For example,



# Reference mismatch



1    Base MPLS Imposition MSD   [RFC8491]



vs.


     identity base-mpls-imposition-msd {
       base msd-base-mpls;
       description
         "Base MPLS Imposition MSD.";
       reference
         "RFC 8491: Signaling Maximum SID Depth (MSD) using IS-IS
          RFC 8476: Signaling Maximum SID Depth (MSD) using OSPF
          RFC 8664: Path Computation Element Communication Protocol
                    (PCEP) Extensions for Segment Routing
          RFC 8814: Signaling Maximum SID Depth (MSD) Using the Border
                    Gateway Protocol - Link State";
     }



# description mismatch



The draft says “"description":  Replicates the name from the registry.” but the module does not follow that. For example;



     identity erld-mpls {

       base msd-base-mpls;

       description

         "msd-erld is defined to advertise the Entropy Readable

          Label Depth (ERLD).";



While the registry says:



2    ERLD-MSD   [RFC9088]

     # name mismatch

     Note also that the label used here is “erld-mpls” not “erld-msd” + the description uses “msd-elrd” instead of “erld-mds”.  Please fix that as well. Thanks.


  *   Please update this sentence “Unassigned or reserved values are not present in the module.” to also include the experimental values.
  *   This might be seen as an editing taste, but I would use a new subsection for the request to IANA to add the new data plane column. The reasoning is to separate the required instructions for IANA to maintain the module vs. modify the existing registry.

Feel free to ignore or grab whatever you think useful in the review list :-)

Cheers,
Med

De : Yingzhen Qu <[e-mail]>
Envoyé : vendredi 14 juin 2024 18:39
À : 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: [Last-Call] [RTG-DIR]Re: Rtgdir last call review of draft-ietf-mpls-msd-yang-07

Hi Med,

Version -10 has been uploaded, and we added a "Data-Plane" column to the IANA registry.

Thanks,
Yingzhen

On Fri, Jun 7, 2024 at 7:22 AM <[e-mail]<mailto:[e-mail]>> wrote:
Hi Acee,

“Would adding the data-plane column to the IANA registry satisfy your concern? “

Yes, thanks.

Cheers,
Med

De : Acee Lindem <[e-mail]<mailto:[e-mail]>>
Envoyé : jeudi 6 juin 2024 19:27
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : Dhruv Dhody <[e-mail]<mailto:[e-mail]>>; Yingzhen Qu <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Last Call <[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>
Objet : Re: [Last-Call] [RTG-DIR]Re: Rtgdir last call review of draft-ietf-mpls-msd-yang-07


Hi Med,

On Jun 6, 2024, at 05:49, [e-mail]<mailto:[e-mail]> wrote:

Re-,

Please see inline.

Cheers,
Med

De : Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
Envoyé : jeudi 6 juin 2024 11:22
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : Yingzhen Qu <[e-mail]<mailto:[e-mail]>>; Acee Lindem <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Last Call <[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>
Objet : [Last-Call] Re: [RTG-DIR]Re: Rtgdir last call review of draft-ietf-mpls-msd-yang-07

Hi Med,

On Thu, Jun 6, 2024 at 8:24 AM <[e-mail]<mailto:[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.
[Med] These two are not conflicting :-) If the information is explicit, then record it in the registry, not infer it from the narrative text or the MSD name.

Can this be a guideline for designated experts to verify without adding a new column?

[Med] The concern is beyond the DE review. Once a change is made to the registry: how to mirror that automatically in the IANA-maintained module using the current instructions in the spec? Which information in the registry will be used to trigger whether the base identity is to be used, existing child ones, or creating new child ones, etc. We need to make the maintenance task implementable, but easy.

Are you envisioning this being automated with a very naive script? We are in the age of AI and the discerning the data-plane seems trivial.

Would adding the data-plane column to the IANA registry satisfy your concern?

Thanks,
Acee

____________________________________________________________________________________________________________

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.