Original text:
Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after sending a GOAWAY frame. <del> Once GOAWAY is sent, the server MUST reject requests sent on streams with an identifier greater than or equal to the indicated last Stream ID.  Clients MUST NOT send new requests on the connection after receiving GOAWAY, although requests might already be in transit.  A new connection can be established for new requests. If the client has sent requests on streams with a Stream ID greater than or equal to that indicated in the GOAWAY frame, those requests are considered rejected (request-cancellation).  Clients SHOULD cancel any requests on streams above this ID.  Servers MAY also reject requests on streams below the indicated ID if these requests were not processed. </del>  Requests on Stream IDs less than the Stream ID in the GOAWAY frame <del> might have been processed; their status cannot be known until they are completed successfully, reset individually, or the connection terminates. </del>  Servers SHOULD send a GOAWAY frame when the closing of a connection is known in advance, even if the advance notice is small, so that the

Reviewer comments:
Another attempt to group related concepts in this section which hopefully (This is technically design, because previously-required server behavior is now only recommended.)
Why do I have to explicitly cancel after GOAWAY? Given that GOAWAY already tells the client this, what's the point?
GOAWAY tells the client that those requests aren't going to be serviced, but the streams will continue to exist. If the cleanup period is significant, having the streams open is a bad idea. However, attaching SHOULD to this is unnecessary, I think that we might instead just note that clients are free to do as they please with streams that won't be answered.
Discussed in Tokyo; this doesn't need to be required server behavior, but recommended (or RECOMMENDED) as a method to clean up state. Should have a reminder cross-reference to request rejection.
Lgtm now

Revised text:
Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after sending a GOAWAY frame.  <ins> Clients MUST NOT send new requests on the connection after receiving GOAWAY; a new connection MAY be established to send additional requests. Some requests might already be in transit.  If the client has already sent requests on streams with a Stream ID greater than or equal to that indicated in the GOAWAY frame, those requests will not be processed and MAY be retried by the client on a different connection. The client MAY cancel these requests.  It is RECOMMENDED that the server explicitly reject such requests (see request-cancellation) in order to clean up transport state for the affected streams. </ins> Requests on Stream IDs less than the Stream ID in the GOAWAY frame  <ins> might have been processed; their status cannot be known until a response is received, the stream is reset individually, or the connection terminates.  Servers MAY reject individual requests on streams below the indicated ID if these requests were not processed. </ins> Servers SHOULD send a GOAWAY frame when the closing of a connection is known in advance, even if the advance notice is small, so that the