clarify who configures and why

1 files changed, 8 insertions, 4 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index b1e3740..35a0770 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -939,10 +939,12 @@ Connectivity | |Underlay|  |Underlay|  | Underlay | ...
           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
+          previous one expires. When using unreliable underlays, the application
+          <bcp14>MAY</bcp14> want to use an even higher frequency and transmit
+          more <tt>HelloMessages</tt> within an expiration interval 
           to ensure that neighbours almost always have non-expired
-          <tt>HelloMessages</tt> at their disposal.
+          <tt>HelloMessages</tt> at their disposal even if some messages
+          are lost.
         </t>
         <t>       
           Whenever a peer receives such a <tt>HelloMessage</tt>
@@ -1128,7 +1130,9 @@ BEGIN
           the peer has encountered.  To ensure that the peer does
           not run out of memory, information about older requests
     is discarded.
-    The value of <tt>MAX_RECENT</tt> <bcp14>MAY</bcp14> be configurable.
+    The value of <tt>MAX_RECENT</tt> <bcp14>MAY</bcp14> be configurable
+    at the host level to use available memory resources without
+    conflicting with other system requirements and limitations.
     <tt>MAX_RECENT</tt> <bcp14>SHOULD</bcp14>
     be at least 128 * 10<sup>3</sup>.
     If the pending table is smaller, the likelihood grows that a peer