Change:
3. <del> This document is designed to operate in one of two primary topologies shown below, which we call "Shared Mode" and "Split Mode" </del> <ins> This protocol is designed to operate in one of two topologies illustrated below, which we call "Shared Mode" and "Split Mode". </ins> 3.1. In Shared Mode, the provider is the origin server for all the domains <del> whose DNS records point to it and clients form a TLS connection directly to that provider, which has access to the plaintext of the connection. </del> <ins> whose DNS records point to it.  In this mode, the TLS connection is terminated by the provider. </ins> <del> In Split Mode, the provider is _not_ the origin server for private domains.  Rather the DNS records for private domains point to the </del> <ins> In Split Mode, the provider is not the origin server for private domains.  Rather, the DNS records for private domains point to the </ins> provider, and the provider's server relays the connection back to the <del> backend server, which is the true origin server.  The provider does not have access to the plaintext of the connection. </del> <ins> origin server, who terminates the TLS connection with the client. Importantly, service provider does not have access to the plaintext of the connection. In the remainder of this document, we will refer to the ECH-service provider as the "client-facing server" and to the TLS terminator as the "backend server".  These are the same entity in Shared Mode, but in Split Mode, the client-facing and backend servers are physically separated. </ins> 3.2. <del> ECH works by encrypting the entire ClientHello, including the SNI and any additional extensions such as ALPN.  This requires that each provider publish a public key and metadata which is used for ClientHello encryption for all the domains for which it serves directly or indirectly (via Split Mode).  This document defines the format of the SNI encryption public key and metadata, referred to as an ECH configuration, and delegates DNS publication details to HTTPS- RR, though other delivery mechanisms are possible.  In particular, if some of the clients of a private server are applications rather than Web browsers, those applications might have the public key and metadata preconfigured. When a client wants to form a TLS connection to any of the domains served by an ECH-supporting provider, it constructs a ClientHello in the regular fashion containing the true SNI value (ClientHelloInner) and then encrypts it using the public key for the provider.  It then constructs a new ClientHello (ClientHelloOuter) with an innocuous SNI (and potentially innocuous versions of other extensions such as ALPN RFC7301) and containing the encrypted ClientHelloInner as an extension.  It sends ClientHelloOuter to the server. Upon receiving ClientHelloOuter, the server can then decrypt ClientHelloInner and either terminate the connection (in Shared Mode) or forward it to the backend server (in Split Mode). Note that both ClientHelloInner and ClientHelloOuter are both valid, complete ClientHello messages.  ClientHelloOuter carries an encrypted representation of ClientHelloInner in a "encrypted_client_hello" extension, defined in encrypted-client-hello. </del> <ins> ECH allows the client to encrypt sensitive ClientHello extensions, e.g., SNI, ALPN, etc., under the public key of the client-facing server.  This requires the client-facing server to publish the public key and metadata it uses for ECH for all the domains for which it serves directly or indirectly (via Split Mode).  This document defines the format of the ECH encryption public key and metadata, referred to as an ECH configuration, and delegates DNS publication details to HTTPS-RR, though other delivery mechanisms are possible. In particular, if some of the clients of a private server are applications rather than Web browsers, those applications might have the public key and metadata preconfigured. When a client wants to establish a TLS session with the backend server, it constructs its ClientHello as usual (we will refer to this as the ClientHelloInner message) and then encrypts this message using the ECH public key.  It then constructs a new ClientHello (ClientHelloOuter) with innocuous values for sensitive extensions, e.g., SNI, ALPN, etc., and with the encrypted ClientHelloInner in an "encrypted_client_hello" extension, which this document defines (encrypted-client-hello).  Finally, it sends ClientHelloOuter to the server. Upon receiving ClientHelloOuter, the client-facing server processes the encrypted ClientHelloInner and either terminates the connection (in Shared Mode) or forwards it to the backend server (in Split Mode). </ins> 4.

Discussion:
Use the term "plaintext" consistently. Be consistent about the number of spaces following a period. (We'll go with one.) Editorial changes to Sec.1-3.