[Dots] Warren Kumari's No Objection on draft-ietf-dots-data-channel-28: (with COMMENT)

[Warren Kumari via Datatracker <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-dots-data-channel-28: 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:
https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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...