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://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/model-vs-module/draft-ietf-netmod-rfc8407bis.txt 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 <acee.i...@gmail.com> > Envoyé : jeudi 3 avril 2025 23:13 > À : Mahesh Jethanandani <mjethanand...@gmail.com> > Cc : The IESG <i...@ietf.org>; draft-ietf-ospf-sr-y...@ietf.org; > lsr-chairs <lsr-cha...@ietf.org>; lsr <lsr@ietf.org>; Christian > Hopps <cho...@chopps.org> > 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 <acee.i...@gmail.com> > wrote: > > > > Hi Mahesh, et al, > > > >> On Apr 3, 2025, at 4:08 PM, Acee Lindem <acee.i...@gmail.com> > wrote: > >> > >> Hi Mahesh, > >> > >>> On Apr 3, 2025, at 3:54 PM, Mahesh Jethanandani > <mjethanand...@gmail.com> wrote: > >>> > >>> Hi Acee, > >>> > >>>> On Apr 1, 2025, at 2:40 PM, Acee Lindem <acee.i...@gmail.com> > wrote: > >>>> > >>>> Hi Mahesh, > >>>> > >>>>> On Apr 1, 2025, at 5:14 PM, Mahesh Jethanandani via > Datatracker <nore...@ietf.org> 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 > >>>>> > www.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-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 > >>> mjethanand...@gmail.com > >>> > >>> > >>> > >>> > >>> > >>> > >> > > ____________________________________________________________________________________________________________ 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. _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
