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.