chapter 1

1 files changed, 27 insertions, 27 deletions

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index ad5f17f..66fdfab 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -70,7 +70,7 @@
 
               Our primary envisioned application domain is the
               distribution of revocation messages in the GNU Name
-              System (GNS) <xref target="GNS" format="default" /><xref target="GNS" format="default"/>. In GNS,
+              System (GNS) <xref target="GNS" format="default" />. In GNS,
               key revocation messages are usually flooded across the
               peer-to-peer overlay network to all connected peers
               whenever a key is revoked. However, as peers may be
@@ -91,7 +91,7 @@
               computational results. We note that for such systems,
               the set reconciliation protocol is merely a component of
               a multiparty consensus protocol, such as the one
-              described in F.Dold's "Byzantine set-union consensus using
+              described in Dold's "Byzantine set-union consensus using
               efficient set reconciliation" <xref target="ByzantineSetUnionConsensusUsingEfficientSetReconciliation" format="default"/>.
             </t>
             <t>
@@ -108,12 +108,14 @@
               the number of network round-trips and the number of bytes
               sent over the network.  Thus, for the protocol to choose
               the right parameters for a given situation, applications
-              using the protocol SHOULD provide a parameter that specifies
+              using an implementation of the protocol SHOULD provide a
+              parameter that specifies
               the cost-ratio of round-trips vs. bandwidth usage.  Given
-              this trade-off factor, the protocol will then choose parameters
-              that minimize the total execution costs.  In particular, there
+              this trade-off factor, an implementation CAN then choose parameters
+              that minimize total execution cost.  In particular, there
               is one major choice to be made, namely between sending the
-              complete set of elements, or sending only the elements that differ.
+              complete set of elements, or computing the set differences and
+              transmitting only the elements in the set differences.
               In the latter case, our design is basically a concrete
               implementation of a proposal by Eppstein.<xref target="Eppstein" format="default" />
             </t>
@@ -123,9 +125,7 @@
               fault-tolerant because it provides cryptographic and
               probabilistic methods to discover if the other peer
               is dishonest or misbehaving.
-            </t>
-            <t>
-              The objective here is to limit resources wasted on
+              Here, the security objective is to limit resources wasted on
               malicious actors. Malicious actors could send malformed
               messages, including malformed set elements, claim to
               have much larger numbers of valid set elements than they
@@ -141,27 +141,27 @@
             </t>
             <t>
               To defend against some of these attacks, applications
-              need to remember the number of elements previously
-              shared with a peer, and provide a way to check that
-              elements are well-formed. Applications may also be able
-              to provide an upper bound on the total number of valid
-              elements that may exist. For example, in E-voting, the
-              number of eligible voters could be used to provide such
+              SHOULD remember the number of elements previously
+              shared with a peer, and SHOULD provide a way to check that
+              elements are well-formed. Applications MAY also
+              provide an upper bound on the total number of valid
+              elements that exist. For example, in E-voting, the
+              number of eligible voters MAY be used to provide such
               an upper bound.
             </t>
-
             <t>
-                Initially, this RFC was created as part of Elias Summermatter's
-                bachelor thesis. Many of the algorithms and parameters
-                documented in this RFC are derived in detail in this thesis.
-                <xref target="byzantine_fault_tolerant_set_reconciliation" format="default"/>
+              A first draft of this RFC is part of Elias Summermatter's
+              bachelor thesis. Many of the algorithms and parameters
+              documented in this RFC are derived from experiments
+              detailed in this thesis.
+              <xref target="byzantine_fault_tolerant_set_reconciliation" format="default"/>
             </t>
 
             <t>
-                This document defines the normative wire format of resource records, resolution processes,
-                cryptographic routines and security considerations for use by implementors.
-                SETU requires a bidirectional secure communication channel between the two parties.
-                Specification of the communication channel is out of scope of this document.
+              This document defines the normative wire format of resource records, resolution processes,
+              cryptographic routines and security considerations for use by implementors.
+              SETU requires a bidirectional secure communication channel between the two parties.
+              Specification of the communication channel is out of scope of this document.
             </t>
             <t>
                 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
@@ -1600,7 +1600,7 @@ FUNCTION get_bucket_id (key, number_of_buckets_per_element, ibf_size)
                     <t>
                         The <em><xref target="messages_request_full" format="title" /></em> message is sent by the initiating peer in <strong>Expect SE</strong> state to the receiving peer, if
                         the operation mode "<xref target="modeofoperation_full-sync" format="title" />" is
-                        determined to be the superior <xref target="modeofoperation" format="title" /> and that it is the better choice that 
+                        determined to be the superior <xref target="modeofoperation" format="title" /> and that it is the better choice that
                        the other peer sends his elements first. The initiating peer changes after sending the <em><xref target="messages_request_full" format="title" /></em> message into
                         <strong>Full Receiving</strong> state.
                     </t>
@@ -1659,7 +1659,7 @@ FUNCTION get_bucket_id (key, number_of_buckets_per_element, ibf_size)
                     <t>
                         The <em><xref target="messages_send_full" format="title" /></em> message is sent by the initiating peer in <strong>Expect SE</strong> state to the receiving peer if
                         the operation mode "<xref target="modeofoperation_full-sync" format="title" />" is
-                        determined as superior <xref target="modeofoperation" format="title" /> and that it is the better choice that the 
+                        determined as superior <xref target="modeofoperation" format="title" /> and that it is the better choice that the
                         peer sends his elements first. The initiating peer changes after sending the <em><xref target="messages_request_full" format="title" /></em> message into
                         <strong>Full Sending</strong> state.
                     </t>
@@ -2557,7 +2557,7 @@ FUNCTION END
                 <t>
                     In order to calculate this plausibility, in Summmermatters paper <xref target="byzantine_fault_tolerant_set_reconciliation" format="default"/>
                     a formula was developed, which depicts the probability with which one
-                    can calculate the corresponding plausibility based on the number of 
+                    can calculate the corresponding plausibility based on the number of
                     new and repeated elements after each received element.
                 </t>
                 <t>