commit 38089ddf3f7789972b2cee1bc4ae32a85a608470
parent 7ba1709e99bbdaa004125df05d261ca44b6ce733
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 14 Feb 2022 22:50:59 +0100
add some comments
Diffstat:
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git 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) -> RequestEvaluationResult</dt>
