Original text:
existing registry for Alerts (defined in RFC8446), with the "DTLS-OK" column being set to "Y". <del> 8.3. IANA is requested to create an entry, ESNI(0xff9f), in the existing registry for Resource Record (RR) TYPEs (defined in RFC6895) with "Meaning" column value being set to "Encrypted SNI". </del> 

Reviewer comments:
Because this document now delegates the way the keys are advertised from the RRType ESNI to HTTPSSVC shouldn't the RRType Considerations be removed from this document.

Revised text:
existing registry for Alerts (defined in RFC8446), with the "DTLS-OK" column being set to "Y".  <ins> 9. When operating in Split Mode, backend servers will not have access to PaddedServerNameList.sni or ClientESNIInner.nonce without access to the ESNI keys or a way to decrypt ClientEncryptedSNI.encrypted_sni. One way to address this for a single connection, at the cost of having communication not be unmodified TLS 1.3, is as follows. Assume there is a shared (symmetric) key between the client-facing server and the backend server and use it to AEAD-encrypt Z and send the encrypted blob at the beginning of the connection before the ClientHello.  The backend server can then decrypt ESNI to recover the true SNI and nonce. 10. Alternative approaches to encrypted SNI may be implemented at the TLS or application layer.  In this section we describe several alternatives and discuss drawbacks in comparison to the design in this document. 10.1. 10.1.1. In this variant, TLS Client Hellos are tunneled within early data payloads belonging to outer TLS connections established with the client-facing server.  This requires clients to have established a previous session --- and obtained PSKs --- with the server.  The client-facing server decrypts early data payloads to uncover Client Hellos destined for the backend server, and forwards them onwards as necessary.  Afterwards, all records to and from backend servers are forwarded by the client-facing server - unmodified.  This avoids double encryption of TLS records. Problems with this approach are: (1) servers may not always be able to distinguish inner Client Hellos from legitimate application data, (2) nested 0-RTT data may not function correctly, (3) 0-RTT data may not be supported - especially under DoS - leading to availability concerns, and (4) clients must bootstrap tunnels (sessions), costing an additional round trip and potentially revealing the SNI during the initial connection.  In contrast, encrypted SNI protects the SNI in a distinct Client Hello extension and neither abuses early data nor requires a bootstrapping connection. 10.1.2. In this variant, client-facing and backend servers coordinate to produce "combined tickets" that are consumable by both.  Clients offer combined tickets to client-facing servers.  The latter parse them to determine the correct backend server to which the Client Hello should be forwarded.  This approach is problematic due to non- trivial coordination between client-facing and backend servers for ticket construction and consumption.  Moreover, it requires a bootstrapping step similar to that of the previous variant.  In contrast, encrypted SNI requires no such coordination. 10.2. 10.2.1. In this variant, clients request secondary certificates with CERTIFICATE_REQUEST HTTP/2 frames after TLS connection completion. In response, servers supply certificates via TLS exported authenticators I-D.ietf-tls-exported-authenticator in CERTIFICATE frames.  Clients use a generic SNI for the underlying client-facing server TLS connection.  Problems with this approach include: (1) one additional round trip before peer authentication, (2) non-trivial application-layer dependencies and interaction, and (3) obtaining the generic SNI to bootstrap the connection.  In contrast, encrypted SNI induces no additional round trip and operates below the application layer. 11. The design described here only provides encryption for the SNI, but not for other extensions, such as ALPN.  Another potential design would be to encrypt all of the extensions using the same basic structure as we use here for ESNI.  That design has the following advantages: It protects all the extensions from ordinary eavesdroppers If the encrypted block has its own KeyShare, it does not necessarily require the client to use a single KeyShare, because the client's share is bound to the SNI by the AEAD (analysis needed). It also has the following disadvantages: The client-facing server can still see the other extensions.  By contrast we could introduce another EncryptedExtensions block that was encrypted to the backend server and not the client-facing server. It requires a mechanism for the client-facing server to provide the extension-encryption key to the backend server (as in communicating-sni and thus cannot be used with an unmodified backend server. A conformant middlebox will strip every extension, which might result in a ClientHello which is just unacceptable to the server (more analysis needed). </ins>