Change:
MUST return a 405 Method Not Allowed response for any HTTP PATCH request. <ins> As the HTTP PATCH request sent by a WHIP client may be received out of order by the WHIP resource, the WHIP resource MUST generate a unique strong entity-tag identifying the ICE session as per RFC7232 section 2.3.  The initial value of the entity-tag identifying the initial ICE session MUST be returned in an ETag header in the 201 response to the initial POST request to the WHIP endpoint and in the 200 OK of a PATCH request that triggers an ICE restart. A WHIP client sending a PATCH request for performing trickle ICE MUST contain an If-Match header with the latest known entity-tag as per RFC7232 section 3.1.  When the PATCH request is received by the WHIP resource, it MUST compare the entity-tag value requested with the current entinty-tag of the resource as per RFC7232 section 3.1 and return a 412 Precondition Failed response if they do not match. Entity-tag validation MUST only be used for HTTP requests requiring to match a known ICE session and SHOULD NOT be used otherwise, for example in the HTTP DELETE request to terminate the session. </ins> A WHIP resource receiving a PATCH request with new ICE candidates, but which does not perform an ICE restart, MUST return a 204 No <del> content response without body. </del> <ins> content response without body.  If the media server does not support a candidate transport or is not able to resolve the connection address it MUST accept the HTTP request with the 204 response and silently discard the candidate. A WHIP client sending a PATCH request for performing ICE restart MUST contain an If-Match header with a field-value "*" as per RFC7232 section 3.1. </ins> If the HTTP PATCH request results in an ICE restart, the WHIP resource SHALL return a 200 OK with an "application/trickle-ice- sdpfrag" body containing the new ICE username fragment and password <del> and, optionally, the new set of ICE candidates for the media server. As the HTTP PATCH request sent by a WHIP client may be received out of order by the WHIP resource, the WHIP resource SHOULD keep track of the previous values of the ICE username fragment and client used by the WHIP client.  If an HTTP PATCH request is received with a previously used ICE username fragment and password by the client, the WHIP endpoint SHALL NOT perform and ICE restart but reject the request with a 409 Conflict response instead. </del> <ins> and, optionally, the new set of ICE candidates for the media server and the new entity-tag correspond to the new ICE session in an ETag response header. If the ICE request can not be performed by the WHIP resource it MUST return an appropriate HTTP error code but MUST NOT terminate the session immediately.  The WHIP client COULD try again to perform a new ICE restart or terminate the session issuing a HTTP DELETE request instead.  In any case the session MUST be terminated if the ICE consent expires as a consequence of the failed ICE restart. Given that in order to send new ICE candidates to the WHIP resource, the WHIP client needs to know the entity-tag associated to the ICE session, it MUST buffer any gathered candidates before the HTTP response to the initial PUT request or the PATCH request with the new entity-tag value is received.  Once the entity-tag value is known the WHIP client SHOULD send a single aggregated HTTP PATCH request with all the ICE candidates it has buffered so far. </ins> 4.2.

Discussion:
As per
thank you NAME added new changes per your feedback
PATCH request may be received out of order, how do we handle that? ICE candidate, ICE restart reversed order: ICE candidate with old ufrag should be discarded ICE restart, ICE candidate reversed order: Should ICE candidate trigger ICE restart anyway? Agreed solution: use Etag for requests/responses