Acee, I think that you have this right, IMO.
Cheers, Med PS: Not reviewing in detail as I still need to do a full check to update by DISCUSS ballot. Thanks. > -----Message d'origine----- > De : Acee Lindem <[email protected]> > Envoyé : vendredi 4 avril 2025 14:04 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > Cc : Mahesh Jethanandani <[email protected]>; > [email protected]; The IESG <[email protected]> > Objet : Re: data model vs module Again (RE: Mahesh Jethanandani's > No Objection on draft-ietf-ospf-sr-yang-37: (with COMMENT)) > > > At the risk of needing to change it again, I've applied the > guidance in the -42 version of the OSPF SR MPLS YANG Data Model: > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > datatracker.ietf.org%2Fdoc%2Fdraft-ietf-ospf-sr- > yang%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C513ecab78d > 8c4b9f219908dd7370ec6e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% > 7C638793651014584155%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% > 3D%3D%7C0%7C%7C%7C&sdata=%2B46C4Ro9XlYbt9XDegsqy62rmFnEF%2F2wrgpJM > 7ELON4%3D&reserved=0 > > I hope we are done. > > Thanks, > Acee > > > On Apr 4, 2025, at 7:32 AM, Acee Lindem <[email protected]> > wrote: > > > > Hi Med, Mahesh, > > > > Given the definitions in your draft, referring the "YANG Data > Model" as a whole should be in draft title, abstract, and high- > level statements. > > > > You have deprecated the term "YANG data module" in favor of > "YANG module" and this should be used when referring to a specific > self-contained module. > > > > Does everyone agree with this guidance? I'm ok with it and would > like to put an end, once and for all, blanket comments to change > all instances of "YANG Data Model" to "YANG Data Module" with no > clear understanding of the semantics of the two terms. I've added > the IESG back to the cc: list so we can get some consistency here. > > > > Other than, changing "YANG data module" to "YANG module", what > are you suggesting for > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > datatracker.ietf.org%2Fdoc%2Fdraft-ietf-ospf-sr- > yang%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C513ecab78d > 8c4b9f219908dd7370ec6e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% > 7C638793651014599279%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% > 3D%3D%7C0%7C%7C%7C&sdata=2VntMk%2BaAi65wp3kk%2B4pPTsMqayGBnfoBfPR1 > 79xt1E%3D&reserved=0? > > > > > > Thanks, > > Acee > > > >> On Apr 4, 2025, at 1:28 AM, [email protected] wrote: > >> > >> Hi Acee, all, > >> (moving this discussion to netmod, hence cci everyone else) > >> > >> The guidance so far was to avoid "data module" and "YANG > model". Benoît has more context on this when he was OPS AD. > >> > >> Let's us use this discussion to converge on some clear guidance > for every one. > >> > >> Here is a first draft of guidance I suggest we add to 8407bis. > This inspires from the guidance I shared earlier in this thread: > >> > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > aut > >> hor- > tools.ietf.org%2Fapi%2Fiddiff%3Furl_1%3Dhttps%3A%2F%2Fnetmod-wg.g > >> ithub.io%2Frfc8407bis%2Fdraft-ietf-netmod- > rfc8407bis.txt%26url_2%3Dht > >> tps%3A%2F%2Fnetmod-wg.github.io%2Frfc8407bis%2Fmodel-vs- > module%2Fdraf > >> t-ietf-netmod- > rfc8407bis.txt&data=05%7C02%7Cmohamed.boucadair%40orang > >> > e.com%7C513ecab78d8c4b9f219908dd7370ec6e%7C90c7a20af34b40bfbc48b92 > 53b > >> > 6f5d20%7C0%7C0%7C638793651014607501%7CUnknown%7CTWFpbGZsb3d8eyJFbX > B0e > >> > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIl > >> > dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tTRCn82BitJLUgs3b1NIhuBBWaVYBbTp > uk6 > >> 7L6zf9xA%3D&reserved=0 > >> > >> Do we need to say more/less? Is this still confusing? > Obviously, text > >> is welcome and makes the editor happy ;-) > >> > >> Cheers, > >> Med > >> > >>> -----Message d'origine----- > >>> De : Acee Lindem <[email protected]> Envoyé : jeudi 3 avril > 2025 > >>> 23:13 À : Mahesh Jethanandani <[email protected]> Cc : > The > >>> IESG <[email protected]>; [email protected]; lsr- > chairs > >>> <[email protected]>; lsr <[email protected]>; Christian Hopps > >>> <[email protected]> Objet : Re: Mahesh Jethanandani's No > Objection > >>> on draft-ietf-ospf- > >>> sr-yang-37: (with COMMENT) > >>> > >>> > >>> Here what ChatGTP says (so it has to be right 😎): > >>> > >>> The difference between a YANG data model and a YANG data > module lies > >>> in their scope and usage: > >>> • YANG Data Model: > >>> • A data model defines the structure and constraints of > >>> configuration and state data for a specific system or > protocol. > >>> • It provides an abstract representation of how data > should be > >>> organized, regardless of its implementation. > >>> • It can consist of multiple modules and submodules that > >>> together describe a network configuration or operational > state. > >>> • YANG Data Module: > >>> • A module is a self-contained YANG file that defines a > >>> specific part of a data model. > >>> • It includes definitions of data nodes (like > containers, > >>> lists, and leaf nodes), RPCs, notifications, and > augmentations. > >>> • A module may import or include other modules or > submodules > >>> to extend its functionality. > >>> Example: > >>> • YANG Data Model: The entire OpenConfig BGP model, which > consists > >>> of multiple modules defining BGP configuration and operational > >>> state. > >>> • YANG Data Module: The openconfig-bgp.yang file, which > >>> specifically defines BGP-related configurations. > >>> In short, a YANG data model is the broader concept, while a > YANG > >>> module is an actual implementation unit within a model. > >>> > >>> > >>> I believe I have made this distinction in the latest version > of the > >>> draft: > >>> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >>> datatracker.ietf.org%2Fdoc%2Fdraft-ietf-ospf-sr- > >>> > yang%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce269fce709 > >>> > 84491ee6ab08dd72f496bb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% > >>> > 7C638793117023476441%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > >>> > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% > >>> > 3D%3D%7C0%7C%7C%7C&sdata=o72AnR17w9EHpADb4TbAaecH0TtTERka%2Bc%2BTZ > >>> Anof80%3D&reserved=0 as I refer to the "YANG data model" when > >>> referring to the YANG model as a whole and "YANG data module" > when > >>> referring to the ietf-ospf-sr-mpls data module. > >>> > >>> The only change I might make is: > >>> > >>> OLD: > >>> The defined YANG data model is an augmentation to the OSPF > YANG > >>> data model [RFC9129]. > >>> > >>> NEW: > >>> The defined ospf-sr-mpls data module provides augmentations > to > >>> ietf-ospf data module defined in "YANG Data Model for the > OSPF > >>> Protocol" > >>> [RFC9129]. > >>> > >>> I also feel there are people (not mentioning any names) > providing > >>> guidance on this distinction with no clear semantics other > than > >>> replace "data model" with "data module". > >>> > >>> Thanks, > >>> Acee > >>> > >>> > >>> > >>> > >>> > >>>> On Apr 3, 2025, at 4:43 PM, Acee Lindem <[email protected]> > >>> wrote: > >>>> > >>>> Hi Mahesh, et al, > >>>> > >>>>> On Apr 3, 2025, at 4:08 PM, Acee Lindem > <[email protected]> > >>> wrote: > >>>>> > >>>>> Hi Mahesh, > >>>>> > >>>>>> On Apr 3, 2025, at 3:54 PM, Mahesh Jethanandani > >>> <[email protected]> wrote: > >>>>>> > >>>>>> Hi Acee, > >>>>>> > >>>>>>> On Apr 1, 2025, at 2:40 PM, Acee Lindem > <[email protected]> > >>> wrote: > >>>>>>> > >>>>>>> Hi Mahesh, > >>>>>>> > >>>>>>>> On Apr 1, 2025, at 5:14 PM, Mahesh Jethanandani via > >>> Datatracker <[email protected]> wrote: > >>>>>>>> > >>>>>>>> Mahesh Jethanandani has entered the following ballot > >>> position for > >>>>>>>> draft-ietf-ospf-sr-yang-37: No Objection > >>>>>>>> > >>>>>>>> When responding, please keep the subject line intact and > >>> reply to > >>>>>>>> all email addresses included in the To and CC lines. > (Feel > >>> free to > >>>>>>>> cut this introductory paragraph, however.) > >>>>>>>> > >>>>>>>> > >>>>>>>> Please refer to > >>>>>>>> > >>> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >>>>>>>> > >>> > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw > ww > >>> > .ietf.org%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C513ec > ab > >>> > 78d8c4b9f219908dd7370ec6e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0 > >>> > %7C638793651014620677%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy > dW > >>> > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 > D% > >>> > 3D%7C0%7C%7C%7C&sdata=mXJysPx%2FpzQ3%2Fw67yEn%2FVbKYVr20qXcYin%2FJ > kV > >>> > boPBI%3D&reserved=0%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandlin > g- > >>> ballo > >>>>>>>> t- > >>> > positions%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce26 > >>>>>>>> > >>> > 9fce70984491ee6ab08dd72f496bb%7C90c7a20af34b40bfbc48b9253b6f5d20%7 > >>>>>>>> > >>> > C0%7C0%7C638793117023493729%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG > >>>>>>>> > >>> > kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU > >>>>>>>> > >>> > IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TvgQkJLD8Jk%2B3RXO4gZSFd6uHeGmKgpD > >>>>>>>> sWK%2Fw3uBKr4%3D&reserved=0 for more information about > how > >>> to > >>>>>>>> handle DISCUSS and COMMENT positions. > >>>>>>>> > >>>>>>>> > >>>>>>>> The document, along with other ballot positions, can be > >>> found here: > >>>>>>>> > >>> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >>>>>>>> datatracker.ietf.org%2Fdoc%2Fdraft-ietf-ospf-sr- > >>> yang%2F&data=05%7C > >>>>>>>> > >>> > 02%7Cmohamed.boucadair%40orange.com%7Ce269fce70984491ee6ab08dd72f4 > >>>>>>>> > >>> > 96bb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387931170235024 > >>>>>>>> > >>> > 46%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > >>>>>>>> > >>> > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > >>>>>>>> > >>> > &sdata=Yn5qKrO4%2FddFJRx6L%2FeIm1fSnJXKmEyoh%2BUMRvbwt7M%3D&reserv > >>>>>>>> ed=0 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> --------------------------------------------------------- > --- > >>> ------ > >>>>>>>> ---- > >>>>>>>> COMMENT: > >>>>>>>> --------------------------------------------------------- > --- > >>> ------ > >>>>>>>> ---- > >>>>>>>> > >>>>>>>> Section 1, paragraph 0 > >>>>>>>>> This document defines a YANG data model [RFC7950] that > can > >>> be > >>>>>>>>> used to manage OSPFv2 extensions for Segment Routing > >>> [RFC8665] > >>>>>>>>> and OSPFv3 extensions for Segment Routing [RFC8666] for > the > >>> MPLS > >>>>>>>>> data plane. It is an augmentation to the OSPF YANG data > >>> model [RFC9129]. > >>>>>>>> > >>>>>>>> This is a similar comment to the YANG module for SR on > ISIS. > >>> There > >>>>>>>> seems to be some confusion on the use of the terms "YANG > >>> module" > >>>>>>>> and "YANG data model" in this document. A "YANG data > model" > >>> refers > >>>>>>>> to a collection of YANG modules and submodules that > together > >>>>>>>> define a structured representation configuration, > >>> operational > >>>>>>>> data, notifications, and RPCs for a given system or > >>> protocol, > >>>>>>>> while a "YANG module" refers to a specific YANG file > (.yang) > >>> defining a set of nodes (container, list, leaf, etc.) that > represent > >>> configuration or state data. > >>>>>>>> Moreover, a YANG module can be independent and augment > other > >>> modules. > >>>>>>>> > >>>>>>>> Based on that definition, what you seem to be defining is > a > >>> YANG > >>>>>>>> module more than a YANG data model. Can that be reflected > >>> consistently in this document? > >>>>>>> > >>>>>>> I'll fix this. > >>>>>> > >>>>>> I was referring to this comment which you agreed to fix, > not > >>> just in this document but presumably in the ISIS document as > well. > >>> Looking at the -41 version of the document, I did not see any > >>> changes to reflect this change, unless I am missing something. > >>>>> > >>>>> > >>>>> I removed raw-sid from the sid-tlv-encoding based on your > >>> comments. Are you referring to "YANG model" vs "YANG data > module"? > >>> I went back and forth on these a number of time based on > definition > >>> Med provided - please send me a diff of which ones need to be > >>> changed. > >>>>> > >>>>> Note that the title of the draft is "A YANG Data Model for > OSPF > >>> Segment Routing over the MPLS Data Plane". > >>>> > >>>> > >>>> And if I look through the references, we already have these > data > >>> models: > >>>> > >>>> > >>>> [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data > Model > >>> for > >>>> Routing Management (NMDA Version)", RFC 8349, DOI > >>> 10.17487/RFC8349, > >>>> March 2018, > >>>> > >>> > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >>> Fwww.rfc- > >>> > editor.org%2Finfo%2Frfc8349&data=05%7C02%7Cmohamed.boucadair%40ora > >>> > nge.com%7Ce269fce70984491ee6ab08dd72f496bb%7C90c7a20af34b40bfbc48b > >>> > 9253b6f5d20%7C0%7C0%7C638793117023510793%7CUnknown%7CTWFpbGZsb3d8e > >>> > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > >>> > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oZTIGsOtVZ802TBNdM3H% > >>> 2FkMjgy9ZkJrlL%2BLsqLBed6Y%3D&reserved=0>. > >>>> > >>>> [RFC9020] Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and > J. > >>>> Tantsura, "YANG Data Model for Segment Routing", RFC 9020, > DOI > >>>> 10.17487/RFC9020, May 2021, > >>>> > >>> > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >>> Fwww.rfc- > >>> > editor.org%2Finfo%2Frfc9020&data=05%7C02%7Cmohamed.boucadair%40ora > >>> > nge.com%7Ce269fce70984491ee6ab08dd72f496bb%7C90c7a20af34b40bfbc48b > >>> > 9253b6f5d20%7C0%7C0%7C638793117023519210%7CUnknown%7CTWFpbGZsb3d8e > >>> > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > >>> > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UY%2FmHYHL46l4f2X7Ouj > >>> F8m1GdojqhKlXCUyUNWCLVB8%3D&reserved=0>. > >>>> > >>>> [RFC9129] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. > Lindem, > >>> "YANG > >>>> Data Model for the OSPF Protocol", RFC 9129, DOI > >>> 10.17487/RFC9129, > >>>> October 2022, > >>>> > >>> > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >>> Fwww.rfc- > >>> > editor.org%2Finfo%2Frfc9129&data=05%7C02%7Cmohamed.boucadair%40ora > >>> > nge.com%7Ce269fce70984491ee6ab08dd72f496bb%7C90c7a20af34b40bfbc48b > >>> > 9253b6f5d20%7C0%7C0%7C638793117023527378%7CUnknown%7CTWFpbGZsb3d8e > >>> > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > >>> > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=500%2B%2Bh8Phdc3fa9Ai > >>> l%2FP8OU2mxfwyFQmPAkg9WCh4Vg%3D&reserved=0>. > >>>> > >>>> > >>>> [RFC9587] Lindem, A., Palani, S., and Y. Qu, "YANG Data Model > >>> for > >>>> OSPFv3 Extended Link State Advertisements (LSAs)", RFC 9587, > DOI > >>>> 10.17487/RFC9587, June 2024, > >>>> > >>> > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >>> Fwww.rfc- > >>> > editor.org%2Finfo%2Frfc9587&data=05%7C02%7Cmohamed.boucadair%40ora > >>> > nge.com%7Ce269fce70984491ee6ab08dd72f496bb%7C90c7a20af34b40bfbc48b > >>> > 9253b6f5d20%7C0%7C0%7C638793117023535417%7CUnknown%7CTWFpbGZsb3d8e > >>> > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > >>> > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NwTQvTjDbf72YT7e8my0L > >>> jr%2F28SVc6L1R4EbpxYYKUA%3D&reserved=0>. > >>>> > >>>> > >>>> My take was that we should refer the "YANG Data Model" when > >>> referring to the model as a whole and "YANG Data Module" when > >>> specifically referring to the ietf-ospf-sr-mpls.yang data > module. > >>> This is what has been done the -41 version. > >>>> > >>>> Like I said in a previous E-mail, the guidance given is > >>> especially ambiguous when there is a single data module in the > data > >>> model. > >>>> > >>>> Thanks, > >>>> Acee > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> > >>>>> I'm not an author on the IS-IS SR YANG model but Yingzhen > and I > >>> have been in communication since the start and we will sync up > IS- > >>> IS to the IESG comments and changes made for OSPF. > >>>>> > >>>>> Thanks, > >>>>> Acee > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> Thanks. > >>>>>> > >>>>>> Mahesh Jethanandani > >>>>>> [email protected] > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >> > >> > __________________________________________________________________ > ___ > >> _______________________________________ > >> 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. _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
