Last Call Review of draft-ietf-dots-signal-filter-control-04
review-ietf-dots-signal-filter-control-04-opsdir-lc-chown-2020-06-15-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. 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.

This document is one of a set of documents produced by the DDoS Open Threat
Signalling (DOTS) working group, and builds on previously published RFCs (RFC
8782, 8783). It describes a mechanism by which the DOTS signalling channel
defined in RFC 8782 can be used to allow a DOTS client that is under attack to
change the filtering rules and thus the mitigation behaviour being applied to
it via a DOTS server, even when the downstream to it may be saturated.

The text is well-written with a good structure and a healthy number of
examples. I would asses its current state as Ready with Nits.  The new
capability seems very useful.

General comments:

I am not wholly clear about some terms, e.g. “idle time” seems to be when no
mitigation is in place, but does this mean no filtering rules are active, or no
anti-DDoS rules are active?  Or are all DOTS rules there for mitigation rather
than general protection?

If I understand correctly, this extension allows new filter rules to be added,
such as rate limits, so it’s not just that the signal channel can be used to
control (activate and deactivate) existing filters.  If correct, perhaps that
could be made more explicit early on, even in the abstract.

Section 1.1:

The problem statement is good.  A very clear requirement.

Section 1.2:

I would add some text that briefly explains the different properties of RFC
8782 and 8783, i.e. that with its lightweight design and heartbeat protocol
(section 4.7 of RFC 8782) the signalling channel can be used to communicate
with a DOTS server even when the downstream link to the DOTS client is
saturated.  As it is, you have to be familiar with RFC 8782 to understand
what’s written here; some extra clarity would be useful.

Section 3.2.1:

“A DOTS client relies on information received from the DOTS server…” but can it
always receive such information if the link is saturated?  It seems to me that
you can push messages from client to server under an attack, but cannot assume
the reverse is true?

Nits:

Abstract:

The filtering rules are “supposed to be conveyed during idle time .. by the
data channel” - does that mean they can be conveyed outside quiet time, or MUST
NOT be conveyed outside idle time over the data channel?   Or does the new
capability in this document make that a MUST or SHOULD NOT?

Section 1.1:
What is “the conflict” in para 4?

Otherwise, very clean with no typos that I see.

Best wishes,
Tim