Original text:
HelloRetryRequest processing apply. Clients bind encryption of the second ClientHelloInner to encryption <del> of the first ClientHelloInner via the derived ech_hrr_key by modifying HPKE setup as follows: </del>  The "info" parameter to SetupPSKS is the concatenation of "tls ech", <del> a zero byte, and the serialized ECHConfig.  Clients then encrypt the second ClientHelloInner using this new HPKE context.  In doing so, the encrypted value is also authenticated by ech_hrr_key.  The rationale for this is described in flow-hrr-hijack. Client-facing servers perform the corresponding process when decrypting second ClientHelloInner messages.  In particular, upon receipt of a second ClientHello message with a ClientECH value, servers set up their HPKE context and decrypt ClientECH as follows: ClientHelloOuterAAD is computed from the second ClientHelloOuter as described in authenticating-outer.  The "info" parameter to SetupPSKR is computed as above. </del>  If the client offered ECH in the first ClientHello, then it MUST offer ECH in the second.  Likewise, if the client did not offer ECH aborts the connection with a "decrypt_error" alert rather than continuing the handshake with the second ClientHelloOuter.  [[OPEN ISSUE: If the client-facing server implements stateless HRR, it has no way to send a cookie, short of as-yet-unspecified integration with the backend server.  Stateful HRR on the client-

Reviewer comments:
Now that we have separate client HRR and server HRR sections, move some server text to the server section. Also clarify that the second ClientHelloOuterAAD is computed from the second ClientHelloOuter, not reusing the first value. (Some cleanup in advance of writing up the HPKE context reuse version.)
Can we merge this? The number of PRs is getting confusing. NAME

Revised text:
HelloRetryRequest processing apply. Clients bind encryption of the second ClientHelloInner to encryption  <ins> of the first ClientHelloInner via the derived ech_hrr_key by running a modified encryption process: </ins> The "info" parameter to SetupPSKS is the concatenation of "tls ech",  <ins> a zero byte, and the serialized ECHConfig.  ClientHelloOuterAAD is computed from the second ClientHelloOuter as described in authenticating-outer.  Note the encrypted value is also authenticated by ech_hrr_key.  The rationale for this is described in flow-hrr- hijack. </ins> If the client offered ECH in the first ClientHello, then it MUST offer ECH in the second.  Likewise, if the client did not offer ECH aborts the connection with a "decrypt_error" alert rather than continuing the handshake with the second ClientHelloOuter. <ins> When decrypting the second ClientECH.payload, the client-facing server performs a corresponding process to client-hrr: ClientHelloOuterAAD is computed from the second ClientHelloOuter as described in authenticating-outer.  The "info" parameter to SetupPSKR is the concatenation of "tls ech", a zero byte, and the serialized ECHConfig. </ins> [[OPEN ISSUE: If the client-facing server implements stateless HRR, it has no way to send a cookie, short of as-yet-unspecified integration with the backend server.  Stateful HRR on the client-