[art] Artart last call review of draft-ietf-dots-telemetry-19

[James Gruessing via Datatracker <[e-mail]>]

Reviewer: James Gruessing
Review result: Ready with Nits

This is my review of draft-ietf-dots-telemetry-19 as requested by ARTART chairs.

Overall this is a well written document that explains its purpose, rationale,
and technical details for someone like myself with no previous knowledge of DOTS
or its underlying dependent protocols. As such my focus in this review has been
looking at the readability of the document through the eyes of a future implementer.

Comments:

3.2 - At a few points in this section, the concept of "measurements should be
taken when traffic is 'normal'" is repeated a few times and done in a way not as
clear as it could be. The authors should consider editing this section to be
more concise and avoid repetition.

3.3 - Perhaps a clear definition for the word "pipe" belongs in the terminology
section? Although it may appear obvious as to what it means, it is jargon that
is not used in RFC 9132 nor 9133. Consider that a client split with multiple
interfaces/networks/DOTS domains etc may affect interpretation of the word, and
thus the potential value it should calculate and send.

4.2 - This section could be expanded to cover quite a few duplicate pieces of
normative language listed throughout later sections - for example there are many
references to 'cuid' being mandatory and should not be present in PUT/DELETE
request bodies. Putting common details in this section, and exceptions
throughout should make interpretation by implementers easier particularly for
the structure of Uri-Path values.

9 - It may be beneficial to implementers if this section provides guidance on
the use of plain text diagnostic payloads for the additional error cases this
document defines.

Nit:

8.2 - Figure 48 shows the target of "https1" not "http1", the text above
refers to the latter.