[lsd0003] branch master updated: Changed some more

[gnunet]

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

elias-summermatter pushed a commit to branch master
in repository lsd0003.

The following commit(s) were added to refs/heads/master by this push:
     new 0ee6d56  Changed some more
0ee6d56 is described below

commit 0ee6d56638928879c19d313fc20d9839d6b90fcb
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Thu Jun 10 07:33:11 2021 +0200

    Changed some more
---
 draft-summermatter-set-union.xml | 34 +++++++++++++++-------------------
 1 file changed, 15 insertions(+), 19 deletions(-)

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index 1d0f0b6..244e79e 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -14,7 +14,7 @@
 <?rfc sortrefs="yes" ?>
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>
-<rfc category="info" docName="draft-schanzen-gns-01" ipr="trust200902"
+<rfc category="info" docName="draft-summermatter-set-union-03" 
ipr="trust200902"
      obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
     <!-- xml2rfc v2v3 conversion 2.26.0 -->
     <front>
@@ -849,7 +849,7 @@ FUNCTION get_bucket_id (key, number_of_buckets_per_element, 
ibf_size)
                 exchange the full sets.
             </t>
             <t>
-                <eref 
target="https://git.gnunet.org/lsd0003.git/plain/statemachine/full_state_machine.png";>Link
 to statemachine diagram</eref>
+                <eref 
target="https://git.gnunet.org/lsd0003.git/plain/statemachine/full_state_machine.png";>Link
 to the statemachine diagram</eref>
             </t>
             <t>
                 The second possibility is that the difference of the sets is 
small compared to the set size.
@@ -880,7 +880,7 @@ FUNCTION get_bucket_id (key, number_of_buckets_per_element, 
ibf_size)
                     set elements in <em><xref target="messages_full_element" 
format="title" /></em> messages 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>
-                    <eref 
target="https://git.gnunet.org/lsd0003.git/plain/statemachine/state_machine_full.png";>Link
 to statemachine diagram</eref>
+                    <eref 
target="https://git.gnunet.org/lsd0003.git/plain/statemachine/state_machine_full.png";>Link
 to the statemachine diagram</eref>
                 </t>
                 <t><strong>The behavior of the participants the different 
state is described below:</strong></t>
                 <dl>
@@ -927,7 +927,7 @@ FUNCTION get_bucket_id (key, number_of_buckets_per_element, 
ibf_size)
                     is called the passive peer.
                 </t>
                 <t>
-                    <eref 
target="https://git.gnunet.org/lsd0003.git/plain/statemachine/differential_state_machine.png";>Link
 to statemachine diagram</eref>
+                    <eref 
target="https://git.gnunet.org/lsd0003.git/plain/statemachine/differential_state_machine.png";>Link
 to the statemachine diagram</eref>
                 </t>
                 <t><strong>The behavior of the participants the different 
states is described below:</strong></t>
                 <dl>
@@ -1010,7 +1010,7 @@ FUNCTION get_bucket_id (key, 
number_of_buckets_per_element, ibf_size)
                         <t>
                             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
+                            A negative (-1) pure bucket indicates that an 
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>
@@ -1033,7 +1033,7 @@ FUNCTION get_bucket_id (key, 
number_of_buckets_per_element, ibf_size)
                             <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 active peer. If a inquiry has been sent and
                                 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. The sent demand needs to be 
added to a list with unsatisfied demands.
@@ -1047,13 +1047,9 @@ FUNCTION get_bucket_id (key, 
number_of_buckets_per_element, ibf_size)
                                 <em><xref target="messages_elements" 
format="title" /></em> message if a offer request
                                 for the element has been sent.
                                 In case the demanded element does not exist in 
the
-                                set there was probably a bucket decoded that 
was not pure so potentially all <em><xref target="messages_offer" 
format="title" /></em>
-                                and <em><xref target="messages_demand" 
format="title" /></em> messages sent later are invalid
-                                in this case a role change active -> passive 
with a new IBF is easiest.
-
-                                If a demand for the same element is received 
multiple times the demands should be
-                                discarded.
-                                FIXME: I thought demanding the same element 
multiple times is now verboten?
+                                set, there was probably a bucket decoded that 
was not pure. Potentially all <em><xref target="messages_offer" format="title" 
/></em>
+                                and <em><xref target="messages_demand" 
format="title" /></em> messages sent later are invalid.
+                                In this case a role change active -> passive 
with a new IBF is easiest.
                             </dd>
                             <dt><em><xref target="messages_elements" 
format="title" /></em> message:</dt>
                             <dd>
@@ -1311,7 +1307,7 @@ FUNCTION get_bucket_id (key, 
number_of_buckets_per_element, ibf_size)
             </section>
 
             <section anchor="messages_elements" numbered="true" toc="default">
-                <name>Elements</name>
+                <name>Element</name>
 
                 <section anchor="messages_elements_description" 
numbered="true" toc="default">
                     <name>Description</name>
@@ -1787,8 +1783,8 @@ FUNCTION get_bucket_id (key, 
number_of_buckets_per_element, ibf_size)
                 <section anchor="messages_sec_description" numbered="true" 
toc="default">
                     <name>Description</name>
                     <t>
-                        The Strata estimator can be compressed with gzip to 
improve performance. For
-                        details see section <xref target="performance" 
format="title" />.
+                        The Strata estimator can be compressed with gzip to 
improve performance. This can be recognized
+                        by the different message type number from <xref 
target="gana" format="title" />.
                     </t>
                     <t>
                         Since the content of the message is the same as the 
uncompressed Strata Estimator, the details
@@ -2022,7 +2018,7 @@ FUNCTION END
                     </figure>
                 </section>
                 <section anchor="performance_num_buck_hash" numbered="true" 
toc="default">
-                    <name>Number of buckets a element is hashed into</name>
+                    <name>Number of buckets an element is hashed into</name>
                     <t>
                         The number of buckets an element is hashed to is 
hardcoded to 3. Reasoning and
                         justification can be found in the following work
@@ -2357,7 +2353,7 @@ FUNCTION END
                     The messages are dependent on each other. There are 
dependencies that are
                     mandatory, e.g. for a sent "Demand" message, an "Element" 
message must
                     always be received. But there are also messages for which 
a response is
-                    not mandatory, e.g. the "Inquiry" message is only followed 
by an
+                    not mandatory, e.g. the <em><xref 
target="messages_inquiry" format="title" /></em> message is only followed by an
                     "Offer" message, if the corresponding element is in the 
set. Due to this
                     fact, checks can be installed to verify compliance with 
the following chain.
                 </t>
@@ -2862,7 +2858,7 @@ FUNCTION END
                         <t>
                         A check needs to be in place that prevents receiving 
an inquiry
                         for an element multiple times or more inquiries than 
are plausible.
-                        The sending and receiving of <xref 
target="messages_inquiry" format="title" /> messages should
+                        The sending and receiving of <em><xref 
target="messages_inquiry" format="title" /></em> messages should
                         always be protected with an <xref 
target="security_generic_functions_mfc" format="title" />
                         to secure the protocol against missing, doubled, not 
in order or unexpected messages.
                         </t>

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