gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lsd0004] branch master updated: add some comments


From: gnunet
Subject: [lsd0004] branch master updated: add some comments
Date: Mon, 14 Feb 2022 22:51:02 +0100

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 38089dd  add some comments
38089dd is described below

commit 38089ddf3f7789972b2cee1bc4ae32a85a608470
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Feb 14 22:50:59 2022 +0100

    add some comments
---
 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 4c8797f..b755a06 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -106,7 +106,7 @@
       write this Kind at this Resource-ID.  If this check fails, the
       request MUST be rejected with an Error_Forbidden error."
         -->
-        FIXME: Here we should also cite and discuss RELOAD 
(https://datatracker.ietf.org/doc/html/rfc6940)
+        <!--FIXME: Here we should also cite and discuss RELOAD 
(https://datatracker.ietf.org/doc/html/rfc6940)-->
         and establish why we need this spec and are not a "Topology plugin"
         in RELOAD. The argumentation revolves around the trust model 
(openness) and
         security aspects (path signatures).
@@ -463,7 +463,6 @@ Connectivity | |Underlay|  |Underlay|
         The required functionality are abstracted through the following
         procedures:
       </t>
-      <!-- FIXME separate procedures from events -->
       <dl>
         <dt>
           <tt>TRY_CONNECT(N, A)</tt>
@@ -479,14 +478,14 @@ Connectivity | |Underlay|  |Underlay|
         </dt>
         <dd>
           A function which tells the underlay to keep a hold on the connection
-          to a peer <tt>P</tt>. FIXME what is this needed for?
+          to a peer <tt>P</tt>. <!--FIXME what is this needed for?-->
         </dd>
         <dt>
           <tt>DROP(P)</tt>
         </dt>
         <dd>
           A function which tells the underlay to drop the connection to a
-          peer <tt>P</tt>. FIXME what is this needed for?
+          peer <tt>P</tt>. <!--FIXME what is this needed for?-->
         </dd>
         <dt>
           <tt>M = RECEIVE(P)</tt>
@@ -509,7 +508,7 @@ Connectivity | |Underlay|  |Underlay|
         <dd>
           A procedure that provides estimates on the network size
           <tt>S</tt> for use in the DHT routing algorithms.
-          FIXME: What is S and give an example.
+          <!--FIXME: What is S and give an example.-->
         </dd>
       </dl>
       <t>
@@ -760,8 +759,8 @@ Connectivity | |Underlay|  |Underlay|
           are represented in an options field in the messages.
           Each flag is represented by a bit in the field starting from 0 as
           the rightmost bit to 15 as the leftmost bit.
-          FIXME: Actually, we set those bits and then store the resulting
-          value in NBO...
+          <!--FIXME: Actually, we set those bits and then store the resulting
+          value in NBO...-->
         </t>
         <dl>
           <dt>0: Demultiplex-Everywhere</dt>
@@ -897,9 +896,6 @@ Connectivity | |Underlay|  |Underlay|
         </section>
       </section>
       <section anchor="p2p_put" numbered="true" toc="default">
-        <!-- FIXME: Blocks have KEYs. GETs only have
-        QueryHashes the reply refers to the QueryHash, but
-        QueryHash MAY not be Block key -->
         <name>PutMessage</name>
         <section anchor="p2p_put_wire">
           <name>Wire Format</name>
@@ -1190,7 +1186,7 @@ Connectivity | |Underlay|  |Underlay|
               </ol>
             </li>
             <li>
-              FIXME: We only handle if not GNUNET_BLOCK_EVALUATION_OK_LAST.
+              <!--FIXME: We only handle if not 
GNUNET_BLOCK_EVALUATION_OK_LAST.-->
               This means that we must evaluate the Reply produced in the
               previous step using <tt>ValidateBlockReply</tt> for this
               <tt>BTYPE</tt>
@@ -1357,7 +1353,7 @@ Connectivity | |Underlay|  |Underlay|
               </t>
               <t>
                 For each pending request the reply is routed to the requesting
-                node <tt>N'</tt>. FIXME routed to node or forwarded to peer?
+                peer <tt>P'</tt>. <!--FIXME routed to node or forwarded to 
peer?-->
               </t>
             </li>
           </ol>
@@ -1402,7 +1398,8 @@ Connectivity | |Underlay|  |Underlay|
           <dd>
             is used to evaluate the request for a block. It is used as part of
             <tt>GetMessage</tt> processing, where the block payload is still 
unkown,
-            but the block <tt>XQuery</tt> (FIXME: Undefined here) and 
<tt>Key</tt> can and
+            but the block <tt>XQuery</tt> <!--(FIXME: Undefined here)-->
+            and <tt>Key</tt> can and
             MUST be verified, if possible.
           </dd>
           <dt>ValidateBlockStoreRequest(Block, Key) -&gt; 
RequestEvaluationResult</dt>

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]