[lsd0004] branch master updated (668bc8a -> ada4dc0)

[gnunet]

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

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

    from 668bc8a  -fix registry
     new 0c12e28  Include GNS I-D
     new f489988  I have so many questions.
     new ada4dc0  Too specific wording for L2NSE; already defined. GANA 
apparently already created the entries.

The 3 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 draft-schanzen-r5n.xml | 64 ++++++++++++++++++++++++++++++--------------------
 1 file changed, 39 insertions(+), 25 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 123f0a9..5db7b9e 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -19,6 +19,7 @@
 <!ENTITY RFC8032 PUBLIC "" 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml";>
 <!ENTITY RFC8126 PUBLIC "" 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml";>
 <!ENTITY RFC8174 PUBLIC "" 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml";>
+<!ENTITY I-D.schanzen-gns PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.schanzen-gns.xml";>
 ]>
 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
 <?rfc strict="yes" ?>
@@ -168,7 +169,7 @@
       <dd>
         Applications are components which directly use the DHT overlay
         interfaces. Possible applications include the GNU Name System
-        <xref target="I-D.draft-schanzen-gns"/> and the CADET transport system
+        <xref target="I-D.schanzen-gns"/> and the CADET transport system
         <xref target="cadet"/>.
       </dd>
       <dt>Application API</dt>
@@ -404,6 +405,7 @@ Connectivity | |Underlay|  |Underlay|
         API:
       </t>
       <dl>
+        <!-- FIXME: Not used anywhere in draft -->
         <dt>
           <tt>TRY_CONNECT(N, A)</tt>
         </dt>
@@ -413,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>
@@ -422,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>
@@ -525,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>
@@ -538,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"/>.
@@ -554,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"/>).
@@ -571,8 +584,7 @@ Connectivity | |Underlay|  |Underlay|
          The general format of a HELLO URL uses "gnunet://"
           as the scheme, followed by "hello/" for the name
           of the GNUnet subsystem, followed by "/"-separated values
-          with the GNS
-         Base32 encoding (FIXME: described here or reference GNS draft?) of
+          with the GNS Base32 encoding (<xref target="I-D.schanzen-gns"/>) of
           the <tt>Peer ID</tt>, a Base32-encoded EdDSA signature, and an 
expiration
           time in seconds since the UNIX Epoch in decimal format.
          After this a "?" begins a list of key-value pairs where the key
@@ -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.
@@ -819,11 +835,10 @@ bchar = *(ALPHA / DIGIT)
            <t>
             This function computes the number of neighbors
            that a message should be forwarded to.  The arguments
-           are the desired replication level (<tt>REPL_LVL</tt>), the 
<tt>HOPCOUNT</tt> of the message so far, and
-           the base-2 logarithm of the current network
-           size estimate (<tt>L2NSE</tt>) as provided
-           by the underlay.  The result
-           is the non-negative number of next hops to
+           are the desired replication level (<tt>REPL_LVL</tt>), the 
<tt>HOPCOUNT</tt> of the message so far and
+           and the current network size estimate (<tt>L2NSE</tt>) as provided
+           by the underlay.
+            The result is the non-negative number of next hops to
            select.  The following figure gives the
            pseudocode for computing the number of neighbors
            the peer should attempt to forward the message to.
@@ -844,6 +859,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 +1226,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 +2257,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
@@ -2523,7 +2551,7 @@ gnunet+tcp://12.3.4.5/
       <t>
         The registration policy for this sub-registry is "First Come First
         Served", as described in <xref target="RFC8126"/>.
-        GANA is requested to populate this registry as follows:
+        GANA created the registry as follows:
       </t>
       <figure anchor="figure_btypenums" title="The Block Type Registry.">
         <artwork name="" type="" align="left" alt=""><![CDATA[
@@ -2622,6 +2650,7 @@ Type    | Name            | References | Description
         &RFC6940;
         &RFC8126;
         &RFC8174;
+        &I-D.schanzen-gns;
 
       <reference anchor="ed25519" 
target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9";><front><title>High-Speed
 High-Security Signatures</title><author initials="D." surname="Bernstein" 
fullname="Daniel Bernstein"><organization>University of Illinois at 
Chicago</organization></author><author initials="N." surname="Duif" 
fullname="Niels Duif"><organization>Technische Universiteit 
Eindhoven</organization></author><author initials="T." surname="Lange" 
fullname="Tanja Lange" [...]
 
@@ -2666,21 +2695,6 @@ Type    | Name            | References | Description
           <date year="2014"/>
         </front>
       </reference>
-      <reference anchor="I-D.draft-schanzen-gns" 
target="https://datatracker.ietf.org/doc/draft-schanzen-gns/";>
-        <front>
-          <title>The GNU Name System</title>
-          <author initials="M." surname="Schanzenbach" fullname="Martin 
Schanzenbach">
-            <organization>GNUnet e.V.</organization>
-          </author>
-          <author initials="C." surname="Grothoff" fullname="Christian 
Grothoff">
-            <organization>GNUnet e.V.</organization>
-          </author>
-          <author initials="B." surname="Fix" fullname="Bernd Fix">
-            <organization>GNUnet e.V.</organization>
-          </author>
-          <date year="2021"/>
-        </front>
-      </reference>
     </references>
     <section anchor="bloom_filters" numbered="true" toc="default">
       <name>Bloom filters in R<sup>5</sup>N</name>

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