[lsd0004] branch master updated: add version field to flags

[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 fce237f  add version field to flags
fce237f is described below

commit fce237fe18344e4ab1b2d2470b8be5a3e8b03940
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Sat Aug 26 12:15:04 2023 +0200

    add version field to flags
---
 draft-schanzen-r5n.xml | 48 +++++++++++++++++++++++++++++-------------------
 1 file changed, 29 insertions(+), 19 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 1f38bde..cef5382 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -706,22 +706,22 @@ Connectivity | |Underlay|  |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 <tt>HELLO</tt> 
block.
-          Section <xref target="hello_url"/> specifies a URL format for 
encoding HELLO
-          blocks as text strings which allow portable, human-readable, 
text-based serialization
+          <xref target="hello_url"/> specifies a URL format for encoding HELLO
+          blocks as text strings. The URL format thus provides a portable, 
human-readable, text-based serialization
           format that can, for example, be encoded into a QR code for 
dissemination.
           HELLO URLs <bcp14>SHOULD</bcp14> be supported by implementations for 
both import and export
           of <tt>HELLO</tt>s.
         </t>
         <t>
           To discover peers for its routing table, a peer will initiate 
<tt>GetMessage</tt> requests
-          <xref target="p2p_get"/> asking for blocks of type <tt>HELLO</tt> 
using its own peer identity 
+          (see <xref target="p2p_get"/>) asking for blocks of type 
<tt>HELLO</tt> using its own peer identity 
           in the <tt>QUERY_HASH</tt> field of the message.
           The <tt>PEER_BF</tt> is initialized and set using the peers own peer 
identity as well as the identities
           of all currently connected <em>neighbors</em>. <!-- note: we mean 
the identities here! FIX with terminology... -->
           These requests <bcp14>MUST</bcp14> use the <tt>FindApproximate</tt> 
and <tt>DemultiplexEverywhere</tt>
           flags. <tt>FindApproximate</tt> will ensure that other peers will 
reply
-          with keys they merely consider close-enough, while 
<tt>DemultiplexEverywhere</tt>
-          will cause each peer on the path to respond, which is likely to yield
+          with results where the keys are merely considered close-enough, 
while <tt>DemultiplexEverywhere</tt>
+          will cause each peer on the path to respond. The combination of 
these flags is thus likely to yield
           <tt>HELLO</tt>s of peers that are useful somewhere in the routing 
table.
           The <tt>RECOMMENDED</tt> replication level to be set in the 
<tt>REPL_LVL</tt> field is 4.
           The size and format of the result filter is specified in <xref 
target="hello_block"/>.
@@ -735,12 +735,12 @@ Connectivity | |Underlay|  |Underlay|  | Underlay | ...
           An implementation <bcp14>MUST</bcp14> advertise its addresses 
periodically to its
          <em>neighbors</em> through <tt>HelloMessage</tt>s.
           The advertisement interval and expiration should be configurable or 
chosen at the discretion
-         of the implementation based on external factors such as DHCP leases.
+         of the implementation based on external factors such as expiration of 
DHCP leases.
           The specific frequency of advertisements <bcp14>MAY</bcp14> depend 
on available bandwidth,
           the set of already connected neighbors,  the workload of the system 
and other factors which are at the discretion of
           the developer, but <bcp14>SHOULD</bcp14> be a fraction of the 
expiration period.
           Whenever a peer receives such a  <tt>HELLO</tt>  message from 
another peer that is
-          already in the routing table, it must cache it as long as that peer 
is in its routing table
+          already in the routing table, it must cache it as long as that peer 
remains in its routing table
           (or until the <tt>HELLO</tt> expires) and serve it in response to
           <tt>GET</tt> requests for <tt>HELLO</tt> blocks (see <xref 
target="p2p_get_processing"/>).
           This behaviour makes it unnecessary to initiate dedicated 
<tt>PutMessages</tt> containing
@@ -751,19 +751,19 @@ Connectivity | |Underlay|  |Underlay|  | Underlay | ...
         <name>Peer Bloom Filter</name>
         <t>
           As DHT <tt>GetMessage</tt>s and <tt>PutMessage</tt>s traverse a 
random path through the network for the
-          first <tt>L2NSE</tt> hops, it is essential that routing loops are 
avoided.
-          This peer Bloom filter is constant in size at <tt>L=1024</tt> bits 
(128 bytes) and
-          <tt>k=16</tt> bits set per element.
+          first <tt>L2NSE</tt> hops, a key design objective of R<sup>5</sup>N 
is to avoid routing loops.
           The peer Bloom filter is part of the routing metadata in
-          messages in order to prevent circular routes and is updated at each 
hop with the hops
-          peer identity.
+          messages to prevent circular routes. It is updated at each hop where 
the hops
+          peer public key is added to it.
+          It is constant in size at <tt>L=1024</tt> bits (128 bytes) and
+          sets <tt>k=16</tt> bits per element.
           For the next hop selection in both the random and the deterministic
-          case, any peer which is in the Bloom filter for the respective 
message
-          is not included in the peer selection process.
+          case, any peer which is in the peer Bloom filter for the respective 
message
+          is excluded from the peer selection process.
         </t>
         <t>
           Any peer which is forwarding <tt>GetMessage</tt>s or 
<tt>PutMessage</tt>s
-          (<xref target="p2p_messages"/>) adds its own peer public key to the
+          (<xref target="p2p_messages"/>) thus adds its own peer public key to 
the
           peer Bloom filter.
           This allows other peers to (probabilistically) exclude already
           traversed peers when searching for the next hops in the routing 
table.
@@ -777,15 +777,17 @@ Connectivity | |Underlay|  |Underlay|  | Underlay | ...
           <tt>M(e) -> SHA-512 (e) as uint32[]</tt>
         </t>
         <t>
-          The element <tt>e</tt> is hashed using SHA-512.
-          The resulting byte string is interpreted as a string of k=16
+          The element <tt>e</tt> is the peer public key which is hashed using 
SHA-512.
+          The resulting 512-bit peer identity is interpreted as an array of 
k=16
           32-bit integers in network byte order which are used to set and 
check the bits
           in <tt>B</tt> using <tt>BF-SET</tt> and <tt>BF-TEST</tt>.
         </t>
         <t>
          We note that the peer Bloom filter may exclude peers due to 
false-postive
          matches.  This is acceptable as routing should nevertheless
-         terminate (with high probability) in close vicinity of the key.
+         terminate (with high probability) in close vicinity of the key. 
Furthermore,
+         due to the randomization of the first L2NSE hops, it is possible that
+         false-positives will be different when a request is repeated.
         </t>
       </section>
       <section anchor="routing_functions">
@@ -1000,13 +1002,21 @@ BEGIN
             to enable checking of the next signature. This flag MUST never be 
set in
             a query.
           </dd>
-          <dt>4-15: Reserved</dt>
+          <dt>4-7: Reserved</dt>
           <dd>
             The remaining bits are reserved for future use and
            <bcp14>MUST</bcp14> be set to 0 when initiating an operation.
            If non-zero bits are received, implementations <bcp14>MUST</bcp14>
            preserve these bits when forwarding messages.
           </dd>
+          <dt>8-15: Version</dt>
+          <dd>
+            These bits are used to encode the R<sup>5</sup>N DHT protocol
+           version. They <bcp14>MUST</bcp14> be set to 0. Future revisions
+           of the protocol <bcp14>MAY</bcp14> change the message format.
+           It is envisioned that other cryptographic primitives 
<bcp14>MAY</bcp14>
+           be introduced into the network protocol in the future via this 
mechanism.
+          </dd>
         </dl>
       </section>
       <section anchor="p2p_pathelement">

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