gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lsd0004] 02/03: Rewrite abstract and introduction


From: gnunet
Subject: [lsd0004] 02/03: Rewrite abstract and introduction
Date: Fri, 23 Dec 2022 10:14:52 +0100

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

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

commit 9c8096bc033985fdfb1247a2275ced82253bc8c9
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Fri Dec 23 18:14:02 2022 +0900

    Rewrite abstract and introduction
---
 draft-schanzen-r5n.xml | 69 ++++++++++++++++++++++++++++++++------------------
 1 file changed, 45 insertions(+), 24 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index d9bd0be..01649ee 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -74,16 +74,24 @@
     <workgroup>Independent Stream</workgroup>
     <keyword>distributed hash tables</keyword>
     <abstract>
-      <t>This document contains the R<sup>5</sup>N DHT technical 
specification.</t>
       <t>
-        This document defines the normative wire format of resource records,
-        resolution processes, cryptographic routines and security 
considerations for
+        This document contains the R<sup>5</sup>N DHT technical specification.
+        R<sup>5</sup>N is a secure distributed hash table (DHT) routing 
algorithm
+        and data structure for decentralized applications.
+        It features an open peer-to-peer overlay routing mechanism which 
supports ad-hoc
+        permissionless participation and support for topologies in 
restricted-route
+        environments.
+      </t>
+      <t>
+        This document defines the normative wire format of protocol messages,
+        routing algorithms, cryptographic routines and security considerations 
for
         use by implementers.
       </t>
       <t>
         This specification was developed outside the IETF and does not have 
IETF
         consensus. It is published here to guide implementation of 
R<sup>5</sup>N and to
-        ensure interoperability among implementations.
+        ensure interoperability among implementations including the 
pre-existing
+        GNUnet implementation.
       </t>
     </abstract>
   </front>
@@ -110,30 +118,28 @@
         in RELOAD. The argumentation revolves around the trust model 
(openness) and
         security aspects (path signatures).-->
       <t>
-        Distributed Hash Tables (DHTs) are a key data structure for the
-        construction of decentralized applications.
-        DHTs are important because they generally provide a robust and
-        efficient means to distribute the storage and retrieval of
-        key-value pairs.
+        This specification describes the protocol of R<sup>5</sup>N.
+        R<sup>5</sup> stands for "randomized recursive routing for 
restricted-route
+        networks" and its first academic description can be found in
+        <xref target="R5N"/>.
       </t>
       <t>
-        While <xref target="RFC6940"/> already provides a peer-to-peer (P2P)
-        signaling protocol with extensible routing and topology mechanisms,
-        it also relies on strict admission control through the use of either
-        centralized enrollment servers or pre-shared keys.
-        Some decentralized applications require a more open system that
-        enables ad-hoc participation and other means to prevent common attacks
-        on P2P overlays.
+        R<sup>5</sup>N is a Distributed Hash Table (DHTs).
+        DHTs are a key data structure for the construction of decentralized 
applications.
+        and they generally provide a robust and efficient means to distribute 
the
+        storage and retrieval of key-value pairs.
       </t>
       <t>
-        This document contains the technical specification
-        of the R<sup>5</sup>N DHT <xref target="R5N"/>, a secure DHT routing 
algorithm
-        and data structure for decentralized applications.
-        R<sup>5</sup>N is an open P2P overlay routing mechanism which supports 
ad-hoc
-        permissionless participation and support for
-        topologies in restricted-route environments.  R<sup>5</sup>N also
-       includes advanced features like tracing paths messages take through the
-       network, response filters and on-path application-specific data 
validation.
+        The core idea behind R<sup>5</sup>N is to combine an initial 
randomized routing
+        algorithm with an efficient, classical closest-peer algorithm.
+        This allows us to construct an algorithm that is able to escape and 
circumvent
+        restricted route environments while at the same time allow for O(log 
n) routing
+        complexity.
+      </t>
+      <t>
+        R<sup>5</sup>N also includes advanced features like tracing paths 
messages take
+        through the network, response filters and on-path application-specific 
data
+        validation.
       </t>
       <t>
         This document defines the normative wire format of peer-to-peer
@@ -2568,6 +2574,21 @@ gnunet+tcp://12.3.4.5/ \
           filtered by the result filter.
         </t>
       </section>
+      <section>
+        <name>Access control</name>
+        <t>
+          By design R<sup>5</sup>N does not rely on strict admission control 
through
+          the use of either centralized enrollment servers or pre-shared keys.
+          This is a key distintion over protocols that do rely on this kind of 
access
+          control such as <xref target="RFC6940"/> which, like R<sup>5</sup>N, 
provides
+          a peer-to-peer (P2P) signaling protocol with extensible routing and 
topology
+          mechanisms.
+          <!-- FIXME: Can we give examples here? -->
+          Some decentralized applications require a more open system that
+          enables ad-hoc participation and other means to prevent common 
attacks
+          on P2P overlays.
+        </t>
+      </section>
     </section>
     <section anchor="iana" numbered="true" toc="default">
       <name>IANA Considerations</name>

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]