commit 493430793e2814b5fb5fd787b9a186bcfea05128
parent fd792950235f8d753fe90e0a5b227555c31e5b69
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Sun, 20 Aug 2023 18:02:47 +0200
try to address FIXME
Diffstat:
1 file changed, 28 insertions(+), 56 deletions(-)
diff --git 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.">
@@ -1173,20 +1159,6 @@ BEGIN
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
-| PEER C |
-| (32 byte) |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| SIGNATURE D |
-| (64 byte) |
-| |
-| |
-| |
-| |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
<t>
@@ -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 |
+-----+-----+-----+-----+-----+-----+-----+-----+
