[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0004] branch master updated: try to address FIXME
|
From: |
gnunet |
|
Subject: |
[lsd0004] branch master updated: try to address FIXME |
|
Date: |
Sun, 20 Aug 2023 18:03:01 +0200 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository lsd0004.
The following commit(s) were added to refs/heads/master by this push:
new 4934307 try to address FIXME
4934307 is described below
commit 493430793e2814b5fb5fd787b9a186bcfea05128
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Sun Aug 20 18:02:47 2023 +0200
try to address FIXME
---
draft-schanzen-r5n.xml | 84 +++++++++++++++++---------------------------------
1 file changed, 28 insertions(+), 56 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index ed3f2a5..0259345 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -1021,11 +1021,12 @@ BEGIN
</section>
<section anchor="p2p_pathelement">
<!-- TODO-GROTHOFF: Discuss this change again. The text is currently
not correct
- it is very difficult to understand. Is it worth 32 byte -->
+ it is very difficult to understand. Is it worth 32 byte;
+ CG: I've fixed the figures, tried to clarify the text. Is it OK
now? -->
<name>Path Element</name>
<t>
A path element represents a hop in the path a message has taken
- through the network.
+ through the overlay network.
The wire format of a path element is illustrated in
<xref target="figure_pathelement"/>.
</t>
@@ -1054,23 +1055,23 @@ BEGIN
<dt>SIGNATURE</dt>
<dd>
is a 64 byte EdDSA signature using the current hop's private
- key affirming the previous and next hops.
+ key affirming the peer IDs of the previous and next hops.
</dd>
<dt>PEER ID</dt>
<dd>
- is the EdDSA public key of the peer on the path.
+ is the EdDSA public key of the previous peer on the path.
</dd>
</dl>
<t>
An ordered list of path elements may be appended to any routed
<tt>PutMessage</tt>s or <tt>ResultMessage</tt>s.
- The signature of a path element is created by the current hop
+ The signature of a path element is created by the current hop only
after it made its routing decision identifiying the successor peer.
</t>
<t>
<xref target="figure_path_ex"/> shows the wire format of an example
- path from Peers A over B and C as it would be received by D in the
- <tt>PUTPATH</tt> of a <tt>PutMessage</tt> or the combined
+ path from peer A over peers B and C as it would be received by peer
D in the
+ <tt>PUTPATH</tt> of a <tt>PutMessage</tt>, or as the combined
<tt>PUTPATH</tt> and <tt>GETPATH</tt> of a <tt>ResultMessage</tt>.
The wire format of the path elements allows a natural
extension of the <tt>PUTPATH</tt> along the route of the
<tt>ResultMessage</tt>
@@ -1085,7 +1086,7 @@ BEGIN
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE A |
-| (64 byte) |
+| (64 bytes) |
| |
| |
| |
@@ -1094,12 +1095,12 @@ BEGIN
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| PEER A |
-| (32 byte) |
+| (32 bytes) |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE B |
-| (64 byte) |
+| (64 bytes) |
| |
| |
| |
@@ -1108,26 +1109,12 @@ BEGIN
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| PEER B |
-| (32 byte) |
+| (32 bytes) |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE C |
-| (64 byte) |
-| |
-| |
-| |
-| |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| PEER C |
-| (32 byte) |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| SIGNATURE D |
-| (64 byte) |
+| (64 bytes) |
| |
| |
| |
@@ -1143,16 +1130,15 @@ BEGIN
path element is omitted leaving only the Peer ID required for the
verification of the subsequent path element signature.
Such a truncated path is indicated with the respective flag (<xref
target="route_flags"/>).
- The Peer ID of the last path element is omitted as it must be that of
- the sender of the PutMesssage or ResultMessage.
- The wire format of a truncated example path from Peers B over C to D
- is illustrated in <xref target="figure_path_ex_trunc"/>.
- The wire format of an example path from Peers B over C as it
- would be received by D in a <tt>PutMessage</tt> or
<tt>ResultMessage</tt>
+ The peer ID of the signer of the last path element is omitted as it
must be that of
+ the sender of the <tt>PutMesssage</tt> or <tt>ResultMessage</tt>.
Similarly,
+ the peer ID of the receiving peer used in the last path element is
omitted as
+ it must be SELF.
+ The wire format of a truncated example path from peers B over C to D
is illustrated in <xref target="figure_path_ex_trunc"/>.
- A <tt>ResultMessage</tt> would indicate in the <tt>PATH_LEN</tt>
field
- a length of 1.
- A <tt>PutMessage</tt> would indicate a length of 1 as the sum of
+ Here, a <tt>ResultMessage</tt> would indicate in the
<tt>PATH_LEN</tt> field
+ a length of 1 while
+ a <tt>PutMessage</tt> would indicate a length of 1 as the sum of
<tt>PUTPATH_L</tt> and <tt>GETPATH_L</tt> fields.
</t>
<figure anchor="figure_path_ex_trunc" title="Example of a truncated
path from Peer B to Peer D.">
@@ -1172,20 +1158,6 @@ BEGIN
| |
| |
| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| PEER C |
-| (32 byte) |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| SIGNATURE D |
-| (64 byte) |
-| |
-| |
-| |
-| |
-| |
-| |
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
@@ -1252,12 +1224,12 @@ BEGIN
</dd>
<dt>PEER PREDECESSOR</dt>
<dd>
- the Peer ID of the previous hop. If the signing peer initiated
+ the peer ID of the previous hop. If the signing peer initiated
the PUT, this field is set to all zeroes.
</dd>
<dt>PEER SUCCESSOR</dt>
<dd>
- the Peer ID of the next hop (not of the signer).
+ the peer ID of the next hop (not of the signer).
</dd>
</dl>
</section>
@@ -1265,15 +1237,15 @@ BEGIN
<section anchor="p2p_hello" numbered="true" toc="default">
<name>HelloMessage</name>
<t>
- When the Underlay notifies the implementation of added or removed
+ When the underlay signals the implementation of added or removed
addresses through <tt>ADDRESS_ADDED</tt> and <tt>ADDRESS_DELETED</tt>
- it <bcp14>MAY</bcp14> disseminate those changes to neighbors using
+ an implementation <bcp14>MAY</bcp14> disseminate those changes to
neighbors using
<tt>HelloMessage</tt>s.
- Initiation of <tt>HelloMessages</tt> by the implementation itself is
<bcp14>RECOMMENDED</bcp14>.
+ Initiation of such <tt>HelloMessages</tt> by the implementation
itself is <bcp14>RECOMMENDED</bcp14>.
<tt>HelloMessage</tt>s are used to inform neighbors of
a peer about the sender's available addresses. The
recipients use these messages to inform their respective
- Underlays about ways to sustain the connections and to
+ underlays about ways to sustain the connections and to
generate <tt>HELLO</tt> blocks (see <xref target="hello_block"/>)
to answer peer discovery queries
from other peers.
@@ -1287,7 +1259,7 @@ BEGIN
| MSIZE | MTYPE | RESERVED | URL_CTR |
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE /
-/ (64 byte) |
+/ (64 bytes) |
+-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [lsd0004] branch master updated: try to address FIXME,
gnunet <=