[lsd0004] branch master updated: minor edits, comments on questions

[gnunet]

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

grothoff pushed a commit to branch master
in repository lsd0004.

The following commit(s) were added to refs/heads/master by this push:
     new 90bf72e  minor edits, comments on questions
90bf72e is described below

commit 90bf72e5e98a0534d9b24e52c3b0c33b20344151
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Sun Aug 20 16:11:12 2023 +0200

    minor edits, comments on questions
---
 draft-schanzen-r5n.xml | 106 +++++++++++++++++++++++++++++++------------------
 1 file changed, 68 insertions(+), 38 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 1601264..e1d34ff 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -337,34 +337,48 @@ gnunet+tcp://12.3.4.5/
     <section>
       <name>Overview</name>
       <t>
-        In R<sup>5</sup>N peers communicate with each other in order to 
realize and
-        maintain two basic operations of a distributed hash table:
+        In R<sup>5</sup>N peers communicate with each other to provide
+        the two fundamental operations of any distributed hash table:
       </t>
       <ul>
         <li>
-          PUT: This operation stores a block payload on one or more peers with
-          the goal of making the block availiable for queries using the GET 
operation.
+          <tt>PUT</tt>: This operation stores a <em>Block</em>
+         under a <em>Key</em> on one or more <em>Peer</em>s with
+          the goal of making the <em>Block</em> availiable for queries using 
the <tt>GET</tt> operation.
           In the classical definition of a dictionary interface, this 
operation would be
           called "insert".
         </li>
         <li>
-          GET: This operation queries the network of peers for blocks
-          previously stored under or near the key.
+          <tt>GET</tt>: This operation queries the network of peers for any 
number of <em>Block</em>s
+          previously stored under or near a <em>Key</em>.
           In the classical definition of a dictionary interface, this 
operation would be
           called "find".
         </li>
       </ul>
       <t>
-        A peer or its implementation does not necessarily need to expose the 
above operations
-        to applications but it commonly will.
-        For example, the peer could be a server purely used for bootstrapping, 
routing or
-        supporting the overlay network with resources.
-        An example for possible semantics of the above operations provided as 
an API to applications by an
-        implementation are outlined in <xref target="overlay"/>.
+       An example for possible semantics of the above operations
+       provided as an API to applications by an implementation are
+       outlined in <xref target="overlay"/>.
       </t>
       <t>
-        In a trivial scenario where there is only one peer (the local host),
-        R<sup>5</sup>N operates in a very similar fashion to a dictionary data 
structure.
+        A <em>Peer</em> does not necessarily need to expose the above
+        operations to <em>Application</em>s, but it commonly will.  A
+        <em>Peer</em> that does not expose the above operations could
+        be a host purely used for <em>Bootstrapping</em>,
+       <em>Routing</em> or supporting
+        the overlay network with resources.
+      </t>
+      <t>
+       Similarly, there could be hosts on the network that
+       participate in the DHT but do not route traffic or store
+       data. Examples for such hosts would be mobile devices with
+       limited bandwidth, battery and storage capacity.  Such hosts
+       may be used to run applications that use the DHT. However, we
+       will not refer to such hosts as <em>Peer</em>s.
+      </t>
+      <t>
+        In a trivial scenario where there is only one <em>Peer</em> (on the 
local host),
+        R<sup>5</sup>N operates similarly to a dictionary data structure.
         However, the default use case is one where nodes communicate directly 
and
         indirectly in order to realize a distributed storage mechanism.
         This communication requires a lower-level peer addressing and message 
transport
@@ -382,27 +396,32 @@ gnunet+tcp://12.3.4.5/
       </t>
       <!-- consider moving some of this back into sec considerations -->
       <t>
-        Specifics about the protocols of the underlays providing
-       connectivity or the applications using the DHT are out of
-       the scope of this document.
+        Specifics about the protocols of the underlays implementing
+        the <em>Underlay Interface</em> or the <em>Application</em>s
+        using the DHT are out of the scope of this document.
       </t>
       <t>
-        In order to establish an initial connection to a network of 
R<sup>5</sup>N
-        peers, at least one initial, addressable peer is required as part of 
the bootstrapping process.
-        Further peers, including neighbors, are then learned via a peer 
discovery
-        process as defined in <xref target="find_peer"/>.
+        To establish an initial connection to a network of
+        R<sup>5</sup>N peers, at least one initial, addressable
+        <em>Peer</em> is required as part of the
+        <em>Bootstrapping</em> process.  Further <em>Peer</em>s,
+        including <em>Neighbor</em>s, are then learned via a peer
+        discovery process as defined in <xref target="find_peer"/>.
       </t>
       <t>
-        Across this document, the functional components of an R<sup>5</sup>N
-        implementation are divided into routing (<xref target="routing"/>),
-        message processing (<xref target="p2p_messages"/>) and
-        block processing (<xref target="blockstorage"/>).
-        Applications that require application-specific block payloads are 
expected to
-        register a block type in the GANA block type registry (<xref 
target="gana_block_type"/>)
-        and provide a specification of the associated block operations (<xref 
target="block_functions"/>).
-        to implementors of R<sup>5</sup>N.
-        <xref target="figure_r5n_arch"/> illustrates the architectural 
overview of
-        R<sup>5</sup>N.
+        Across this document, the functional components of an
+        R<sup>5</sup>N implementation are divided into
+        <em>Routing</em> (<xref target="routing"/>), <em>Message
+        Processing</em> (<xref target="p2p_messages"/>) and
+        <em>Block</em> processing (<xref target="blockstorage"/>).
+        <em>Application</em>s that require application-specific
+        <em>Block</em> payloads are expected to register a
+        <em>Block-Type</em> in the GANA <em>Block-Type</em> registry
+        (<xref target="gana_block_type"/>) and provide a specification
+        of the associated block operations (<xref
+        target="block_functions"/>).  to implementors of
+        R<sup>5</sup>N.  <xref target="figure_r5n_arch"/> illustrates
+        the architectural overview of R<sup>5</sup>N.
       </t>
       <figure anchor="figure_r5n_arch" title="The R5N architecture.">
         <artwork><![CDATA[
@@ -435,22 +454,25 @@ Connectivity | |Underlay|  |Underlay|  | Underlay | ...
     <section anchor="underlay" numbered="true" toc="default">
       <name>Underlay</name>
       <t>
-        In the network underlay, how a peer is addressable is out of scope of 
this document.
-        For example, the peer may have a TCP/IP address, or expose a QUIC 
endpoint.
+        How peers are addressed in the underlay is out of scope of this 
document.
+        For example, a peer may have a TCP/IP address, or expose a QUIC 
endpoint.
         While the specific addressing options and mechanisms are out of scope
         for this document, it is necessary to define a universal addressing
-        format in order to facilitate the distribution of connectivity
-        information to other peers in the DHT overlay.
-        This format is the "HELLO" Block (described in <xref 
target="hello_block"/>),
+        format in order to facilitate the distribution of <em>Address</em>
+        information to other <em>Peer</em>s in the DHT overlay.
+        This standardized format is the <em>HELLO Block</em>
+       (described in <xref target="hello_block"/>),
        which contains sets of URIs.
         The scheme of each URI indicates which underlay understands the
-       respective address given in the rest of the URI.
+       respective <em>Address</em> details which are encoded in the rest of 
the URI.
       </t>
       <!--
         1) The current API is always fire+forget, it doesn't allow for flow
         control. I think we need to add that, possibly for sending and 
receiving.
 
-        IDK.
+        IDK. 
+       CG: I think we should not have flow control for the DHT; overkill,
+       should instead simply define transmission as unreliable.
 
         2) I'm not sure what to do with the crypto: mandate EdDSA or allow the
         underlay to do whatever public keys it likes.
@@ -458,6 +480,11 @@ Connectivity | |Underlay|  |Underlay|  | Underlay | ...
         We need keys in the overlay. (Path signatures). Do they need to
         be the same keys???
 
+        CG: I'd mandate EdDSA. CONG will have mitigation to establish
+       EdDSA keys over libp2p, even if libp2p does not use EdDSA. But,
+       that said, I'm not sure if we should even mandate AE on the
+       underlay.
+
         3) I think we may want to mandate that the lower layer at least
         authenticate the other peer (i.e. every UDP message could be in
         cleartext, but would need to come with an EdDSA signature, alas 92 byte
@@ -465,6 +492,9 @@ Connectivity | |Underlay|  |Underlay|  | Underlay | ...
         see how we can offer even the most minimal protections against peer
         impersonation attacks. WDYT?
 
+        CG: Yes, I think authentication should be mandatory, but not 
+        any _specific_ type of encryption.
+
         Security considerations? Prerequisites?
       -->
       <t>

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