Various connection changes

1 files changed, 18 insertions, 8 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index fe62993..e5f72b2 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -436,7 +436,6 @@ Connectivity | |Underlay|  |Underlay|
         API:
       </t>
       <dl>
-        <!-- FIXME: Not used anywhere in draft -->
         <dt>
           <tt>TRY_CONNECT(N, A)</tt>
         </dt>
@@ -564,9 +563,13 @@ Connectivity | |Underlay|  |Underlay|
         information about its current set of neighbors.
         Upon receiving a connection notification from the Underlay through
         <tt>PEER_CONNECTED</tt>, information on the new neighbor
-        <bcp14>MUST</bcp14> be added, and similarly when
-        a disconnect is indicated by the Underlay through
-        <tt>PEER_DISCONNECTED</tt> the peer <bcp14>MUST</bcp14> be removed.
+        <bcp14>MUST</bcp14> be added.
+        Similarly when a disconnect is indicated by the Underlay through
+        <tt>PEER_DISCONNECTED</tt> messages for all addresses of the peer it
+        <bcp14>MUST</bcp14> be removed.
+        The implementation <bcp14>MAY</bcp14> try to re-establish connection
+        to the peer by issuing <tt>TRY_CONNECT</tt> requests on the Underlay
+        using valid HELLO caches.
       </t>
       <t>
         In order to achieve O(log n) routing performance,
@@ -596,7 +599,8 @@ Connectivity | |Underlay|  |Underlay|
           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.
+          least one working HELLO which is then in turn used to call <tt>TRY_CONNECT</tt>
+          on the Underlay.
           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.
@@ -638,14 +642,20 @@ Connectivity | |Underlay|  |Underlay|
           HELLOs 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
           HELLO 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.
-          Whenever a peer receives such a HELLO message from another peer,
-          it must cache it as long as that peer is in its routing table
+          Whenever a peer receives such a HELLO 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 HELLO expires) and serve it in response to
-          Peer Discovery requests.  Details about the format of the
+          <!-- FIXME wat is a Peer Discovery request??
+               maybe a HELLO GET request?
+          -->
+          Peer Discovery requests.
+          Details about the format of the
           HELLO message are given in <xref target="p2p_hello_wire"/>.
         </t>
         <t>