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.
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 ..."
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 ..."
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 module."
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.
> 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
