1 files changed, 42 insertions, 29 deletions

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index e0ea02f..4531e19 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -2390,7 +2390,7 @@ FUNCTION unpack_counter(ibf, offset, count, cbl, pd)
 # Returns: Salted value
 
 FUNCTION se_key_salting(value, salt)
-    s=(salt * 7) % 64
+    s = (salt * 7) % 64
     return (value >> s) | (value << (64 - s))
 
                                     ]]></artwork>
@@ -2406,44 +2406,38 @@ FUNCTION se_key_salting(value, salt)
 
     <section anchor="security" numbered="true" toc="default">
         <name>Security Considerations</name>
-
         <t>
             The security considerations in this document focus mainly on the security
             goal of availability. The primary goal of the protocol is to prevent an attacker from
-            wasting cpu and network resources of the attacked peer.
+            wasting computing and network resources of the attacked peer.
         </t>
         <t>
             To prevent denial of service attacks, it is vital to check that peers can only
             reconcile a set once in a predefined time span. This is a predefined value and needs
             to be adapted per use basis. To enhance reliability and to allow
-            failed decoding attempts in the protocol, it is possible to introduce a threshold for max failed reconciliation
-            ties.
-        </t>
-        <t>
-            The formal format of all messages needs to be properly validated. This is important to prevent many
-            attacks on the code. The application data MUST be validated by the application using
-            the protocol not by the implementation of the protocol.
-            In case the format validation fails the set operation MUST be terminated.
+            for legitimate failures, say due to network connectivity issues,
+            applications SHOULD define a threshold for
+            the maximum number of failed reconciliation attempts in a given time period.
         </t>
-
-        <t>
-            To prevent an attacker from sending a peer into an endless loop between active and passive decoding, a
-            limitation for active/passive roll switches is required. This can be implemented by
-            a simple counter which terminates the operation after a predefined number of switches.
-            The number of switches needs to be defined in such a way that it is very unprobable that more
-            switches are required an the malicious intend of the other peer can be assumed.
-        </t>
-
         <t>
             It is important to close and purge connections after a given timeout
             to prevent draining attacks.
         </t>
         <section anchor="security_generic_functions" numbered="true" toc="default">
-            <name>General Security Check</name>
+            <name>General Security Checks</name>
             <t>
                In this section general checks are described which should be applied to multiple states.
             </t>
 
+            <section anchor="security_generic_input_validation" numbered="true" toc="default">
+              <name>Input validation</name>
+              <t>
+                The format of all received messages needs to be properly validated. This is important to prevent many
+                attacks on the code. The application data MUST be validated by the application using
+                the protocol not by the implementation of the protocol.
+                In case the format validation fails the set operation MUST be terminated.
+              </t>
+            </section>
             <section anchor="security_generic_functions_check_byzantine_boundaries" numbered="true" toc="default">
                 <name>Byzantine Boundaries</name>
                 <t>
@@ -2481,9 +2475,21 @@ FUNCTION END
                     ]]></artwork>
                 </figure>
                 <t>
-                    For the byzantine upper bound checks to function flawlessly, it needs to be ensured that the estimates of the set size
-                    difference added together never exceed the set byzantine upper bound. This could for example happen
-                    if the strata estimator overestimates the set difference.
+                  For the byzantine upper bound checks to function
+                  correctly, implementations must ensure that the
+                  estimates of the set size difference added together
+                  never exceed the set byzantine upper bound.  This
+                  could for example happen if the strata estimator
+                  overestimates the set difference.
+                  <!-- FIXME: if an implementation does this, then
+                       the first two parts of the check are trivially
+                       satisfied; so likely we should formulate this
+                       not as a 'check' function to be _actually_
+                       executed, but as a plausibility check which
+                       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. -->
                 </t>
             </section>
 
@@ -2510,13 +2516,13 @@ FUNCTION END
 # Returns TRUE if message is valid in state and FALSE if not
 
 FUNCTION check_valid_state (as, s)
-    FOR (as in as)
+    FOR (as in as) ## FIXME: WTF? as in as??? Also: overall terrible way to do this -- where would 'as' come from? Also, I do not think this function SHOULD even be in the RFC (technically, all you want to say is 's in as').
         IF (as == s)
             RETURN TRUE
         END IF
     FOR END
     RETURN FALSE
-FUNCTION END
+FUNCTION END # FIXME: you did not use FUNCTION END above... Be consistent!
                     ]]></artwork>
                 </figure>
             </section>
@@ -2708,9 +2714,16 @@ FUNCTION END
             <section anchor="security_generic_functions_active_passive_switches" numbered="true" toc="default">
                 <name>Limit Active/Passive Decoding changes</name>
                 <t>
-                    The limitation of the maximum allowed active/passive changes during differential synchronisation is key
-                    to security. By limiting the maximum rounds in differential synchronisation an attacker can not waste
-                    unlimited amount of resources by just pretending an IBF does not decode.
+                  To prevent an attacker from sending a peer into an endless loop between active and passive decoding, a
+                  limitation for active/passive roll switches is required. This can be implemented by
+                  a simple counter which terminates the operation after a predefined number of switches.
+                  The number of switches needs to be defined in such a way that it is very unprobable that more
+                  switches are required an the malicious intend of the other peer can be assumed.
+                </t>
+                <t>
+                  Thus, the limitation of the maximum allowed active/passive changes during differential synchronisation is key
+                  to security. By limiting the maximum rounds in differential synchronisation an attacker can not waste
+                  unlimited amount of resources by just pretending an IBF does not decode.
                 </t>
                 <t>
                     The question after how many active/passive switches it can be assumed that the other peer is not honest,