Skip to main content

Last Call Review of draft-ietf-dots-telemetry-use-cases-12
review-ietf-dots-telemetry-use-cases-12-rtgdir-lc-eastlake-2022-10-02-00

Request Review of draft-ietf-dots-telemetry-use-cases
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2022-09-22
Requested 2022-09-08
Requested by Alvaro Retana
Authors Yuhei Hayashi , Meiling Chen , Li Su
I-D last updated 2022-10-02
Completed reviews Secdir Last Call review of -12 by Phillip Hallam-Baker (diff)
Rtgdir Last Call review of -12 by Donald E. Eastlake 3rd (diff)
Artart Last Call review of -11 by Sean Turner (diff)
Genart Last Call review of -11 by Peter E. Yee (diff)
Comments
The document describes some expected interactions with routing.
Assignment Reviewer Donald E. Eastlake 3rd
State Completed
Request Last Call review on draft-ietf-dots-telemetry-use-cases by Routing Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/kAsYlM1sa8QkckNy5Np1d5tPMx8
Reviewed revision 12 (document currently at 16)
Result Has issues
Completed 2022-10-02
review-ietf-dots-telemetry-use-cases-12-rtgdir-lc-eastlake-2022-10-02-00
Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and sometimes
on special request. The purpose of the review is to provide assistance to
the Routing ADs. For more information about the Routing Directorate, please
see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-name-version
Reviewer: Donald Eastlake 3rd
Review Date: 2 October 2022
Intended Status: Informational

Summary:
I have some minor concerns about this document that I think should be
resolved before publication.

Comments:
This is a reasonably straightforward Informational document giving examples
of the use of DOTS Telemetry, as specified in RFC 9244, to improve the
efficiency of DDoS mitigation. It is quite readable but I found the text to
be somewhat verbose and repetitive.

Major Issues:
No major issues found.

Minor Issues:

Section 3.1.1, page 6: If the point is that some DMSes have limited
capacity, then shouldn't directing "as much of the top-talker's traffic to
the DMS as possible" by "directing as much of the top-talker's traffic to
each DMS as that DMS can handle" or the like?

Why is only SNMP mentioned in this document and not YANG?

Nits:

I am suspicious of the heavy use of the word "optimal" in this document. I
did not see any place where the criterion or metric for optimality is
defined nor did I see any demonstration that the example uses provide
optimal mitigation techniques. But it is hard to blame the authors of this
draft when the Standards Track RFC 9244 on which these examples are based
has the same problem. If it were not for the use of "optimal" in RFC 9244,
I would have counted this as a Minor Issue.

For example, Section 3.1.2, page 8, asserts that, based on DOTS telemetry
information, "the orchestrator selects an optimal DMS". It then gives as an
example a very simple selection algorithm which I might describe as
selecting an "adequate" DMS. Then in the following one-sentence paragraph,
it says the selection algorithm is out of scope. How can it be asserted
that an optimal DMS will be selected without giving any hint as to how to
find an algorithm to make such an optimal choice? Similar comments would
apply to other Sections of this document.

Section 3.1.5: "based about the" -> "based on the"

Sections 4 and 9: There seems to be a dangling "Thanks to" at the end of
Section 9. The last line of Section 4 seems to be an acknowledgement which
should, perhaps, be in Section 9.

Adding a reference for "DNS Water Torture Attack" would be good.

Suggest deleting both occurrences of "In particular".

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com