1 files changed, 15 insertions, 21 deletions

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index 10a5ce0..270bad2 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -2542,25 +2542,23 @@ peers set           +---------+        +---------+        +---------+
                      ===>: Always answer needed.
                     ]]></artwork>
                 </figure>
-                <!-- CORRECT -->
                 <t>
-                    In the message control flow its important to ensure that no duplicated message are received
+                    In the message control flow its important to ensure that no duplicated messages are received
                     (Except inquiries where collisions are possible) and only messages are received which are compliant
                     with the flow in <xref target="security_generic_functions_mfc_chain" format="default" />.
-                    To link messages the SHA-512 element hashes that are part of all messages except in the
-                    <em><xref target="messages_inquiry" format="title" /></em> message can be used.
+                    To link messages the SHA-512 element hashes, that are part of all messages, except in the
+                    <em><xref target="messages_inquiry" format="title" /></em> messages, can be used.
                     To link an <em><xref target="messages_inquiry" format="title" /></em> message to an
                     <em><xref target="messages_offer" format="title" /></em> message
                     the SHA-512 hash from the offer has to be salted and converted to the IBF-Key (as described in
-                    <xref target="ibf_format_id_generation_pseudo_code" format="default" />) this then can
-                    be matched against the received <em><xref target="messages_inquiry" format="title" /></em> message.
+                    <xref target="ibf_format_id_generation_pseudo_code" format="default" />). The IBF-Key can
+                    be matched with the received <em><xref target="messages_inquiry" format="title" /></em> message.
                 </t>
                 <t>
-                    In the end of the set reconciliation operation after receiving and sending the
-                    <em><xref target="messages_done" format="title" /></em> message it should be checked
+                    At the end of the set reconciliation operation after receiving and sending the
+                    <em><xref target="messages_done" format="title" /></em> message, it should be checked
                     that all demands have been satisfied and all elements have been received.
                 </t>
-                <!-- CORRECT -->
                 <t>
                     This is based on <xref target="byzantine_fault_tolerant_set_reconciliation" format="default"/>, section 5.3 (Message Control Flow).
                 </t>
@@ -2748,20 +2746,18 @@ END FUNCTION
                           abort the protocol if its resource limits are likely to be
                           exceeded, or if the size is implausible for the given operation.
                         </t>
-                        <!-- CORRECT -->
                         <t>
-                          It needs to be checked that that the offset (message field "OFFSET")
+                          It needs to be checked that the offset (message field "OFFSET")
                           for every received <em><xref target="messages_ibf" format="title" /></em> message
                           is strictly monotonic increasing and is a multiple of the MAX_BUCKETS_PER_MESSAGE
-                          defined in the <xref target="constants" format="title" /> section otherwise the
+                          defined in the <xref target="constants" format="title" /> section, otherwise the
                           connection MUST be aborted.
                         </t>
                         <t>
                           An other sanity check is to ensure that the "OFFSET" message field never
-                          is a higher than the "IBF SIZE" field in the <em><xref target="messages_ibf" format="title" /></em>
+                          is higher than the "IBF SIZE" field in the <em><xref target="messages_ibf" format="title" /></em>
                           message.
                         </t>
-                        <!-- CORRECT -->
                     </dd>
                     <dt><xref target="messages_ibf_last" format="title" /></dt>
                     <dd>
@@ -2771,22 +2767,20 @@ END FUNCTION
                             should conclude the transmission of the IBF and a change to the <strong>Active Decoding</strong>
                             phase should be ensured.
                         </t>
-                        <!-- CORRECT -->
                         <t>
-                            To verify that all IBFs have been received a simple validation can be made
-                            the number of buckets in the <em><xref target="messages_ibf_last" format="title" /></em> message
+                            To verify that all IBFs have been received, a simple validation can be made.
+                            The number of buckets in the <em><xref target="messages_ibf_last" format="title" /></em> message
                             added to the value in the message OFFSET field should always be equal to the "IBF SIZE".
                         </t>
                         <t>
                             Further plausibility checks can be made. One is to ensure that after each active/passive
-                            switch the IBF can never more than double in size. An other plausibility check is
-                            is that an IBF probably never will be bigger than the byzantine upperbound multiplied by two.
+                            switch the IBF can never be more than double in size. Another plausibility check is
+                            that an IBF probably never will be larger than the byzantine upperbound multiplied by two.
                             The third plausibility check is to take successfully decoded IBF keys (received offers and demands)
-                            into account and validating the size of the received IBF with the in <xref target="performance_formula_ibf_parameters_code" format="default" />
+                            into account and to validate the size of the received IBF with the in <xref target="performance_formula_ibf_parameters_code" format="default" />
                             described function get_next_ibf_size(). If any of these three checks fail the operation
                             must be aborted.
                         </t>
-                        <!-- CORRECT -->
                     </dd>
                 </dl>
             </section>