Change handling of HELLOs in Puts and Results from MUST to SHOULD

also makes wording more consistent.

1 files changed, 24 insertions, 26 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 0024d8e..0aaee8d 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -1529,12 +1529,13 @@ BEGIN
               of the message.  
             </li>-->
             <li>
-              If the flag is not set, the <tt>PATH_LEN</tt>
+              If the <tt>RecordRoute</tt> flag is not set, the <tt>PATH_LEN</tt>
               <bcp14>MUST</bcp14> be set to zero.
-              If the <tt>PATH_LEN</tt> is non-zero,
+              If the flag is set and <tt>PATH_LEN</tt> is non-zero,
               the local peer <bcp14>SHOULD</bcp14> verify the signatures from the <tt>PUTPATH</tt>.
               Verification <bcp14>MAY</bcp14> involve checking all signatures or any random
-              subset of the signatures.  It is <bcp14>RECOMMENDED</bcp14> that peers adapt
+              subset of the signatures.
+              It is <bcp14>RECOMMENDED</bcp14> that peers adapt
               their behavior to available computational resources so as to not make signature
               verification a bottleneck.  If an invalid signature is found, the
               <tt>PUTPATH</tt> <bcp14>MUST</bcp14> be truncated to only include the elements
@@ -1547,25 +1548,19 @@ BEGIN
               be stored locally in the block storage.
             </li>
             <li>
+              <!-- FIXME: Discuss: Changed from MUST to SHOULD - MSC -->
               If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the
-              peer <bcp14>MUST</bcp14> be considered for the local routing
-              table if the respective k-bucket is not yet full. In this case,
-              the local peer <bcp14>MUST</bcp14> try to establish a connection
+              peer <bcp14>SHOULD</bcp14> be considered for the local routing
+              table by using the peer address in <tt>BLOCK_KEY</tt>.
+              An implementation <bcp14>MAY</bcp14> choose to ignore the <tt>HELLO</tt>, for example
+              because the routing table or the respective k-bucket is already full.
+              If the peer is a suitable candidate for insertion, the local peer <bcp14>MUST</bcp14> try to establish a connection
               to the peer indicated in the <tt>HELLO</tt> block using the address information
               from the <tt>HELLO</tt> block and the Underlay function <tt>TRY_CONNECT</tt>.
-              <!-- FIXME: The above behaviour has a catch: If the implementation only connects to one
-                   address from the hello using TRY_CONNECT, the Underlay also knows only about that connection
-                   If that failes and PEER_DISCONNECT is called, this neighbor is dead.
-                   We could say here that the implementation SHOULD instruct to connect to ALL
-                   addresses or risk flaky connections. The choice of address is also unclear.
-                   R5N does not really know what the Underlay supports (maybe more than provided in
-                   own addresses) - Added this for now: -->
-              The implementation <bcp14>MAY</bcp14> instruct the Underlay to connect to all provided addresses
+              The implementation <bcp14>MUST</bcp14> instruct the Underlay to connect to all provided addresses
               using <tt>TRY_CONNECT</tt> in order to make the underlay aware of multiple addresses for this connection.
-              If a connection is established, the signal <tt>PEER_CONNECTED</tt> will cause
-              the peer to be 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>.
+              When a connection is established, the signal <tt>PEER_CONNECTED</tt> will cause
+              the peer to be added to the respective k-bucket of the routing table (<xref target="routing"/>).
             </li>
             <li>
               Given the value in <tt>REPL_LVL</tt>, <tt>HOPCOUNT</tt> and the
@@ -1992,16 +1987,19 @@ BEGIN
               does not have to match the <tt>QUERY_HASH</tt>.
             </li>
             <li>
+              <!-- FIXME: Discuss: Changed from MUST to SHOULD - MSC -->
               If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the
-              peer <bcp14>MUST</bcp14> be considered for the local routing
-              table if the respective k-bucket is not yet full. In this case,
-              the local peer <bcp14>MUST</bcp14> try to establish a connection
+              peer <bcp14>SHOULD</bcp14> be considered for the local routing
+              table by using the peer address computed from the block using<tt>DeriveBlockKey</tt>.
+              An implementation <bcp14>MAY</bcp14> choose to ignore the <tt>HELLO</tt>, for example
+              because the routing table or the respective k-bucket is already full.
+              If the peer is a suitable candidate for insertion, the local peer <bcp14>MUST</bcp14> try to establish a connection
               to the peer indicated in the <tt>HELLO</tt> block using the address information
-              from the <tt>HELLO</tt> 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>
+              from the <tt>HELLO</tt> block and the Underlay function <tt>TRY_CONNECT</tt>.
+              The implementation <bcp14>MUST</bcp14> instruct the Underlay to connect to all provided addresses
+              using <tt>TRY_CONNECT</tt> in order to make the underlay aware of multiple addresses for this connection.
+              When a connection is established, the signal <tt>PEER_CONNECTED</tt> will cause
+              the peer to be added to the respective k-bucket of the routing table (<xref target="routing"/>).            </li>
             <li>
               <t>
                 If the <tt>QUERY_HASH</tt> of this <tt>ResultMessage</tt> is found in the