[lsd0004] 02/02: Improve structure and wording.

[gnunet]

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

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

commit c6ca26acbc38e8a736780b140080193074c7935b
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Dec 26 11:18:44 2022 +0900

    Improve structure and wording.
---
 draft-schanzen-r5n.xml | 23 ++++++++++-------------
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 08f1497..9bbebfc 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -633,14 +633,15 @@ Connectivity | |Underlay|  |Underlay|
           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 <tt>HELLO</tt> 
block.
-          <!-- FIXME: Is this really an encoding of a block? It seems to me 
that "HELLO"
-               is not properly defined.
-               FIXME: Should? Isn't this part of the HelloMessage? -->
+          <!-- FIXME It is unclear why this is needed and why it is here. THis 
is a serialization format
+               of the HELLO block that is not used anywhere in the draft. I 
already moved the formati itself
+               into the appendix. -->
           For this, section <xref target="hello_url"/> specifies a URL format 
for encoding HELLO
           blocks as text strings which <bcp14>SHOULD</bcp14> be supported by 
implementations.
         </t>
         <t>
-          <!-- FIXME REPL_LVL unclear, RF_SIZE unclear -->
+          <!-- FIXME REPL_LVL unclear, RF_SIZE unclear. Sections like this 
make me wonder how
+               we can avoid using prose to specify message creation -->
           To discover peers for its routing table, a peer will initiate 
<tt>GetMessage</tt> requests
           <xref target="p2p_get"/> asking for blocks of type  <tt>HELLO</tt>  
using its own peer address as
           <tt>QUERY_HASH</tt>, filtering all of its neighbors via the Bloom 
filter described
@@ -676,10 +677,7 @@ Connectivity | |Underlay|  |Underlay|
           Whenever a peer receives such a  <tt>HELLO</tt>  message from 
another peer that is
           already in the routing table, it must cache it as long as that peer 
is in its routing table
           (or until the <tt>HELLO</tt> expires) and serve it in response to
-          <!-- FIXME wat is a Peer Discovery request??
-               maybe a <tt>HELLO</tt> GET request?
-          -->
-          Peer Discovery requests.
+          GET requests for <tt>HELLO</tt> blocks (see <xref 
target="p2p_get_processing"/>).
         </t>
       </section>
       <section anchor="routing_bloomfilter">
@@ -1329,7 +1327,7 @@ BEGIN
               the peer is removed from the routing table, or the information 
is replaced by another message from the peer.
               <!-- FIXME same problem as for <tt>HELLO</tt> 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
+              The implementation <bcp14>SHOULD</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 and
               to maintain optimal connectivity.
             </li>
@@ -1572,16 +1570,15 @@ BEGIN
               number of peers to forward the message to. The implementation 
<bcp14>MAY</bcp14>
               forward to fewer or no peers in order to handle resource 
constraints
               such as limited bandwidth.
-              <!-- FIXME: From above. it seems to me that here we need to add 
a new putpath
-                   signature element (as we know the successor now)-->
-              For each selected peer with peer address <tt>P</tt> a dedicated 
<tt>PutMessage'</tt>
+              For each selected peer with peer address <tt>P</tt> a dedicated 
<tt>PutMessage_P</tt>
               is created containing the original (and where applicable already 
updated) fields
               of the received <tt>PutMessage</tt>.
               In each message the local peer address <bcp14>MUST</bcp14> be 
added to the
               <tt>PEER_BF</tt> and the <tt>HOPCOUNT</tt> is incremented by 1.
               If the <tt>RecordRoute</tt> flag is set, a new Path Element is 
created and added
               to the <tt>PUTPATH</tt> fields and the <tt>PATH_LEN</tt> field 
is incremented by 1.
-              Finally, <tt>SEND(P, PutMessage')</tt> is called.
+              The successor in the new Path Element is the recipient peer 
<tt>P</tt> of the <tt>PutMessageP</tt>.
+              Finally, the messages are sent using <tt>SEND(P, 
PutMessageP)</tt> each recipient.
             </li>
           </ol>
         </section>

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