Early Review of draft-ietf-teas-yang-sr-te-topo-04
review-ietf-teas-yang-sr-te-topo-04-yangdoctors-early-lhotka-2019-06-10-00

This document and YANG module "ietf-sr-topology" contained therein
contribute two new types to the family of network topology data
models: segment routing and segment routing traffic engineering
topologies. The document also provides a companion module
"ietf-sr-topology-state" intended for non-NMDA implementations.

From the YANG point of view, both modules are in a relatively good
shape. Also, as far as I can tell, they satisfy the requirements
specified in RFC 8345.

The example instance data contained in Appendix B successfully passes
formal validation against the date model, which is far from
commonplace for early versions of documents. See however comment #1
below.

**** Comments

1. I have argued several times that using URIs as identifiers of all
   network topology objects in RFC 8345 is an overkill. Now, the
   present draft demonstrates the consequences: id values used in
   many places of the example data (Appendix B) are not valid URIs!
   For example, "link-id" leaves have values like
   "D1,1-2-1,D2,2-1-1", which is not a URI.

   This type violation isn't caught by validating tools because the
   "ietf-inet-types:uri" type doesn't specify a regular expession
   pattern. However, its description states clearly that the type
   represents URI as defined by STD 66.

2. The module uses (indirectly) the grouping "srlr" from the
   "ietf-segment-routing-common" module. This grouping defines two
   leaves, "lower-bound" and "upper-bound". I assume it is expected
   that the former must not be greater than the latter. This is
   however not enforced by the data model. My suggestion is to add a
   "must" statement to the "srlr" grouping corresponding to this
   constraint.

3. Typos in the module text:

   - description of grouping "sr-topology-type":
     s/toplogies/topologies/

   - description of container "sr-mpls":
     s/Indiates/Indicates/