lsd0004

LSD0004: R5N Distributed Hash Table
Log | Files | Refs

commit e62b6c8939a7d13a0d2b036fdd0fb923b0a8872f
parent 5729ba5c9a597ed2761fb55eb23e5b95e5bf5879
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date:   Mon, 15 Jul 2024 17:07:50 +0200

pass msc

Diffstat:
Mdraft-schanzen-r5n.xml | 40++++++++++++++++++++++++----------------
1 file changed, 24 insertions(+), 16 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml @@ -264,10 +264,10 @@ <dt>Block Type</dt> <dd> A unique 32-bit value identifying the data format of a <em>block</em>. - <em>Block types</em> may be public or private. - Applications that require application-specific - block payloads are expected to register a - block type in the GANA Block-Type registry + <em>Block types</em> are public and applications that require + application-specific + block payloads are expected to register one or more + block types in the GANA Block-Type registry (<xref target="gana_block_type"/>) and provide a specification of the associated block operations (<xref target="block_functions"/>) to implementors of @@ -1196,7 +1196,8 @@ ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE): of <tt>GetMessages</tt> or <tt>PutMessages</tt>. The status of initiator is relevant for peers when processing <tt>ResultMessages</tt> - due to the required handover of results to the originating application. + due to the required handover of results to the application that requested + the respective result. </t> <t> The implementation <bcp14>MUST</bcp14> listen for <tt>RECEIVE(P, M)</tt> signals @@ -1244,9 +1245,11 @@ ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE): </dd> <dt>3: Truncated</dt> <dd> - This is a special flag which is set if a peer truncated the path - and thus the first hop on the path is given without a signature - to enable checking of the next signature. This flag MUST never be set in + This is a special flag which is set if a peer truncated the + recorded path. + This results in the first hop on the path to be given without a signature + to enable checking of the next signature. + This flag <bcp14>MUST NOT</bcp14> be set in a <tt>GetMessage</tt>. </dd> <dt>4-7: Reserved</dt> @@ -1312,7 +1315,8 @@ ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE): included after the last signature as it must be that of the sender 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. + an untruncated path is not stated explicitly, as it must be <tt>ZERO</tt> + (32 NULL-bytes). </t> <t> <xref target="figure_path_ex"/> shows the wire format of an example @@ -1389,7 +1393,7 @@ ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE): <t> A path may be truncated in which case the signature of the truncated path element is omitted leaving only the public key of the peer preceeding - the trunction which is required for the + the truncation which is required for the verification of the subsequent path element signature. Such a truncated path is indicated with the respective truncated flag (<xref target="route_flags"/>). @@ -2524,11 +2528,15 @@ ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE): <t> This section describes various considerations R<sup>5</sup>N implementations must consider with respect to blocks. - Specifically, implementations <bcp14>SHOULD</bcp14> be able - to validate and persist blocks. Implementations + Specifically, implementations <bcp14>SHOULD</bcp14> be validate and persist + blocks. + Implementations <bcp14>MAY</bcp14> not support validation for all types - of blocks. On some devices, storing blocks <bcp14>MAY</bcp14> - also be impossible due to lack of storage capacity. + of blocks. + For example, on some devices, storing blocks is impossible due to lack of + storage capacity. + Block storage improves lookup performance for local applications and also + other peers. Not storing blocks results in degraded performance. </t> <t> The block type determines the format and handling of the block @@ -2645,7 +2653,7 @@ ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE): <bcp14>SHOULD NOT</bcp14> be returned to the previous hop. Peers that do not understand the block type <bcp14>MAY</bcp14> return such duplicate results - anyway. + anyway and implementations must take this into account. </dd> <dt>FILTER_IRRELEVANT</dt> <dd> @@ -2654,7 +2662,7 @@ ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE): <bcp14>SHOULD NOT</bcp14> be returned to the previous hop. Peers that do not understand the block type <bcp14>MAY</bcp14> return such irrelevant results - anyway. + anyway and implementations must take this into account. </dd> </dl> <t>