[Teas] Benjamin Kaduk's No Objection on draft-ietf-teas-yang-te-topo-16: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-teas-yang-te-topo-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Alvaro for pointing out the specific considerations on the
geolocation variables.

This document has a large number (6) of authors;
https://www.rfc-editor.org/policy.html#policy.authlist implies that
justification is needed for more than 5 authors.

Section 3.4

I'm confused why the transitional TE link disappears once a normal
TE link abstracting away the layer transition appears -- is there no
longer potential to do layer transition at that node (e.g., to take
a different path in the server layer network) once a layer
transition is in use?

Section 8

I'm not sure I understand why the te:templates tree is not called
out as "sensitive" -- is it just the "template" nature?  Lots of
these look like things that could have detrimental impact if
modified in an actual live instance -- ID, bandwidth, type, etc., so
I mostly assume that it's just the templatey-ness, but don't quite
understand how that works.

There are a number of places where editorial attention would be beneficial; I
only noted a small subset of them.  One recurring theme is "<foo> is assigned
with the <bar>  unique ID", which might be more clearly phrased as "A <foo> is
assigned a unique ID within the scope of <bar>".  Some other specific items
follow.

Section 1

   [...] There could be one or more TE Topologies present in a given
   Traffic Engineered system. The TE Topology is the topology on which
   path computational algorithms are run to compute Traffic Engineered
   Paths (TE Paths).

nit: If there could be more than one, it seems grammatically
improper to use the definite article "the" (without further
qualification) to refer to them.

Section 1.1

   Customized TE Topology: Customized TE Topology is a custom topology
   that is produced by a provider for a given Client. This topology
   typically augments the Client's Native TE Topology. Path
   computational algorithms aren't typically run on the Customized TE
   Topology; they are run on the Client's augmented Native TE Topology.

This text doesn't really help me tell the difference between the
"Client's augmented Native TE Topology" and the "Customized TE
Topology", which is the Client's Native TE Topology plus some
unspecified augmentation (that is apparently different from the one
used for path computation).

Section 2

   - Each TE Topological element has an information source associated
     with it. In some scenarios, there could be more than one
     information source associated with each topological element.

editorial: I'd suggest replacing the last "each" with "any given",
and maybe "has an" with "has at least one".

Section 3.3

   TE link is an element of a TE topology (presented as an edge on TE
   graph, arrows indicate one or both directions of the TE link).

(I don't see any arrows in Figure 1.)

   [...] TE link
   is connected to TE node, terminating the TE link via exactly one TE
   link termination point (LTP).

Even unidirectional links have a source and destination; presumably
both of those are attributes of the TE link?  Perhaps "for any given
node" should be more explicit?

Section 3.8

   [...] From the point of view of
   a potential TE path LLCL provides a list of valid TE links the TE
   path needs to start/stop on for the connection, taking the TE path,
   to be successfully terminated on the TTP in question.

nit: this could probably be reworded to be more clear, maybe:

%  From the point of view of usability in creating a TE path, the LLCL
%  provides a list of the TE links that would be valid path components
%  for paths involving the TTP in question.

Section 3.10

   is unique across all TE topologies provided by the same provider.  The
   client layer LIPs and the server layer TTPs associated within a given

Should that be "LTPs" instead of "LIPs"?

Section 4.4

   [...] maintain. For example, in addition to the merged TE topology depicted
   in the upper part of Figure 1, the client may merge the abstract TE

Figure 1 was long ago and does not seem relevant.  Was this supposed
to be Figure 9 or Figure 10?

Section 7

     grouping connectivity-label-restriction-list {
       description
         "List of abel restrictions specifying what labels may or may
          not be used on a link connectivity.";
       list label-restriction {
         key "index";
         description
           "List of abel restrictions specifying what labels may or may
            not be used on a link connectivity.";

presumably "label" rather than "abel" (twice)?

Another typo -- "speficied" for "specified" (also twice).
And "souruce" for "source" (twice)

Appendix C

Are there really supposed to be 63 occurrences of the string
"Attribute 11 for example technology" (i.e., with no "Attribute 1",
"Attribute 2", etc.)?