diff --git a/draft-vesco-vcauthtls.md b/draft-vesco-vcauthtls.md
index 3b86d94..7a5a085 100644
--- a/draft-vesco-vcauthtls.md
+++ b/draft-vesco-vcauthtls.md
@@ -284,7 +284,13 @@ Server -> dlt2 : DID Resolve
 <!-- ![mutual-vc](images/mutual-vc.svg) -->
 
 ## Mutual authentication with Client using Verifiable Credential and Server using X.509 Certificate
-This example combines the use of a raw public key and an X.509 certificate. The client uses a VC for client authentication, and the server provides an X.509 certificate. The client expresses its ability to process an X.509 certificate or a raw public key from the server. In addtion it is willing to use either a VC or an X.509 certificate for client-side authentication. The server then selects X.509 to authenticate with the client and VC for client authentication. The server then sends a list of DID methods of its choice.
+
+This example shows a TLS 1.3 handshake with mutual authentication that combines the use of Verifiable Credential and X.509 certificate. The client uses a Verifiable Credential, and the server uses an X.509 certificate.
+The client expresses its willingness to process an X.509 certificate from the server. In addition, it expresses the capability to be authenticated with a Verifiable Credential or an X.509 certificate.
+The server selects X.509 certificate to authenticate with the client and Verifiable Credential for client authentication. Then, the server sends the CertificateRequest message together with the did_methods extension with a set of DID Methods of its choice.
+The server sends its X.509 certificate and the client its Verifiable Credential into their respective Certificate message.
+
+<!-- TODO description of DID resolve at server side -->
 
 <!--
 ```
@@ -314,7 +320,7 @@ Server -> IOTA : DID Resolve
 
 ## Mutual authentication with Client using X.509 Certificate and Server using Verifiable Credential
 
-This example proposes a client authenticating with an X.509 certificate and a server with a VC. The client is capable to process and validate a VC from the server, in fact it also sends the did_methods extension. The server then decides to request an X.509 certificate from the client and to provide a VC to authenticate with the client.
+<!-- This example proposes a client authenticating with an X.509 certificate and a server with a VC. The client is capable to process and validate a VC from the server, in fact it also sends the did_methods extension. The server then decides to request an X.509 certificate from the client and to provide a VC to authenticate with the client. -->
 
 <!--
 ```
@@ -354,10 +360,10 @@ server sends an HRR when it does not have a DID compatible with the list of DID
 
 <!-- We should discuss or include references to revocation processes -->
 
-All the security considerations presented in [RFC8446](https://datatracker.ietf.org/doc/html/rfc8446) applies to this document as well.
+<!-- All the security considerations presented in [RFC8446](https://datatracker.ietf.org/doc/html/rfc8446) applies to this document as well.
 Further considerations, though, about the DID resolution process are worth discussing. Assuming that a DID resolution is performed in clear, a man-in-the-middle could impersonate the DLT node, forge a DID document containing the authenticating endpoint's DID, associate it with a key pair that he owns, and then return it to the DID resolver. Thus, the attacker is able to compute a valid CertificateVerify message by possessing the long term private key. In practice, the man-in-the-middle attacker breaks in transit the immutability feature of the DLT (i.e. the RoT for identity public keys).
 A reasonable solution to this attack could be to create a TLS channel towards the DLT node and authenticate only the latter to rely on the received data. The DLT node must be authenticated through an X.509 certificate. The number of DLT nodes within an IoT large scale systems is expected to be very low (i.e. one or a couple of nodes) with respect to the total number of IoT and edge nodes, so adopting X.509 certificates to authenticate those DLT nodes does not reduce the overall benefit in terms of lower complexity and cost associated to certificate management proper of SSI solution.
-In order to reduce the overhead of establishing a TLS channel with the DLT node for DID resolution, there are two possible approaches (i) leverage session resumption and 0 round-trip time (0-RTT) features of TLS 1.3 or (ii) change the logic of DLT nodes and adopt a data protection solution (e.g. with HMAC to authenticate the data from DLT node).
+In order to reduce the overhead of establishing a TLS channel with the DLT node for DID resolution, there are two possible approaches (i) leverage session resumption and 0 round-trip time (0-RTT) features of TLS 1.3 or (ii) change the logic of DLT nodes and adopt a data protection solution (e.g. with HMAC to authenticate the data from DLT node). -->
 
 # IANA Considerations