Change:
that a deliberate connection migration is accompanied by a change in the connection ID and necessitate that connection ID aware DDoS defense system must have the same information about connection IDs as <del> the load balancer I-D.ietf-quic-load-balancers. It is questionable if connection migrations must be supported during a DDoS attack.  If the connection migration is not visible to the network that performs the DDoS detection, an active, migrated QUIC connection may be blocked by such a system under attack.  As soon as the connection blocking is detected by the client, the client may rely on the fast resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. </del> <ins> the load balancer I-D.ietf-quic-load-balancers.  This may be complicated where mitigation and load balancing environments are logically separate. It is questionable whether connection migrations must be supported during a DDoS attack.  If the connection migration is not visible to the network that performs the DDoS detection, an active, migrated QUIC connection may be blocked by such a system under attack.  As soon as the connection blocking is detected by the client, the client may rely on the fast resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. </ins> 4.5.

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.