commit ad0ed3e3d108fe618732c65dc25cdda9e87fe4ee
parent 3217f39e11167ccf51517996642001c9ef3ce3af
Author: Elias Summermatter <elias.summermatter@seccom.ch>
Date: Wed, 16 Jun 2021 13:20:49 +0200
Corrected some gramar
Diffstat:
1 file changed, 15 insertions(+), 21 deletions(-)
diff --git 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>
