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 >> >> >> >> >> >> > _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
