Draft:    draft-ietf-teas-sf-aware-topo-model-08.txt
Module:   ietf-te-topology-sf
Revision: 2021-06-28


General:

This document is well written and understandable, even though
the topic is complex.


Issues:

1)
Not clear why information-source-entry/service-function/link-terminations/link-termination/from
is just an empty NP-container. Description says "Reference to the link termination point.";
Not clear how this empty NP-container is a reference to anything.

2)
The "service-function-id" and "sf-connection-point-id" leafs are each used in 4 places.
Perhaps use groupings instead of cut-and-paste?
The type is a plain string. Is this really what is desired?
It is not clear if these leafs are administrative labels or real linkage.
The description is (e.g.) "Reference to a network service or a network function."
This implies some linkage to another YANG object somewhere, but no mention of any
such objects. Should this be a leafref to a specific node (or union of leafrefs
to multiple objects)?

3)
The service-function key (id) is also a plain string.
Should the type "yang-identifier" be used instead?
Or maybe a different common type.  Is is not unusual to limit the length
of string identifiers provided by a client.  Obvious;y a server can
return a "too-big" error but it might be useful to pick a length
every server must support (e.g. 1..64).


Module:   ietf-te-topology-sf-state
Revision: 2021-06-28

This is a non-NMDA version of the ietf-te-topology-sf module.
It appears to completely correct and no new issues exist.

(There should be a YANG extension to tell compilers and other tools
that module foo-state is really the non-NMDA variant of foo, and
not just a different module with a name that matches a common pattern.
Not an issue for this draft.)