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