Original text:
Upon receipt of a GOAWAY frame, if the client has already sent requests with a Stream ID greater than or equal to the identifier <del> received in a GOAWAY frame, those requests will not be processed. Clients can safely retry unprocessed requests on a different connection.  A client that is unable to retry requests loses all requests that are in flight when the server closes the connection. </del>  Requests on Stream IDs less than the Stream ID in a GOAWAY frame from the server might have been processed; their status cannot be indicated ID if these requests were not processed. If a server receives a GOAWAY frame after having promised pushes <del> with a Push ID greater than or equal to the identifier received in a GOAWAY frame, those pushes will not be accepted. </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:
Ambiguous description with for user agents in : It'd be better to remove or clarify rather than ambiguously allowing user agents with . A bit misleading expression with in This sentence looks to readers like that clients MAY send same requests on another connection even when the server keeps canceling or something regardless of clients' requests. There should be additional sentences no matter if it's the expected behavior or not. Some phrases in look verbose and confusingThe link in is wrong: should be replaced with .
These are separate issues, so let's look at them separately: This is deliberately vague, and the reason is explicitly stated. They don't affect the operation of the protocol, but user agents are allowed to make use of the associations in implementation-specific ways. This reflects HTTP/2, where some browsers use the association and some do not. Here again, I'm not seeing the problem. The requests have been canceled -- effectively "unsent" on this connection. If the client still needs to make those requests, they can't send them on this connection, but they MAY open a new connection. "received in a" -> "contained in the" would help here, unless you had a suggestion for making it tighter. The final issue is unrelated to these drafts, and is something the Tools server does. If you see an incorrect reference in the text draft or Editor's Copy HTML, please do point them out.

Revised text:
Upon receipt of a GOAWAY frame, if the client has already sent requests with a Stream ID greater than or equal to the identifier  <ins> contained in the GOAWAY frame, those requests will not be processed.  Clients can safely retry unprocessed requests on a different connection.  A client that is unable to retry requests loses all requests that are in flight when the server closes the connection. </ins> Requests on Stream IDs less than the Stream ID in a GOAWAY frame from the server might have been processed; their status cannot be indicated ID if these requests were not processed. If a server receives a GOAWAY frame after having promised pushes  <ins> with a Push ID greater than or equal to the identifier contained in the GOAWAY frame, those pushes will not be accepted. </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