Cleanup some fixmes. Identified further unclarities.

1 files changed, 21 insertions, 39 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index c4eda07..14487b2 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -1214,23 +1214,10 @@ BEGIN
       <section anchor="p2p_hello" numbered="true" toc="default">
         <name>HelloMessage</name>
         <t>
-          <!-- FIXME: While it is discussed here how to hangle HelloMessages
-               nowhere in the draft is a HelloMessage created at the
-               initiator so it is completely irrelevant atm -->
           When the Underlay notifies the implementation of added or removed
           addresses through <tt>ADDRESS_ADDED</tt> and <tt>ADDRESS_DELETED</tt>
           it <bcp14>MAY</bcp14> disseminate those changes to neighbors using
           <tt>HelloMessage</tt>s.
-          <!-- FIXME yesyes this is blabla and obvious when reading the processing section.
-              In contrast to a <tt>HELLO</tt> block, a
-          <tt>HelloMessage</tt> does not contain the ID of
-          the peer the address information is about: in a
-          <tt>HelloMessage</tt>, the address information is always
-          about the sender.
-          Since the Underlay is responsible to determine the
-          peer ID of the sender for all messages, it would thus be
-          redundant to also include the peer ID in the
-          <tt>HelloMessage</tt>.-->
           <!-- FIXME: Are hello messages should or must?
                Only recommended not, if so, what if that is not done?
           -->
@@ -1657,7 +1644,7 @@ BEGIN
             <dt>PEER_BF</dt>
             <dd>
               A peer Bloom filter to stop circular routes (see <xref target="routing_bloomfilter"/>).
-              Set by the initiator to include itself. <!-- Is that so? -->
+              Set by the initiator to include itself. <!-- FIXME Is that so? -->
               Modified by processing peers to include their own peer address.
             </dd>
             <dt>QUERY_HASH</dt>
@@ -1740,36 +1727,31 @@ BEGIN
                 steps:
               </t>
               <ol type="%c)">
-                <!-- FIXME: It is not clear that this is a fallthrough statement -->
-                <!-- FIXME: Are <tt>HELLO</tt> blocks according to the spec stored in block storage but never looked for? -->
+                <!-- FIXME it seems to me as if some blocks need to be "synthesized", e.g.
+                     HELLOs from HelloMessages... this needs to be specified.-->
                 <li>
-                  If <tt>BTYPE</tt> indicates a request for a <tt>HELLO</tt> block or
+                  If the <tt>BTYPE</tt> does not indicate a request for a <tt>HELLO</tt> block or
                   <tt>ANY</tt>,
-                  the peer <bcp14>MUST</bcp14> consult its own <tt>HELLO</tt> as well as
-                  the HELLOs it has cached for the
-                  peers in its routing table instead of the local block
-                  storage (while continuing to respect flags like
-                  <tt>DemultiplexEverywhere</tt>
-                  and <tt>FindApproximate</tt>).
+                  the implementation <bcp14>MUST</bcp14> only consider blocks in the local block storage.
+                  Otherwise, the implementation <bcp14>MUST</bcp14> only consider its own <tt>HELLO</tt> and
+                  the <tt>HELLO</tt>s it has cached for the peers in its routing table as blocks.
                 </li>
                 <li>
                   If <tt>FLAGS</tt> indicate a <tt>FindApproximate</tt> request,
-                  the peer <bcp14>SHOULD</bcp14> try to respond with the closest block it
-                  has that is not filtered by the
-                  <tt>RESULT_BF</tt>.
-                </li>
-                <li>
-                  Else, the peer <bcp14>MUST</bcp14> respond if it has a valid block
-                  that matches the key exactly and that is
+                  the peer <bcp14>SHOULD</bcp14> try to respond with the closest block (smallest value
+                  of <tt>GetDistance(QUERY_HASH, BLOCK_KEY)</tt>) it
+                  can find that is not filtered by the <tt>RESULT_BF</tt>.
+                  Otherwise, the peer <bcp14>MUST</bcp14> respond if it has a valid block
+                  with a <tt>BLOCK_KEY</tt> that matches the <tt>QUERY_HASH</tt> exactly and that is
                   not filtered by the <tt>RESULT_BF</tt>.
                 </li>
               </ol>
               <t>
-               Any such resulting block <bcp14>MUST</bcp14> be encapsulated in a
+               The resulting block, if any, <bcp14>MUST</bcp14> be encapsulated in a
                <tt>ResultMessage</tt> and <bcp14>SHOULD</bcp14> be transmitted to the
-               neighbor from which the request was received.  Implementations
-               <bcp14>MAY</bcp14> drop messages if they are resource-constrained.
-               However, <tt>ResultMessage</tt>s <bcp14>SHOULD</bcp14> be given the
+               neighbor from which the request was received.
+               Implementations <bcp14>MAY</bcp14> drop messages if they are resource-constrained.
+               However, <tt>ResultMessage</tt>s <bcp14>MUST</bcp14> be given the
                highest priority among competing transmissions.
               </t>
               <t>
@@ -1780,7 +1762,7 @@ BEGIN
               </t>
             </li>
             <li>
-              Given the value in <tt>REPL_LVL</tt>, the number of peers to forward to
+              Using the value in <tt>REPL_LVL</tt>, the number of peers to forward to
               <bcp14>MUST</bcp14> be calculated using
               <tt>ComputeOutDegree()</tt>.
               If there is at least one
@@ -1789,9 +1771,9 @@ BEGIN
               forward to fewer or no peers in order to handle resource constraints
               such as bandwidth.
               The peer Bloom filter <tt>PEER_BF</tt> <bcp14>MUST</bcp14> be updated with the local
-              peer address <tt>SELF</tt>.
-              For all peers with peer address <tt>P'</tt> chosen to forward the message
-              to, <tt>SEND(P', GetMessage')</tt> is called.  Here, <tt>GetMessage'</tt>
+              peer address <tt>SELF</tt> for any forwarded message.
+              For all peers with peer address <tt>P</tt> chosen to forward the message
+              to, <tt>SEND(P, GetMessageP)</tt> is called.  Here, <tt>GetMessageP</tt>
               is the original message with the updated fields for <tt>HOPCOUNT</tt> (incremented
               by 1), <tt>PEER_BF</tt> and <tt>RESULT_FILTER</tt>.
             </li>
@@ -2448,7 +2430,7 @@ BEGIN
             of decreasing proximity.
           </dd>
         </dl>
-        <section>
+        <section anchor="approx_search">
           <name>Approximate Search Considerations</name>
         <t>
           Over time a peer may accumulate a significant number of blocks