diff --git a/docs/architecture/tls13-experimental.md b/docs/architecture/tls13-experimental.md
index 88d0b73..859ff2b 100644
--- a/docs/architecture/tls13-experimental.md
+++ b/docs/architecture/tls13-experimental.md
@@ -133,17 +133,25 @@
 
   (1) This is just for comparison.
 
-  (2) The MVP sends one shared secret corresponding to the configured preferred
-      group. The preferred group is the group of the first curve in the list of
-      allowed curves as defined by the configuration. The allowed curves are
-      by default ordered as follow: `secp256r1`, `x25519`, `secp384r1`
-      and finally `secp521r1`. This default order is aligned with the
-      list of mandatory-to-implement groups (in absence of an application
-      profile standard specifying otherwise) defined in section 9.1 of the
-      specification. The list of allowed curves can be changed through the
-      `mbedtls_ssl_conf_curves()` API.
+  (2) The MVP sends only one shared secret corresponding to the configured
+	  preferred group. This could, however end up with connection failure if the
+	  server does not support our preferred curve, as we have yet to implement
+	  HelloRetryRequest. The preferred group is the group of the first curve in
+	  the list of allowed curves as defined by the configuration. The list of
+	  mandatory-to-implement groups (in absence of an application profile
+	  standard specifying otherwise) as defined in section 9.1 of the
+	  specification gives the preferred order as follows: `secp256r1`, `x25519`,
+	  `secp384r1` and finally `secp521r1`. If we could therefore fix the use of
+	  `secp256r1`, then we would be guaranteed that the server supported it,
+	  however our current curve preference order puts `x25519` before
+	  `secp256r1` and changing this for only TLS1.3 would be potentially
+	  difficult (we have no desire to change TLS1.2 behaviour). The likelyhood
+	  of finding a server that doesn't support `x25519` is quite low and indeed
+	  the end user could themselves change the order of preference of curves
+	  using the `mbedtls_ssl_conf_curves()` API if they wished to do so, so we
+	  are leaving the current preference order intact.
 
-  (3) The MVP proposes only TLS 1.3 and does not support version negociation.
+  (3) The MVP proposes only TLS 1.3 and does not support version negotiation.
       Out-of-protocol fallback is supported though if the Mbed TLS library
       has been built to support both TLS 1.3 and TLS 1.2: just set the
       maximum of the minor version of the SSL configuration to