1 files changed, 9 insertions, 3 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 412c460..746003a 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -1721,13 +1721,17 @@ bchar = *(ALPHA / DIGIT)
             <li>
               If the <tt>BTYPE</tt> is supported, then the <tt>BLOCK</tt> 
               <bcp14>MUST</bcp14> be validated against the 
-              requested <tt>BTYPE</tt>.  To do this, the peer attempts to compute the
-              key using <tt>DeriveBlockKey</tt>.  Note that the computed key
-              does not have to match the <tt>QUERY_HASH</tt>.  Next, the peer
+              requested <tt>BTYPE</tt>.  To do this, the peer
               checks that the block is valid using <tt>ValidateBlockStoreRequest</tt>.
               If the result is <tt>BLOCK_INVALID</tt>, the message <bcp14>MUST</bcp14> be
               discarded.
             </li>
+            <li>
+              The peer also attempts to compute the
+              key using <tt>DeriveBlockKey</tt>.  This may result in <tt>NONE</tt>.
+              The result is used later.  Note that even if a key was computed, it
+              does not have to match the <tt>QUERY_HASH</tt>.
+            </li>
             <li>
               If the sender of the message is already found on the
               <tt>GETPATH</tt>, the path <bcp14>MUST</bcp14> be truncated at this position.
@@ -1741,6 +1745,8 @@ bchar = *(ALPHA / DIGIT)
               to the peer indicated in the HELLO block using the address information
               from the HELLO block. If a connection is established,
               the peer is added to the respective k-bucket of the routing table.
+              Note that the k-bucket <bcp14>MUST</bcp14> be determined by the
+              key computed using <tt>DeriveBlockKey</tt> and not by the <tt>QUERY_HASH</tt>.
             </li>
             <li>
               <t>