Original text:
If the value is "esni_accept", the client MUST check that the extension's "nonce" field matches ClientESNIInner.nonce and otherwise abort the connection with an "illegal_parameter" alert. <del> The client then proceeds with the connection as usual, verifying the certificate against the desired name. </del>  If the value is "esni_retry_request", the client proceeds with the <del> handshake, verifying the certificate against ESNIKeys.public_name as described in verify-public-name.  If verification or the handshake fails, the client MUST return a failure to the calling application.  It MUST NOT use the retry keys. </del>  Otherwise, when the handshake completes successfully with the <del> public name verified, the client MUST abort the connection with an "esni_required" alert.  It then processes the "retry_keys" field from the server's "encrypted_server_name" extension. </del>  If one of the values contains a version supported by the client, it can regard the ESNI keys as securely replaced by the server. If the server negotiates an earlier version of TLS, or if it does not provide an "encrypted_server_name" extension in EncryptedExtensions, <del> the client proceeds with the handshake, verifying the certificate against ESNIKeys.public_name as described in verify-public-name.  The client MUST NOT enable the False Start optimization RFC7918 for this handshake.  If verification or the handshake fails, the client MUST return a failure to the calling application.  It MUST NOT treat this as a secure signal to disable ESNI. </del>  Otherwise, when the handshake completes successfully with the public <del> name verified, the client MUST abort the connection with an </del>  "esni_required" alert.  The client can then regard ESNI as securely disabled by the server.  It SHOULD retry the handshake with a new transport connection and ESNI disabled. When the server cannot decrypt or does not process the "encrypted_server_name" extension, it continues with the handshake using the cleartext "server_name" extension instead (see server- <del> behavior).  Clients that offer ESNI then verify the certificate with the public name, as follows: </del>  If the server resumed a session or negotiated a session that did not use a certificate for authentication, the client MUST abort respond with an empty Certificate message, denoting no client certificate. <del> Note that verifying a connection for the public name does not verify it for the origin.  The TLS implementation MUST NOT report such connections as successful to the application.  It additionally MUST ignore all session tickets and session IDs presented by the server. These connections are only used to trigger retries, as described in handle-server-response.  This may be implemented, for instance, by reporting a failed connection with a dedicated error code. </del>  5.2. associated with the ESNI name.  The server was unable to decrypt then ESNI name, so it should not resume them when using the cleartext SNI name.  This restriction allows a client to reject <del> resumptions in verify-public-name. </del>  If the ClientEncryptedSNI.record_digest value does match the cryptographic hash of a known ESNIKeys, the server performs the If the server sends a NewSessionTicket message, the corresponding ESNI PSK MUST be ignored by all other servers in the deployment when not negotiating ESNI, including servers which do not implement this <del> specification.  This may be implemented by adding a new field to the server session state which earlier implementations cannot parse. </del>  This restriction provides robustness for rollbacks (see misconfiguration). ESNI keys, or if a deployment of ESNI must be rolled back on the server. <del> The retry mechanism repairs most such inconsistencies.  If server and advertised keys mismatch, the server will respond with esni_retry_requested.  If the server does not understand the "encrypted_server_name" extension at all, it will ignore it as required by RFC8446; Section 4.1.2.  Provided the server can present a certificate valid for the public name, the client can safely retry with updated settings, as described in handle-server-response. </del>  Unless ESNI is disabled as a result of successfully establishing a connection to the public name, the client MUST NOT fall back to if all Web browsers start using ESNI, the presence of this value does not signal suspicious behavior to passive eavesdroppers.  7.2.5. This design is not forward secret because the server's ESNI key is

Reviewer comments:
(WG email coming shortly.) Update: This has been rebased to master, now that is merged. The new server behavior ("Improve ESNI robustness") means clients can send GREASE ESNI extensions without interop issues. Write some text recommending this, better meeting the "Do not stick out" criteria.
The GREASE section seems fine to me. (NAME is there other new material in this PR?) NAME NAME please have a look when possible.
It's whatever's in the second commit, so mostly that section but also a bit elsewhere: URL
I share the view that the GREASE section looks fine.
NAME Did you mean to leave the comments on URL (Notably the text already has seen a number of revisions here. I haven't gone back to update this PR yet. This PR was meant to just be the second commit.)
Ugh. Having something which claims to be a merged PR is kind of an attractive nusiance, then, no? Perhaps you can apply the changes here?
In my defense, I split them at your request and did include the following. ;-) But, sure, I can rebase this one. I figured was the bulk of the interesting bits (7401f55013f68ec47dad36b99977ad6aa881d9f1 is much smaller) so I figured we'd first and then I'd update this one at the end.
Sure, and I read that as "this is an accurate reflection of my put for both of these". But, sure, I can rebase this one. I figured Thanks.
Well, it was when I wrote that sentence. :-) Anyway, it's now been rebased and I've incorporated your comments as well.

Revised text:
If the value is "esni_accept", the client MUST check that the extension's "nonce" field matches ClientESNIInner.nonce and otherwise abort the connection with an "illegal_parameter" alert.  <ins> The client then proceeds with the connection as usual, authenticating the connection for the origin server. </ins> If the value is "esni_retry_request", the client proceeds with the  <ins> handshake, authenticating for ESNIKeys.public_name as described in auth-public-name.  If authentication or the handshake fails, the client MUST return a failure to the calling application.  It MUST NOT use the retry keys. </ins> Otherwise, when the handshake completes successfully with the  <ins> public name authenticated, the client MUST abort the connection with an "esni_required" alert.  It then processes the "retry_keys" field from the server's "encrypted_server_name" extension. </ins> If one of the values contains a version supported by the client, it can regard the ESNI keys as securely replaced by the server. If the server negotiates an earlier version of TLS, or if it does not provide an "encrypted_server_name" extension in EncryptedExtensions,  <ins> the client proceeds with the handshake, authenticating for ESNIKeys.public_name as described in auth-public-name.  If an earlier version was negotiated, the client MUST NOT enable the False Start optimization RFC7918 for this handshake.  If authentication or the handshake fails, the client MUST return a failure to the calling application.  It MUST NOT treat this as a secure signal to disable ESNI. </ins> Otherwise, when the handshake completes successfully with the public  <ins> name authenticated, the client MUST abort the connection with an </ins> "esni_required" alert.  The client can then regard ESNI as securely disabled by the server.  It SHOULD retry the handshake with a new transport connection and ESNI disabled. When the server cannot decrypt or does not process the "encrypted_server_name" extension, it continues with the handshake using the cleartext "server_name" extension instead (see server-  <ins> behavior).  Clients that offer ESNI then authenticate the connection with the public name, as follows: </ins> If the server resumed a session or negotiated a session that did not use a certificate for authentication, the client MUST abort respond with an empty Certificate message, denoting no client certificate.  <ins> Note that authenticating a connection for the public name does not authenticate it for the origin.  The TLS implementation MUST NOT report such connections as successful to the application.  It additionally MUST ignore all session tickets and session IDs presented by the server.  These connections are only used to trigger retries, as described in handle-server-response.  This may be implemented, for instance, by reporting a failed connection with a dedicated error code. 5.1.4. If the client attempts to connect to a server and does not have an ESNIKeys structure available for the server, it SHOULD send a GREASE I-D.ietf-tls-grease "encrypted_server_name" extension as follows: Select a supported cipher suite, named group, and padded_length value.  The padded_length value SHOULD be 260.  Set the "suite" field to the selected cipher suite. Set the "key_share" field to a randomly-generated valid public key for the named group. Set the "record_digest" field to a randomly-generated string of hash_length bytes, where hash_length is the length of the hash function associated with the chosen cipher suite. Set the "encrypted_sni" field to a randomly-generated string of 16 + padded_length + tag_length bytes, where tag_length is the tag length of the chosen cipher suite's associated AEAD. If the server sends an "encrypted_server_name" extension, the client MUST check the extension syntactically and abort the connection with a "decode_error" alert if it is invalid.  If the "response_type" field contains "esni_retry_requested", the client MUST ignore the extension and proceed with the handshake.  If it contains "esni_accept" or any other value, the client MUST abort the connection with an "illegal_parameter" alert. Offering a GREASE extension is not considered offering an encrypted SNI for purposes of requirements in client-behavior.  In particular, the client MAY offer to resume sessions established without ESNI. </ins> 5.2. associated with the ESNI name.  The server was unable to decrypt then ESNI name, so it should not resume them when using the cleartext SNI name.  This restriction allows a client to reject  <ins> resumptions in auth-public-name. Note that an unrecognized ClientEncryptedSNI.record_digest value may be a GREASE ESNI extension (see grease-extensions), so it is necessary for servers to proceed with the connection and rely on the client to abort if ESNI was required.  In particular, the unrecognized value alone does not indicate a misconfigured ESNI advertisement (misconfiguration).  Instead, servers can measure occurrences of the "esni_required" alert to detect this case. </ins> If the ClientEncryptedSNI.record_digest value does match the cryptographic hash of a known ESNIKeys, the server performs the If the server sends a NewSessionTicket message, the corresponding ESNI PSK MUST be ignored by all other servers in the deployment when not negotiating ESNI, including servers which do not implement this  <ins> specification. </ins> This restriction provides robustness for rollbacks (see misconfiguration). ESNI keys, or if a deployment of ESNI must be rolled back on the server.  <ins> The retry mechanism repairs inconsistencies, provided the server is authoritative for the public name.  If server and advertised keys mismatch, the server will respond with esni_retry_requested.  If the server does not understand the "encrypted_server_name" extension at all, it will ignore it as required by RFC8446; Section 4.1.2. Provided the server can present a certificate valid for the public name, the client can safely retry with updated settings, as described in handle-server-response. </ins> Unless ESNI is disabled as a result of successfully establishing a connection to the public name, the client MUST NOT fall back to if all Web browsers start using ESNI, the presence of this value does not signal suspicious behavior to passive eavesdroppers. <ins> Additionally, this specification allows for clients to send GREASE ESNI extensions (see grease-extensions), which helps ensure the ecosystem handles the values correctly. </ins> 7.2.5. This design is not forward secret because the server's ESNI key is