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. 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 7.2, paragraph 9 > reference > "RFC XXXX"; You are missing the title of RFC XXXX here. 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. 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. The IANA review of this document seems to not have concluded yet. _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
