Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
draft-ietf-dots-signal-filter-control-07

[[ questions ]]

[ section 3.2.1 ]

* "If not, the polling mechanism ... has to be followed".  Should this use some
  actual 2119 language?

* Is the specified client behaviour in the event of a 5.03 really MUST? That
  would definitely seem like recommended behaviour to me, but does it perhaps
  risk being over-specified to say retries without parameters MUST be
  attempted? I.e., should it be a SHOULD?


[[ nits ]]

[ section 6 ]

* "entitled to access only to resources" ->
  "entitled to access only the resources"

Some minor stuff only:

Section 1.1:

OLD:

   A typical case is a conflict between filtering rules installed by a
   DOTS client and the mitigation actions of a DDoS mitigator.  Such
   case is a DOTS client which configures during 'idle' time (i.e., no
   mitigation is active) some filtering rules using the DOTS data
   channel protocol to permit traffic from accept-listed sources, but
   during a volumetric DDoS attack the DDoS mitigator identifies the
   source addresses/prefixes in the accept-listed filtering rules are
   attacking the target.  For example, an attacker can spoof the IP
   addresses of accept-listed sources to generate attack traffic or the
   attacker can compromise the accept-listed sources and program them to
   launch a DDoS attack.

NEW:

   A typical case is a conflict between filtering rules installed by a
   DOTS client and the mitigation actions of a DDoS mitigator.  Consider,
   for instance, a DOTS client that configures during 'idle' time (i.e., no
   mitigation is active) some filtering rules using the DOTS data
   channel protocol to permit traffic from accept-listed sources.  However,
   during a volumetric DDoS attack the DDoS mitigator identifies the
   source addresses/prefixes in the accept-listed filtering rules are
   attacking the target.  For example, an attacker can spoof the IP
   addresses of accept-listed sources to generate attack traffic or the
   attacker can compromise the accept-listed sources and program them to
   launch a DDoS attack.

Section 1.2:

* "An augment to the DOTS signal channel ..." -- s/augment/amendment/ ("augment" isn't a thing, it's an action)

Section 3.2.1:

* Although this section declares the acronym "ACE" for "Access Control Entry", that acronym is used nowhere else in the document.

* "... notifies that DOTS client with the change ..." -- s/with/of, I think?

Section 6:

* "... does not allow to create new filtering rules ..." -- s/to create/creation of/

* "... entitled to access only to resources ..." -- s/only to/only those/

Thanks for responding to the SECDIR review (and thanks to Shawn Emery for conducting the review).

Thanks for addressing my COMMENTs.

Thank you for the work put into this document. 

I appreciated the clarity, the use of IPv6 examples, and the inclusion of the YANG model.

Only one minor suggestion about the title of section 1.2 as "The Solution" looks a little marketing ;-) I would prefer "Mitigation Technique" or something more 'engineering-oriented'

Regards

-éric

I found this document well written and easy to read and understand, particularly through the use of clear examples, so thank you.

Regards,
Rob