commit 0ee6d56638928879c19d313fc20d9839d6b90fcb
parent 9c42def25d73b5b284eaf0f58d66d5e4ffbef07c
Author: Elias Summermatter <elias.summermatter@seccom.ch>
Date: Thu, 10 Jun 2021 07:33:11 +0200
Changed some more
Diffstat:
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git 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>
