Original text:
A "HpkeKeyConfig" structure carrying the configuration information associated with the HPKE public key.  Note that this structure contains the "config_id" field, which applies to the entire <del> ECHConfigContents.  Sites MUST NOT publish two differet"ECHConfigContents" values with the same "HpkeKeyConfig" value. </del>  The longest name of a backend server, if known.  If this value is not known it can be set to zero, in which case clients SHOULD use The "HpkeKeyConfig" structure contains the following fields: <del> An opaque identifier for the given HPKE key configuration.  This </del>  is used by clients to indicate the key used for ClientHello encryption. "payload", as computed above. If optional configuration identifiers (see optional-configs)) are <del> used, "config_id" SHOULD be set to a randomly generated eight bytes. Unless specified by the application using (D)TLS or externally configured on both sides, implementations MUST compute the field as specified in encrypted-client-hello. </del>  6.1.1. The client then modifies the "encrypted_client_hello" extension in ClientHelloOuter as follows: <del> "config_id" is replaced with the empty string. </del>  "cipher_suite" is unchanged and contains the client's chosen HPKE cipher suite. RFC8701 "encrypted_client_hello" extension in the first ClientHello as follows: <del> Set the "config_id" field to a random eight byte string. </del>  Set the "cipher_suite" field to a supported HpkeSymmetricCipherSuite.  The selection SHOULD vary to exercise ClientHelloOuter also contains the "encrypted_client_hello" extension.  If not, it MUST abort the handshake with a "missing_extension" alert.  Otherwise, it checks that <del> ClientECH.cipher_suite is unchanged, and that ClientECH.config_id and ClientECH.enc are empty.  If not, it MUST abort the handshake with an "illegal_parameter" alert. </del>  Finally, it decrypts the new ClientECH.payload as a second message with the previous HPKE context:

Reviewer comments:
accidentally targeted an older branch that was since merged into master. This just takes the same change and redirects it to the main branch.

Revised text:
A "HpkeKeyConfig" structure carrying the configuration information associated with the HPKE public key.  Note that this structure contains the "config_id" field, which applies to the entire  <ins> ECHConfigContents.  Sites MUST NOT publish two different "ECHConfigContents" values with the same "HpkeKeyConfig" value. The RECOMMENDED technique for choosing "config_id" is to choose a random byte.  This process is repeated if this config_id matches that of any valid ECHConfig, which could include any ECHConfig that has been recently removed from active use. </ins> The longest name of a backend server, if known.  If this value is not known it can be set to zero, in which case clients SHOULD use The "HpkeKeyConfig" structure contains the following fields:  <ins> A one-byte identifier for the given HPKE key configuration.  This </ins> is used by clients to indicate the key used for ClientHello encryption. "payload", as computed above. If optional configuration identifiers (see optional-configs)) are  <ins> used, "config_id" SHOULD be set to a randomly generated byte.  Unless specified by the application using (D)TLS or externally configured on both sides, implementations MUST set the field as specified in encrypted-client-hello. </ins> 6.1.1. The client then modifies the "encrypted_client_hello" extension in ClientHelloOuter as follows:  <ins> "config_id" is unchanged and contains the "config_id" corresponding to the client's chosen ECHConfig. </ins> "cipher_suite" is unchanged and contains the client's chosen HPKE cipher suite. RFC8701 "encrypted_client_hello" extension in the first ClientHello as follows:  <ins> Set the "config_id" field to a random byte. </ins> Set the "cipher_suite" field to a supported HpkeSymmetricCipherSuite.  The selection SHOULD vary to exercise ClientHelloOuter also contains the "encrypted_client_hello" extension.  If not, it MUST abort the handshake with a "missing_extension" alert.  Otherwise, it checks that  <ins> ClientECH.cipher_suite and ClientECH.config_id are unchanged, and that ClientECH.enc is empty.  If not, it MUST abort the handshake with an "illegal_parameter" alert. </ins> Finally, it decrypts the new ClientECH.payload as a second message with the previous HPKE context: