diff --git a/index.bs b/index.bs
index acf1afdc..1a37ed59 100644
--- a/index.bs
+++ b/index.bs
@@ -3708,6 +3708,95 @@ and makes it clear when the state described by the flags is reset.
 
 <!-- TODO: add examples -->
 
+<h3 id="registries">Use registries to allow constrained extensions outside the original standards track</h3>
+
+When you expect a feature to need to be extended over time,
+and it would be inappropriate to
+manage that change through the same standards process that defined the original feature,
+then a registry is usually the right design.
+
+[[spec-variability#variability|"Variability complicates interoperability."]]
+When a feature needs optional components,
+it is easiest to manage the complication if
+a single group is in charge of the whole design.
+This implies that most optional features should be defined
+in the same specification that defined the original feature.
+
+Sometimes new extensions are expected to be needed in the future.
+It is often most appropriate
+to have revise the specification to define an extension.
+This can reduce or avoid any need to precisely define requirements for extensions.
+
+However, if extensions need to be defined through
+a different process than updating the full specification,
+a registry is usually the right way to manage the known extensions.
+Default to defining either
+an IANA registry governed by [[RFC8126]] or a [[w3c-process#registries|W3C Registry]],
+but another similar mechanism is also acceptable.
+
+The place in a specification that dispatches to an extension's implementation
+is known as an <dfn export>extension point</dfn>.
+To maximize the chance that a specification with extension points is interoperably implemented,
+each extension point should
+
+* define how implementations can negotiate which extensions are acceptable,
+* define what to do with unrecognized extensions
+    (see [[RFC6709#section-4|section 4 of RFC6709]]),
+* define what interface extensions are supposed to implement, and
+* link to a specification of each extension that is
+    detailed enough to support interoperable implementations of the extension,
+    as is required by
+    the IETF's [[RFC8126#section-4.6|Specification Required]] registration policy.
+
+Registries help because they
+
+* give each extension a unique name to use
+    in negotiation and
+    in recognizing what extension is in use,
+* provide a place to link to extension specifications
+    (if the registry requires this), and
+* help readers find the name for a desired purpose.
+
+It is tempting to additionally require that registry entries be
+"good" in some way beyond what is needed to achieve interoperability.
+Whether this can succeed depends on the ecosystem and the expected implementers.
+Implementers are most likely to be willing to
+navigate a demanding registration process and
+constrain their implementations to match strict registration requirements
+when they are a small set, wealthy, and generally-aligned,
+as in the case of web browser engines.
+The more diverse or constrained implementers become,
+the less you can expect them to consistently work to register extensions.
+
+At the limit, implementers might not even be willing to specify their extensions.
+If the specification authors consider this likely, it may be worth allowing
+[[rfc8126#section-4.4|first-come-first-served registrations without a specification]]
+just to reduce the risk of name collisions,
+although the registry should still encourage full specifications.
+
+In the case of a registry that doesn't require specifications,
+it can be tempting to identify extensions with URLs or URIs instead of registered strings.
+This has the effect of defining a [[rfc8126#section-4.3|hierarchical registration policy]]
+and making it very easy to extend the feature,
+by just picking a URL from a domain that the extender controls.
+This clearly loses the interoperability benefits of requiring a specification,
+and in the case of DNS-based URLs,
+it also risks that the entity that defined the extension may lose control of its domain.
+URIs are appropriate for a few kinds of very-low-coordination extension,
+but most of the time a WG-managed permissive registry table will work better.
+
+Because an [=extension point=] defines an interface,
+and it's difficult to be confident in an interface definition
+before that interface has several implementations,
+any new registry should start with at least 2-3 entries defined.
+Each of these initial registry entries
+can be either required or optional for implementations to recognize.
+For extension points that can't just be ignored when their extension isn't recognized,
+then the registry should include at least 1 required entry.
+
+See [[qaframe-spec#extensions]] and [[RFC6709]] for
+more guidance on how to design extensibility.
+
 <h3 id="implementability">Resolving tension between interoperability and implementability</h3>
 
 <!--