Code change:
excessive number of server push streams can be treated as a StreamErrorHandler of type ENHANCE_YOUR_CALM. <del> Processing capacity cannot be guarded as effectively as state capacity. The SETTINGS frame can be abused to cause a peer to expend additional processing time.  This might be done by pointlessly changing SETTINGS parameters, setting multiple undefined parameters, or changing the same setting multiple times in the same frame.  WINDOW_UPDATE or PRIORITY frames can be abused to cause an unnecessary waste of resources. Large numbers of small or empty frames can be abused to cause a peer to expend time processing frame headers.  Note, however, that some uses are entirely legitimate, such as the sending of an empty DATA or CONTINUATION frame at the end of a stream. Field section compression also offers some opportunities to waste processing resources; see COMPRESSION for more details on potential abuses. Limits in SETTINGS parameters cannot be reduced instantaneously, which leaves an endpoint exposed to behavior from a peer that could exceed the new limits.  In particular, immediately after establishing a connection, limits set by a server are not known to clients and could be exceeded without being an obvious protocol violation. All these features -- i.e., SETTINGS changes, small frames, field section compression -- have legitimate uses.  These features become a burden only when they are used unnecessarily or to excess. An endpoint that doesn't monitor this behavior exposes itself to a risk of denial-of-service attack.  Implementations SHOULD track the use of these features and set limits on their use.  An endpoint MAY treat activity that is suspicious as a ConnectionErrorHandler of type </del> <ins> A number of HTTP/2 implementations were found to be vulnerable to denial of service NFLX-2019-002.  The following lists known ways that implementations might be subject to denial of service attack: Most of the features that might be exploited for denial of service -- i.e., SETTINGS changes, small frames, field section compression -- have legitimate uses.  These features become a burden only when they are used unnecessarily or to excess. An endpoint that doesn't monitor use of these features exposes itself to a risk of denial of service.  Implementations SHOULD track the use of these features and set limits on their use.  An endpoint MAY treat activity that is suspicious as a ConnectionErrorHandler of type </ins> ENHANCE_YOUR_CALM. 10.5.1.

Related discussion:
text: After carefully reviewing the Netflix advisories, it was clear that the problem was that implementations didn't read the original text. The TCP window reduction attack in CVE-2019-9517 was not mentioned, and it is a clever exploit. The rest were clearly already documented. I took the opportunity to restructure things a little bit. The first few CVEs were about causing the victim to enqueue a bunch of frames and then exploit the fact that this queuing was badly inefficient. Those got a list of their own. I purposefully left CVE-2019-9516 out. Though I am sad that people didn't free() after malloc(), this is pretty much just a systematized memory leak and I don't feel like calling that out in an RFC. I've cited the disclosure page, so I think we're covered there anyway.
The spec includes language on this, but it turned out that many implementations failed to properly safeguard themselves. Clearer descriptions of problems based on this experience would be good.
I don’t think it hurts to tighten the text up here and add more examples, at least so new implementations are better able to learn from past mistakes. However, we should probably keep in mind that this cannot possibly be an exhaustive list of exhaustion attacks.
This is the Netflix write-up, which might be a good reference: URL I can only imagine citing a markdown file on GitHub will raise eyebrows, but it's not a bad summary of issues.
One minor suggestion, otherwise I’m happy with the new text.