diff --git a/draft-ietf-tls-esni.md b/draft-ietf-tls-esni.md
index d70b5b6b..97c06699 100644
--- a/draft-ietf-tls-esni.md
+++ b/draft-ietf-tls-esni.md
@@ -220,11 +220,16 @@ The ECH configuration is defined by the following `ECHConfig` structure.
         HpkeSymmetricCipherSuite cipher_suites<4..2^16-4>;
     } HpkeKeyConfig;
 
+    struct {
+        ECHConfigExtensionType ech_config_extension_type;
+        opaque extension_data<0..2^16-1>;
+    } ECHConfigExtension;
+
     struct {
         HpkeKeyConfig key_config;
         uint8 maximum_name_length;
         opaque public_name<1..255>;
-        Extension extensions<0..2^16-1>;
+        ECHConfigExtension extensions<0..2^16-1>;
     } ECHConfigContents;
 
     struct {
@@ -284,8 +289,8 @@ an IPv4 address.
 public_name.
 
 extensions
-: A list of extensions that the client must take into consideration when
-generating a ClientHello message. These are described below
+: A list of ECH configuration extensions that the client must take into
+consideration when generating a ClientHello message. These are described below
 ({{config-extensions}}).
 
 [[OPEN ISSUE: determine if clients should enforce a 63-octet label limit for
@@ -347,11 +352,14 @@ ECH configuration extensions are used to provide room for additional
 functionality as needed. See {{config-extensions-guidance}} for guidance on
 which types of extensions are appropriate for this structure.
 
-The format is as defined in {{RFC8446, Section 4.2}}.
-The same interpretation rules apply: extensions MAY appear in any order, but
-there MUST NOT be more than one extension of the same type in the extensions
-block. An extension can be tagged as mandatory by using an extension type
-codepoint with the high order bit set to 1.
+The format is as defined in {{ech-configuration}} and mirrors
+{{Section 4.2 of RFC8446}}. However, ECH configuration extension types are
+maintained by IANA as described in {{config-extensions-iana}}.
+ECH configuration extensions follow the same interpretation rules as TLS
+extensions: extensions MAY appear in any order, but there MUST NOT be more
+than one extension of the same type in the extensions block. An extension can
+be tagged as mandatory by using an extension type codepoint with the high
+order bit set to 1.
 
 Clients MUST parse the extension list and check for unsupported mandatory
 extensions. If an unsupported mandatory extension is present, clients MUST
@@ -1697,6 +1705,38 @@ IANA is requested to create an entry, ech_required(121) in the existing registry
 for Alerts (defined in {{!RFC8446}}), with the "DTLS-OK" column set to
 "Y".
 
+## ECH Configuration Extension Registry {#config-extensions-iana}
+
+IANA is requested to create a new "ECHConfig Extension" registry in a new
+"TLS Encrypted Client Hello (ECH) Configuration Extensions" page. New
+registrations need to list the following attributes:
+
+Value:
+: The two-byte identifier for the ECHConfigExtension, i.e., the
+ECHConfigExtensionType
+
+Extension Name:
+: Name of the ECHConfigExtension
+
+Recommended:
+: A "Y" or "N" value indicating if the extension is TLS WG recommends that the
+extension be supported. This column is assigned a value of "N" unless
+explicitly requested. Adding a value with a value of "Y" requires Standards
+Action {{RFC8126}}.
+
+Reference:
+: The specification where the ECHConfigExtension is defined
+
+Notes:
+: Any notes associated with the entry
+{: spacing="compact"}
+
+New entries in this registry are subject to the Specification Required
+registration policy ({{!RFC8126, Section 4.6}}).
+
+The registration policy for for the "ECHConfig Extension Type" registry
+is Specification Required {{!RFC8126}}.
+
 # ECHConfig Extension Guidance {#config-extensions-guidance}
 
 Any future information or hints that influence ClientHelloOuter SHOULD be