[Last-Call] RtgDir Last Call review: draft-ietf-dots-telemetry-use-cases-12

Donald Eastlake <d3e3e3@gmail.com> Sun, 02 October 2022 22:41 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7EDC14F725; Sun, 2 Oct 2022 15:41:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.856
X-Spam-Level:
X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82RDitDIhVXt; Sun, 2 Oct 2022 15:41:44 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A207C14F724; Sun, 2 Oct 2022 15:41:44 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id o7so6983543lfk.7; Sun, 02 Oct 2022 15:41:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date; bh=cf6lXQPa5n10PTbJQ4Lc85uclrLFbLa9yyNZiaxugdE=; b=NmpwEntElL0n1wwBywmHdpM9647kMdN8v8LxElvfgAqhELdebH2mlSvH2Qe9QeCt94 4MtsXs85xpcoZqPdJobBBle3CmdVMdAjuArSMMBtlj3jutyrPtxFVM6k60SpMq5e8aQD dNXFZYOT5t8K94QN8XEk6ZKjW2A4fWkz7x7+YhTXUmSorEsj7axQv2eqS9+NoJn4dqTs aS1FbLjG4h4ZvCVczFtL2NgwA8u5J/qdbJNbguXjothvhNvmybT4AIsZU2WNROQozfcd F/kBKjnRFltethu9TfdWMWxWclaWGpN6SDCFhxc/qIN7LMP4Kw+mN177ckacRV9nOrTV iDkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=cf6lXQPa5n10PTbJQ4Lc85uclrLFbLa9yyNZiaxugdE=; b=K05Y+6Zyr8lwPI/vXdMWka/2JGFaagDQWiyKBtVG54q8a+nshAOK88h18gzxDXaD9o yMxZnVnoKJ7G+B8voA3Wu/OLHd2ysIiaodYDQXDrYPLu7ZzW+yCDOXLXUzhWNVEmYmDb ZSkvh81kvk3hxEPGotB47xw19Wbv9xZVbrQFQam1unkBu+z2WaPHR6PXl7LtS6DuUeoc CSyvjE3HikwMa7g/s2iPGujk5yDXI0SSLynTS/pAy0xylbliZFn6VkYaqGEEJtOmAy5O AngeMaPkismqi8XKNx5gkxc4CKSXrBviuwkOCvjuZUYRANpgxvN7oUaScqRk6BHOt4Lr eNDQ==
X-Gm-Message-State: ACrzQf2Vh4AZovxRXDmUEHZ45WasSFHJhrm0m5R4SqQ5m3JZcaWgxmq1 /+FLg1S1WLp6mRDakYwX2GPweLSHXR/BkCtwZn+mUqRlYC/JdQ==
X-Google-Smtp-Source: AMsMyM6+g6ZMRIatYraYRufTNcAUGmNmwSgla1vtXnupESOfQvElWm8ZqPbiumV7kEv3TqJODajbTy03Roc1XCFLtUY=
X-Received: by 2002:a05:6512:2150:b0:4a2:2f09:9629 with SMTP id s16-20020a056512215000b004a22f099629mr1778072lfr.198.1664750501675; Sun, 02 Oct 2022 15:41:41 -0700 (PDT)
MIME-Version: 1.0
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sun, 2 Oct 2022 18:41:30 -0400
Message-ID: <CAF4+nEEmry0O_PuY2T5OoN_4V_g250QR+y=g-sgedYzSy34SMA@mail.gmail.com>
To: "<rtg-ads@ietf.org> (rtg-ads@ietf.org)" <rtg-ads@ietf.org>
Cc: rtg-dir@ietf.org, dots@ietf.org, Last Call <last-call@ietf.org>, draft-ietf-dots-telemetry-use-cases@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004ac7dc05ea14eecd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/OGk-Cwm86ucxpp4aClTtFI2zdHE>
Subject: [Last-Call] RtgDir Last Call review: draft-ietf-dots-telemetry-use-cases-12
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Oct 2022 22:41:48 -0000

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