Draft: draft-ietf-tls-esni

Commentary: Tried to clarify some text , PTAL :) For the backend server , I think the notation is a little confusing ( pedantically , should n't it be ? ) . Ca n't we just concatenate the two messages and call it a day ? 
 Thanks !
Paragraph (version A):
The client-facing server advertises a sequence ECH configurations to
clients, serialized as follows.
Paragraph (version B):
The client-facing server advertises a sequence of ECH configurations
to clients, serialized as follows.
Paragraph (version A):
The cipher suite used to encrypt ClientHelloInner.  This MUST
match a value provided in the corresponding
"ECHConfig.cipher_suites" list.
Paragraph (version B):
The cipher suite used to encrypt ClientHelloInner.  This MUST
match a value provided in the corresponding
"ECHConfigContents.cipher_suites" list.
Paragraph (version A):
Some TLS 1.3 extensions can be quite large and having them both in
ClientHelloInner and ClientHelloOuter will lead to a very large
overall size.  One particularly pathological example is "key_share"
with post-quantum algorithms.  In order to reduce the impact of
duplicated extensions, the client may use the "ech_outer_extensions"
extension.
Paragraph (version B):
Some TLS 1.3 extensions can be quite large, thus repeating them in
the ClientHelloInner and ClientHelloOuter can lead to an excessive
overall size.  One pathological example is "key_share" with post-
quantum algorithms.  To reduce the impact of duplicated extensions,
the client may use the "ech_outer_extensions" extension.
Paragraph (version A):
To offer ECH, the client first chooses a suitable ECH configuration.
To determine if a given "ECHConfig" is suitable, it checks that it
supports the KEM algorithm identified by "ECHConfig.kem_id", at least
one KDF/AEAD algorithm identified by "ECHConfig.cipher_suites", and
the version of ECH indicated by "ECHConfig.version".  Once a suitable
configuration is found, the client selects the cipher suite it will
use for encryption.  It MUST NOT choose a cipher suite or version not
advertised by the configuration.  If no compatible configuration is
found, then the client SHOULD proceed as described in grease-ech.
Paragraph (version B):
To offer ECH, the client first chooses a suitable ECH configuration.
To determine if a given "ECHConfig" is suitable, it checks that it
supports the KEM algorithm identified by "ECHConfig.contents.kem_id",
at least one KDF/AEAD algorithm identified by
"ECHConfig.contents.cipher_suites", and the version of ECH indicated
by "ECHConfig.contents.version".  Once a suitable configuration is
found, the client selects the cipher suite it will use for
encryption.  It MUST NOT choose a cipher suite or version not
advertised by the configuration.  If no compatible configuration is
found, then the client SHOULD proceed as described in grease-ech.
Paragraph (version A):
The value of "ECHConfig.public_name" MUST be placed in the
"server_name" extension.
Paragraph (version B):
The value of "ECHConfig.contents.public_name" MUST be placed in
the "server_name" extension.
Paragraph (version A):
Note that the HPKE functions Deserialize and SetupBaseS are those
which match "ECHConfig.kem_id" and the AEAD/KDF used with "context"
are those which match the client's chosen preference from
"ECHConfig.cipher_suites".  The "info" parameter to SetupBaseS is the
concatenation of "tls ech", a zero byte, and the serialized
ECHConfig.
Paragraph (version B):
Note that the HPKE functions Deserialize and SetupBaseS are those
which match "ECHConfig.contents.kem_id" and the AEAD/KDF used with
"context" are those which match the client's chosen preference from
"ECHConfig.contents.cipher_suites".  The "info" parameter to
SetupBaseS is the concatenation of "tls ech", a zero byte, and the
serialized ECHConfig.
Paragraph (version A):
If L >= D, add L - D bytes of padding.  This rounds to the
server's advertised hint, i.e., ECHConfig.maximum_name_length.
Paragraph (version B):
If L >= D, add L - D bytes of padding.  This rounds to the
server's advertised hint, i.e.,
ECHConfig.contents.maximum_name_length.
Paragraph (version A):
If the server used ClientHelloOuter, the client proceeds with the
handshake, authenticating for ECHConfig.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.
Paragraph (version B):
If the server used ClientHelloOuter, the client proceeds with the
handshake, 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 use the retry keys.
Paragraph (version A):
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
ECHConfigContents.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.
Paragraph (version B):
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.
Paragraph (version A):
The client MUST verify that the certificate is valid for
ECHConfigContents.public_name.  If invalid, it MUST abort the
connection with the appropriate alert.
Paragraph (version B):
The client MUST verify that the certificate is valid for
ECHConfig.contents.public_name.  If invalid, it MUST abort the
connection with the appropriate alert.
Paragraph (version A):
where Derive-Secret and Handshake Secret are as specified in RFC8446,
Section 7.1, and ClientHelloInner..ServerHelloECHConf refers to the
sequence of handshake messages beginning with the first ClientHello
and ending with ServerHelloECHConf.  Finally, the backend server
constructs its ServerHello message so that it is equal to
ServerHelloECHConf but with the last 8 bytes of ServerHello.random
set to the first 8 bytes of accept_confirmation.
Paragraph (version B):
where Derive-Secret and Handshake Secret are as specified in RFC8446,
Section 7.1, and ClientHelloInner...ServerHelloECHConf refers to the
sequence of handshake messages beginning with the first ClientHello
and ending with ServerHelloECHConf.  Finally, the backend server
constructs its ServerHello message so that it is equal to
ServerHelloECHConf but with the last 8 bytes of ServerHello.random
set to the first 8 bytes of accept_confirmation.