Change:
Open to discussion about whether all of these are ID_ERROR or not.
I've tried to improve the readability of this section a bit; I turned Ian's suggested parallel paragraphs around to talk about why client and server would send the frame (and the corresponding responses) instead of talking about behavior on receipt. Please take a fresh look, NAME and NAME
I think there are some edge cases with the CANCELPUSH frame that we don't explain: reception of a CANCELPUSH frame with ID greater than the current push limit reception of CANCEL_PUSH with ID that has already been used
I'd also add a CANCELPUSH from the client for a PUSHID that has not been promised.
CANCEL_PUSH with a reused ID is probably indistinguishable from receiving one for a stream that's already open; you SHOULD reset the stream (which is a no-op if the stream is already full transferred).

Discussion:
frame identifies a server push by Push ID (see frame-push-promise), encoded as a variable-length integer. <del> When a server receives this frame, it aborts sending the response for the identified server push.  If the server has not yet started to send the server push, it can use the receipt of a CANCEL_PUSH frame to avoid opening a push stream.  If the push stream has been opened by the server, the server SHOULD abruptly terminate that stream. A server can send the CANCEL_PUSH frame to indicate that it will not be fulfilling a promise prior to creation of a push stream.  Once the push stream has been created, sending CANCEL_PUSH has no effect on the state of the push stream.  The server SHOULD abruptly terminate the push stream instead. </del> <ins> When a client sends CANCEL_PUSH, it is indicating that it does not wish to receive the promised resource.  The server SHOULD abort sending the resource, but the mechanism to do so depends on the state of the corresponding push stream.  If the server has not yet created a push stream, it does not create one.  If the push stream is open, the server SHOULD abruptly terminate that stream.  If the push stream has already ended, the server MAY still abruptly terminate the stream or MAY take no action. When a server sends CANCEL_PUSH, it is indicating that it will not be fulfilling a promise and has not created a push stream.  The client should not expect the corresponding promise to be fulfilled. Sending CANCEL_PUSH has no direct effect on the state of existing push streams.  A server SHOULD NOT send a CANCEL_PUSH when it has already created a corresponding push stream, and a client SHOULD NOT send a CANCEL_PUSH when it has already received a corresponding push stream. </ins> A CANCEL_PUSH frame is sent on the control stream.  Receiving a CANCEL_PUSH frame on a stream other than the control stream MUST be

The CANCEL_PUSH frame carries a Push ID encoded as a variable-length integer.  The Push ID identifies the server push that is being <del> cancelled (see frame-push-promise). </del> <ins> cancelled (see frame-push-promise).  If a CANCEL_PUSH frame is received which references a Push ID greater than currently allowed on the connection, this MUST be treated as a connection error of type HTTP_ID_ERROR. </ins> If the client receives a CANCEL_PUSH frame, that frame might identify <del> a Push ID that has not yet been mentioned by a PUSH_PROMISE frame. </del> <ins> a Push ID that has not yet been mentioned by a PUSH_PROMISE frame due to reordering.  If a server receives a CANCEL_PUSH frame for a Push ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST be treated as a connection error of type HTTP_ID_ERROR. </ins> 7.2.4.

The MAX_PUSH_ID frame (type=0xD) is used by clients to control the number of server pushes that the server can initiate.  This sets the <del> maximum value for a Push ID that the server can use in a PUSH_PROMISE frame.  Consequently, this also limits the number of push streams that the server can initiate in addition to the limit maintained by the QUIC transport. </del> <ins> maximum value for a Push ID that the server can use in PUSH_PROMISE and CANCEL_PUSH frames.  Consequently, this also limits the number of push streams that the server can initiate in addition to the limit maintained by the QUIC transport. </ins> The MAX_PUSH_ID frame is always sent on the control stream.  Receipt of a MAX_PUSH_ID frame on any other stream MUST be treated as a