I have so many questions.

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|
         API:
       </t>
       <dl>
+        <!-- FIXME: Not used anywhere in draft -->
         <dt>
           <tt>TRY_CONNECT(N, A)</tt>
         </dt>
@@ -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.
         </dd>
+        <!-- FIXME: Not used anywhere in draft -->
         <dt>
           <tt>HOLD(P)</tt>
         </dt>
@@ -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.
         </dd>
+        <!-- FIXME: Not used anywhere in draft -->
         <dt>
           <tt>DROP(P)</tt>
         </dt>
@@ -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.
       </t>
@@ -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"/>.
       </t>
       <t>
+        <!-- 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.
       </t>
       <t>
+        <!-- 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 127.0.0.1 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))
 ]]></artwork>
             </figure>
+            <!-- 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. -->
   	    <t>
 	      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">
         <name>HelloMessage</name>
  	<t>
+          <!-- 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://12.3.4.5/
             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