Early Review of draft-ietf-teas-yang-topology-filter-02
review-ietf-teas-yang-topology-filter-02-yangdoctors-early-rahman-2026-04-07-00

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.