Last Call Review of draft-ietf-dots-requirements-16
review-ietf-dots-requirements-16-opsdir-lc-bradner-2018-11-24-00
| Request | Review of | draft-ietf-dots-requirements |
|---|---|---|
| Requested rev. | no specific revision (document currently at 22) | |
| Type | Last Call Review | |
| Team | Ops Directorate (opsdir) | |
| Deadline | 2018-11-23 | |
| Requested | 2018-11-02 | |
| Draft last updated | 2018-11-24 | |
| Completed reviews |
Secdir Last Call review of -16 by Brian Weis
(diff)
Opsdir Last Call review of -16 by Scott Bradner (diff) Tsvart Last Call review of -16 by Joseph Touch (diff) Genart Last Call review of -16 by Robert Sparks (diff) Genart Telechat review of -18 by Robert Sparks (diff) |
|
| Assignment | Reviewer | Scott Bradner |
| State | Completed | |
| Review | review-ietf-dots-requirements-16-opsdir-lc-bradner-2018-11-24 | |
| Reviewed rev. | 16 (document currently at 22) | |
| Review result | Has Nits | |
| Review completed: | 2018-11-24 |
Review
review-ietf-dots-requirements-16-opsdir-lc-bradner-2018-11-24
This is an OPS-DIR review of Distributed Denial of Service (DDoS) Open Threat Signaling Requirements (draft-ietf-dots-requirements) This document lists requirements for a protocol to used between providers of DDOS mitigation services and users of such services, as such there can be no direct operational issues with the document. I also did not find any indirect operational issues. I think the document would benefit from the addition of a section before the requirements section that specifically describes the setup assumed by the document. The descriptions before there hint at a presumed setup but a new section that clearly states the setup would be helpful. (the setup appears to be one where all network traffic to and from a protected entity flows through a DDoS mitigation service provider. The provider includes one or more DOTS servers. The protected entity includes one or more DOTS clients that communicate with the DOTS servers) Requirement SIG-005 addresses channel redirection – maybe there needs to be a way that clients can move to a new server on their own if they lose hearbeat from the server they were using – that might include a way for a server to provide a list of alternative servers to the clients