1 files changed, 114 insertions, 131 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index f4a8099..dcc05d7 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -202,6 +202,18 @@
         The peer that initially creates and sends a GetMessage (<xref target="p2p_get"/>) or
         PutMessage message (<xref target="p2p_put"/>).
       </dd>
+      <dt>HELLO block</dt>
+      <dd>
+        A HELLO block is a block with a dedicated block type and is specified in this document.
+        The HELLO block is used to store and retrieve Peer addresses.
+        In this document, HELLO blocks are used by the peer discovery mechanism.
+      </dd>
+      <dt>HELLO URL</dt>
+      <dd>
+        HELLO URLs are URL-formatted HELLO blocks.
+        They can used for out-of-band exchanges of peer information and are used for
+        address update signalling messages to neighbours.
+      </dd>
       <dt>Key</dt>
       <dd>
         512-bit identifier of a location in the DHT. Multiple <tt>Block</tt>s can be
@@ -320,8 +332,8 @@
       <t>
         In order to establish an initial connection to a network of R<sup>5</sup>N
         peers, an initial, addressable bootstrap peer is required.
-        Further peers, including neighbors, are then learned via a bootstrapping
-        process as defined in <xref target="bootstrapping"/>.
+        Further peers, including neighbors, are then learned via a peer discovery
+        process as defined in <xref target="find_peer"/>.
       </t>
       <t>
         Across this document, the functional components of an R<sup>5</sup>N
@@ -519,133 +531,6 @@ Connectivity | |Underlay|  |Underlay|
         and message transmission.
       </t>
     </section>
-    <section anchor="bootstrapping">
-      <name>Bootstrapping</name>
-      <t>
-        Initially, the implementation depends upon either the Underlay providing at
-        least one initial connection to a peer (signalled through
-        <tt>PEER_CONNECTED</tt>), or the application/end-user providing at
-        least one working HELLO to the DHT for bootstrapping.
-        While details on how the first connection is established <bcp14>MAY</bcp14>
-        depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done
-        by an out-of-band exchange of the information from a HELLO block.
-        <!-- FIXME: Is this really an encoding of a block? It seems to me that "HELLO"
-             is not properly defined. -->
-        For this, section <xref target="hello_url"/> specifies a URL format for encoding HELLO
-        blocks as text strings which <bcp14>SHOULD</bcp14> be supported by implementations.
-      </t>
-      <t>
-        Regardless of how the initial connections are established, the
-        peers resulting from these initial connections
-        are subsequently stored in the routing table component
-        <xref target="routing_table"/>.
-      </t>
-      <t>
-        Furthermore, the Underlay <bcp14>SHOULD</bcp14> provide the implementation with one or more
-        addresses signalled through <tt>ADDRESS_ADDED</tt>.  Zero addresses <bcp14>MAY</bcp14> be
-        provided if a peer can only establish outgoing connections and is otherwise unreachable.
-        <!-- FIXME: What about HelloMessages? What is the distinction between HELLO blocks
-             and HELLO messages? -->
-        The implementation periodically advertises all
-        active addresses in a HELLO block <xref target="hello_block"/>.
-      </t>
-      <t>
-        <!-- FIXME: Maybe make this a SHOULD and explain what happens if the implementation
-             does not. We should allow a minimal implementation of the protocol. -->
-        In order to fill its routing table by finding close peers in the network, an
-        implementation <bcp14>MUST</bcp14> now periodically send peer discovery messages
-        <xref target="find_peer"/>.
-      </t>
-      <t>
-        The frequency of advertisement and peer discovery messages
-        <bcp14>MAY</bcp14> be adapted according to network conditions,
-        the set of already connected neighbors,
-        the workload of the system and other factors which are at the discretion of
-        the developer.
-      </t>
-      <t>
-        <!-- FIXME: This whole section is a bit odd and I think we should breat it up
-             into an overview and the below explanaton should be part of message
-             processing -->
-        Any implementation encountering a HELLO GET request <bcp14>MUST</bcp14> respond
-        with its own HELLO block except if that block is
-        filtered by the request's result filter (see <xref target="result_filter"/>).
-        Implementations <bcp14>MAY</bcp14> respond
-        with additional valid HELLO blocks of other peers with keys
-        closest to the key of the GET request.  A HELLO block is "valid"
-        if it is non-expired and
-        is not excluded by the result filter.  "closest" is defined
-        by considering the distances between the request's key and the
-        peer addresses of all of the valid HELLO blocks known at the local node.
-      </t>
-      <section anchor="hello_url">
-        <name>HELLO URLs</name>
-        <t>
-          The general format of a HELLO URL uses "gnunet://"
-          as the scheme, followed by "hello/" for the name
-          of the GNUnet subsystem, followed by "/"-separated values
-          with the GNS Base32 encoding (<xref target="I-D.schanzen-gns"/>) of
-          the <tt>Peer ID</tt>, a Base32-encoded EdDSA signature, and an expiration
-          time in seconds since the UNIX Epoch in decimal format.
-          After this a "?" begins a list of key-value pairs where the key
-          is the URI scheme of one of the peer's addresses and the value
-          is the URL-escaped payload of the address URI without the "://".
-        </t>
-        <t>
-          For example, consider the following URL:
-        </t>
-        <figure>
-          <artwork type="abnf"><![CDATA[
-gnunet://hello/RH1M20EPK834M6MHZ72\
-G3CMBSF3ECKNY4W0T9VAQP9Z7SZEM6Y3G/\
-NGRTAH6RA04X467CGCH7M7CEXR5F9CV5HT\
-ZFK0G9BWETY3CCE2QWGVT4WA7JN5M9HMWG\
-60A00R71F1PJP8N5628EKGHHBAGA7M8JW3\
-0/1647134480?udp=127.0.0.1%3A2086
-
-FIXME: signature is invalid, should
-maybe generate proper test vector.
-]]>
-        </artwork>
-        </figure>
-        <t>
-          It specifies that the peer with the ID "RH1M...6Y3G"
-          is reachable via "udp" at 127.0.0.1 on port 2086 until
-          1647134480 seconds after the Epoch.  Note that "udp"
-          here is underspecified and just used as a simple example.
-          <!-- FIXME: Must be supported by which underlay?
-               This does not make sense. I may be able to generate
-               addr-names that my underlay supports, but there is not
-               way to guarantee that all underlays support it. -->
-          In practice, the key (addr-name)
-          <bcp14>MUST</bcp14> refer to a scheme supported by a
-          DHT Underlay.
-        </t>
-        <t>
-          The general syntax of HELLO URLs specified using
-          Augmented Backus-Naur Form (ABNF) of <xref target="RFC5234"/> is:
-        </t>
-        <figure>
-          <artwork type="abnf"><![CDATA[
-hello-URL = "gnunet://hello/" meta [ "?" addrs ]
-meta = pid "/" sig "/" exp
-pid = *bchar
-sig = *bchar
-exp = *DIGIT
-addrs = addr *( "&" addr )
-addr = addr-name "=" addr-value
-addr-name = scheme
-addr-value = *pchar
-bchar = *(ALPHA / DIGIT)
-]]>
-        </artwork>
-        </figure>
-        <t>
-         'scheme' is defined in <xref target="RFC3986" /> in Section 3.1.
-         'pchar' is defined in <xref target="RFC3986" />, Appendix A.
-        </t>
-      </section>
-    </section>
     <section anchor="routing" numbered="true" toc="default">
       <name>Routing</name>
       <t>
@@ -689,6 +574,20 @@ bchar = *(ALPHA / DIGIT)
           upper limit on the number of neighbors kept per k-bucket.
         </t>
         <t>
+          Initially, the implementation depends upon either the Underlay providing at
+          least one initial connection to a peer (signalled through
+          <tt>PEER_CONNECTED</tt>), or the application/end-user providing at
+          least one working HELLO to the DHT for bootstrapping.
+          While details on how the first connection is established <bcp14>MAY</bcp14>
+          depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done
+          by an out-of-band exchange of the information from a HELLO block.
+          <!-- FIXME: Is this really an encoding of a block? It seems to me that "HELLO"
+               is not properly defined.
+               FIXME: Should? Isn't this part of the HelloMessage? -->
+          For this, section <xref target="hello_url"/> specifies a URL format for encoding HELLO
+          blocks as text strings which <bcp14>SHOULD</bcp14> be supported by implementations.
+        </t>
+        <t>
           Implementations <bcp14>SHOULD</bcp14> try to keep at least
           5 entries per k-bucket.  Embedded systems that cannot manage
           this number of connections <bcp14>MAY</bcp14> use connection-level
@@ -730,6 +629,22 @@ bchar = *(ALPHA / DIGIT)
           Peer Discovery requests.  Details about the format of the
           HELLO message are given in <xref target="p2p_hello_wire"/>.
         </t>
+        <t>
+          The frequency of advertisement and peer discovery messages
+          <bcp14>MAY</bcp14> be adapted according to network conditions,
+          the set of already connected neighbors,
+          the workload of the system and other factors which are at the discretion of
+          the developer.
+        </t>
+        <t>
+          Furthermore, the Underlay <bcp14>SHOULD</bcp14> provide the implementation with one or more
+          addresses signalled through <tt>ADDRESS_ADDED</tt>. Zero addresses <bcp14>MAY</bcp14> be
+          provided if a peer can only establish outgoing connections and is otherwise unreachable.
+          <!-- FIXME: What about HelloMessages? What is the distinction between HELLO blocks
+               and HELLO messages? -->
+          The implementation periodically advertises all
+          active addresses in a HELLO block <xref target="hello_block"/>.
+        </t>
       </section>
       <section anchor="routing_bloomfilter">
         <name>Peer Bloom Filter</name>
@@ -1767,7 +1682,8 @@ BEGIN
                 <li>
                   If <tt>BTYPE</tt> indicates a request for a HELLO block or
                   <tt>ANY</tt>,
-                  the peer <bcp14>MUST</bcp14> consult the HELLOs it has cached for the
+                  the peer <bcp14>MUST</bcp14> consult its own HELLO as well as
+                  the HELLOs it has cached for the
                   peers in its routing table instead of the local block
                   storage (while continuing to respect flags like
                   <tt>DemultiplexEverywhere</tt>
@@ -3020,5 +2936,72 @@ Type    | Name            | References | Description
         </t>
       </section>
     </section>
-  </back>
+  <section anchor="hello_url">
+        <name>HELLO URLs</name>
+        <t>
+          The general format of a HELLO URL uses "gnunet://"
+          as the scheme, followed by "hello/" for the name
+          of the GNUnet subsystem, followed by "/"-separated values
+          with the GNS Base32 encoding (<xref target="I-D.schanzen-gns"/>) of
+          the <tt>Peer ID</tt>, a Base32-encoded EdDSA signature, and an expiration
+          time in seconds since the UNIX Epoch in decimal format.
+          After this a "?" begins a list of key-value pairs where the key
+          is the URI scheme of one of the peer's addresses and the value
+          is the URL-escaped payload of the address URI without the "://".
+        </t>
+        <t>
+          For example, consider the following URL:
+        </t>
+        <figure>
+          <artwork type="abnf"><![CDATA[
+gnunet://hello/RH1M20EPK834M6MHZ72\
+G3CMBSF3ECKNY4W0T9VAQP9Z7SZEM6Y3G/\
+NGRTAH6RA04X467CGCH7M7CEXR5F9CV5HT\
+ZFK0G9BWETY3CCE2QWGVT4WA7JN5M9HMWG\
+60A00R71F1PJP8N5628EKGHHBAGA7M8JW3\
+0/1647134480?udp=127.0.0.1%3A2086
+
+FIXME: signature is invalid, should
+maybe generate proper test vector.
+]]>
+        </artwork>
+        </figure>
+        <t>
+          It specifies that the peer with the ID "RH1M...6Y3G"
+          is reachable via "udp" at 127.0.0.1 on port 2086 until
+          1647134480 seconds after the Epoch.  Note that "udp"
+          here is underspecified and just used as a simple example.
+          <!-- FIXME: Must be supported by which underlay?
+               This does not make sense. I may be able to generate
+               addr-names that my underlay supports, but there is not
+               way to guarantee that all underlays support it. -->
+          In practice, the key (addr-name)
+          <bcp14>MUST</bcp14> refer to a scheme supported by a
+          DHT Underlay.
+        </t>
+        <t>
+          The general syntax of HELLO URLs specified using
+          Augmented Backus-Naur Form (ABNF) of <xref target="RFC5234"/> is:
+        </t>
+        <figure>
+          <artwork type="abnf"><![CDATA[
+hello-URL = "gnunet://hello/" meta [ "?" addrs ]
+meta = pid "/" sig "/" exp
+pid = *bchar
+sig = *bchar
+exp = *DIGIT
+addrs = addr *( "&" addr )
+addr = addr-name "=" addr-value
+addr-name = scheme
+addr-value = *pchar
+bchar = *(ALPHA / DIGIT)
+]]>
+        </artwork>
+        </figure>
+        <t>
+         'scheme' is defined in <xref target="RFC3986" /> in Section 3.1.
+         'pchar' is defined in <xref target="RFC3986" />, Appendix A.
+        </t>
+      </section>
+    </back>
 </rfc>