More peer discovery. Lots WIP and unclear

1 files changed, 21 insertions, 24 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index e5b8218..2e1bf76 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -652,12 +652,27 @@ Connectivity | |Underlay|  |Underlay|
            <tt>HELLO</tt> s of peers that are useful somewhere in the routing table.
         </t>
         <t>
-          <!-- This here sais that this is a mandatory functionality. in HelloMessage it
-               sais RECOMMENDED -->
-          To facilitate peer discovery, each peer <bcp14>MUST</bcp14> broadcast its own
-          <tt>HELLO</tt> message to all peers in the routing table periodically.
-          The specific frequency <bcp14>MAY</bcp14> depend on available bandwidth
-          but <bcp14>SHOULD</bcp14> be a fraction of the expiration period.
+          In order to facilitate the above,
+          the Underlay is expected to 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.
+          <!-- Periodically? sometimes? on change? -->
+          An implementation <bcp14>MUST</bcp14> advertise its addresses by:
+        </t>
+        <!-- FIXME both things here are grossly underdefined for a MUST:
+             Message flags, BF, REPL_LVL etc
+             -->
+        <ul>
+          <li>Initiating <tt>HelloMessage</tt>s to the peers in its routing table (<xref target="p2p_hello_wire"/>).</li>
+          <li>Initiating <tt>PutMessage</tt>s containing <tt>HELLO</tt> blocks (<xref target="hello_block"/>).</li>
+        </ul>
+        <t>
+          <!-- FIXME This here sais that this is a mandatory functionality. in HelloMessage it
+               sais RECOMMENDED
+               FIXME: Expiration time of messages unclear -->
+          The specific frequency of advertisements <bcp14>MAY</bcp14> depend on available bandwidth,
+          the set of already connected neighbors,  the workload of the system and other factors which are at the discretion of
+          the developer, but <bcp14>SHOULD</bcp14> be a fraction of the expiration period.
           Whenever a peer receives such a  <tt>HELLO</tt>  message from another peer that is
           already in the routing table, it must cache it as long as that peer is in its routing table
           (or until the <tt>HELLO</tt> expires) and serve it in response to
@@ -665,24 +680,6 @@ Connectivity | |Underlay|  |Underlay|
                maybe a <tt>HELLO</tt> GET request?
           -->
           Peer Discovery requests.
-          Details about the format of the
-          <tt>HELLO</tt> 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 <tt>HELLO</tt> blocks
-               and <tt>HELLO</tt> messages? -->
-          The implementation periodically advertises all
-          active addresses in a <tt>HELLO</tt> block <xref target="hello_block"/>.
         </t>
       </section>
       <section anchor="routing_bloomfilter">