diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md
index b01965a..43eb9f7 100644
--- a/draft-ietf-lamps-pq-composite-kem.md
+++ b/draft-ietf-lamps-pq-composite-kem.md
@@ -234,6 +234,12 @@ informative:
     author:
       org: National Institute of Standards and Technology (NIST)
     date: July 26, 2024
+  ETSI.TS.103.744:
+    title: "ETSI TS 103 744 V1.1.1 CYBER; Quantum-safe Hybrid Key Exchanges"
+    target: https://www.etsi.org/deliver/etsi_ts/103700_103799/103744/01.01.01_60/ts_103744v010101p.pdf
+    author:
+      org: ETSI
+    date: 2020-12
 
 
 --- abstract
@@ -261,7 +267,7 @@ Editorial changes:
 * ASN.1 module fixes (thanks Russ and Carl).
   * Renamed the module from Composite-KEM-2023 -> Composite-MLKEM-2024
   * Simplified the ASN.1 module to make it more compiler-friendly (thanks Carl!) -- should not affect wire encodings.
-
+* Added an appendix "Comparison with other Hybred KEMs" with sub-sections on X-Wing and ETSI CatKDF
 
 Still to do in a future version:
 
@@ -281,7 +287,7 @@ Cautious implementers may opt to combine cryptographic algorithms in such a way
 
 Certain jurisdictions are already recommending or mandating that PQC lattice schemes be used exclusively within a PQ/T hybrid framework. The use of Composite scheme provides a straightforward implementation of hybrid solutions compatible with (and advocated by) some governments and cybersecurity agencies [BSI2021].
 
-In addition, [BSI2021] specifically references this specification as a concrete example of hybrid X.509 certificates.
+In addition, [BSI2021] specifically references the composite specification as a concrete example of hybrid X.509 certificates.
 
 A more recent example is [ANSSI2024], a document co-authored by French Cybersecurity Agency (ANSSI),
 Federal Office for Information Security (BSI), Netherlands National Communications Security Agency (NLNCSA), and
@@ -1585,6 +1591,32 @@ With regard to the traditional algorithms, RSA or Elliptic Curve, in order to ac
 
 <!-- End of Implementation Considerations section -->
 
+# Comparison with other Hybred KEMs
+
+## X-Wing
+
+This specification borrows extensively from the analysis and KEM combiner construction presented in [X-Wing]. In particular, X-Wing and id-MLKEM768-X25519 are largely interchangeable. The one difference is that X-Wing uses a combined KeyGen function to generate the two component private keys from the same seed, which gives some additional binding properies. However, using a derived value as the seed for ML-KEM.KeyGen_internal() is, at time of writing, explicitely disallowed by [FIPS.203] which makes it impossible to create a FIPS-compliant implentation of X-Wing KeyGen / private key import. For this reason, this specification keeps the key generatation for both components separate so that implementers are free to use an existing certified hardware or software module for one or both components.
+
+Due to the difference in key generation and security properties, X-Wing and id-MLKEM768-X25519 have been registered as separate algorithms with separate OIDs, and they use a different domain separator string in order to ensure that their ciphertexts are not inter-compatible.
+
+## ETSI CatKDF
+
+[ETSI.TS.103.744] section 8.2 defines CatKDF as:
+
+~~~
+1) Form secret = psk || k1 || k 2 || … || k n.
+2) Set f_context = f(context, MA, MB), where f is a context formatting function.
+3) key_material = KDF(secret, label, f_context, length).
+4) Return key_material.
+
+MA shall contain all of the public keys.
+MB shall contain all of the corresponding public keys and ciphertexts.
+~~~
+
+The main difference between the Composite KEM combiner and the ETSI CatKDF combiner is that CatKDF makes the more conservative choice to bind the public keys and ciphertexts of both components, while Composite KEM follows the analysis presented in [X-Wing] that while preserving the security properties of the traditional component requires binding the public key and ciphertext of the traditional component, it is not necessary to do so for ML-KEM thanks to the rejection sampling step of the Fujisaki-Okamoto transform.
+
+Additionally, ETSI CatKDF uses HKDF [RFC5869] as the KDF which aligns with some of the variants in this specification, but not the ones that use SHA3.
+
 
 # Intellectual Property Considerations