Skip to main content

Early Review of draft-ietf-teas-sf-aware-topo-model-08

Request Review of draft-ietf-teas-sf-aware-topo-model-08
Requested revision 08 (document currently at 12)
Type Early Review
Team YANG Doctors (yangdoctors)
Deadline 2021-12-08
Requested 2021-11-08
Requested by Vishnu Pavan Beeram
Authors Igor Bryskin , Xufeng Liu , Young Lee , Jim Guichard , Luis M. Contreras , Daniele Ceccarelli , Jeff Tantsura , Dmytro Shytyi
I-D last updated 2021-12-14
Completed reviews Yangdoctors Early review of -08 by Andy Bierman (diff)
Assignment Reviewer Andy Bierman
State Completed
Request Early review on draft-ietf-teas-sf-aware-topo-model by YANG Doctors Assigned
Posted at
Reviewed revision 08 (document currently at 12)
Result Ready w/issues
Completed 2021-12-14
Draft:    draft-ietf-teas-sf-aware-topo-model-08.txt
Module:   ietf-te-topology-sf
Revision: 2021-06-28


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


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.

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)?

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.)