1 files changed, 22 insertions, 5 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 60c5967..9495cbf 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -563,13 +563,10 @@ 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.
+        <bcp14>MUST</bcp14> be added to the routing table.
         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.
+        <bcp14>MUST</bcp14> be removed from the routing table.
       </t>
       <t>
         In order to achieve O(log n) routing performance,
@@ -601,6 +598,8 @@ Connectivity | |Underlay|  |Underlay|
           <tt>PEER_CONNECTED</tt>), or the application/end-user providing at
           least one working HELLO which is then in turn used to call <tt>TRY_CONNECT</tt>
           on the Underlay.
+          This is commonly achieved through the configuration of hardcoded bootstrap peers
+          or bootstrap servers either for the Underlay or the R<sup>5</sup>N implementation.
           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.
@@ -627,6 +626,11 @@ Connectivity | |Underlay|  |Underlay|
           largest number of neighbors. The eviction strategy <bcp14>MUST</bcp14> be
           to drop the shortest-lived connections first.
         </t>
+        <t>
+          The implementation <bcp14>MAY</bcp14> cache valid HELLOs of disconnected
+          peers outside of the routing table and sporadically or periodically try to (re-)establish connection
+          to the peer by issuing <tt>TRY_CONNECT</tt> requests on the Underlay.
+        </t>
       </section>
       <section anchor="find_peer">
         <name>Peer Discovery</name>
@@ -1315,6 +1319,10 @@ BEGIN
             <li>
               The HELLO information is cached in the routing table until it expires,
               the peer is removed from the routing table, or the information is replaced by another message from the peer.
+              <!-- FIXME same problem as for HELLO blocks: We do not need to TRY_CONNECT here because we already have
+                   a connection, obviously. But we may want to TRY_CONNECT on the new addresses? Adding for now -->
+              The implementation <bcp14>MAY</bcp14> instruct the Underlay to connect to all now available addresses
+              using <tt>TRY_CONNECT</tt> in order to make the underlay aware of alternative addresses for this connection.
             </li>
             <li>
               <!-- We need a statement like this here. Should they? Can they? What if they are (not)? -->
@@ -1545,6 +1553,15 @@ BEGIN
               the local peer <bcp14>MUST</bcp14> try to establish a connection
               to the peer indicated in the HELLO block using the address information
               from the HELLO block and the Underlay function <tt>TRY_CONNECT</tt>.
+              <!-- FIXME: The above behaviour has a catch: If the implementation only connects to one
+                   address from the hello using TRY_CONNECT, the Underlay also knows only about that connection
+                   If that failes and PEER_DISCONNECT is called, this neighbor is dead.
+                   We could say here that the implementation SHOULD instruct to connect to ALL
+                   addresses or risk flaky connections. The choice of address is also unclear.
+                   R5N does not really know what the Underlay supports (maybe more than provided in
+                   own addresses) - Added this for now: -->
+              The implementation <bcp14>MAY</bcp14> instruct the Underlay to connect to all provided addresses
+              using <tt>TRY_CONNECT</tt> in order to make the underlay aware of multiple addresses for this connection.
               If a connection is established, the signal <tt>PEER_CONNECTED</tt> will cause
               the peer to be added to the respective k-bucket of the routing table.
               Note that the k-bucket <bcp14>MUST</bcp14> be determined by the