[Top][All Lists]

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

[lsd0003] branch master updated: Fixed some more Fix me's

From: gnunet
Subject: [lsd0003] branch master updated: Fixed some more Fix me's
Date: Mon, 14 Jun 2021 11:05:33 +0200

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

elias-summermatter pushed a commit to branch master
in repository lsd0003.

The following commit(s) were added to refs/heads/master by this push:
     new 6f51c70  Fixed some more Fix me's
6f51c70 is described below

commit 6f51c7007332c3ead16616f5638980f179659511
Author: Elias Summermatter <>
AuthorDate: Mon Jun 14 11:02:41 2021 +0200

    Fixed some more Fix me's
 draft-summermatter-set-union.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index b883d53..ba5210e 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -1004,7 +1004,7 @@ hashSum |    0x0101   |    0x5151   |    0x5050   |    
0x0000   |
                       In this case the passive peer answers with <em><xref 
target="messages_offer" format="title" /></em> messages
                       which contain the SHA-512 hash of the requested element. 
 If the passive peer does not have an element with
                       a matching element ID, it MUST ignore the inquiry (in 
this case, a bucket was falsely classified as pure, decoding the IBF will 
eventually fail, and roles will be swapped).
-                      T  <!-- FIXME: should we not remember that this happened 
and FAIL if the other peer sends DONE instead of an IBF? @Christian this is not 
implemented should I add it to the RFC anyways? -->
+                      It should be verified that after an falsely classified 
pure bucket a role change is made.
                       If multiple elements match the 64 bit element ID, the 
                       peer MUST send offers for all of the matching elements.
@@ -1168,7 +1168,7 @@ hashSum |    0x0101   |    0x5151   |    0x5050   |    
0x0000   |
                 The first case is when one of the peers announces having an 
empty set. This is announced by setting
                 the SETSIZE field in the <em><xref target="messages_se" 
format="title" /></em> to 0.
                 <!-- FIXME: why not also do this if sending the elements is 
about as
-                     expensive as sending the SE? Should be a simple 
calculation. @Christian this is a future improvement but work to be done 
(thesis: future work) should i add stuff that is not already implemented? -->
+                     expensive as sending the SE? Should be a simple 
calculation. (thesis summermatter: future work) -->
                 The second case is if the application requests full 
synchronisation explicitly.
                 This is useful for testing and MUST NOT be used in production.

To stop receiving notification emails like this one, please contact

reply via email to

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