Reviewer: Tim Chown Review result: Has Nits 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
