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