Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification
draft-ietf-dots-data-channel-31

Thank you for writing this - I found it useful and interesting.

I do have a few comments / suggestions to try improve the document further.

1:  "In most cases, sufficient scale can be achieved by compromising enough end-hosts and using those infected hosts to perpetrate and amplify the attack."
This is somewhat misleading - it sounds somewhat like the reflectors which get used for amplification attacks (e.g DNS servers) have been compromised. Perhaps "In most cases, sufficient scale can be achieved by compromising enough end-hosts or using amplification attacks" - in the grand scheme of things this isn't super important, but because it is so close to the beginning of the document it would be nice to set the tone correctly...

2: "After discovering the RESTCONF API root, a DOTS client uses this value as the initial part of the path in the request URI, in any subsequent request to the DOTS server."
The commas seem superfluous, and make reading this hard.

3: "It is RECOMMENDED that DOTS clients and gateways support means to alert administrators about loop errors so that appropriate actions are undertaken."
Truly a nit, but I had to reread this sentence multiple times before I got it -- I would suggest s/means/methods/ (or "provide methods"). 

4: TCP flags. It is really common to match on "Established" sessions (or packets with or without the SYN flag -- I think it would be **really** helpful to describe how this is done / have an example, etc. While readers should be able to figure this out, it would be helpful to have this so people can find it in a panic. Actually, more examples in the Appendix would be generally useful...

5: "The DOTS gateway, that inserted a ’cdid’ in a PUT request, MUST strip the ’cdid’ parameter in the corresponding response before forwarding the response to the DOTS client."
Extra commas...

Thanks to everyone who worked on this document. Alexey covered all of my
substantive comments, and I support his DISCUSS; I only have a few editorial
nits to suggest.

---------------------------------------------------------------------------

ID Nits reports:

  ** There is 1 instance of too long lines in the document, the longest one
     being 5 characters in excess of 72.

---------------------------------------------------------------------------

§3.4:

>  its own information (e.g., server names, literal IP addresses) is
>  present in the "Via" header of a DOTS message it receives:

Nit: "...header field..."

>     header, the DOTS gateway MUST NOT forward the DOTS message.

Nit: "...header field..."

>  error-info:     <via-header> : A copy of the Via header when

Nit: "<via-header-field>...header field..."

>  o  Otherwise, the DOTS agent MUST update or insert the "Via" header
>     by appending its own information.

Nit: "...header field..."

>  DOTS client domain SHOULD remove the previous "Via" header
>  information after checking for a loop before forwarding.  This

Nit: "...header field..."

I did not have a chance to review this document but I am balloting No Objection on the basis of the Gen-ART review.

Alexey has this well covered, and I support his DISCUSS.

Thanks for addressing my discuss!

Thanks for addressing my DISCUSS.