Hi Acee, Thanks for addressing my DISCUSS comments. I should have said RFC 9587 (YANG Data Model for OSPFv3 Extended Link State Advertisement (LSAs), not 9507, which I see there is a reference for already. This will clear my DISCUSS.
Cheers. > On Feb 18, 2025, at 10:56 AM, Acee Lindem <[email protected]> wrote: > > Hi Mahesh, > > Thanks for your review and comments. Version -28 addresses your comments. See > inline. > >> On Feb 18, 2025, at 1:19 AM, Mahesh Jethanandani via Datatracker >> <[email protected]> wrote: >> >> Mahesh Jethanandani has entered the following ballot position for >> draft-ietf-lsr-ospf-admin-tags-27: Discuss >> >> 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-lsr-ospf-admin-tags/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Please do not fret. I have two DISCUSS points, both of which should be fairly >> easy to take care of. >> >> Section 7.2, paragraph 12 >>> augment "/rt:routing/rt:control-plane-protocols/" >>> + "rt:control-plane-protocol/ospf:ospf/" >>> + "ospf:areas/ospf:area/ospf:ranges/ospf:range" { >>> when "derived-from-or-self(../../../../../" >>> + "rt:type, 'ospf:ospf')" { >>> description >>> "This augments the OSPF routing protocol area range >>> configuration."; >>> } >>> description >>> "This augments the OSPF protocol area range configuration >>> with administrative tags. The configured tags will be >>> advertised with summary prefix when it is active."; >>> container admin-tags { >>> when "../ospf:advertise = 'true'"; >>> leaf-list admin-tag { >>> type uint32; >>> description >>> "Administrative tags."; >>> } >>> description >>> "OSPF prefix administrative tags."; >>> } >>> } >>> >>> augment "/rt:routing/rt:control-plane-protocols/" >>> + "rt:control-plane-protocol/ospf:ospf/" >>> + "ospf:areas/ospf:area/ospf:ranges/ospf:range" { >>> when "derived-from-or-self(../../../../../" >>> + "rt:type, 'ospf:ospf')" { >>> description >>> "This augments the OSPF routing protocol area range >>> configuration."; >>> } >>> description >>> "This augments summary route configuration with >>> administrative tags."; >>> leaf-list admin-tag { >>> type uint32; >>> description >>> "Administrative tags."; >>> } >>> } >> >> I am not clear on the difference between these two augment statements. Both >> augment statements seem the same to me, even as they add different data >> nodes. >> Can they not be collapsed? While I do not expect tools such as pyang or >> yanglint to catch this, it will most likely cause one of the statements to be >> removed. > > The first instance with the container and the "when" constraint was added to > disallow configuration > of tags for an area range whose advertisement is being suppressed. The > second instance should > have been removed. Good Catch!!! > > >> >> Section 7.2, paragraph 1 >>> The following is the YANG module: >> >> This YANG model is normatively including modules from RFC 8349, 9129, 6991, >> and >> 9507. While there is a normative reference for RFC 9129, the others are >> missing >> in the "Normative References" section. Please add. > > I've added all of these but RFC 9507 which is not augmented or imported. > >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Section 7.2, paragraph 9 >>> reference >>> "RFC XXXX"; >> >> You are missing the title of RFC XXXX here. > > Fixed. > > >> >> Section 8, paragraph 1 >>> The YANG modules specified in this document define a schema for data >>> that is designed to be accessed via network management protocols such >>> as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer >>> is the secure transport layer, and the mandatory-to-implement secure >>> transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer >>> is HTTPS, and the mandatory-to-implement secure transport is TLS >>> [RFC8446]. >> >> The template has been updated slightly for this paragraph. Please see >> draft-ietf-netmod-rfc8407bis, Section 3.7.1 for the latest text for this >> paragraph. > > I've updated the text and references to match the new template. > > > >> Finally, a non-blocking comment. It would have been really helpful >> for an implemter to be able to see an example on how to use this mode. > > This isn't in the -28 version. We'll discuss among co-authors - I've had > trouble getting my > YANG tools for this to work on MacOS but heretofore have failed. Perhaps, I > should > concede to use an Ubuntu VM. > > >> >> The IANA review of this document seems to not have concluded yet. > > This is a consequence of the tools. I updated the IANA text to include the > IANA > groups for the registries (based on Roman's editorial comment). This triggers > a > new required IANA review. > > Thanks, > Acee Mahesh Jethanandani [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
