commit 83f4057b303e282207b4f0b260da7e8c921b32ac
parent b316e764dca34238144c5f5b94a2f3ab45a7a9d8
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Thu, 23 Jun 2022 20:52:31 +0200
-comments
Diffstat:
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -1636,8 +1636,10 @@ BEGIN
steps:
</t>
<ol type="%c)">
+ <!-- FIXME: It is not clear that this is a fallthrough statement -->
+ <!-- FIXME: Are HELLO blocks according to the spec stored in block storage but never looked for? -->
<li>
- If <tt>TYPE</tt> indicates a request for a HELLO block,
+ If <tt>BTYPE</tt> indicates a request for a HELLO block,
the peer <bcp14>MUST</bcp14> consult the HELLOs it has cached for the
peers in its routing table instead of the local block
storage (while continuing to respect flags like
@@ -1649,6 +1651,7 @@ BEGIN
the peer <bcp14>SHOULD</bcp14> try to respond with the closest block it
has that is not filtered by the
<tt>RESULT_BF</tt>. However, implementations also <bcp14>MUST</bcp14>
+ <!-- FIXME MSC: I suggest NOT normatively defining such a consideration -> security consideration -->
avoid an exhaustive search of their database, as there could be
cases where too many local results are filtered by the result
filter. To avoid denial of service attacks, implementations
