[lsd0004] branch master updated: Cleanup some fixmes. Identified further unclarities.

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0004.

The following commit(s) were added to refs/heads/master by this push:
     new bb023bd  Cleanup some fixmes. Identified further unclarities.
bb023bd is described below

commit bb023bdbb21eed4a1002c26fd7b9b15d30fa63e3
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Dec 26 15:37:48 2022 +0900

    Cleanup some fixmes. Identified further unclarities.
---
 draft-schanzen-r5n.xml | 60 ++++++++++++++++++--------------------------------
 1 file 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

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.