[lsd0003] branch master updated: Corrected some gramar

[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 ad0ed3e  Corrected some gramar
ad0ed3e is described below

commit ad0ed3e3d108fe618732c65dc25cdda9e87fe4ee
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Wed Jun 16 13:20:49 2021 +0200

    Corrected some gramar
---
 draft-summermatter-set-union.xml | 36 +++++++++++++++---------------------
 1 file 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>

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