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

[gnunet]

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 <elias.summermatter@seccom.ch>
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 
passive
                       peer MUST send offers for all of the matching elements.
                     </dd>
@@ -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.
               </t>

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