commit b621c412b3a70f906ece7a97aabea1cb15ec5fd1
parent 3a2ed928c57940dd07a4cf6aae59d54af9b59fc8
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 26 Dec 2022 11:00:51 +0900
Change handling of HELLOs in Puts and Results from MUST to SHOULD
also makes wording more consistent.
Diffstat:
1 file changed, 24 insertions(+), 26 deletions(-)
diff --git 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
