[lsd0004] branch master updated: add addressing

[gnunet]

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

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

The following commit(s) were added to refs/heads/master by this push:
     new 281d0e1  add addressing
281d0e1 is described below

commit 281d0e12537f218797b84f6ac0b474325eac5585
Author: Martin Schanzenbach <mschanzenbach@posteo.de>
AuthorDate: Sat Jun 26 17:05:13 2021 +0200

    add addressing
---
 draft-schanzen-r5n.xml | 145 ++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 143 insertions(+), 2 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 317d784..92815ef 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -6,6 +6,7 @@
 <!ENTITY RFC3686 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml";>
 <!ENTITY RFC3826 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml";>
 <!ENTITY RFC3912 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml";>
+<!ENTITY RFC3986 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml";>
 <!ENTITY RFC4648 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml";>
 <!ENTITY RFC5869 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml";>
 <!ENTITY RFC5890 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml";>
@@ -106,6 +107,102 @@
 
      </t>
    </section>
+   <section anchor="connectivity" numbered="true" toc="default">
+     <name>Connectivity and addressing</name>
+     <t>
+       In the DHT overlay, a peer is addressable by its Peer ID.
+       The Peer ID is the 256-bit hash of the peer public key.
+       The peer public key is the public key of the corresponding
+       Ed25519<xref target="ed25519" /> peer private key.
+     </t>
+     <t>
+       In the network underlay, a peer is addressable by traditional
+       means out of scope of this document. For example, the peer may
+       have a TCP/IP address, or a HTTPS endpoint.
+       While the specific addressing options and mechanisms are out of scope
+       for this document, it is necessary to define a universal addressing
+       format in order to facilitate the distribution of connectivity
+       information to other peers in the DHT overlay.
+       This format is the "HELLO" message. A "HELLO" is a human-readable
+       UTF-8  <xref target="RFC3629" /> string consisting of the peer
+       public key and the HELLO URI <xref target="RFC3986" />.
+     </t>
+       <figure>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+hello-format := <peer-public-key> <hello-uri>
+peer-public-key := [A-HJ-NP-Z1-9]+
+         ]]></artwork>
+     </figure>
+     <t>
+       For the string representation of the peer public key,
+       the base-32 encoding "StringEncode" is used.
+       However, instead of following <xref target="RFC4648"/> the
+       character map is based on the optical character recognition friendly
+       proposal of Crockford <xref target="CrockfordB32"/>.
+       The only difference to Crockford is that the letter
+       "U" decodes to the same base-32 value as the letter "V" (27).
+     </t>
+     <t>
+       The "scheme" part of the HELLO URI defined the addressing scheme
+       which is used. An example of an addressing scheme used throughout
+       this document is "ip+tcp", which refers to a standard TCP/IP socket
+       connection. The "hier"-part of the URI must provide a suitable
+       address for the given addressing scheme.
+       The following is a non-normative example of a HELLO containing three
+       HELLO URIs:
+     </t>
+       <figure>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+Y924NSHMMZ1N1SQCE5TXF93ED6S6JY311K0QT86G9WJC68F6XVZ0 \
+        ip+tcp://1.2.3.4:6789 \
+        gnunet+tcp://12.3.4.5/ \
+        i2p+udp://1.2.4.5:424/ \
+        tor+onionv3://rasdflkjasdfliasduf.onion/
+         ]]></artwork>
+     </figure>
+
+     <t>
+       It is expected that there are basic mechanisms available to
+       manage peer connectivity and addressing.
+       The required functionality are abstracted through the following
+       procedures and events:
+     </t>
+     <dl>
+       <dt>PEER_CONNECTIVITY_CHANGED</dt>
+       <dd>
+         is a signal that allows the DHT to react to peers which connect or
+         disconnect. Such an event triggers, for example, updates in the
+         routing table.
+       </dd>
+       <dt>CONNECT</dt>
+       <dd>
+         A function which allows a peer to attempt the establishment of
+         a connection to another peer using an address.
+       </dd>
+       <dt>RECEIVE</dt>
+       <dd>
+         A function or event that allows the peer to receive protocol
+         messages as defined in this document from a connected peer.
+       </dd>
+       <dt>SEND</dt>
+       <dd>
+         A function that allows a peer to send protocol messages as defined
+         in this document to a connected peer.
+       </dd>
+       <dt>NETWORK_SIZE_ESTIMATE</dt>
+       <dd>
+         A function or event that provides estimates on the network size
+         for use in the DHT routing algorithms.
+       </dd>
+       <dt>ADDRESS_CHANGED</dt>
+       <dd>
+         An event that allows the DHT to learn and react to address changes
+         of the peer. This information is used, for example, to publish
+         connectivity as part of the bootstrapping and overlay creation.
+       </dd>
+     </dl>
+   </section>
+
    <section anchor="p2p_messages" numbered="true" toc="default">
      <name>Peer-to-peer wire formats</name>
       <section anchor="p2p_bf" numbered="true" toc="default">
@@ -439,8 +536,52 @@ Purpose | Name            | References | Description
      <references>
        <name>Normative References</name>
 
-       &RFC2119;
-       &RFC8126;
+         &RFC2119;
+         &RFC3629;
+         &RFC3986;
+         &RFC4648;
+         &RFC8126;
+ 
+      <reference anchor="ed25519" 
target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9";>
+         <front>
+           <title>High-Speed High-Security Signatures</title>
+          <author initials="D." surname="Bernstein" fullname="Daniel 
Bernstein">
+            <organization>University of Illinois at Chicago</organization>
+          </author>
+
+          <author initials="N." surname="Duif"
+            fullname="Niels Duif">
+          <organization>Technische Universiteit Eindhoven</organization>
+
+        </author>
+          <author initials="T." surname="Lange"
+            fullname="Tanja Lange">
+          <organization>Technische Universiteit Eindhoven</organization>
+
+          </author>
+          <author initials="P." surname="Schwabe"
+            fullname="Peter Schwabe">
+          <organization>National Taiwan University</organization>
+
+          </author>
+          <author initials="B." surname="Yang"
+            fullname="Bo-Yin Yang">
+          <organization>Academia Sinica</organization>
+
+          </author>
+           <date year="2011"/>
+         </front>
+       </reference>
+
+       <reference anchor="CrockfordB32" 
target="https://www.crockford.com/base32.html";>
+         <front>
+           <title>Base32</title>
+          <author initials="D." surname="Douglas" fullname="Crockford">
+          </author>
+
+           <date year="2019" month="March"/>
+         </front>
+       </reference>
 
        <reference anchor="GANA" target="https://gana.gnunet.org/";>
          <front>

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