Change:
4.4. Current practices in detection and mitigation of Distributed Denial <del> of Service (DDoS) attacks generally involve passive measurement using network flow data RFC7011, classification of traffic into "good" (productive) and "bad" (DoS) flows, and filtering of these bad flows in a "scrubbing" environment.  Key to successful DDoS mitigation is efficient classification of this traffic. Limited first-packet garbage detection as in sec-garbage and stateful tracking of QUIC traffic as in sec-stateful above can be used in this classification step. </del> <ins> of Service (DDoS) attacks generally involves classification of incoming traffic (as packets, flows, or some other aggregate) into "good" (productive) and "bad" (DDoS) traffic, then differential treatment of this traffic to forward only good traffic, to the extent possible.  This operation is often done in a separate specialized mitigation environment through which all traffic is filtered; a generalized architecture for separation of concerns in mitigation is given in DOTS-ARCH. Key to successful DDoS mitigation is efficient classification of this traffic in the mitigation environment.  Limited first-packet garbage detection as in sec-garbage and stateful tracking of QUIC traffic as in sec-stateful above may be useful during classification. </ins> Note that the use of a connection ID to support connection migration renders 5-tuple based filtering insufficient and requires more state

Discussion:
This is not how it works. A few examples: URL URL
I'm not sure I see support for "this is not how it works" in your examples: SYN cookies on their own are a 1990s technique for end-system DoS prevention, which, while useful at transport-terminating front ends as part of a larger DoS prevention strategy, aren't really usable on their own at scale. The paper you link to here (from ICWET, and itself a decade old) primarily deals with the separation of good from bad flows at layer 7, not necessarily how the front-end handles these flows once classified. But you're definitely right that this is not only how it works: the DoS mitigation landscape is wide and varied (even if at the end of the day the only strategy we have found to work at scale is "eat the DoS". That said, this text could be improved: it discounts detection and classification mechanisms other than based on flow designators derived from passive measurement, does not mention protocols other than IPFIX and the flow model that comes along with it when classifying traffic, etc. The text should also be more applicable to UDP reflection DoS, which is a primary concern in wire image differentiation in QUIC (and which also isn't otherwise addressed in the document or in this issue). Adding a path-observable SYN cookie equivalent to QUIC, while useful, seems difficult to achieve given the working group's history of consensus about path-observable wire image features, so other classification mechanisms are what we'll be left with.
Exactly my point. The passive measurements are generally only useful to prevent the collateral damage to the network infrastructure of an ISP or a datacenter network under an attack. While the infrastructure impact of QUIC is itself an intriguing research topic, DDoS affects not only transit networks but also the endpoints in ways that could not be prevented with any passive flow classification.
The intent of this section is to cover DoS mitigation on the "downstream" segment, all the way from transit to endpoint, with access and front-end networks in between; the further you get from the endpoint the harder classification is, but the larger the impact of filtering operations.

AIUI transit networks generally only get involved at the BGP level (i.e., when an affected destination prefix is temporarily announced via a mitigation/filtering network to route traffic for scrubbing), but we shouldn't look at just the endpoint/frontend, either, This document probably shouldn't go all the way down the DoS prevention architecture rabbithole (note to self: check to see whether DOTS has something we can refer to here). But I'll put some effort into making this more general.
This is more of an "e.g." than "i.e.", but fine. I must say this is also a place where the infrastructure could be affected by the HTTP protocol upgrade. E.g. if the risk model assumes large transport layer floods, then the optical links towards the scrubbing center should be upgraded to carry ~22x more traffic.
actually, no; improve section 4.4 as well.
Err. "Current practices in detection and mitigation of Distributed Denial of Service (DDoS) attacks generally involves classification of incoming traffic (as packets, flows, or some other aggregate) into "good" (productive) and "bad" (DDoS) traffic" No. It generally does not. There are active and passive countermeasures, there are SYN cookies, truncated DNS responses, captchas, etc. The draft is still missing all of those.
I think what is still missing is to note that this document is generally scoped to in-network manageability and therefore does not discuss measures that can be applied directly at the end hosts. Maybe we can clarify this by add one simple word like this: s/Current practices in detection and mitigation/Current in-network practices in detection and mitigation/ ?
No, this is still not fair. Active countermeasures like SYN proxying still belong to the network. Probably the only way to do this properly would be to say that "Current practices in passive detection and mitigation" do whatever they do, and to add later in the section that there are also practices in active mitigation which are not supported by the protocol (the last paragraph basically sums it up) when the endpoint is not cooperating. It'd be also a good idea to highlight the impact of the lack of active mitigation features, and to hint to how the endpoint could cooperate.