clarify frequency

1 files changed, 14 insertions, 3 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 2d81bda..3c75039 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -929,13 +929,24 @@ Connectivity | |Underlay|  |Underlay|  | Underlay | ...
           implementation, it is <bcp14>RECOMMENDED</bcp14> to choose external
           factors such as expiration of DHCP leases to determine the values.
           The specific frequency of advertisements
-          <bcp14>SHOULD</bcp14> be a fraction of the expiration
+          <bcp14>SHOULD</bcp14> be smaller than the expiration
           period.
           It <bcp14>MAY</bcp14> additionally 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.
-          Whenever a peer receives such a <tt>HELLO</tt>
-          message from another peer that is already in the routing
+          If <tt>HelloMessages</tt> are not updated before they expire,
+          peers might be unable to discover and connect to the respective
+          peer, and thus miss out on quality routing table entries. This
+          would degrade the performance of the DHT and <bcp14>SHOULD</bcp14>
+          thus be avoided by advertising updated <tt>HELLOs</tt> before the
+          previous one expires. When using unreliable underlays, it
+          <bcp14>MAY</bcp14> be a good idea to use an even higher frequency
+          to ensure that neighbours almost always have non-expired
+          <tt>HelloMessages</tt> at their disposal.
+        </t>
+        <t>       
+          Whenever a peer receives such a <tt>HelloMessage</tt>
+          from another peer that is already in the routing
           table, it must cache it as long as that peer remains in its
           routing table (or until the <tt>HELLO</tt> expires) and
           serve it in response to <tt>GET</tt> requests for