Hi Mahesh, > On Apr 3, 2025, at 5:44 PM, Acee Lindem <acee.i...@gmail.com> wrote: > > Hi Mahesh, > > See inline. > >> On Apr 3, 2025, at 5:29 PM, Mahesh Jethanandani <mjethanand...@gmail.com> >> wrote: >> >> Hi Acee, >> >> You got it right (at least ChatGPT did :-). >> >> There are a few more places where I see the discrepancy. And you are right >> that rfc8407bis should provide some guidance if it does not already. > > And reviewers who don't know what they're taking about should keep quiet. > >> >> 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]. >> >> Perhaps: >> "This document defines a YANG 1.1 module [RFC7950] that can be used ..." > > In the first paragraph of the draft, I'm referring to the YANG model as a > whole. The fact that there is a single data module is irrelevant. > > >> >> Section 2, paragraph 0 >>> This document defines a model for OSPF Segment Routing Extensions for >>> both OSPFv2 [RFC8665] and OSPFv3 [RFC8666]. > >> >> Perhaps, >> "This document defines a module for OSPF Segment Routing Extensions ..." > > Same as previous. > > >> Section 3, paragraph 0 >>> [RFC2328], [RFC4915], [RFC5340], [RFC6991], [RFC8102], [RFC8294], >>> [RFC8349], [RFC9587], and [I-D.ietf-rtgwg-segment-routing-ti-lfa] are >>> referenced in the YANG data model. >> >> Perhaps: >> "... referenced in the YANG data modu > > This is already changed in the -41 version. > > >> >> Section 3, paragraph 2 >>> This YANG model conforms to the Network Management >>> Datastore Architecture (NMDA) as described in RFC 8342. >> >> Perhaps: >> "This YANG module conforms to the Network Management ..." >> Thanks. > > This also refers to the model generically. However, I wouldn't be opposed to > making it specific in this context since section 3 is specific to the > ietf-ospf-sr-mpls data module. > > "The ietf-ospf-sr-mpls data module conforms... "
You must be looking at an older version as this is no longer in section 3. The NMDA architecture is only referenced in section 1. Thanks, Acee > > Thanks, > Acee > > >> >>> On Apr 3, 2025, at 2:13 PM, Acee Lindem <acee.i...@gmail.com> wrote: >>> >>> 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://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/ 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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >>>>>>>> >>>>>>>> for more information about how to handle DISCUSS and COMMENT positions. >>>>>>>> >>>>>>>> >>>>>>>> The document, along with other ballot positions, can be found here: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> 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://www.rfc-editor.org/info/rfc8349>. >>>> >>>> [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://www.rfc-editor.org/info/rfc9020>. >>>> >>>> [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://www.rfc-editor.org/info/rfc9129>. >>>> >>>> >>>> [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://www.rfc-editor.org/info/rfc9587>. >>>> >>>> >>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> >> Mahesh Jethanandani >> mjethanand...@gmail.com >> >> >> >> >> >> > _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
