Original text:
"ECHConfigContents.cipher_suites" list. The HPKE encapsulated key, used by servers to decrypt the <del> corresponding "payload" field.  This field is empty in ClientHelloOuters sent in response to HelloRetryRequest. </del>  The serialized and encrypted ClientHelloInner structure, encrypted using HPKE as described in real-ech. Next, the client determines the length L of encrypting EncodedClientHelloInner with the selected HPKE AEAD.  This is typically the sum of the plaintext length and the AEAD tag length. <del> The client fills in a "encrypted_client_hello" extension with the outer variant of ClientECH with following values: </del>  "config_id", the identifier corresponding to the chosen ECHConfig structure; generates a random PSK identity with the same length.  It also generates a random, 32-bit, unsigned integer to use as the "obfuscated_ticket_age".  Likewise, for each inner PSK binder, the <del> client generates random string of the same length. </del>  <del> If the server replies with a "pre_shared_key" extension in its </del>  ServerHello, then the client MUST abort the handshake with an "illegal_parameter" alert. a "decode_error" alert if it is invalid.  It otherwise ignores the extension and MUST NOT use the retry keys. <del> [[OPEN ISSUE: if the client sends a GREASE "encrypted_client_hello" extension, should it also send a GREASE "pre_shared_key" extension? If not, GREASE+ticket is a trivial distinguisher.  See issue #384.]] </del> Offering a GREASE extension is not considered offering an encrypted ClientHello for purposes of requirements in client-behavior.  In particular, the client MAY offer to resume sessions established

Reviewer comments:
Just some minor nits I picked up during a slow pass of the spec.
LGTM pending one nit.

Revised text:
"ECHConfigContents.cipher_suites" list. The HPKE encapsulated key, used by servers to decrypt the  <ins> corresponding "payload" field.  This field is empty in a ClientHelloOuter sent in response to HelloRetryRequest. </ins> The serialized and encrypted ClientHelloInner structure, encrypted using HPKE as described in real-ech. Next, the client determines the length L of encrypting EncodedClientHelloInner with the selected HPKE AEAD.  This is typically the sum of the plaintext length and the AEAD tag length.  <ins> The client fills in an "encrypted_client_hello" extension with the outer variant of ClientECH with the following values: </ins> "config_id", the identifier corresponding to the chosen ECHConfig structure; generates a random PSK identity with the same length.  It also generates a random, 32-bit, unsigned integer to use as the "obfuscated_ticket_age".  Likewise, for each inner PSK binder, the  <ins> client generates a random string of the same length. </ins>  <ins> Per the rules of real-ech, the server is not permitted to resume a connection in the outer handshake.  If ECH is rejected and the client-facing server replies with a "pre_shared_key" extension in its </ins> ServerHello, then the client MUST abort the handshake with an "illegal_parameter" alert. a "decode_error" alert if it is invalid.  It otherwise ignores the extension and MUST NOT use the retry keys.  Offering a GREASE extension is not considered offering an encrypted ClientHello for purposes of requirements in client-behavior.  In particular, the client MAY offer to resume sessions established