[lsd0004] branch master updated: -misc terminology clarifications

[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 7adc54c  -misc terminology clarifications
7adc54c is described below

commit 7adc54c64408944d12d83d0361cbdde56fcc9df3
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Thu Mar 10 07:10:53 2022 +0100

    -misc terminology clarifications
---
 draft-schanzen-r5n.xml | 32 ++++++++++++++++++++------------
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index de918b2..545a727 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -180,47 +180,55 @@
           a peer in the underlay.
           The <tt>Peer Address</tt> is derived from the <tt>Peer ID</tt>.
         </dd>
+        <dt>Key</dt>
+        <dd>
+          Fixed-sized identifier of a location in the DHT. Multiple 
<tt>Block</tt>s can be
+         stored under the same key. <tt>Peer Addresses</tt> must also always 
be valid keys.
+        </dd>
         <dt>Neighbour:</dt>
         <dd>
-          A neighbour is a peer which is directly connected to our peer.
+          A neighbour is a peer which is directly able to communicate
+         with our peer via the <tt>Underlay Interface</tt>.
         </dd>
         <dt>Block:</dt>
         <dd>
-          An object or group of objects stored in the DHT.
+          Variable-size unit of payload stored in the DHT
+         under a <tt>Key</tt>. Commonly also called a &quot;value&quot; when 
talking
+         about a DHT as a &quot;key-value store&quot;.
         </dd>
         <dt>Block-Type:</dt>
         <dd>
-          A unique 32-bit value identifying a block type.
+          A unique 32-bit value identifying the data format of a 
<tt>Block</tt>.
           Block-Types are either private or allocated by GANA (see <xref 
target="gana"/>).
         </dd>
         <dt>Block Storage</dt>
         <dd>
-          The Block Storage component is used to persist and manage data
-          by peers. It includes logic for quotas, caching stragegies and
+          The <tt>Block Storage</tt> component is used to persist and manage 
<tt>Block</tt> data
+          by peers. It includes logic for enforcing storage quotas, caching 
strategies and
           data validation.
         </dd>
         <dt>Responsible Peer:</dt>
         <dd>
-          The peer <tt>N</tt> that is responsible for a specific resource 
<tt>K</tt>, as defined by
+          The peer <tt>N</tt> that is responsible for a specific key 
<tt>K</tt>, as defined by
           the <tt>SelectClosestPeer(K, P)</tt> algorithm (see <xref 
target="routing"/>.
         </dd>
         <dt>Applications</dt>
         <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"/> or the CADET transport system
+          <xref target="I-D.draft-schanzen-gns"/> and the CADET transport 
system
           <xref target="cadet"/>.
         </dd>
         <dt>Application API</dt>
         <dd>
           The application API exposes the core operations of the DHT overlay
           to applications.
-          This includes querying and retrieving data from the DHT.
+          This includes storing blocks in the DHT and retrieving blocks from 
the DHT.
         </dd>
         <dt>Message Processing</dt>
         <dd>
-          The Message Processing component processes requests from and 
responses
-          to applications as well as messages from the underlay network.
+          The Message Processing component processes requests from and
+         generates responses to applications and the underlay network.
         </dd>
         <dt>Routing</dt>
         <dd>
@@ -230,10 +238,10 @@
         </dd>
         <dt>Underlay Interface</dt>
         <dd>
-          The DHT Underlay Interface is an abstraction layer on top of the
+          The Underlay Interface is an abstraction layer on top of the
           supported links of a peer. Peers may be linked by a variety of
           different transports, including "classical" protocols such as
-          TCP, UDP and TLS or advanced protocols such as GNUnet, L2P or Tor.
+          TCP, UDP and TLS or advanced protocols such as GNUnet, I2P or Tor.
         </dd>
       </dl>
     </section>

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