[lsd0004] branch master updated: -fix spelling of R5N

[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 d536f20  -fix spelling of R5N
d536f20 is described below

commit d536f200e4571e8d0c1f182013d67251774c1536
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Thu Mar 10 06:44:02 2022 +0100

    -fix spelling of R5N
---
 draft-schanzen-r5n.xml | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 31819fa..95ee6d9 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -73,7 +73,7 @@
     <workgroup>Independent Stream</workgroup>
     <keyword>distributed hash tables</keyword>
     <abstract>
-      <t>This document contains the R5N DHT technical specification.</t>
+      <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
@@ -81,7 +81,7 @@
       </t>
       <t>
         This specification was developed outside the IETF and does not have 
IETF
-        consensus. It is published here to guide implementation of R5N and to
+        consensus. It is published here to guide implementation of 
R<sup>5</sup>N and to
         ensure interoperability among implementations.
       </t>
     </abstract>
@@ -126,9 +126,9 @@
       </t>
       <t>
         This document contains the technical specification
-        of the R5N DHT <xref target="R5N"/>, a secure DHT routing algorithm
+        of the R<sup>5</sup>N DHT <xref target="R5N"/>, a secure DHT routing 
algorithm
         and data structure for decentralized applications.
-        R5N is an open P2P overlay routing mechanism which supports ad-hoc
+        R<sup>5</sup>N is an open P2P overlay routing mechanism which supports 
ad-hoc
         participation and security properties including support for
         topologies in restricted-route environments and path signatures.
       </t>
@@ -223,7 +223,7 @@
         <dt>Routing</dt>
         <dd>
           The Routing component includes the routing table as well as
-          routing and peer selection logic. It facilitates the R5N routing
+          routing and peer selection logic. It facilitates the R<sup>5</sup>N 
routing
           algorithm with required data structures and algorithms.
         </dd>
         <dt>Underlay Interface</dt>
@@ -238,8 +238,8 @@
     <section anchor="architecture" numbered="true" toc="default">
       <name>Architecture</name>
       <t>
-        R5N is an overlay network with a pluggable transport layer.
-        The following figure shows the R5N architecture.
+        R<sup>5</sup>N is an overlay network with a pluggable transport layer.
+        The following figure shows the R<sup>5</sup>N architecture.
       </t>
       <figure title="The R5N Architecture.">
         <artwork><![CDATA[
@@ -603,7 +603,7 @@ Connectivity | |Underlay|  |Underlay|
       <section anchor="peer_storage">
         <name>Peer Storage</name>
         <t>
-          A R5N implementation must store the information on connected peers
+          A R<sup>5</sup>N implementation must store the information on 
connected peers
           and update changes accordingly in a local persistance component such
           as a database.
           Upon receiving a connection notification from the Underlay through
@@ -667,7 +667,7 @@ Connectivity | |Underlay|  |Underlay|
         <name>Routing Table</name>
         <t>
           In order to select peers which are suitable destinations for
-          routing messages, R5N uses a hybrid approach:
+          routing messages, R<sup>5</sup>N uses a hybrid approach:
           Given an estimated network size N, the peer selection for the
           first N hops is random. After the initial N hops, peer selection
           follows an XOR-based peer distance calculation.
@@ -698,7 +698,7 @@ Connectivity | |Underlay|  |Underlay|
         <t>
           As the message traverses a random path through the network for the
           first N hops, it is essential that routing loops are avoided.
-          In R5N, a bloomfilter is used as part of the routing metadata in
+          In R<sup>5</sup>N, a bloomfilter is used as part of the routing 
metadata in
           messages. The bloomfilter is updates at each hop with the hops
           peer identity.
           For the next hop selection in both the random and the deterministic
@@ -706,7 +706,7 @@ Connectivity | |Underlay|  |Underlay|
           is not included in the peer selection process.
         </t>
         <t>
-          The R5N routing component <bcp14>MUST</bcp14> implement the 
following functions:
+          The R<sup>5</sup>N routing component <bcp14>MUST</bcp14> implement 
the following functions:
         </t>
         <dl>
           <dt>

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