Hi all, When explaining YANG in the context of data management I always use “YANG data model”, as “data model” is the common term used to denote the structure (i.e., schema) of data. On the other hand, the term “module” is specific to the YANG language. Therefore, “YANG data module” is not clear to me.
However, I would like to take advantage of this thread to bring back the concern I raised a few months ago on the limitations for identifying and managing YANG data models. I understand and I can live with the proposal to define a “(YANG) data model” as a set of YANG modules. If we all agree on this definition, then I think we really need to clarify how we identify and refer to a YANG data model. For example, say there is a YANG data model composed of a YANG module “A” that depends on the YANG modules “B” and “C”. How do we refer to this data model? Do we take the name “A” from the (parent) YANG module? And how about versioning? After all, from a user application perspective, you interact with the whole data model. Many thanks! Best regards, Nacho. From: Acee Lindem <[email protected]> Date: Friday, 4 April 2025 at 14:05 To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>, The IESG <[email protected]> Subject: [netmod] Re: data model vs module Again (RE: Mahesh Jethanandani's No Objection on draft-ietf-ospf-sr-yang-37: (with COMMENT)) AVISO/WARNING: Este correo electrónico se originó desde fuera de la organización. No haga clic en enlaces ni abra archivos adjuntos a menos que reconozca al remitente y sepa que el contenido es seguro / This email has been originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 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://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/ 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://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/? > > > 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://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 <[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 >>>>>>>> >>> www.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballo<http://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 >>>>>> [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. > _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected] ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
