[lsd0004] 02/03: I have so many questions.

[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 f4899881724fd7d22524cfcc2eb62c9c8880a080
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Sun Dec 25 13:21:44 2022 +0900

    I have so many questions.
---
 draft-schanzen-r5n.xml | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

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

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