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 >>>>>>>> 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]
