[Teas] Re: [Lsr] Re: draft-ietf-teas-yang-topology-filter-02 early Yangdoctors review

[Vishnu Pavan Beeram <[e-mail]>]

Hi Reshad,

Thanks for confirming the -03 changes, and for the follow-up on the
typedefs. We have posted -04, which addresses your remaining points:
https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-topology-filter-04

On igp-protocol: you are right that it duplicated an existing type. The
module already uses te-info-source from RFC 8795 for source-id in the
info-source lists, and igp-protocol mirrored its OSPFv2, OSPFv3 and IS-IS
values. In -04 we removed igp-protocol, and protocol-id is now
tet:te-info-source restricted to ospfv2, ospfv3 and isis (a YANG 1.1
enumeration restriction). That reuses an existing TEAS type, keeps the
instance encoding unchanged, and leaves no typedef to relocate. It also
avoids importing the OSPF and IS-IS modules. Please let us know if this
addresses your concern.

On the groupings and common definitions: we agree in principle, and will
move them if a suitable common module emerges.

-04 also has some housekeeping (module revision date and copyright year,
IANA section aligned with the RFC 9907 template, updated references and a
few clarified descriptions).

Thanks again for the thorough review.

Regards,
Pavan (on behalf of the authors)

On Wed, Sep 9, 2026 at 8:20 PM Reshad Rahman <[e-mail]> wrote:

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