commit 6f51c7007332c3ead16616f5638980f179659511
parent 887c2c28be70606826175f403e52366ccd80e1af
Author: Elias Summermatter <elias.summermatter@seccom.ch>
Date: Mon, 14 Jun 2021 11:02:41 +0200
Fixed some more Fix me's
Diffstat:
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git 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>
