Original text:
or MAY take no action. When a server sends CANCEL_PUSH, it is indicating that it will not be <del> fulfilling a promise and has not created a push stream.  The client should not expect the corresponding promise to be fulfilled. </del>  Sending CANCEL_PUSH has no direct effect on the state of existing <del> 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.  If a push stream arrives after a client has sent CANCEL_PUSH, this MAY be treated as a stream error of type H3_STREAM_CREATION_ERROR. </del>  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

Reviewer comments:
by reversing the polarity of a SHOULD. Doesn't break interop, but it's always safer to send CANCEL_PUSH than to omit it, so let's not recommend omitting it under any circumstances.
The spec suggest that a server should send a CANCELPUSH to notify a client that it will not fulfill a PUSHPROMISE. The server should send CANCELPUSH before a push stream has been open. The server still can cancel a push stream after it has been created and that will have a similar effect as a CANCELPUSH frame. There is a small problem with that. If the server resets a push stream before client starts reading, the client may have not read the pushid from the stream and that pushid will never be fulfill or cancel for the client point of view. Should there be a sentence in the spec explaining this? Probably suggesting not to cancel a push stream until server is certain that client has read it, which is difficult. Should the spec suggest ot send CANCEL_PUSH even after a push stream has been created?
The server doesn't need to ensure that the push ID is read if CANCELPUSH is used, mostly. If the stream type is read, but not the push ID (which is entirely possible), then the client will know that there was a push and that it didn't happen, but can't connect that with the promise or cancellation. In that case, clients need to handle that. In fact, this highlights the value of CANCELPUSH in the case where the stream is reset.
This will not break interop either way. We can change the recommendation easily.
This issue and its fix has been pretty well discussed already. The proposal is borderline on a design change, so I've marked this as design to get some visibility during the next consensus call.
lgtm

Revised text:
or MAY take no action. When a server sends CANCEL_PUSH, it is indicating that it will not be  <ins> fulfilling a promise.  The client cannot expect the corresponding promise to be fulfilled, unless it has already received and processed the promised response.  A server SHOULD send a CANCEL_PUSH even if it has opened the corresponding stream. </ins> Sending CANCEL_PUSH has no direct effect on the state of existing  <ins> push streams.  A client SHOULD NOT send a CANCEL_PUSH when it has already received a corresponding push stream.  A push stream could arrive after a client has sent CANCEL_PUSH, because a server might not have processed the CANCEL_PUSH.  The client SHOULD abort reading the stream with an error code of H3_REQUEST_CANCELLED. </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