[Dots] Éric Vyncke's No Objection on draft-ietf-dots-signal-call-home-11: (with COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Mon, 14 December 2020 10:40 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dots@ietf.org
Delivered-To: dots@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 259613A0F2F; Mon, 14 Dec 2020 02:40:47 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-dots-signal-call-home@ietf.org, dots-chairs@ietf.org, dots@ietf.org, Valery Smyslov <valery@smyslov.net>, valery@smyslov.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= <evyncke@cisco.com>
Message-ID: <160794244713.23722.10716414184806475697@ietfa.amsl.com>
Date: Mon, 14 Dec 2020 02:40:47 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/LPcSdxj1MJ-n2QgXi8yPWyKEzzs>
Subject: [Dots] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-dots-signal-call-home-11=3A_=28with_COMMENT=29?=
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Dec 2020 10:40:47 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-dots-signal-call-home-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thank you for the work put into this document. Congratulations for the many
nice ASCII artworks ;-) Using the SVG alternate artwork could have even been
nicer ;-)

Please find below  some non-blocking COMMENT points (but replies would be
appreciated), and some nits.

I will let the transport AD to decide on the IANA point.

I hope that this helps to improve the document,



-- Abstract --
I wonder whether the 2nd paragraph is really useful.

-- Section 1.1 --
Should the DOTS acronym be expanded before first use ?

Please add a reference to "Slowloris"

Did the authors/WG consider mentioning MUD in this lengthy discussion about IoT
@ Home ?

-- Section 5.2.1 --
"When an outgoing attack that saturates the outgoing link", but, what about an
"incoming attack" ?

-- Section 5.2.2 --
Thank you for using an IPv6-only example !

-- Section 5.3.1 --
Can source-prefix be a link-local address (normally not forwarded by a router
but what if the CPE is a layer-2 node) ?

In figure 9, while "2001:db8:123::/128" is a valid node address but it looks
like a prefix, may I suggest to use "2001:db8:123::1/128" that better suggest a
host address ?

-- Section 5.3.2 --
Congratulations to the authors for describing the NAT64/MAP behaviors.

-- Section 8 --
"The DOTS Call Home can be misused " should probably include "server".

-- Section 9 --
How is the privacy among DOTS servers enforced ? E.g., how can the DOTS client
only send mitigation information about subscriber A prefix(es) and not
subscriber B prefix(es)? There could obviously be a link to RADIUS and DHCP
servers but I did not read anything about this. Or is 'common sense' / implicit

== NITS ==

s/Figure 10 depictes/Figure 10 depicts/