commit 9c8096bc033985fdfb1247a2275ced82253bc8c9
parent 2ac5ecf82d1a00fbc399247579f1b28d602c09a1
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Fri, 23 Dec 2022 18:14:02 +0900
Rewrite abstract and introduction
Diffstat:
1 file changed, 45 insertions(+), 24 deletions(-)
diff --git 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>
