1 files changed, 30 insertions, 15 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 9b5aece..58f5e2b 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -484,20 +484,28 @@ Connectivity | |Underlay|  |Underlay|
     <section>
       <name>Bootstrapping</name>
       <t>
-        It is assumed that the node is already connected to at least
-        one other node.
-        First, those initial nodes are sorted into their respective buckets.
+        Initially, the implementation depends upon the Underlay to provide at
+        least one initial connection to a peer signalled through
+        <tt>PEER_CONNECTED</tt>.
+        The initial set of peers is stored in the routing table component
+        <xref target="routing_table"/>.
       </t>
       <t>
-        In order to find the closest nodes in the network to itself, an
-        implementation MUST now periodically send HELLO GET queries for its own
-        node address.
-        Both the "record route" and "find node" message options are set in the
-        GET queries in order to learn nodes and network topology from the
-        message route and in order to receive approximate replies to the
-        query key (the node address).
+        Further, the Underlay must provide the implementation with one or more
+        addresses signalled through <tt>ADDRESS_ADDED</tt>.
+        The implementation then proceeds to periodically advertise all
+        active addresses in a HELLO block <xref target="hello_block"/>.
+      </t>
+      <t>
+        In order to find more close nodes in the network, an
+        implementation MUST now periodically <xref target="find_peer"/> messages.
+      </t>
+      <t>
+        In both cases the frequency of advertisements and peer discovery
+        MAY be adapted according to network conditions, connected peers,
+        workload of the system and other factors which are at the discretion of
+        the developer.
       </t>
-      <t>FIXME: Periodically -&gt; more specific? No. Frequency may be adapted depending on network conditions, known nodes, busy/idle etc.</t>
       <t>
         Any implementation encountering a HELLO GET request initially
         sends its own node address if it.
@@ -527,6 +535,12 @@ Connectivity | |Underlay|  |Underlay|
           follows an XOR-based node distance calculation.
         </t>
       </section>
+      <section anchor="find_peer">
+        <name>Peer Discovery</name>
+        <t>
+          FIXME: Elaborate on FindPeer here
+        </t>
+      </section>
       <section anchor="routing_table">
         <name>Routing Table</name>
         <t>
@@ -1263,10 +1277,11 @@ tor+onionv3://rasdflkjasdfliasduf.onion/
       </t>
       <figure anchor="figure_btypenums">
         <artwork name="" type="" align="left" alt=""><![CDATA[
-Number | Name   | Contact | References | Description
--------+--------+---------+------------+-------------------------
+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 node
+7       HELLO    N/A       [This.I-D]   Type of a block that contains
+                                        a HELLO for a node
 11      GNS      N/A       GNS          Block for storing record data
 ]]></artwork>
       </figure>
@@ -1277,7 +1292,7 @@ Number | Name   | Contact | References | Description
       <figure anchor="figure_purposenums">
         <artwork name="" type="" align="left" alt=""><![CDATA[
 Purpose | Name            | References | Description
---------+-----------------+------------+--------------------------
+--------+-----------------+------------+---------------
 ]]></artwork>
       </figure>
     </section>