YANG Data Model for Traffic Engineering (TE) Topologies
draft-ietf-teas-yang-te-topo-22
Yes
(Deborah Brungard)
No Objection
(Alexey Melnikov)
(Alissa Cooper)
(Mirja Kühlewind)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 15 and is now closed.
Warren Kumari
No Objection
Comment
(2018-06-06 for -16)
Unknown
In the “Trusting AD, ran out of time “ sense.
Deborah Brungard Former IESG member
Yes
Yes
(for -15)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(2018-06-06 for -16)
Unknown
I agree with Warren's comment. ;-)
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -15)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -16)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(2018-06-06 for -16)
Unknown
Security Considerations: It is important to call out the fact that the sensitive information in the readable data nodes includes geolocation.
Ben Campbell Former IESG member
No Objection
No Objection
(2018-06-06 for -16)
Unknown
Just some editorial comments: - There is conflicting 2119/8174 boilerplate in the front material and in §1.1. I assume the latter is the correct boilerplate. - The writing style makes heavy use of imbedded definitions and examples in parenthetical phrases. I personally find that creates quite a bit of readability friction. It would be easier to read if such things were split out into their own sentences. - Some of the figures have legends, but most do not. It would be very helpful to include legends in those figures that depend on different line styles to convey meaning. (e.g. Figure 1).
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2018-06-06 for -16)
Unknown
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.)?
Ignas Bagdonas Former IESG member
No Objection
No Objection
(2018-06-07 for -16)
Unknown
Focusing on YANG modules part only (as ran out of time for detailed review of reasoning behind model design) there does not appear to be any noticeable problems.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -16)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2018-06-05 for -16)
Unknown
I found myself wondering what the last sentence in - TE Topology may not be congruent to the routing topology (topology constructed based on routing adjacencies) in a given TE System. There isn't always a one-to-one association between a TE-link and a routing adjacency. For example, the presence of a TE link between a pair of nodes doesn't necessarily imply the existence of a routing-adjacency between these nodes. was saying about what IS implied between these nodes. I'm guessing, but this draft seems to assume a relatively low level amount of experience with traffic engineering, so I can imagine readers who could benefit from a word or two of explanation.
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -16)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -16)
Unknown