path: root/draft-schanzen-r5n.xml
diff options
Diffstat (limited to 'draft-schanzen-r5n.xml')
1 files changed, 30 insertions, 1 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 607171e..f195c5f 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -405,6 +405,7 @@ Connectivity | |Underlay| |Underlay|
+ <!-- FIXME: Not used anywhere in draft -->
<tt>TRY_CONNECT(N, A)</tt>
@@ -414,6 +415,7 @@ Connectivity | |Underlay| |Underlay|
When the connection attempt is successful, information on the new
peer is offered through the <tt>PEER_CONNECTED</tt> signal.
+ <!-- FIXME: Not used anywhere in draft -->
@@ -423,6 +425,7 @@ Connectivity | |Underlay| |Underlay|
of active connections. With this function the DHT can indicate to the
underlay which connections should preferably be preserved.
+ <!-- FIXME: Not used anywhere in draft -->
@@ -526,6 +529,8 @@ Connectivity | |Underlay| |Underlay|
While details on how the first connection is established <bcp14>MAY</bcp14>
depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done
by an out-of-band exchange of the information from a HELLO block.
+ <!-- FIXME: Is this really an encoding of a block? It seems to me that "HELLO"
+ is not properly defined. -->
For this, section <xref target="hello_url"/> specifies a URL format for encoding HELLO
blocks as text strings which <bcp14>SHOULD</bcp14> be supported by implementations.
@@ -539,10 +544,14 @@ Connectivity | |Underlay| |Underlay|
Furthermore, the Underlay <bcp14>SHOULD</bcp14> provide the implementation with one or more
addresses signalled through <tt>ADDRESS_ADDED</tt>. Zero addresses <bcp14>MAY</bcp14> be
provided if a peer can only establish outgoing connections and is otherwise unreachable.
+ <!-- FIXME: What about HelloMessages? What is the distinction between HELLO blocks
+ and HELLO messages? -->
The implementation periodically advertises all
active addresses in a HELLO block <xref target="hello_block"/>.
+ <!-- FIXME: Maybe make this a SHOULD and explain what happens if the implementation
+ does not. We should allow a minimal implementation of the protocol. -->
In order to fill its routing table by finding close peers in the network, an
implementation <bcp14>MUST</bcp14> now periodically send peer discovery messages
<xref target="find_peer"/>.
@@ -555,6 +564,9 @@ Connectivity | |Underlay| |Underlay|
the developer.
+ <!-- FIXME: This whole section is a bit odd and I think we should breat it up
+ into an overview and the below explanaton should be part of message
+ processing -->
Any implementation encountering a HELLO GET request <bcp14>MUST</bcp14> respond
with its own HELLO block except if that block is
filtered by the request's result filter (see <xref target="result_filter"/>).
@@ -601,6 +613,10 @@ maybe generate proper test vector.
is reachable via "udp" at on port 2086 until
1647134480 seconds after the Epoch. Note that "udp"
here is underspecified and just used as a simple example.
+ <!-- FIXME: Must be supported by which underlay?
+ This does not make sense. I may be able to generate
+ addr-names that my underlay supports, but there is not
+ way to guarantee that all underlays support it. -->
In practice, the key (addr-name)
<bcp14>MUST</bcp14> refer to a scheme supported by a
DHT Underlay.
@@ -844,6 +860,12 @@ BEGIN
return 1 + (RM1 / (L2NSE + RM1 * HOPCOUNT))
+ <!-- FIXME: WTF? So much wrong here.
+ 1. Why is this not part of code if necessary?
+ 2. Why is this necessary?
+ 3. Why probabillistic?
+ Implementations are bound to get this wrong. -->
The above calculation may yield values that are
not discrete. Hence, the result <bcp14>MUST</bcp14> be
@@ -1205,6 +1227,9 @@ BEGIN
<section anchor="p2p_hello" numbered="true" toc="default">
+ <!-- FIXME: While it is discussed here how to hangle HelloMessages
+ nowhere in the draft is a HelloMessage created at the
+ initiator so it is completely irrelevant atm -->
<tt>HelloMessage</tt>s are used to inform neighbors of
a peer about the sender's available addresses. The
recipients use these messages to inform their respective
@@ -2233,7 +2258,11 @@ gnunet+tcp://
Bloom filter following the definition from <xref target="bloom_filters"/>
and consists of a variable number of buckets <tt>L</tt>.
<tt>L</tt> depends on the number of elements <tt>|E|</tt> known to be filtered at the
- initiator. If <tt>|E|</tt> is zero, the size <tt>L</tt> is set to 32 bits to provide some minimum
+ initiator.
+ <!-- FIXME: Minimum space for used for what? There is no example given anywhere in the
+ spec how this becomes relevant. Again, this is not some abstract block,
+ but specifically a HELLO (see above). -->
+ If <tt>|E|</tt> is zero, the size <tt>L</tt> is set to 32 bits to provide some minimum
space (to be used by peers when forwarding the request after
returning local results).
Otherwise, <tt>L</tt> is set to the minimum of