Skip to main content

Early Review of draft-ietf-dots-telemetry-10
review-ietf-dots-telemetry-10-opsdir-early-nainar-2020-07-17-00

Request Review of draft-ietf-dots-telemetry-09
Requested revision 09 (document currently at 25)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2020-07-17
Requested 2020-06-25
Requested by Liang Xia
Authors Mohamed Boucadair , Tirumaleswar Reddy.K , Ehud Doron, Meiling Chen , Jon Shallow
I-D last updated 2020-07-17
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)
Comments
Since all the defined DOTS telemetry attributes with YANG data model are very related with traffic and flow analysis, and other network ops related information, we need the ops directorate to help us to review their usage.
Thanks!
Assignment Reviewer Nagendra Kumar Nainar
State Completed
Request Early review on draft-ietf-dots-telemetry by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/Uv_bfazi1q9udU1pcVTE2IrOMDU
Reviewed revision 10 (document currently at 25)
Result Has nits
Completed 2020-07-17
review-ietf-dots-telemetry-10-opsdir-early-nainar-2020-07-17-00
Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts per guidelines in RFC5706.

Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Overall Summary:

This draft is a standard track proposing telemetry attributes for DOTS signal
channel (RFC8782) that can be exchanged between DOTS client and server. The
draft clarifies that these attributes are not mandatory. As these telemetry
attributes are extensions of the existing DOTS signal channel and it already
clarifies that they are not mandatory, this draft does not introduce any
backward compatibility issues.

The draft also proposes high level error handling mechanism for the telemetry
attributes defined in this document.

Overall this is a well written document. Some ambiguity observed that needs
attention are listed below:

--> The below reference seems to be wrong. RFC7252 is COAP and not CBOR. I
think it should be RFC7049.

"Telemetry messages exchanged between DOTS agents are serialized using
   Concise Binary Object Representation (CBOR) [RFC7252]"

--> An early reference to RFC7950 may be useful in Section 4.5.

--> tsid seems to be a terminology introduced in this draft. It will be good to
add this in the terminology section. Same for tmid.

--> Section 6.1.2 states that a PUT request with link capacity set to 0 to
delete a link when the other link is active. What happens if a PUT request is
sent with all the links set to a capacity of 0?. Will it be treated as error or
as "DELETE"?.

--> The DMS mentioned below can be expanded or included in the terminology
section. I cant find it in RFC8287 as well.

The 'total-attack-traffic' attribute (Figure 27) conveys the total
   attack traffic identified by the DOTS client domain's DMS (or DDoS

--> I understand that Pre-or-Ongoing-Mitigation attribute can be signaled by
DOTS client or Server. Can this be used to report an ongoing attack to the
server?. If so, what should be the value set in the end-time field?.

--> I am skipping the YANG module as I noticed that YANGDOCTOR review is
already done.

Few nits:

s/If no target clause in included in the request/If no target clause is
included in the request