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 > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
