diff --git a/draft-kohbrok-mls-implementation-considerations.md b/draft-kohbrok-mls-implementation-considerations.md
index eb32bf2..56482ef 100644
--- a/draft-kohbrok-mls-implementation-considerations.md
+++ b/draft-kohbrok-mls-implementation-considerations.md
@@ -45,6 +45,37 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
 document are to be interpreted as described in BCP 14 {{RFC2119}} {{!RFC8174}}
 when, and only when, they appear in all capitals, as shown here.
 
+# Typed structs
+In many places, MLS uses a typed pattern of structs, where we have a type `uint`,
+followed by a `select` statement that decides the type of the following field based on the preceding type `uint`.
+For example the Credential struct:
+
+```
+struct {
+    CredentialType credential_type;
+    select (Credential.credential_type) {
+        case basic:
+            BasicCredential;
+
+        case x509:
+            Certificate chain<1..2^32-1>;
+    };
+} Credential;
+```
+
+Other examples are `Content`/`ContentType`, `PSKType` in `PreSharedKey`, `Sender`/`SenderType` and `Proposal`/`ProposalType`.
+
+We can generalise this into a typed struct as follows:
+
+```
+struct {
+    T type;
+    select(typed<T>.type) {
+        T.variant1: 
+            Variant1 
+    }
+} typed<T>
+```
 
 # Security Considerations