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 <[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://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
>>> [email protected]
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
