[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: more graphics
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: more graphics |
|
Date: |
Thu, 10 Mar 2022 11:17:36 +0100 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new aa69ed9 more graphics
aa69ed9 is described below
commit aa69ed90dc6a186dbce6d9720e4682a31fd0f824
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Thu Mar 10 11:17:33 2022 +0100
more graphics
---
draft-schanzen-gns.xml | 78 ++++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 70 insertions(+), 8 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 4e0a9bd..868643e 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1731,7 +1731,7 @@ GET(key) -> value
<t>
Resource records are grouped by their respective labels,
encrypted and published together in a single resource records block
- (RRBLOCK) in the storage under a key q: PUT(q, RRBLOCK).
+ (RRBLOCK) in the storage under a key q as illustrated in <xref
target="figure_storage_publish"/>.
The key q is derived from the zone key and the respective
label of the contained records.
The required knowledge of both zone key and label in combination
@@ -1742,6 +1742,34 @@ GET(key) -> value
The implementation <bcp14>MUST</bcp14> use the PUT storage procedure in
order to update
the zone contents accordingly.
</t>
+ <figure anchor="figure_storage_publish" title="Management and publication
of local zones in the distributed storage.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Local Host | Distributed
+ | Storage
+ |
+ | +--------+
+ | / /|
+ | +--------+ |
++-----------+ +---------+ | | | |
+| | | |PUT(q, RRBLOCK) | | Public | |
+| User | | GNS |----------------|->| Zones | |
+| | | | | | |/
++-----------+ +---------+ | +--------+
+ | A |
+ | | Zone records |
+ | | grouped by label |
+ | | |
+ | +---------+ |
+ |Create / Delete / | /| |
+ |and Update +---------+ | |
+ |Local Zones | | | |
+ | | Local | | |
+ +-------------->| Zones | | |
+ | |/ |
+ +---------+ |
+ ]]></artwork>
+ </figure>
+
<section anchor="blinding" numbered="true" toc="default">
<name>The Storage Key</name>
<t>
@@ -1957,19 +1985,51 @@ q := SHA-512 (ZKDF-Public(zk, label))
Instead, it <bcp14>MUST</bcp14> respond to a resolution request with
either the
requested resource record or an error message in case the resolution
fails.
- The following sections detail how resolution is initiated and each
- iteration in the resolution is processed.
- </t>
- <t>
+ <xref target="figure_resolution"/> illustrates how an application
+ requests the lookup of a GNS name (1).
The application <bcp14>MAY</bcp14> provide a desired record type to the
resolver.
- The desired record type is used to guide processing.
+ Subsequently, the Start Zone is determined (2) and the recursive
+ resolution process started.
+ This is where the desired record type is used to guide processing.
For example, if a zone delegation record type is requested, the
resolution of the apex label in that zone must be skipped, as
the desired record is already found.
- The resolver implementation <bcp14>MUST NOT</bcp14> filter results
according to the desired
- record type.
+ Details on how the resolution process is initiated and each iterative
+ result (3a,3b) in the resolution is processed are provided in the
sections below.
+ The results of the lookup are eventually returned to the application
(4).
+ The implementation <bcp14>MUST NOT</bcp14> filter results
+ according to the desired record type.
Filtering of record sets is typically done by the application.
</t>
+ <figure anchor="figure_resolution" title="The recursive GNS resolution
process.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Local Host | Distributed
+ | Storage
+ |
+ | +--------+
+ | / /|
+ | +--------+ |
++-----------+ (1) Name +---------+ | | | |
+| | Lookup | | (3a) GET(q) | | Public | |
+|Application|----------| GNS |-------------------|->| Zones | |
+| |<---------| |<------------------|--| |/
++-----------+ (4) +---------+ (3b) RRBLOCK | +--------+
+ Records A |
+ | |
+ | |
+ (2) Determination of | |
+ Start Zone | |
+ | |
+ +---------+ |
+ / | /| |
+ +---------+ | |
+ | | | |
+ | Start | | |
+ | Zones | | |
+ | |/ |
+ +---------+ |
+ ]]></artwork>
+ </figure>
<section anchor="governance" numbered="true" toc="default">
<name>Start Zones</name>
<t>
@@ -2081,6 +2141,8 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
record could not be processed <bcp14>SHOULD</bcp14> be returned in
the error
description. The implementation <bcp14>MAY</bcp14> choose not to
return the reason for the failure,
merely complicating troubleshooting for the user.
+ </t>
+ <t>
The next steps depend on the context of the name that is being
resolved:
</t>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: more graphics,
gnunet <=