[lsd0004] 02/02: Change handling of HELLOs in Puts and Results from MUST to SHOULD

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0004.

commit b621c412b3a70f906ece7a97aabea1cb15ec5fd1
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Dec 26 11:00:51 2022 +0900

    Change handling of HELLOs in Puts and Results from MUST to SHOULD
    
    also makes wording more consistent.
---
 draft-schanzen-r5n.xml | 50 ++++++++++++++++++++++++--------------------------
 1 file 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

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.