[Teas] Yangdoctors early review of draft-ietf-teas-actn-pm-telemetry-autonomics-08

[Reshad Rahman via Datatracker <[e-mail]>]

Reviewer: Reshad Rahman
Review result: Ready with Issues

This is my YANG Doctor review of
draft-ietf-teas-actn-pm-telemetry-autonomics-08.

I have reviewed the document and looked at references such as
draft-ietf-teas-actn-vn-yang, RFC8453, RFC8309 etc. I think I got to grasp the
intent of the document, at least the autonomics part. However I am not sure I
fully understand how everything fits in together. I don't follow the TEAS WG
anymore, I tried to catch up by searching the archive but I didn't see any
discussions on this document in the archive. Having more examples may help.

Comments on the document:

The document title, abstract and YANG modules all use the term "telemetry". I
do not see anything specific to telemetry in the YANG modules, it is just extra
data being modelled in TE tunnels and VNs. There are a couple of examples with
establish-subscription, but that IMO still doesn't the model telemetry specific.

Introduction, 5th paragraph. I don't get "to provide an ability to program
their customized performance monitoring subscription". Possible it's because
I'm missing the big picture. My suggestion is to clarify/simplify. But if the
WG is good with this, fine with me.

Introduction, 6th paragraph. The following statement is of some concern to me
because of the potential confusion. Again, up to the WG. Nit: missing "way"
after "different".
 "The term performance monitoring is used in this document in a
   different from how the term has been used in TE networks for many
   years."

Section 2. Figure 1 is a nice diagram, but it is not clear where/how this
document fits in.

Section 2, next to last bullet. "other SLA requirements". It would help to have
an example of such an SLA requirement.

Section 5.2. There's a mismatch between the text for figure 9 (copy-paste from
text for figure 8?) and figure 9.

IANA Considerations: For YANG module name registry, the reference should be
RFC6020, not RFC7950.

Comments on the YANG models:

Why use identity for scale-op? enum seems fine for up and down.

For threshold-time and cooldown-time, is it ok to have value 0?

For threshold-value, why use a string. I realize using a union might be tricky
here, but why not uint64? Is it because there might be a threshold which cannot
be expressed as a value?

Telemetry-id seems unnecessary. First it's not clear whether it's unique per TE
tunnel. And, why invent a new "id", why not refer to the TE tunnel using its
key?

For scale-in and scale-out, by how much? Is there a missing leaf node or did I
misunderstand how this works?

For grouping-op(eration), are "and" and "or" still needed considering those are
in scaling-criteria-operation?

Typos:

- analize (analyze)

- interpritted (interpreted)

- criterias (criteria)

Regards,
Reshad.