diff --git a/rfc/0006_ws2p_v2.md b/rfc/0006_ws2p_v2.md
index 39f902d3fcc21a437925edf6450999d000307dcf..317d6d72da13915267aaf3424734c47c1f2c05aa 100644
--- a/rfc/0006_ws2p_v2.md
+++ b/rfc/0006_ws2p_v2.md
@@ -279,14 +279,14 @@ The utf8 format is used to display the endpoint in a human-readable format. It i
 
 General utf8 endpoint format :
 
-    API_NAME VERSION NF1 .. NFn (AF1 .. AFn) IP4 [IP6] HOST PORT PATH
+    API_NAME VERSION n NF1 .. NFn n2 AF1 .. AFn2 IP4 [IP6] HOST PORT PATH
 
 NF := NETWORK_FEATURE
 AF := API_FEATURE
 
 Example:
 
-    WS2P 2 S (DEFLATE LOW ABF) g1.durs.ifee.fr 443 ws2p
+    WS2P 2 1 S 3 DEFLATE LOW RBF g1.durs.ifee.fr 443 ws2p
 
 Same endpoint in binary format :
 
@@ -324,7 +324,7 @@ Signed document declaring all the endpoints of a peer.
 |  endpoints_datas  | calculate*    | [(u16, endpoint); endpoints_count] |
 |     signature     | 64            | [u8; 64]                           |
 
-endpoints_datas := tuples table (endpoint_size, endpoint).
+endpoints_datas := table of tuples (endpoint_size, endpoint).
 
 `endpoint_size` type : u16.
 
@@ -333,7 +333,7 @@ endpoints_datas := tuples table (endpoint_size, endpoint).
 The document is represented by an array of bytes containing (peer_card_size + 2) bytes.  
 to sign the document it is necessary to calculate the hash sha256 of this bytes array then to sign the hash obtained with the issuer's private key.
 
-### Peer card JSON format
+### Peer card BMA JSON format
 
     {
         "version": Number(VERSION),
@@ -395,6 +395,8 @@ If the key is a member: +1
 If the key is preferred/privileged: +2  
 If the key is the same as yourself: +4 (for multi-node)
 
+In case of equality, the order in which the endpoints will be contacted will depend on the sorting algorithm used according to the implementations, there are no rules, we can consider that it is pseudo-random.
+
 ## Establishing a WS2P connection
 
 After sorting all WS2P endpoints according to the criteria described in the previous section,
@@ -410,6 +412,8 @@ for each connection attempt, the process is as follows:
 
 *timeout : 15 seconds for connection to a conventional endpoint. 30 seconds for connection to a hidden tor service.
 
+WARNING: independently of all these rules, each implementation must integrate its own anti-spam protections. Any connection can be rejected if the situation requires it (attack by denial of service for example).
+
 ### CONNECT message
 
 | data name     | size in bytes | data type    |
@@ -444,7 +448,9 @@ chunk_hash := Last block hash of the chunk.
 | 0000_0010 | ASK_SYNC_CHUNK  |
 | 0000_0100 | RES_SYNC_CHUNK  |
 
-SYNC := Boolean indicating whether the connection corresponds to a synchronization request or not. In case of a synchronization request, the connection will necessarily be accepted but temporary. Whereas in the normal case the connection may or may not be accepted according to classic ws2p rules, but it will be permanent.
+SYNC := Boolean indicating whether the connection corresponds to a synchronization request or not. In case of a synchronization request, the connection will necessarily be accepted if it's possible* but temporary. Whereas in the normal case the connection may or may not be accepted according to classic ws2p rules, but it will be permanent.
+
+_*The anti-spam procedures of the implementation may cause the node to still refuse the connection._
 
 ASK_SYNC_CHUNK := So that the synchronization is not too slow, the nodes to which chunk are requested are required to accept the connection and send at least 1 chunk before closing it. They can of course accept the connection for longer and send several chunks.
 
@@ -476,7 +482,7 @@ challenge_sig := Signature of the challenge given by the other node.
 | 0000_0010 | MEMBER_PUBKEY   |
 | 0000_0100 | MEMBER_PROOF    |
 
-LOW_FLOW_DEMAND := The sender node of this message indicates that it's behind a low speed connection and therefore care must be taken to transmit low volumes of data to it.
+LOW_FLOW_DEMAND := The sender node of this message indicates that it's behind a low speed connection and therefore care must be taken to transmit low volumes of data to it. All the code will do is to be careful to send only essential information and not already sent, which requires caching and pre-processing, that's why we don't do it for normal connections.
 
 MEMBER_PUBKEY: Indicates whether or not the member_pubkey field is present in the message.
 
@@ -526,7 +532,7 @@ target_b_hash := Indicates the current block hash of the message sender node. Th
 
 chunks_hashs_count := `chunks_hashs` array size
 
-chunks_hashs := Hash table of the last block of each chunk.
+chunks_hashs := Hash table of the last block of each chunk. We do not need the block numbers, we know them. Here the remote node sends the hashs of all these chunk, which correspond to the current hashs of all the blocks having a number in 250 module 249, in ascending order.
 
 ### KO message
 
@@ -577,7 +583,9 @@ WARNING : Exception with the ABF api feature : In a WS2P connection between two
 BLOCKS_HASHS := In case of fork, to quickly find the fork point, the node will request the hashes of the ForkWindowsSize of the local blockchains of the other nodes.
 It would be counterproductive to ask directly for the entire blocks, when you will only need them if you actually decide to stack the corresponding branch.
 
-WOT_POOL := For network performance reasons, a Duniter-Rust node never shares its entire wot pool at once. It randomly selects `folders_count` folders among those having received at least `min_cert` certifications. It's the requesting node that sets the values of `min_cert` and `folders_count` according to its connection rate, its configuration and the rate of new folders it has obtained in these previous requests.
+WOT_POOL := For network performance reasons, a Duniter-Rust* node never shares its entire wot pool at once. It randomly selects `folders_count` folders among those having received at least `min_cert` certifications. It's the requesting node that sets the values of `min_cert` and `folders_count` according to its connection rate, its configuration and the rate of new folders it has obtained in these previous requests.
+
+_*This is part of the specificities of WS2P requests in binary format, which will be introduced in all implementations in the future._
 
 ### REQUESTS RESPONSES