From ad0ed3e3d108fe618732c65dc25cdda9e87fe4ee Mon Sep 17 00:00:00 2001 From: Elias Summermatter Date: Wed, 16 Jun 2021 13:20:49 +0200 Subject: 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. ]]> - - 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 . - To link messages the SHA-512 element hashes that are part of all messages except in the - message can be used. + To link messages the SHA-512 element hashes, that are part of all messages, except in the + messages, can be used. To link an message to an message the SHA-512 hash from the offer has to be salted and converted to the IBF-Key (as described in - ) this then can - be matched against the received message. + ). The IBF-Key can + be matched with the received message. - In the end of the set reconciliation operation after receiving and sending the - message it should be checked + At the end of the set reconciliation operation after receiving and sending the + message, it should be checked that all demands have been satisfied and all elements have been received. - This is based on , section 5.3 (Message Control Flow). @@ -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. - - 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 message is strictly monotonic increasing and is a multiple of the MAX_BUCKETS_PER_MESSAGE - defined in the section otherwise the + defined in the section, otherwise the connection MUST be aborted. An other sanity check is to ensure that the "OFFSET" message field never - is a higher than the "IBF SIZE" field in the + is higher than the "IBF SIZE" field in the message. -
@@ -2771,22 +2767,20 @@ END FUNCTION should conclude the transmission of the IBF and a change to the Active Decoding phase should be ensured. - - To verify that all IBFs have been received a simple validation can be made - the number of buckets in the message + To verify that all IBFs have been received, a simple validation can be made. + The number of buckets in the message added to the value in the message OFFSET field should always be equal to the "IBF SIZE". 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 + into account and to validate the size of the received IBF with the in described function get_next_ibf_size(). If any of these three checks fail the operation must be aborted. -
-- cgit v1.2.3