Hi Pavan, authors, My turn to apologize for the delay in responding. Thank you for addressing those comments and I am good with the changes made. Regarding a more central location for the typedefs: reusability of typedefs, groupings etc is important and having everything in 1 module can be problematic because the full schema is imported e.g. see https://mailarchive.ietf.org/arch/msg/idr/EdZkFf-ZI4CEkNniyDQgRo9CGrc/Also why not reuse existing identities for ospfv2, ospfv3 and isis (based on rt:routing-protocol) instead of having a new typedef/enum for the IGP protocol? Is it because you don't want to import the OSPF and ISIS modules? This might be a (non-ideal) way around it: leaf protocol-id { type identityref { base rt:routing-protocol; } description "IGP protocol type. Implementations SHOULD support ospfv2, ospfv3, and isis. Other routing protocol types are outside the scope of this module.";} Regards,Reshad. On Sunday, July 5, 2026 at 11:23:33 PM EDT, Vishnu Pavan Beeram <[email protected]> wrote: Hi Reshad,
Apologies for the delayed response. Thank you for your thorough review of draft-ietf-teas-yang-topology-filter-02. We have posted -03 which addresses your comments. Here is a summary of the changes: Security Considerations (your comment on RFC 9907): - Rewrote the Security Considerations section using the template from RFC 9907 Section 3.7.1, including secure transport (SSH, TLS, QUIC), mutual authentication, and NACM references. - Added RFC 9907 as an informative reference. Defining igp-domain-identifier leaves (your comments on instance-id, division-id, algo-id, mt-id): - Added narrative text in Section 2.1.1 (Topology Reference) defining each leaf in the igp-domain-identifier container. - instance-id: Defined as the IGP protocol instance identifier, noting that multiple instances of the same IGP protocol can coexist on a network element. - division-id: Defined with protocol-specific semantics — OSPF Area ID or IS-IS Level. - algo-id: Renamed to algo-number for consistency with draft-ietf-lsr-isis-flex-algo-yang, as you suggested. - mt-id: Added references to RFC 4915 (OSPF MT) and RFC 5120 (IS-IS MT) in both the YANG module and the normative references. Kept the type as uint16 to accommodate both OSPF (0-127) and IS-IS (0-4095) ranges. - Improved YANG description statements for all of these leaves. Wildcard/default semantics (your comment on absent optional leaves): - Added explicit text stating that absent leaves in igp-domain-identifier are treated as wildcards and match any value. - Added the same wildcard semantics for the te-topology-identifier container. - Added text specifying that absent or empty filter attributes (leaf-lists or lists) in the include-any/include-all/exclude containers are treated as wildcards. Filtering semantics (your comment on include-any/include-all/exclude): - Added detailed definitions for the filtering semantics: - include-any: OR within each attribute list, AND across attribute lists. - include-all: AND within each attribute list, AND across attribute lists. - exclude: OR within each attribute list, AND across attribute lists. Matched elements are excluded. - Across containers: AND operation — an element is included only if it matches include-any AND include-all AND does not match exclude. - Added a note explaining that OR across attribute lists can be achieved by using multiple filters combined via a topology-filter-set (union). - Updated all three YANG container description statements to reflect these semantics. Conflicting entries (your comment on same entry in include and exclude): - The AND operation across containers ensures that exclude always takes precedence — an element matching both an include container and the exclude container will be excluded. Usage examples (RFC 9907 Section 3.12): - Added Appendix A with three JSON encoding examples: - ISIS Level-2 filter with include-any (link-affinity "RED"). - ISIS Flex-Algo 128 filter with exclude (link-affinity "BLUE"). - NRP filter with include-all (link-affinity "RED" + AS 65001) and exclude (link-affinity "BLUE"), plus a topology-filter-set combining multiple filters. Common typedef placement (your comments on igp-protocol and common definitions): - We acknowledge your point. Ideally these would be in a more central location, but for now they remain in this module. We are open to revisiting this if a suitable common module emerges. Other changes in -03: - Updated author/contributor affiliations. Please let us know if you have any further comments or concerns. Note to the WG: From the authors' perspective, we believe the document is ready for Working Group Last Call (WGLC). The -03 revision addresses all the comments raised in the early YangDoctors review, including the addition of precise filtering semantics, wildcard behavior definitions, improved YANG descriptions, RFC 9907 compliant security considerations, and usage examples. We request the chairs to consider initiating a WGLC. Regards, Pavan (on behalf of the authors) On Tue, Apr 7, 2026 at 8:10 PM Reshad Rahman via Datatracker <[email protected]> wrote: Document: draft-ietf-teas-yang-topology-filter Title: YANG Data Model for Topology Filter Reviewer: Reshad Rahman Review result: On the Right Track I've CCed the LSR mailing list since there are LSR related comments here. Here are what I believe are major issues with this document: - Guidelines from RFC9907 are not being followed. e.g. section 3.7.1 (template text) 1st paragraph hasn't been used and RFC9907 etc is not an informative reference. Also no module usage examples (section 3.12). - What is an instance-id? There are no examples provided on what an information source instance is. A reference would also help. - division-id, currently can it only be an OSPF area or ISIS level? - algo-id, please provide a reference. Also in draft-ietf-lsr-isis-flex-algo-yang, it is called algo-number so I suggest to use the same name. - mt-id, please add a reference. Also in this doc it is a uint16, but in RFC9903 it is a uint8 with a range. - General comment: it's too bad that some of those "common definitions" weren't typedefed in a common YANG module. - Similarly, the igp-protocol typedef should ideally be in a more "central location" than in a TEAS topology-filter module. - Many (all?) values have no default and aren't mandatory. e.g. what happens if an igp-domain-identifier has no attributes set? Or even if some attributes are set, are the other attributes "wild carded"? Whether this is valid or not and (if it is) the expected behaviour have to be specified explicitly in the document. - I see no detailed description of what the include-any, include-all and exclude containers actually do. - What is the expected behaviour if a topology filter has the same link-name to node-prefix in include-any, include-all and exclude containers? If such config is invalid, it must be stated in the description. _______________________________________________ Teas mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
