[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0004] 02/03: Reorder sections and add a note on reload
|
From: |
gnunet |
|
Subject: |
[lsd0004] 02/03: Reorder sections and add a note on reload |
|
Date: |
Fri, 23 Dec 2022 11:13:39 +0100 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0004.
commit cd8c94da90d6a8bea1aa8187c4f32e2fbc50b88f
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Fri Dec 23 18:21:09 2022 +0900
Reorder sections and add a note on reload
---
draft-schanzen-r5n.xml | 244 +++++++++++++++++++++++++------------------------
1 file changed, 124 insertions(+), 120 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 3ee4d14..04d0210 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -98,7 +98,11 @@
<middle>
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
- <!--
+ <!--
+ 2022/12/23 MSC: I moved references to rfc6940 to security
considerations.
+ I think we should talk about R5N in the positive here only, not about
+ RELOAD in the negative.
+
- Lean. Can be implemented. Not overengineered.
- Path tracking (more difficult) -> Not built in
- Certificates central server ?
@@ -156,125 +160,125 @@
when, they appear in all capitals, as shown here.
</t>
</section>
- <section anchor="terminology">
- <name>Terminology</name>
- <dl>
- <dt>Applications</dt>
- <dd>
- Applications are components which directly use the DHT overlay
- interfaces. Possible applications include the GNU Name System
- <xref target="I-D.draft-schanzen-gns"/> and the CADET transport
system
- <xref target="cadet"/>.
- </dd>
- <dt>Application API</dt>
- <dd>
- The application API exposes the core operations of the DHT overlay
- to applications.
- This includes storing blocks in the DHT and retrieving blocks from
the DHT.
- </dd>
- <dt>Block</dt>
- <dd>
- Variable-size unit of payload stored in the DHT
- under a <tt>Key</tt>. Commonly also called a "value" when
talking
- about a DHT as a "key-value store".
- </dd>
- <dt>Block Storage</dt>
- <dd>
- The <tt>Block Storage</tt> component is used to persist and manage
- <tt>Block</tt> data by peers.
- It includes logic for enforcing storage quotas, caching strategies
and
- data validation.
- </dd>
- <dt>Block-Type:</dt>
- <dd>
- A unique 32-bit value identifying the data format of a
<tt>Block</tt>.
- Block-Types are either private or allocated by GANA (see
- <xref target="gana"/>).
- </dd>
- <dt>Key</dt>
- <dd>
- 512-bit identifier of a location in the DHT. Multiple
<tt>Block</tt>s can be
- stored under the same key. <tt>Peer Addresses</tt> are valid keys.
- </dd>
- <dt>Message Processing</dt>
- <dd>
- The Message Processing component processes requests from and
- generates responses to applications and the underlay network.
- </dd>
- <dt>Neighbor</dt>
- <dd>
- A neighbor is a peer which is directly able to communicate
- with our peer via the <tt>Underlay Interface</tt>.
- </dd>
- <dt>Peer</dt>
- <dd>
- A host that is participating in the overlay. Peers are
- responsible for holding some portion of the data that has been
- stored in the overlay, and they are responsible for routing
- messages on behalf of other hosts as needed by the Routing
- Algorithm.
- </dd>
- <dt>Peer Address</dt>
- <dd>
- The <tt>Peer Address</tt> is the identifier used on the Overlay
- to address a peer.
- It is a SHA-512 hash of the <tt>Peer ID</tt>.
- </dd>
- <dt>Peer ID</dt>
- <dd>
- The <tt>Peer ID</tt> is the public key which is used to authenticate
- a peer in the underlay.
- The Peer ID is the public key of the corresponding
- Ed25519<xref target="ed25519" /> peer private key.
- </dd>
- <dt>Routing</dt>
- <dd>
- The Routing component includes the routing table as well as
- routing and peer selection logic. It facilitates the R<sup>5</sup>N
routing
- algorithm with required data structures and algorithms.
- </dd>
- <dt>Responsible Peer</dt>
- <dd>
- The peer <tt>N</tt> that is responsible for a specific key
<tt>K</tt>, as
- defined by the <tt>SelectClosestPeer(K, P)</tt> algorithm (see
- <xref target="routing"/>.
- </dd>
- <dt>Underlay Interface</dt>
- <dd>
- The Underlay Interface is an abstraction layer on top of the
- supported links of a peer. Peers may be linked by a variety of
- different transports, including "classical" protocols such as
- TCP, UDP and TLS or advanced protocols such as GNUnet, I2P or Tor.
- </dd>
- </dl>
- </section>
- <section>
- <name>Structure of This Document</name>
- <t>
- <xref target="terminology"/> gives an overview of the terminology
used in
- this document.
- <xref target="architecture"/> then describes the overall
architecture and
- the scope of this specification.
- <xref target="overlay"/> describes the application API, which
clarifies
- the semantics provided by R<sup>5</sup>N for applications
- and thus is crucial as it motivates the rest of the design.
- <xref target="underlay"/> describes the underlay interface. This is
the
- abstraction that applications must provide to R<sup>5</sup>N
- and thus a prerequisite for using the DHT.
- Before a DHT is usable, it must be bootstrapped.
- Bootstrapping is described in <xref target="bootstrapping"/>.
- Bloom filters, a key data structure used in various
- places, are introduced in <xref target="bloom_filters" />
- The central operation of a DHT is routing, which is
- detailed in <xref target="routing"/>. The processing of the various
- network messages is described in <xref target="p2p_messages"/>.
Handling
- of Blocks, including validation and storage are described
- in <xref target="blockstorage"/>. General security considerations
are detailed
- in <xref target="security" />. IANA and GANA registry updates are
listed
- in <xref target="iana" /> and <xref target="gana"/>. The document
concludes with test
- vectors in <xref target="testvectors"/> and appendices with
references.
- </t>
- </section>
+ </section>
+ <section anchor="terminology">
+ <name>Terminology</name>
+ <dl>
+ <dt>Applications</dt>
+ <dd>
+ Applications are components which directly use the DHT overlay
+ interfaces. Possible applications include the GNU Name System
+ <xref target="I-D.draft-schanzen-gns"/> and the CADET transport system
+ <xref target="cadet"/>.
+ </dd>
+ <dt>Application API</dt>
+ <dd>
+ The application API exposes the core operations of the DHT overlay
+ to applications.
+ This includes storing blocks in the DHT and retrieving blocks from the
DHT.
+ </dd>
+ <dt>Block</dt>
+ <dd>
+ Variable-size unit of payload stored in the DHT
+ under a <tt>Key</tt>. Commonly also called a "value" when talking
+ about a DHT as a "key-value store".
+ </dd>
+ <dt>Block Storage</dt>
+ <dd>
+ The <tt>Block Storage</tt> component is used to persist and manage
+ <tt>Block</tt> data by peers.
+ It includes logic for enforcing storage quotas, caching strategies and
+ data validation.
+ </dd>
+ <dt>Block-Type:</dt>
+ <dd>
+ A unique 32-bit value identifying the data format of a <tt>Block</tt>.
+ Block-Types are either private or allocated by GANA (see
+ <xref target="gana"/>).
+ </dd>
+ <dt>Key</dt>
+ <dd>
+ 512-bit identifier of a location in the DHT. Multiple <tt>Block</tt>s
can be
+ stored under the same key. <tt>Peer Addresses</tt> are valid keys.
+ </dd>
+ <dt>Message Processing</dt>
+ <dd>
+ The Message Processing component processes requests from and
+ generates responses to applications and the underlay network.
+ </dd>
+ <dt>Neighbor</dt>
+ <dd>
+ A neighbor is a peer which is directly able to communicate
+ with our peer via the <tt>Underlay Interface</tt>.
+ </dd>
+ <dt>Peer</dt>
+ <dd>
+ A host that is participating in the overlay. Peers are
+ responsible for holding some portion of the data that has been
+ stored in the overlay, and they are responsible for routing
+ messages on behalf of other hosts as needed by the Routing
+ Algorithm.
+ </dd>
+ <dt>Peer Address</dt>
+ <dd>
+ The <tt>Peer Address</tt> is the identifier used on the Overlay
+ to address a peer.
+ It is a SHA-512 hash of the <tt>Peer ID</tt>.
+ </dd>
+ <dt>Peer ID</dt>
+ <dd>
+ The <tt>Peer ID</tt> is the public key which is used to authenticate
+ a peer in the underlay.
+ The Peer ID is the public key of the corresponding
+ Ed25519<xref target="ed25519" /> peer private key.
+ </dd>
+ <dt>Routing</dt>
+ <dd>
+ The Routing component includes the routing table as well as
+ routing and peer selection logic. It facilitates the R<sup>5</sup>N
routing
+ algorithm with required data structures and algorithms.
+ </dd>
+ <dt>Responsible Peer</dt>
+ <dd>
+ The peer <tt>N</tt> that is responsible for a specific key <tt>K</tt>,
as
+ defined by the <tt>SelectClosestPeer(K, P)</tt> algorithm (see
+ <xref target="routing"/>.
+ </dd>
+ <dt>Underlay Interface</dt>
+ <dd>
+ The Underlay Interface is an abstraction layer on top of the
+ supported links of a peer. Peers may be linked by a variety of
+ different transports, including "classical" protocols such as
+ TCP, UDP and TLS or advanced protocols such as GNUnet, I2P or Tor.
+ </dd>
+ </dl>
+ </section>
+ <section>
+ <name>Structure of This Document</name>
+ <t>
+ <xref target="terminology"/> gives an overview of the terminology
used in
+ this document.
+ <xref target="architecture"/> then describes the overall architecture and
+ the scope of this specification.
+ <xref target="overlay"/> describes the application API, which clarifies
+ the semantics provided by R<sup>5</sup>N for applications
+ and thus is crucial as it motivates the rest of the design.
+ <xref target="underlay"/> describes the underlay interface. This is the
+ abstraction that applications must provide to R<sup>5</sup>N
+ and thus a prerequisite for using the DHT.
+ Before a DHT is usable, it must be bootstrapped.
+ Bootstrapping is described in <xref target="bootstrapping"/>.
+ Bloom filters, a key data structure used in various
+ places, are introduced in <xref target="bloom_filters" />
+ The central operation of a DHT is routing, which is
+ detailed in <xref target="routing"/>. The processing of the various
+ network messages is described in <xref target="p2p_messages"/>. Handling
+ of Blocks, including validation and storage are described
+ in <xref target="blockstorage"/>. General security considerations are
detailed
+ in <xref target="security" />. IANA and GANA registry updates are listed
+ in <xref target="iana" /> and <xref target="gana"/>. The document
concludes with test
+ vectors in <xref target="testvectors"/> and appendices with references.
+ </t>
</section>
<section anchor="architecture" numbered="true" toc="default">
<name>Architecture</name>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.