[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0004] branch master updated (fce237f -> bd80a2c)
From: |
gnunet |
Subject: |
[lsd0004] branch master updated (fce237f -> bd80a2c) |
Date: |
Sat, 26 Aug 2023 15:25:37 +0200 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a change to branch master
in repository lsd0004.
from fce237f add version field to flags
new 71afec1 English fix
new ef6f43f add version field to flags -- removed again, truncated flags
to 8 bit for consistency with later sections
new c6749c5 English fix: one byte has no NBO
new dd995fc English fix
new bd80a2c English fix
The 5 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
draft-schanzen-r5n.xml | 29 +++++++++++------------------
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index cef5382..42769fa 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -972,9 +972,9 @@ BEGIN
<section anchor="route_flags">
<name>Flags</name>
<t>
- Flags is a 16-bit vector representing binary options.
+ Flags is an 8-bit vector representing binary options.
Each flag is represented by a bit in the field starting from 0 as
- the rightmost bit to 15 as the leftmost bit.
+ the rightmost bit to 7 as the leftmost bit.
</t>
<dl>
<dt>0: DemultiplexEverywhere</dt>
@@ -1009,14 +1009,6 @@ BEGIN
If non-zero bits are received, implementations <bcp14>MUST</bcp14>
preserve these bits when forwarding messages.
</dd>
- <dt>8-15: Version</dt>
- <dd>
- These bits are used to encode the R<sup>5</sup>N DHT protocol
- version. They <bcp14>MUST</bcp14> be set to 0. Future revisions
- of the protocol <bcp14>MAY</bcp14> change the message format.
- It is envisioned that other cryptographic primitives
<bcp14>MAY</bcp14>
- be introduced into the network protocol in the future via this
mechanism.
- </dd>
</dl>
</section>
<section anchor="p2p_pathelement">
@@ -1069,7 +1061,8 @@ BEGIN
is created by the current hop only after the peer made its routing
decision identifiying the successor peer. The peer public key is not
included after the last signature as it must be that of the sender of
- the message. Similarly, the predecessor of the first element of
+ the message and including it would thus be redundant.
+ Similarly, the predecessor of the first element of
an untruncated path is not stated explicitly, as it must be ZERO.
</t>
<t>
@@ -1395,7 +1388,7 @@ BEGIN
<t>
<tt>PutMessage</tt>s are used to store information at other peers in
the DHT.
Any API which allows applications to initiate <tt>PutMessage</tt>s
needs to
- provide sufficient, implementation-specific information needed to
construct
+ provide sufficient, implementation-specific information to construct
the initial <tt>PutMessage</tt>.
For example, implementations supporting multiple applications and
blocks will
have block type and message flag parameters in addition to the
actual data
@@ -1451,7 +1444,7 @@ BEGIN
</dd>
<dt>VER</dt>
<dd>
- is a 8-bit protocol version in network byte order.
+ is a 8-bit protocol version.
Set to zero. May be used in future protocol versions.
</dd>
<dt>FLAGS</dt>
@@ -1695,7 +1688,7 @@ BEGIN
</dd>
<dt>VER</dt>
<dd>
- is a 8-bit protocol version in network byte order.
+ is a 8-bit protocol version.
Set to zero. May be used in future protocol versions.
</dd>
<dt>FLAGS</dt>
@@ -1928,7 +1921,7 @@ BEGIN
</dd>
<dt>MTYPE</dt>
<dd>
- is the 16-bit message type. Set by the initiator Read-only.
+ is the 16-bit message type. Set by the initiator. Read-only.
It must be set to
the value 148 in network byte order as defined in the GANA
"GNUnet Message Type" registry <xref target="gana_message_type"/>.
</dd>
@@ -2630,9 +2623,9 @@ BEGIN
<tt>REPL_LVL</tt> to a maximum of 16. This imposes
an upper limit on bandwidth amplification an attacker
may achieve for a given network size and topology.
-</t>
+ </t>
<section>
- <name>Disjoint Underlay Protocols</name>
+ <name>Disjoint Underlay or Application Protocol Support</name>
<t>
We note that peers
implementing disjoint sets of underlay protocols may
@@ -2648,7 +2641,7 @@ BEGIN
<t>
When a FindApproximate request is encountered, a peer will try to
respond with the closest block it has that is not filtered by the
- result bloom filter.
+ result Bloom filter.
Implementations <bcp14>MUST</bcp14> ensure that
the cost of evaluating any such query is reasonably small.
For example, implementations <bcp14>MAY</bcp14> consider to
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [lsd0004] branch master updated (fce237f -> bd80a2c),
gnunet <=
- [lsd0004] 02/05: add version field to flags -- removed again, truncated flags to 8 bit for consistency with later sections, gnunet, 2023/08/26
- [lsd0004] 01/05: English fix, gnunet, 2023/08/26
- [lsd0004] 04/05: English fix, gnunet, 2023/08/26
- [lsd0004] 03/05: English fix: one byte has no NBO, gnunet, 2023/08/26
- [lsd0004] 05/05: English fix, gnunet, 2023/08/26