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]
