[lsd0003] branch master updated: chapter 1

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository lsd0003.

The following commit(s) were added to refs/heads/master by this push:
     new da2d890  chapter 1
da2d890 is described below

commit da2d89045c2fc10ea393e4eb917c3dca480486bc
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sat Jun 12 16:49:12 2021 +0200

    chapter 1
---
 draft-summermatter-set-union.xml | 54 ++++++++++++++++++++--------------------
 1 file 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>

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