1 files changed, 45 insertions, 29 deletions

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index 0467499..c2e154a 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -1168,7 +1168,8 @@ 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. (thesis summermatter: future work) -->
+                     expensive as sending the SE? Should be a simple calculation. (thesis summermatter: future work) @Christian:
+                      As discussed 14.06 we let this comment in here as it is described in the thesis-->
                 The second case is if the application requests full synchronisation explicitly.
                 This is useful for testing and MUST NOT be used in production.
               </t>
@@ -2489,7 +2490,7 @@ FUNCTION END
                        is to be applied after the SE calculation to
                        the computed set size differences, resulting
                        in a hard cap on the set size difference estimate
-                       that is then actually used. -->
+                       that is then actually used. @Christian: ???-->
                 </t>
             </section>
 
@@ -2851,7 +2852,8 @@ END FUNCTION
                         send at the beginning of the operation.
                         <!-- FIXME: I don't see how the next sentence makes sense. If we got a FULL_DONE,
                              and we still have differing sets, something is broken and re-doing it hardly
-                             makes sense, right? -->
+                             makes sense, right? @Christian im not sure about that it could be that for example
+                             the set size changes (from application or other sync) while synchronisation is in progress....-->
                         If the sets differ, a resynchronisation is required. The number of possible
                         resynchronisation MUST be limited, to prevent resource exhaustion attacks.
                       </t>
@@ -2872,10 +2874,22 @@ END FUNCTION
                           exceeded, or if the size is implausible for the given operation.
                         </t>
                     </dd>
+                    <dt><xref target="messages_ibf_last" format="title" /></dt>
+                    <dd>
+                        <t>
+                            When all <em><xref target="messages_ibf" format="title" /></em> messages have
+                            been received an <em><xref target="messages_ibf_last" format="title" /></em> message
+                            should conclude the transmission of the IBF and a change to the <strong>Active Decoding</strong>
+                            phase should be ensured.
+                        </t>
+                    </dd>
                     <!-- FIXME: we can also receive an IBF_LAST in this state,
                          here additional sanity checks, like that we have received
                          all of the other fragments/parts of the IBF first and
-                         that the parameters are thus consistent apply. -->
+                         that the parameters are thus consistent apply. @Christian So we would have
+                         to transmit the number of IBF slices that will be transmitted first
+                         to do this check right?
+                          -->
                 </dl>
             </section>
 
@@ -2888,10 +2902,12 @@ END FUNCTION
                     To prevent an endless loop in decoding, loop detection MUST be implemented.
                     The simplest solution is to prevent decoding of more than a given number of elements.
                     <!-- FIXME: this description is awkward. Needs to be discussed.
-                         I think you also do not mean 'hashes' but 'element IDs'. -->
+                         I think you also do not mean 'hashes' but 'element IDs'. @Christian just omit the details
+                         i guess anybody can freely decide how to handle loops its just important that e protection is
+                         in place. Right?-->
                     A more robust solution is to implement a algorithm that detects a loop by
                     analyzing past partially decoded IBFs. This can be achieved
-                    by saving the hash of all prior partly decoded IBFs hashes in a hashmap and check
+                    by saving the element IDs of all prior partly decoded IBFs hashes in a hashmap and check
                     for every inserted hash, if it is already in the hashmap.
                 </t>
                 <t>
@@ -2899,12 +2915,14 @@ END FUNCTION
                     operation MUST be terminated.Furthermore, if the IBF
                     decoding successfully terminates and fewer elements were
                     decoded than plausible, the operation MUST also be terminated.
-                    The upper and lower thresholds
-                    for the number of decoded elements can be calculated with the peers set sizes
-                    and the other peer's committed set sizes from the <strong>Expecting IBF</strong>
-                    state.
+                    The upper thresholds for decoded elements from the IBF is the
+                    remote set size the other peer has committed too (Case if the complete remote set is
+                    new). The lower threshold for decoding element is the absolute value of the difference
+                    between the local and remote set size (Case the set difference is only in the set of
+                    a single peer). The other peer's committed set sizes
+                    is transmitted in the the <strong>Expecting IBF</strong> state.
                     <!-- FIXME: be more precise about how to calculate those
-                         bounds from those inputs. -->
+                         bounds from those inputs.  @Christan better? -->
                 </t>
 
                 <t>Security considerations for received messages:</t>
@@ -2948,15 +2966,15 @@ END FUNCTION
                         <t>
                             The <em><xref target="messages_done" format="title" /></em> message is only received if the IBF has finished
                             decoding and all offers have been sent. If the <em><xref target="messages_done" format="title" /></em> message is received before
-                            the decoding of the IBF is finished or all open offers and demands
+                            the decoding of the IBF is finished or all open demands
                             have been answered, the operation MUST be terminated.
                             <!-- FIXME: it is legitimate to not respond to an offer, right? Otherwise
                                  we would not need demands; hence, the above should only be
-                                 for 'open demands', right? -->
+                                 for 'open demands', right? @Christian your right corrected this one-->
                             If
                             the sets differ, a resynchronisation is required. The number of possible
                             resynchronisation MUST be limited to prevent resource exhaustion attacks.
-                            <!-- FIXME: again, how can this happen? Why should we really allow this? -->
+                            <!-- FIXME: again, how can this happen? Why should we really allow this? @Christian same point above if set changes while we synchronize-->
                         </t>
                         <t>
                             When a <em><xref target="messages_done" format="title" /></em> message is received the
@@ -3004,14 +3022,6 @@ END FUNCTION
                             The set difference calculated from the strata estimator needs to be plausible,
                             which means within the byzantine boundaries described in section <xref target="security_generic_functions_check_byzantine_boundaries" format="title" />.
                         </t>
-                        <t>
-                          <!-- FIXME: I do not think this kind of consideration
-                               belongs into an RFC... Besides, you can have memory
-                               corruption at most steps of the algorithm if the code is sufficiently
-                               careless... -->
-                            In case of compressed strata estimators the unpacking algorithm needs to
-                            be protected against unpacking memory corruption (memory overflow).
-                        </t>
                     </dd>
                 </dl>
             </section>
@@ -3036,10 +3046,10 @@ END FUNCTION
                             elements received matches the number that the remote peer
                             originally committed to transmitting,
                             otherwise the operation MUST be terminated.
-                            <!-- FIXME: this is redundant, already covered by the new state, right? -->
+                            <!-- FIXME: this is redundant, already covered by the new state, right? @Christian: ??? State-->
                             After receiving the
                             <em><xref target="messages_full_done" format="title" /></em> message, future elements MUST NOT be accepted.
-                            <!-- FIXME: again, how can this happen? Why should we really allow this? -->
+                            <!-- FIXME: again, how can this happen? Why should we really allow this? @Christian Again set changes while sync ;-) -->
                             If
                             the sets differ, a resynchronisation is required. The number of possible
                             resynchronisation MUST be limited to prevent resource exhaustion attacks.
@@ -3061,10 +3071,8 @@ END FUNCTION
                                  then the swap will no longer just add 0.5 RTT! I think
                                  we MUST instead permit that an IBF decodes to an element
                                  that was offered/demanded (only in the previous iteration?) and then
-                                 simply SKIP that element ID! -->
-                            In this moment the peer MUST
-                            wait for all open offers and demands to be fulfilled, to prevent
-                            retransmission before switching into active decoding operation mode.
+                                 simply SKIP that element ID! @Christian oh i missed this one. Yes, your right we dont do this!
+                                  -->
                             A switch into active decoding mode MUST only be permitted for
                             a predefined number of times as described in <xref target="security_generic_functions_active_passive_switches" format="default"/>
                         </t>
@@ -3074,9 +3082,17 @@ END FUNCTION
                         <t>
                         A check needs to be in place that prevents receiving an inquiry
                         for an element multiple times or more inquiries than are plausible.
+                        The upper thresholds for sent/received inquiries is the
+                        remote set size the other peer has committed too (Case if the complete remote set is
+                        new). The lower threshold for for sent/received inquiries is the absolute value of the
+                        set difference between the local and remote set size
+                        (Case the set difference is only in the set of a single peer).
+                        The other peer's committed set sizes is transmitted in the the <strong>Expecting IBF</strong> state.
+                        Beware that it is possible to get key collisions and an inquiry for the same key
+                        can be transmitted multiple times, so the threshold should take this into account.
                         <!-- FIXME: how again does one determine how many inquiries are plausible?
                              Be precise! I can see several options (overall set sizes, but also
-                             SE, or even IBF size). -->
+                             SE, or even IBF size). @Christian I Added check parameter-->
                         The sending and receiving of <em><xref target="messages_inquiry" format="title" /></em> messages should
                         always be protected with an <xref target="security_generic_functions_mfc" format="title" />
                         to secure the protocol against missing, duplicated, out-of-order or unexpected messages.