Change:
…eliminate redundancies Avoid restatement by relying on the itemization of conditions that constitute ECH rejection given in 6.1.4. The prior text described aborting the connection with an alert, then processing retryconfigs, which processing could then lead to additional instructions to abort the (aborted) connection with an alert (and possibly a different alert than at first). Remove the use of the "illegalparameter" alert in the case of "if the field contains any other value", which apparently referred to the retryconfig version fields. First, this conflicts with the requirement that the connection be aborted with echrequired. Second, it's not clear what "any other value" is supposed to mean as this determination follows determining whether the members of the set of values are either "supported" or "unsupported". Perhaps it meant a value not considered valid as of the specification version the client was implemented according to? Certainly, in the case where there is at least one supported version found but also at least one such invalid value, it would not be desriable to use an illegalparameter alert, as this situation will naturally arise when servers deploying a new ECH version alongside an existing one serve clients that have not yet been upgraded. It's also unclear what value client discrimination of unsupported-recognized-as-valid from unsupported-not-recognized-as-valid provides. Linearize the presentation.Fix the reference to the obsolete "echretry_request". (See also tlswg/draft-ietf-tls-esni).

Discussion:
authenticating for ECHConfig.contents.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 <del> use the retry configurations. Otherwise, if both authentication and the handshake complete successfully, the client MUST abort the connection with an "ech_required" alert.  It then processes the "retry_configs" field from the server's "encrypted_client_hello" extension. If at least one of the values contains a version supported by the client, it can regard the ECH keys as securely replaced by the server.  It SHOULD retry the handshake with a new transport connection, using the retry configurations supplied by the server. The retry configurations may only be applied to the retry connection. The client MUST NOT use retry configurations for connections beyond the retry.  This avoids introducing pinning concerns or a tracking vector, should a malicious server present client-specific retry configurations in order to identify the client in a subsequent ECH handshake. </del> <ins> use the retry configurations.  It MUST NOT treat this as a secure signal to disable ECH. If the server supplied an "encrypted_client_hello" extension in its EncryptedExtensions message, the client MUST check that it is syntactically valid and the client MUST abort the connection with a "decode_error" alert otherwise.  If an earlier TLS version was negotiated, the client MUST NOT enable the False Start optimization RFC7918 for this handshake.  If both authentication and the handshake complete successfully, the client MUST perform the processing described below then abort the connection with an "ech_required" alert before sending any application data to the server. If the server provided "retry_configs" and if at least one of the values contains a version supported by the client, the client can regard the ECH keys as securely replaced by the server.  It SHOULD retry the handshake with a new transport connection, using the retry configurations supplied by the server.  The retry configurations may only be applied to the retry connection.  The client MUST NOT use retry configurations for connections beyond the retry.  This avoids introducing pinning concerns or a tracking vector, should a malicious server present client-specific retry configurations in order to identify the client in a subsequent ECH handshake. </ins> If none of the values provided in "retry_configs" contains a <del> supported version, the client can regard ECH as securely disabled by the server.  As below, it SHOULD then retry the handshake with a new transport connection and ECH disabled. If the field contains any other value, the client MUST abort the connection with an "illegal_parameter" alert. If the server negotiates an earlier version of TLS, or if it does not provide an "encrypted_client_hello" extension in EncryptedExtensions, the client proceeds with the handshake, authenticating for ECHConfig.contents.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 ECH. Otherwise, when the handshake completes successfully with the public name authenticated, the client MUST abort the connection with an "ech_required" alert.  The client can then regard ECH as securely disabled by the server.  It SHOULD retry the handshake with a new transport connection and ECH disabled. Clients SHOULD implement a limit on retries caused by "ech_retry_request" or servers which do not acknowledge the </del> <ins> supported version, or an earlier TLS version was negotiated, the client can regard ECH as securely disabled by the server, and it SHOULD retry the handshake with a new transport connection and ECH disabled. Clients SHOULD implement a limit on retries caused by receipt of "retry_configs" or servers which do not acknowledge the </ins> "encrypted_client_hello" extension.  If the client does not retry in either scenario, it MUST report an error to the calling application.