hello moved

1 files changed, 248 insertions, 261 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 7b60cb6..3e9a86c 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -5,7 +5,7 @@
 <!ENTITY RFC3629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
 <!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 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">
@@ -333,83 +333,8 @@ PUT(Key, Block, BlockType[, PutParams])
        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" />.
+       This format is the "HELLO" message.
      </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 anchor="figure_hello">
-       <artwork name="" type="" align="left" alt=""><![CDATA[
-0     8     16    24    32    40    48    56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|   TYPE    |   SIZE    |         NODEID        /
-+-----+-----+-----+-----+   (variable length)   /
-/                                               /
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|                   ADDRESSES                   /
-/               (variable length)               |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-         ]]></artwork>
-     </figure>
-     <dl>
-       <dt>TYPE</dt>
-       <dd>
-         is the type of HELLO. A 16-bit number in network byte order.
-         This value determines the type of the NODEID field.
-       </dd>
-       <dt>SIZE</dt>
-       <dd>
-         is the SIZE of the following fields NODEID and ADDRESSES in bytes.
-         In network byte order.
-       </dd>
-       <dt>NODEID</dt>
-       <dd>
-         is the Node ID of the peer which has generated this HELLO.
-         The length content of the NODEID is determined by the TYPE field.
-         Usually, this is a cryptographic public key which allows the
-         Underlay to uniquely identify and authenticate the node.
-       </dd>
-       <dt>ADDRESSES</dt>
-       <dd>
-         is a list of strings which can be used as addresses to contact the
-         node. The strings MUST be 0-terminated.
-         FIXME: Examples? Format determined?
-       </dd>
-     </dl>
-     <!-- FIXME peer id type | length | id payload | 0-terminated strings for addresses
-       <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>
-     -->
 
      <!--
        1) The current API is always fire+forget, it doesn't allow for flow
@@ -1193,228 +1118,290 @@ END
          <name>HELLO</name>
          <t>
            The HELLO block type wire format is illustrated in
-           <xref target="figure_hellobt"/>. A block of type HELLO MUST NOT
-           include extended query data (xquery). Any implementation
-           encountering a HELLO block with xquery data MUST consider the
+           <xref target="figure_hello"/>. A query for block of type HELLO MUST
+           NOT include extended query data (XQuery). Any implementation
+           encountering a HELLO block with XQuery data MUST consider the
            block invalid and ignore it.
          </t>
+         <figure anchor="figure_hello">
+           <artwork name="" type="" align="left" alt=""><![CDATA[
+0     8     16    24    32    40    48    56
++-----+-----+-----+-----+-----+-----+-----+-----+
+|   TYPE    |   SIZE    |         NODEID        /
++-----+-----+-----+-----+   (variable length)   /
+/                                               /
++-----+-----+-----+-----+-----+-----+-----+-----+
+|                   ADDRESSES                   /
+/               (variable length)               |
++-----+-----+-----+-----+-----+-----+-----+-----+
+               ]]>
+           </artwork>
+         </figure>
+         <dl>
+           <dt>TYPE</dt>
+           <dd>
+             is the type of HELLO. A 16-bit number in network byte order.
+             This value determines the type of the NODEID field.
+           </dd>
+           <dt>SIZE</dt>
+           <dd>
+             is the SIZE of the following fields NODEID and ADDRESSES in bytes.
+             In network byte order.
+           </dd>
+           <dt>NODEID</dt>
+           <dd>
+             is the Node ID of the peer which has generated this HELLO.
+             The length content of the NODEID is determined by the TYPE field.
+             Usually, this is a cryptographic public key which allows the
+             Underlay to uniquely identify and authenticate the node.
+           </dd>
+           <dt>ADDRESSES</dt>
+           <dd>
+             is a list of UTF-8 strings <xref target="RFC3629"/> which can be
+             used as addresses to contact the node.
+             The strings MUST be 0-terminated.
+             FIXME: Examples? Format determined?
+           </dd>
+         </dl>
          <t>
            A HELLO reply block MAY be empty. Otherwise, it contains the
-           HELLO URI of a peer.
+           HELLO of a node.
+         </t>
+         <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 <tt>ADDRESSES</tt> part of the <tt>HELLO</tt> indicate endpoints
+           which can be used by the Underlay in order to establish a connection
+           with the node identified by <tt>NODEID</tt>.
+           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 address strings:
          </t>
-         <figure anchor="figure_hellobt">
+         <figure>
            <artwork name="" type="" align="left" alt=""><![CDATA[
-         FIXME: Wire format
-         ]]></artwork>
-         </figure>
-       </section>
+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>
      </section>
    </section>
-
-
-   <section>
-     <name>Bootstrapping</name>
-     <t>
-       It is assumed that the peer is already connected to at least
-       one other peer.
-       First, those initial peers are sorted into their respective buckets.
-     </t>
-     <t>
-       In order to find the closest peers in the network to itself, an
-       implementation MUST now periodically send HELLO GET queries for its own
-       peer ID.
-       Both the "record route" and "find peer" message options are set in the
-       GET queries in order to learn peers and network topology from the
-       message route and in order to receive approximate replies to the
-       query key (the peer ID).
-     </t>
-     <t>FIXME: Periodically -> more specific? No. Frequency may be adapted depending on network conditions, known peers, busy/idle etc.</t>
-     <t>
-       Any implementation encountering a HELLO GET request initially
-       sends its own peer ID if it.
-     </t>
-   </section>
-   <section anchor="security" numbered="true" toc="default">
-     <name>Security Considerations</name>
-     <!-- FIXME: Here we should (again) discuss how the system is open and
+ </section>
+ <section>
+   <name>Bootstrapping</name>
+   <t>
+     It is assumed that the peer is already connected to at least
+     one other peer.
+     First, those initial peers are sorted into their respective buckets.
+   </t>
+   <t>
+     In order to find the closest peers in the network to itself, an
+     implementation MUST now periodically send HELLO GET queries for its own
+     peer ID.
+     Both the "record route" and "find peer" message options are set in the
+     GET queries in order to learn peers and network topology from the
+     message route and in order to receive approximate replies to the
+     query key (the peer ID).
+   </t>
+   <t>FIXME: Periodically -> more specific? No. Frequency may be adapted depending on network conditions, known peers, busy/idle etc.</t>
+   <t>
+     Any implementation encountering a HELLO GET request initially
+     sends its own peer ID if it.
+   </t>
+ </section>
+ <section anchor="security" numbered="true" toc="default">
+   <name>Security Considerations</name>
+   <!-- FIXME: Here we should (again) discuss how the system is open and
      does not have/require a trust anchor a priori. This is (again) in contrast
-     to RELOAD -->
-   </section>
-   <section anchor="gana" numbered="true" toc="default">
-       <name>GANA Considerations</name>
-       <t>
-         GANA <xref target="GANA" />
-         is requested to create a "DHT Block Types" registry.
-         The registry shall record for each entry:
-       </t>
-       <ul>
-         <li>Name: The name of the block type (case-insensitive ASCII
-           string, restricted to alphanumeric characters</li>
-         <li>Number: 32-bit</li>
-         <li>Comment: Optionally, a brief English text describing the purpose of
-           the block type (in UTF-8)</li>
-         <li>Contact: Optionally, the contact information of a person to contact for
-           further information</li>
-         <li>References: Optionally, references describing the record type
-           (such as an RFC)</li>
-       </ul>
-       <t>
-         The registration policy for this sub-registry is "First Come First
-         Served", as described in <xref target="RFC8126"/>.
-         GANA is requested to populate this registry as follows:
-       </t>
-       <figure anchor="figure_btypenums">
-         <artwork name="" type="" align="left" alt=""><![CDATA[
+   to RELOAD -->
+ </section>
+ <section anchor="gana" numbered="true" toc="default">
+   <name>GANA Considerations</name>
+   <t>
+     GANA <xref target="GANA" />
+     is requested to create a "DHT Block Types" registry.
+     The registry shall record for each entry:
+   </t>
+   <ul>
+     <li>Name: The name of the block type (case-insensitive ASCII
+       string, restricted to alphanumeric characters</li>
+     <li>Number: 32-bit</li>
+     <li>Comment: Optionally, a brief English text describing the purpose of
+       the block type (in UTF-8)</li>
+     <li>Contact: Optionally, the contact information of a person to contact for
+       further information</li>
+     <li>References: Optionally, references describing the record type
+       (such as an RFC)</li>
+   </ul>
+   <t>
+     The registration policy for this sub-registry is "First Come First
+       Served", as described in <xref target="RFC8126"/>.
+       GANA is requested to populate this registry as follows:
+     </t>
+     <figure anchor="figure_btypenums">
+       <artwork name="" type="" align="left" alt=""><![CDATA[
 Number | Name   | Contact | References | Description
 -------+--------+---------+------------+-------------------------
 0       ANY      N/A       [This.I-D]   Reserved
 7       HELLO    N/A       [This.I-D]   Type of a block that contains
-                                        a HELLO for a peer
+a HELLO for a peer
 11      GNS      N/A       GNS          Block for storing record data
-           ]]></artwork>
-       </figure>
-       <t>
-         GANA is requested to amend the "GNUnet Signature Purpose" registry
-         as follows:
-       </t>
-       <figure anchor="figure_purposenums">
-         <artwork name="" type="" align="left" alt=""><![CDATA[
+]]>
+       </artwork>
+     </figure>
+     <t>
+       GANA is requested to amend the "GNUnet Signature Purpose" registry
+       as follows:
+     </t>
+     <figure anchor="figure_purposenums">
+       <artwork name="" type="" align="left" alt=""><![CDATA[
 Purpose | Name            | References | Description
 --------+-----------------+------------+--------------------------
-           ]]></artwork>
-       </figure>
-     </section>
-     <!-- gana -->
-     <section>
-       <name>Test Vectors</name>
+]]>
+       </artwork>
+     </figure>
+   </section>
+   <!-- gana -->
+   <section>
+     <name>Test Vectors</name>
    </section>
-   </middle>
-   <back>
-     <references>
-       <name>Normative References</name>
+ </middle>
+ <back>
+   <references>
+     <name>Normative References</name>
 
-         &RFC2119;
-         &RFC3629;
-         &RFC3986;
-         &RFC4648;
-         &RFC6940;
-         &RFC8126;
-         &RFC8174;
- 
-      <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>
+       &RFC2119;
+       &RFC3629;
+     <!--&RFC3986; URI-->
+       &RFC4648;
+       &RFC6940;
+       &RFC8126;
+       &RFC8174;
 
-          <author initials="N." surname="Duif"
-            fullname="Niels Duif">
-          <organization>Technische Universiteit Eindhoven</organization>
+     <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>
-          <author initials="T." surname="Lange"
-            fullname="Tanja Lange">
-          <organization>Technische Universiteit Eindhoven</organization>
+         <author initials="N." surname="Duif"
+           fullname="Niels Duif">
+         <organization>Technische Universiteit Eindhoven</organization>
 
-          </author>
-          <author initials="P." surname="Schwabe"
-            fullname="Peter Schwabe">
-          <organization>National Taiwan University</organization>
+       </author>
+       <author initials="T." surname="Lange"
+         fullname="Tanja Lange">
+       <organization>Technische Universiteit Eindhoven</organization>
 
-          </author>
-          <author initials="B." surname="Yang"
-            fullname="Bo-Yin Yang">
-          <organization>Academia Sinica</organization>
+     </author>
+     <author initials="P." surname="Schwabe"
+       fullname="Peter Schwabe">
+     <organization>National Taiwan University</organization>
 
-          </author>
-           <date year="2011"/>
-         </front>
-       </reference>
+   </author>
+   <author initials="B." surname="Yang"
+     fullname="Bo-Yin Yang">
+   <organization>Academia Sinica</organization>
 
-       <reference anchor="CrockfordB32" target="https://www.crockford.com/base32.html">
-         <front>
-           <title>Base32</title>
-          <author initials="D." surname="Douglas" fullname="Crockford">
-          </author>
+ </author>
+ <date year="2011"/>
+     </front>
+   </reference>
 
-           <date year="2019" month="March"/>
-         </front>
-       </reference>
+   <reference anchor="CrockfordB32" target="https://www.crockford.com/base32.html">
+     <front>
+       <title>Base32</title>
+       <author initials="D." surname="Douglas" fullname="Crockford">
+       </author>
 
-       <reference anchor="GANA" target="https://gana.gnunet.org/">
-         <front>
-           <title>GNUnet Assigned Numbers Authority (GANA)</title>
-           <author><organization>GNUnet e.V.</organization>
-           </author>
-           <date month="April" year="2020" />
-         </front>
-       </reference>
+       <date year="2019" month="March"/>
+     </front>
+   </reference>
 
+   <reference anchor="GANA" target="https://gana.gnunet.org/">
+     <front>
+       <title>GNUnet Assigned Numbers Authority (GANA)</title>
+       <author><organization>GNUnet e.V.</organization>
+       </author>
+       <date month="April" year="2020" />
+     </front>
+   </reference>
 
 
-     </references>
-     <references>
-       <name>Informative References</name>
-      <reference anchor="R5N" target="https://doi.org/10.1109/ICNSS.2011.6060022">
-         <front>
-           <title>R5N: Randomized recursive routing for restricted-route networks</title>
-          <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
-            <organization>Technische Universität München</organization>
-          </author>
 
-          <author initials="C." surname="Grothoff"
-            fullname="Christian Grothoff">
-          <organization>Technische Universität München</organization>
-          </author>
-           <date year="2011"/>
-         </front>
-       </reference>
-       <reference anchor="Kademlia" target="http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf">
-         <front>
-           <title>Kademlia: A peer-to-peer information system based on the xor metric.</title>
-          <author initials="P." surname="Maymounkov" fullname="Petar Maymounkov">
-          </author>
+ </references>
+ <references>
+   <name>Informative References</name>
+   <reference anchor="R5N" target="https://doi.org/10.1109/ICNSS.2011.6060022">
+     <front>
+       <title>R5N: Randomized recursive routing for restricted-route networks</title>
+       <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
+         <organization>Technische Universität München</organization>
+       </author>
+
+       <author initials="C." surname="Grothoff"
+         fullname="Christian Grothoff">
+       <organization>Technische Universität München</organization>
+     </author>
+     <date year="2011"/>
+   </front>
+ </reference>
+ <reference anchor="Kademlia" target="http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf">
+   <front>
+     <title>Kademlia: A peer-to-peer information system based on the xor metric.</title>
+     <author initials="P." surname="Maymounkov" fullname="Petar Maymounkov">
+     </author>
 
-          <author initials="D." surname="Mazieres"
-            fullname="David Mazieres">
-        </author>
-           <date year="2002"/>
-         </front>
+     <author initials="D." surname="Mazieres"
+       fullname="David Mazieres">
+   </author>
+   <date year="2002"/>
+ </front>
        </reference>
 
        <reference anchor="cadet" target="https://doi.org/10.1109/MedHocNet.2014.6849107">
          <front>
            <title>CADET: Confidential ad-hoc decentralized end-to-end transport</title>
-          <author initials="B." surname="Polot" fullname="Bartlomiej Polot">
-            <organization>Technische Universität München</organization>
-          </author>
+           <author initials="B." surname="Polot" fullname="Bartlomiej Polot">
+             <organization>Technische Universität München</organization>
+           </author>
 
-          <author initials="C." surname="Grothoff"
-            fullname="Christian Grothoff">
-          <organization>Technische Universität München</organization>
-          </author>
-           <date year="2014"/>
-         </front>
-       </reference>
-       <reference anchor="I-D.draft-schanzen-gns" target="https://datatracker.ietf.org/doc/draft-schanzen-gns/">
-         <front>
-           <title>The GNU Name System</title>
-          <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach">
-            <organization>GNUnet e.V.</organization>
-          </author>
+           <author initials="C." surname="Grothoff"
+             fullname="Christian Grothoff">
+           <organization>Technische Universität München</organization>
+         </author>
+         <date year="2014"/>
+       </front>
+     </reference>
+     <reference anchor="I-D.draft-schanzen-gns" target="https://datatracker.ietf.org/doc/draft-schanzen-gns/">
+       <front>
+         <title>The GNU Name System</title>
+         <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach">
+           <organization>GNUnet e.V.</organization>
+         </author>
 
-          <author initials="C." surname="Grothoff"
-            fullname="Christian Grothoff">
-          <organization>GNUnet e.V.</organization>
-        </author>
-          <author initials="B." surname="Fix"
-            fullname="Bernd Fix">
-          <organization>GNUnet e.V.</organization>
-          </author>
-           <date year="2021"/>
-         </front>
-       </reference>
+         <author initials="C." surname="Grothoff"
+           fullname="Christian Grothoff">
+         <organization>GNUnet e.V.</organization>
+       </author>
+       <author initials="B." surname="Fix"
+         fullname="Bernd Fix">
+       <organization>GNUnet e.V.</organization>
+     </author>
+     <date year="2021"/>
+   </front>
+ </reference>