Skip to main content

Last Call Review of draft-ietf-dots-telemetry-19
review-ietf-dots-telemetry-19-artart-lc-gruessing-2022-01-15-00

Request Review of draft-ietf-dots-telemetry
Requested revision No specific revision (document currently at 25)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2022-01-24
Requested 2022-01-10
Authors Mohamed Boucadair , Tirumaleswar Reddy.K , Ehud Doron , chenmeiling , Jon Shallow
Draft last updated 2022-01-15
Completed reviews Yangdoctors Early review of -09 by Jan Lindblad (diff)
Opsdir Early review of -10 by Nagendra Kumar Nainar (diff)
Yangdoctors Last Call review of -14 by Jan Lindblad (diff)
Artart Last Call review of -19 by James Gruessing (diff)
Intdir Last Call review of -19 by Ted Lemon (diff)
Genart Last Call review of -19 by Robert Sparks (diff)
Tsvart Last Call review of -19 by Michael Scharf (diff)
Assignment Reviewer James Gruessing
State Completed
Review review-ietf-dots-telemetry-19-artart-lc-gruessing-2022-01-15
Posted at https://mailarchive.ietf.org/arch/msg/art/MbTX3xfg6tMeG6mieAsT7hA3gXs
Reviewed revision 19 (document currently at 25)
Result Ready with Nits
Completed 2022-01-15
review-ietf-dots-telemetry-19-artart-lc-gruessing-2022-01-15-00
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.