[lsd0004] branch master updated (88dcd3b -> c6ca26a)

[gnunet]

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

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

    from 88dcd3b  typo
     new 05bb198  Fix GANA for block types to include specifications.
     new c6ca26a  Improve structure and wording.

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 draft-schanzen-r5n.xml | 33 +++++++++++++++------------------
 1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 8adcfae..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>
@@ -1706,9 +1703,8 @@ BEGIN
            filter because of a false-positive test.
           </t>
           <t>
-            <!-- FIXME: then this should be part of the registration policy -->
            How exactly a block result is added to a result filter
-           <bcp14>MUST</bcp14> be specified as part of the definition of a 
block type.
+           is specified as part of the definition of a block type (cf. <xref 
target="hello_block"/>).
           </t>
         </section>
         <section anchor="p2p_get_processing">
@@ -2619,20 +2615,21 @@ BEGIN
           the block type (in UTF-8)</li>
         <li>Contact: Optionally, the contact information of a person to 
contact for
           further information</li>
-        <li>References: Optionally, references describing the record type
-          (such as an RFC)</li>
+        <li>References: Required, references (such as an RFC) specifying the 
block type and its block functions</li>
       </ul>
       <t>
         The registration policy for this sub-registry is "First Come First
         Served", as described in <xref target="RFC8126"/>.
         GANA created the registry as follows:
       </t>
+      <!-- FIXME changed GNS Reference to This.I-D because we either need to 
define it here
+           or in the GNS RFC. And I think here is better or in a separate 
document -MSC -->
       <figure anchor="figure_btypenums" title="The Block Type Registry.">
         <artwork name="" type="" align="left" alt=""><![CDATA[
 Number| Name           | References | Description
 ------+----------------+------------+-------------------------
 0       ANY              [This.I-D]   Reserved
-11      GNS_NAMERECORD   GNS          Block for GNS records
+11      GNS_NAMERECORD   [This.I-D]   Block for GNS records
 13      DHT_HELLO        [This.I-D]   Address data for a peer
 Contact: r5n-registry@gnunet.org
 ]]></artwork>

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