more comments

1 files changed, 139 insertions, 97 deletions

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index b108c79..ca001a2 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -746,9 +746,9 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
 
                 <t>
                     When the initiating peer decides to use the full synchronisation mode and the set of the initiating peer is bigger than the set of the receiving peer, the initiating
-                    peer sends a <em><xref target="messages_request_full" format="title" /></em> message and change from <strong>Expecting SE</strong> to the <strong>Full Receiving</strong> State.
-                    In all other cases the initiating peer sends all set elements to the other peer followed by the <em><xref target="messages_full_done" format="title" /></em> message and
-                    changes into <strong>Full Sending</strong> state.
+                    peer sends a <em><xref target="messages_request_full" format="title" /></em> message, and transitions from <strong>Expecting SE</strong> to the <strong>Full Receiving</strong> state.
+                    If the set of the initiating peer is smaller, it sends all set elements to the other peer followed by the <em><xref target="messages_full_done" format="title" /></em> message, and
+                    transitions into the <strong>Full Sending</strong> state.
                 </t>
                 <t>
                 ############# Statemaschine diagram full mode ##################
@@ -758,87 +758,105 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
                     <dt><strong>Expecting IBF:</strong></dt>
                     <dd>
                         If a peer in the <strong>Expecting IBF</strong> state receives a <em><xref target="messages_request_full" format="title" /></em> message from the other peer, the
-                        peer starts sending all the elements of the set followed by a <em><xref target="messages_full_done" format="title" /></em> message to the other peer and change to the
-                        <strong>Full Sending</strong> State. If the peer receives an <em><xref target="messages_full_element" format="title" /></em> message the peer changes to the <strong>Full Receiving</strong> state.
+                        peer sends all the elements of its set followed by a <em><xref target="messages_full_done" format="title" /></em> message to the other peer, and transitions to the
+                        <strong>Full Sending</strong> state. If the peer receives an <em><xref target="messages_full_element" format="title" /></em> message, it processes the element and transitions to the <strong>Full Receiving</strong> state.
                     </dd>
                     <dt><strong>Full Sending:</strong></dt>
                     <dd>
-                        While a peer is in <strong>Full Sending</strong> state the peer expects to continuously receiving elements from the other
-                        peer. As soon as a the <em><xref target="messages_full_done" format="title" /></em> message is received the peer changes into <strong>Finished</strong> state.
+                        While a peer is in <strong>Full Sending</strong> state the peer expects to continuously receive elements from the other
+                        peer. As soon as a the <em><xref target="messages_full_done" format="title" /></em> message is received, the peer transitions into
+                        the <strong>Finished</strong> state.
                     </dd>
                     <dt><strong>Full Receiving (In code: Expecting IBF): </strong></dt>
                     <dd>
-                        While a peer is in <strong>Full Receiving</strong> state the peer expects to continuously receiving elements from the other
-                        peer. As soon as a the <em><xref target="messages_full_done" format="title" /></em> message is received the peer sends the remaining elements from his set to the other
-                        peer followed by a <em><xref target="messages_full_done" format="title" /></em>. After sending the last message the peer changes into <strong>Finished</strong> state.
+                        While a peer is in the <strong>Full Receiving</strong> state, it expects to continuously receive elements from the other
+                        peer. As soon as a the <em><xref target="messages_full_done" format="title" /></em> message is received, it sends
+                        the remaining elements (those it did not receive) from its set to the other
+                        peer, followed by a <em><xref target="messages_full_done" format="title" /></em>.
+                        After sending the last message, the peer transitions into the <strong>Finished</strong> state.
                     </dd>
                 </dl>
             </section>
             <section anchor="modeofoperation_individual-elements" numbered="true" toc="default">
                 <name>Delta Synchronisation Mode</name>
                 <t>
-                    When the initiating peer in <strong>Expected SE</strong> state decide to use the delta synchronisation mode, the peer
-                    sends a <em><xref target="messages_ibf" format="title" /></em> to the receiving peer and changes into the <strong>Passive Decoding</strong> state.
+                    When the initiating peer in the <strong>Expected SE</strong> state decides to use the delta synchronisation mode, it
+                    sends a <em><xref target="messages_ibf" format="title" /></em> to the receiving peer and transitions into the <strong>Passive Decoding</strong> state.
                 </t>
                 <t>
-                    The receiving peer in the <strong>Expecting IBF</strong> state then receives the
-                    <em><xref target="messages_ibf" format="title" /></em> message from the initiating peer and changes into <strong>Expecting IBF Last</strong> state when there
-                    are multiple <em><xref target="messages_ibf" format="title" /></em> messages to sent, when there is just a single <em><xref target="messages_ibf" format="title" /></em> message the reviving peer
-                    switches directly to the <strong>Active Decoding</strong> state.
+                    The receiving peer in the <strong>Expecting IBF</strong> state receives the
+                    <em><xref target="messages_ibf" format="title" /></em> message from
+                    the initiating peer and transitions into the <strong>Expecting IBF Last</strong> state when there
+                    are multiple <em><xref target="messages_ibf" format="title" /></em> messages to sent,
+                    when there is just a single <em><xref target="messages_ibf" format="title" /></em> message the reviving peer
+                    transitions directly to the <strong>Active Decoding</strong> state.
                 </t>
                 <t>
-                    The peer that is in the <strong>Active Decoding</strong>, <strong>Finish closing</strong> or in the <strong>Expecting IBF Last</strong> state is called active
-                    peer and the peer that is in <strong>Passive Decoding</strong> and <strong>Finish Waiting</strong> state is called the passive peer.
+                    The peer that is in the <strong>Active Decoding</strong>, <strong>Finish Closing</strong> or in the <strong>Expecting IBF Last</strong>
+                    state is called the active peer and the peer that is in either the <strong>Passive Decoding</strong> or the <strong>Finish Waiting</strong> state
+                    is called the passive peer.
                 </t>
                 <t>
                     ############# Statemaschine Delta Synchronisation Mode ##################
                 </t>
-                <t><strong>The behavior of the participants the different state is described below:</strong></t>
+                <t><strong>The behavior of the participants the different states is described below:</strong></t>
                 <dl>
                     <dt><strong>Passive Decoding:</strong></dt>
                     <dd>
                         <t>
-                        In the <strong>Passive Decoding</strong> state the passive peer reacts to request from the active peer.
-                        The action the passive peer executes depend on the message the passive peer receives in the <strong>Passive Decoding</strong> state from the active peer
-                        and is described bellow on message basis.
+                        In the <strong>Passive Decoding</strong> state the passive peer reacts to requests from the active peer.
+                        The action the passive peer executes depends on the message the passive peer receives in the <strong>Passive Decoding</strong> state from the active peer
+                        and is described below on a per message basis.
                         </t>
 
                         <dl>
-                            <dt><em><xref target="messages_inquiry" format="title" /></em> Message:</dt>
+                            <dt><em><xref target="messages_inquiry" format="title" /></em> message:</dt>
                             <dd>
                                 The <em><xref target="messages_inquiry" format="title" /></em> message
-                                is received if the active peer requests the hash of an element that is missing in the active peers set.
-                                In this case the passive peer answers with an <em><xref target="messages_offer" format="title" /></em> message
-                                which contains a hash of the requested element.
+                                is received if the active peer requests the SHA-512 hash of one or more elements (by sending the 64 bit element ID)
+                                that are missing from the active peer's set.
+                                In this case the passive peer answers with <em><xref target="messages_offer" format="title" /></em> messages
+                                which contain the SHA-512 hash of the requested element.  If the passive peer does not have an element with
+                                a matching element ID, it MUST ignore the inquiry.  If multiple elements match the 64 bit element ID, the passive
+                                peer MUST send offers for all of the matching elements.
                             </dd>
-                            <dt><em><xref target="messages_demand" format="title" /></em> Message:</dt>
+                            <dt><em><xref target="messages_demand" format="title" /></em> message:</dt>
                             <dd>
                                 The <em><xref target="messages_demand" format="title" /></em> message
                                 is received if the active peer requests a complete element that is missing in the active peers set. If the requested element is valid
-                                the passive peer answers with the <em><xref target="messages_elements" format="title" /></em> message which contains the requested element.
+                                the passive peer answers with an <em><xref target="messages_elements" format="title" /></em> message which contains the full,
+                                application-dependent data of the requested element.  If the passive peer receives a demand for a SHA-512 hash for which
+                                it has no element, a protocol violation is detected and the protocol MUST be aborted.
+                                Implementations MAY strengthen this and forbid demands without previous matching offers.
                             </dd>
-                            <dt><em><xref target="messages_offer" format="title" /></em> Message:</dt>
+                            <dt><em><xref target="messages_offer" format="title" /></em> message:</dt>
                             <dd>
                                 The <em><xref target="messages_offer" format="title" /></em> message
-                                is received if the active peer has decoded an element that is present in the active peers set and is missing in the
-                                set of the passive peer. If the offered element is missing in the set of the passive peer, the passive peer answers
-                                with a <em><xref target="messages_demand" format="title" /></em> message.
+                                is received if the active peer has decoded an element that is present in the active peers set and may be missing in the
+                                set of the passive peer. If the SHA-512 hash of the offer is indeed not a hash of any of the elements from the set of
+                                the passive peer, the passive peer MUST answer with a <em><xref target="messages_demand" format="title" /></em> message
+                                for that SHA-512 hash and remember that it issued this demand.
                             </dd>
-                            <dt><em><xref target="messages_elements" format="title" /></em> Message:</dt>
+                            <dt><em><xref target="messages_elements" format="title" /></em> message:</dt>
                             <dd>
-                                A element that is received is saved and validated and not further action is taken.
+                                A element that is received is validated and safed and not further action is taken.
+                                FIXME: Eh, don't we need to (1) check that we did in fact DEMAND this element, and (2) strike it
+                                from the list of pending demands?
                             </dd>
-                            <dt><em><xref target="messages_ibf" format="title" /></em> Message:</dt>
+                            <dt><em><xref target="messages_ibf" format="title" /></em> message:</dt>
                             <dd>
-                                If an <em><xref target="messages_ibf" format="title" /></em> message is received the passive client assumes that the decoding of the IBF
-                                on the active site has failed and role change is initiated. The peer changes  directly
-                                into the <strong>Active Decoding</strong> state or in <strong>Expecting IBF Last</strong> state
-                                depending on how many IBFs are sent.
+                                If an <em><xref target="messages_ibf" format="title" /></em> message is received, this
+                                indicates that decoding of the IBF on the active site has failed and roles should be swapped.
+                                The receiving passive peer transitions into the <strong>Active Decoding</strong> state
+                                or into the <strong>Expecting IBF Last</strong> state depending on how many IBFs are sent.
+                                FIXME: really should use two IBF message types (IBF_DATA, IBF_LAST).
                             </dd>
-                            <dt><em><xref target="messages_done" format="title" /></em> Message:</dt>
+                            <dt><em><xref target="messages_done" format="title" /></em> message:</dt>
                             <dd>
                                 Receiving the <em><xref target="messages_done" format="title" /></em> message signals
-                                the passive peer that all demand of the active peer have been satisfied. In this case the passive peer changes into
+                                the passive peer that all demands of the active peer have been satisfied. Alas, the
+                                active peer will continue to process demands from the passive peer.
+                                Upon receiving this message, the passive peer transitions into the
                                 <strong>Finish Waiting</strong> state.
                             </dd>
                         </dl>
@@ -846,51 +864,63 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
                     <dt><strong>Active Decoding:</strong></dt>
                     <dd>
                         <t>
-                            In <strong>Active Decoding</strong> state the active peer decodes the IBFs and evaluate the set difference
-                            between the active and passive peer. In case the IBF decodes successfully the active peer sends offers and
-                            inquiries to the passive peer depending on which site the element is missing.
+                            In the <strong>Active Decoding</strong> state the active peer decodes the IBFs and evaluates the set difference
+                            between the active and passive peer. Whenever an element ID is obtained by decoding the IBF, the active peer
+                            sends either an offer or an inquiry to the passive peer, depending on which site the decoded element is missing.
                         </t>
                         <t>
-                            If the IBF decodes a positive (1) pure bucket the element is missing on the passive peers site
-                            so the active peer sends an <em><xref target="messages_offer" format="title" /></em> to the active peer.
-                            A negative (-1) pure bucket indicates that a element is missing in the active peers set so the active peers
-                            sends <em><xref target="messages_inquiry" format="title" /></em> to the passive client.
+                            If the IBF decodes a positive (1) pure bucket, the element is missing on the passive peers site.
+                            Thus the active peer sends an <em><xref target="messages_offer" format="title" /></em> to the passive peer.
+                            A negative (-1) pure bucket indicates that a element is missing in the active peers set, so the active peer
+                            sends a <em><xref target="messages_inquiry" format="title" /></em> to the passive peer.
                         </t>
                         <t>
-                            In case the IBF does not successfully decode the active peer sends an IBF to the passive client
-                            and changes into <strong>Passive Decoding</strong> state. This initiates a role change
-                            active->passive.
+                            In case the IBF does not successfully decode anymore, the active peer sends a new IBF to the passive client
+                            and changes into <strong>Passive Decoding</strong> state. This initiates a role swap.
+                            FIXME: On what basis is the new IBF constructed? Specifically, which set is used? Do we
+                            wait for the completion of pending demands first? How do L/k/M change? Some of this should
+                            be detailed here, but the full details likely need a separate section on the algorithms.
                         </t>
                         <t>
-                            All other actions the active peer executes depend on the message the active peer receives from
-                            the passive peer. The actions are described below on message basis:
+                            All other actions taken by the active peer depend on the message the active peer receives from
+                            the passive peer. The actions are described below on a per message basis:
                         </t>
+                        <!-- FIXME: Done message generation not described anywhere! -->
                         <dl>
-                            <dt><em><xref target="messages_offer" format="title" /></em> Message:</dt>
+                            <dt><em><xref target="messages_offer" format="title" /></em> message:</dt>
                             <dd>
                                 The <em><xref target="messages_offer" format="title" /></em> message indicates that the
                                 passive peer received a <em><xref target="messages_inquiry" format="title" /></em> message from
-                                the active peer. If a Inquiry has been sent and the offered element is missing in the active peers set,
+                                the active peer. If a Inquiry has been sent and <!-- FIXME: is this indeed a condition that is checked? -->
+                                the offered element is missing in the active peers set,
                                 the active peer sends a <em><xref target="messages_demand" format="title" /></em> message to the
                                 passive peer.
+                                <!-- FIXME: what happens if the offer is for an element that is not missing? I think then we just ignore it, right? -->
                             </dd>
-                            <dt><em><xref target="messages_demand" format="title" /></em> Message:</dt>
+                            <dt><em><xref target="messages_demand" format="title" /></em> message:</dt>
                             <dd>
-                               The <em><xref target="messages_demand" format="title" /></em> message indicates that the
+                                The <em><xref target="messages_demand" format="title" /></em> message indicates that the
                                 passive peer received a <em><xref target="messages_offer" format="title" /></em> from
                                 the active peer. The active peer satisfies the demand of the passive peer by sending
                                 <em><xref target="messages_elements" format="title" /></em> message if a offer request
                                 for the element has been sent.
+                                FIXME: Do we really check that we first made an offer? FIXME: what happens if
+                                we do not have an element with the respective SHA-512 hash?
+                                FIXME: should we check that a demand cannot be sent repeatedly for the same element?
                             </dd>
-                            <dt><em><xref target="messages_elements" format="title" /></em> Message:</dt>
+                            <dt><em><xref target="messages_elements" format="title" /></em> message:</dt>
                             <dd>
-                                A element that is received is saved and validated and not further action is taken.
+                                A element that is received is validated and saved and not further action is taken.
+                                FIXME: what if we receive elements we already know? Is that cause for failure?
+                                FIXME: Do we not need to remember that our demands were satisfied?
                             </dd>
-                            <dt><em><xref target="messages_done" format="title" /></em> Message:</dt>
+                            <dt><em><xref target="messages_done" format="title" /></em> message:</dt>
                             <dd>
                                 Receiving the message <em><xref target="messages_done" format="title" /></em> indicates
                                 that all demands of the passive peer have been satisfied. The active peer then changes into the
                                 state <strong>Finish Closing</strong> state.
+                                FIXME: We cannot really receive this message before we completed decoding the IBF and send DONE to the passive peer.
+                                So that might be an additional constraint to check here!
                             </dd>
                         </dl>
                     </dd>
@@ -898,7 +928,7 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
                     <dd>
                         <t>
                             In the <strong>Expecing IBF Last</strong> state the active peer continuously receives <em><xref target="messages_ibf" format="title" /></em>
-                            messages from the passive peer. When the last <em><xref target="messages_ibf" format="title" /></em> message is resived
+                            messages from the passive peer. When the last <em><xref target="messages_ibf" format="title" /></em> message is received
                             the active peer changes into <strong>Active Decoding</strong> state.
                         </t>
                     </dd>
@@ -907,6 +937,7 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
                         <t>
                             In this states the peers are waiting for all demands to be satisfied and for the synchronisation
                             to be completed. When all demands are satisfied the peer changes into state <strong>done</strong>.
+                            FIXME: I thought "done" was a message, and the final state was called "Finished"!??!?
                         </t>
                     </dd>
                 </dl>
@@ -914,21 +945,23 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
             <section anchor="modeofoperation_combined-mode" numbered="true" toc="default">
                 <name>Combined Mode</name>
                 <t>
-                    In the Combined Mode the <xref target="modeofoperation_full-sync" format="title" /> and the <xref target="modeofoperation_individual-elements" format="title" />
-                    are combined to reach the optimal result.
+                    In the combined mode the <xref target="modeofoperation_full-sync" format="title" /> and
+                    the <xref target="modeofoperation_individual-elements" format="title" />
+                    are combined to minimize resource consumption.
                 </t>
                 <t>
                     The <xref target="modeofoperation_individual-elements" format="title" /> is only efficient on small set
-                    differences or if the byte-size of the elements is large. Is the set difference big for example
-                    in the initial synchronisation a <xref target="modeofoperation_full-sync" format="title" /> is
-                    more efficient. The exact heuristics and parameter on the basis the protocol evaluates which mode
-                    is the optimal is described in the <xref target="performance" format="title" /> section of this document.
+                    differences or if the byte-size of the elements is large. Is the set difference is estimated to be large
+                    the <xref target="modeofoperation_full-sync" format="title" /> is
+                    more efficient. The exact heuristics and parameters on which the protocol decides which mode
+                    should be used are described in the <xref target="performance" format="title" /> section of this document.
                 </t>
                 <t>
-                    There are two main conditions when a <xref target="modeofoperation_full-sync" format="title" />
-                    is enforced. The first condition is if the flag "FULL_SYNC" is set, this is used for testing purposes only and
-                    should not be used in production environment. The second condition applies if one of the peers has an empty
-                    set and the set is initially synchronized.
+                    There are two main cases when a <xref target="modeofoperation_full-sync" format="title" />
+                    is always used.
+                    The first case is when one of the peers announces having an empty set. FIXME: HOW is this announced?
+                    The second case is if the application requested full synchronization explicitly.
+                    This is useful for testing and should not be used in production.
                 </t>
                 <t>
                     ############# NOTE ############
@@ -950,14 +983,16 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
                 <section anchor="messages_operation_request_description" numbered="true" toc="default">
                     <name>Description</name>
                     <t>
-                        This message is the first message of the protocol and it is sent to signal the receiving peer
+                        This message is the first message of the protocol and it is sent to signal to the receiving peer
                         that the initiating peer wants to initialize a new connection.
                     </t>
                     <t>
-                        This Message is sent in the transition between the <strong>Initiating connection</strong> state and the <strong>Expect SE</strong> state.
+                        This message is sent in the transition between the <strong>Initiating Connection</strong> state and the <strong>Expect SE</strong> state.
                     </t>
                     <t>
-                        If a peer receives this message the peer answers with sending a Strata estimator back.
+                      If a peer receives this message and is willing to run the protocol, it answers by sending back a Strata estimator message.
+                      FIXME: turn 'strata estimator' into a link!
+                      Otherwise it simply closes the connection.
                     </t>
                 </section>
                 <section anchor="messages_operation_request_structure" numbered="true" toc="default">
@@ -984,19 +1019,20 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
                         </dd>
                         <dt>MSG TYPE</dt>
                         <dd>
-                            the type of SETU_P2P_OPERATION_REQUEST as registered in <xref target="gana" format="title" /> in network byte order.
+                            the type of SETU_P2P_OPERATION_REQUEST as registered in <xref target="gana" format="title" />, in network byte order.
                         </dd>
                         <dt>OPERATION TYPE</dt>
                         <dd>
-                            is a 32-bit unsigned integer which describes the type of operation that should be initiated.
+                          is a 32-bit unsigned integer which describes the type of operation that should be initiated.
+                          FIXME: unclear what this is. What operation types are there? What are the numeric values?
                         </dd>
                         <dt>ELEMENT COUNT</dt>
                         <dd>
-                            is the count of the elements the requesting party has stored in a 32-bit unsigned integer.
+                            is the number of the elements the requesting party has in its set, as a 32-bit unsigned integer in network byte order.
                         </dd>
                         <dt>APX</dt>
                         <dd>
-                            is SHA 512-bit hash that identifies the application.
+                            is a SHA-512 hash that identifies the application.
                         </dd>
                     </dl>
                 </section>
@@ -1072,7 +1108,11 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
                         <dt>IBF-SLICES</dt>
                         <dd>
                             are variable count of slices in an array. A single slice contains out of a 64-bit Key, a
-                            32-bit Key Hash and a 32 bit count.
+                            32-bit Key Hash and an 8-bit count.
+                            FIXME: this is not sufficiently precise! How are the element IDs (and IDSUMS) computed?
+                            How are the HASHes (and HASHSUMS) computed? Which byte order is used? What role does
+                            the SALT have in these computations? Definitively needs DETAILED algorithm(s) and
+                            test vectors.
                         </dd>
                     </dl>
                     <figure anchor="figure_ibf_slice">
@@ -1108,7 +1148,7 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
                         case the client changes to the <strong>Finished</strong> state as soon as all demands for elements have been satisfied.
                     </t>
                     <t>
-                        This message is exclusively send in the <xref target="modeofoperation_individual-elements" format="title" />.
+                        This message is exclusively sent in the <xref target="modeofoperation_individual-elements" format="title" />.
                     </t>
                 </section>
                 <section anchor="messages_elements_structure" numbered="true" toc="default">
@@ -1170,15 +1210,15 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
                     <t>
                         The offer message is an answer to an <em><xref target="messages_inquiry" format="title" /></em> message
                         and transmits the full hash of an element that has been requested by the other peer.
-                        This full hash enables the other peer to check if the element is really missing in his set and
-                        eventually send a <em><xref target="messages_demand" format="title" /></em> message for that a element.
+                        This full hash enables the other peer to check if the element is really missing in its set and
+                        eventually sends a <em><xref target="messages_demand" format="title" /></em> message for that a element.
                     </t>
                     <t>
                         The offer is sent and received only in the <strong>Active Decoding</strong> and in the <strong>Passive Decoding</strong>
                         state.
                     </t>
                     <t>
-                        This message is exclusively send in the <xref target="modeofoperation_individual-elements" format="title" />.
+                        This message is exclusively sent in the <xref target="modeofoperation_individual-elements" format="title" />.
                     </t>
                 </section>
                 <section anchor="messages_offer_structure" numbered="true" toc="default">
@@ -1219,12 +1259,12 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
                 <section anchor="messages_inquiry_description" numbered="true" toc="default">
                     <name>Description</name>
                     <t>
-                        The Inquiry message is exclusively send by the active peer in <strong>Active Decoding</strong> state
+                        The Inquiry message is exclusively sent by the active peer in <strong>Active Decoding</strong> state
                         to request the full hash of an element that is missing in the active peers set. This is normally answered
                         by the passive peer with <em><xref target="messages_offer" format="title" /></em> message.
                     </t>
                     <t>
-                        This message is exclusively send in the <xref target="modeofoperation_individual-elements" format="title" />.
+                        This message is exclusively sent in the <xref target="modeofoperation_individual-elements" format="title" />.
                     </t>
                     <t>
                         NOTE: HERE IS AN IMPLEMENTATION BUG UNNECESSARY 32-BIT PADDING!
@@ -1269,12 +1309,12 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
                     <t>
                         The demand message is sent in the <strong>Active Decoding</strong> and in the <strong>Passive Decoding</strong>
                         state. It is a answer to a received <em><xref target="messages_offer" format="title" /></em> message
-                        and its send if the element described in the <em><xref target="messages_offer" format="title" /></em> message
+                        and is sent if the element described in the <em><xref target="messages_offer" format="title" /></em> message
                         is missing in the peers set. In the normal workflow the answer to the demand message is an
                         <em><xref target="messages_elements" format="title" /></em> message.
                     </t>
                     <t>
-                        This message is exclusively send in the <xref target="modeofoperation_individual-elements" format="title" />.
+                        This message is exclusively sent in the <xref target="modeofoperation_individual-elements" format="title" />.
                     </t>
                 </section>
                 <section anchor="messages_demand_structure" numbered="true" toc="default">
@@ -1314,11 +1354,13 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
                 <section anchor="messages_done_description" numbered="true" toc="default">
                     <name>Description</name>
                     <t>
-                        The done message is send when all <em><xref target="messages_demand" format="title" /></em> messages
+                        The done message is sent when all <em><xref target="messages_demand" format="title" /></em> messages
                         have been successfully satisfied and the set is complete synchronized.
+                        FIXME: we might want to consider adding an additional final checksum (XOR SHA-512 hash) over
+                        all elements to this message, to ensure that really both sides ended up with the same set?
                     </t>
                     <t>
-                        This message is exclusively send in the <xref target="modeofoperation_individual-elements" format="title" />.
+                        This message is exclusively sent in the <xref target="modeofoperation_individual-elements" format="title" />.
                     </t>
                 </section>
                 <section anchor="messages_done_structure" numbered="true" toc="default">
@@ -1399,7 +1441,7 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
                     </t>
                     <t>
                         The receiving peer receives the Request Full message in the <strong>Expecting IBF</strong>, afterwards the receiving peer
-                        starts sending his complete set in <xref target="messages_full_element" format="title" /> messages to the initiating peer.
+                        starts sending its complete set in <xref target="messages_full_element" format="title" /> messages to the initiating peer.
                     </t>
                 </section>
                 <section anchor="messages_request_full_structure" numbered="true" toc="default">
@@ -1572,6 +1614,13 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
 
         </section>
 
+        <section anchor="performance" numbered="true" toc="default">
+            <name>Performance Considerations</name>
+            <t>
+                --- TEXT HERE ---
+            </t>
+        </section>
+
         <section anchor="security" numbered="true" toc="default">
             <name>Security Considerations</name>
             <section anchor="security_crypto" numbered="true" toc="default">
@@ -1595,13 +1644,6 @@ hashSum |     0000    |     0000    |     0000    |     0000    |
             </section>
         </section>
 
-        <section anchor="performance" numbered="true" toc="default">
-            <name>Performance</name>
-            <t>
-                --- TEXT HERE ---
-            </t>
-        </section>
-
         <section anchor="gana" numbered="true" toc="default">
             <name>GANA Considerations</name>
             <t>