[Teas] Comments on draft-ietf-teas-yang-te-types

[Matt Hartley <[e-mail]>]

Authors,

Some LC comments on this. Please note that I haven't really been all that
involved in the discussions and I'm coming to it fairly cold... which may
or may not be a good thing :)

p26: identity lsp-protection-unidir-1-to-1: description is "LSP protection
'1+1 Unidirectional Protection'", but that's inconsisent with the name. I'd
expect this to be for 1:1 protection, not 1+1. Or if it is for 1+1, the
name should be ...1-plus-1, shouldn't it? Same for the bidir one below.

p32: identity lsp-encoding-optical-channel: this has the same description
as the next one. One of these needs fixing.

p33: identity route-usage-type has route-exclude-ero as an option. Is that
intended to cover XROs too? Or do we need another identity for XROs?

p34: identity te-optimization-criterion: Can't an optimization criterion be
anything that can be used as a metric? Do we actually need a separate type
here? If we do, what does 'cost' refer to? And is the delay the average or
minimum (as for the metrics)? the model seems inconsitent with itself here.

p37: identity oduc: description is "ODUCn bit rate." For all the other
elements here the ODU type is the same in the description as in the
identity name (barring capitalization) but here it's different. Is there a
reason for that or does something need to be fixed?

p39: grouping te-topology-identifier: leaf provider-id: how do we ensure
uniqueness here? Is this something that will need to be managed in the same
way as IP addresses and AS numbers? Or should we recommend that something
like an AS number or IP address owned by the provider be used here?

p39: grouping te-topology-identifier: leaf topology-id: should we put some
RFC 2119 language in there, if things MUST be unique? And what's the scope
of that uniqueness? Within the provider/client pair? Globally? Something
else? It's unclear.

10.1: You've got the other yang models we're working on as normative
references. Isn't the idea that this document stands alone, and those
documents can reference it? Why do we need them as normative references
here?

Note: Everything after here is nits...

p5, admin-groups: "A union type for TE link's" -> "A union type for a TE
link's"

p5, srlg: "representing the Shared" -> "representing a Shared"

p6, protection-external-commands: "trouble shooting" -> "troubleshooting"

p7: te-class-type, bc-type, bc-model-type: "Diffserv-TE" -> "DS-TE" (since
you went to the trouble of defining this up front...)

p12: typedef te-link-access-type, enum multi-access: is NBMA something that
we can assume is generally understood, or does it need to be expanded?

p13: typedef te-oper-status, enum unknown: I think just "Status cannot be
determined" would do for the description. The rest is redundant.

p13: typedef te-oper-status, enum maintenance: the description here doesn't
reference the control plane (contrast preparing-maintenance above). Would
it be worth specifying that the resource is disabled in both planes?

p17: typedef srlg: I think having the description as "SRLG type" is
confusing (my initial reaction was 'hang on, SRLGs don't have types...').
Maybe just "SRLG"?

p19: identity of-minimize-cost-path: That's a really confusing name. I
thought it was a mangled version of minimize-cost-of-path until I figured
out that the 'of' is just a prefix for objective-function. Maybe
of-minimize-path-cost would be better? Similarly for the next one... maybe
of-minimize-path-load?

p20: identity path-externally-queried: The description is awkward. Maybe:
"Constrained-path LSP in which the path is obtained by querying an external
source, such as a PCE server. In the case that an LSP is defined to be
externally queried, it may also have associated explicit definitions
provided to the external source to aid computation. The path that is
returned by the external source need not be a wholly resolved path back to
the originating system; some additional local computation may also be
required."

p28: identity protection-external-commands: "trouble shooting" ->
"troubleshooting"

p32: identity path-signaling-type: please put a blank line before this so
it's more obvious it's a new base type when reading it.

p36: identity srlg-preferred: is this best-effort? If so, could we have
that in the description?

p37: identity otn-rate-type: description could just be "Base type to
identify OTN bit rates." The rest is redundant.

Cheers

Matt