[lsd0001] branch master updated (77f52c8 -> dcb3ce7)

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a change to branch master
in repository lsd0001.

    from 77f52c8  fix
     new f906fcf  graphics
     new dcb3ce7  typos

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 draft-schanzen-gns.xml | 70 +++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 64 insertions(+), 6 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 306064a..91abda4 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -191,6 +191,12 @@
          An application refers to a component which uses a GNS implementation
          to resolve names into records and processes its contents.
        </dd>
+       <dt>Resolver</dt>
+       <dd>
+         The resolver is the part of the GNS implementation which implements
+         the recursive name resolution logic defined in
+         <xref target="resolution"/>.
+       </dd>
        <dt>Name</dt>
        <dd>
          A name in GNS is a domain name as defined in  <xref target="RFC8499"/>
@@ -326,8 +332,8 @@
      </t>
      <t>
        Zone contents are encrypted and signed
-       before being published in a distributed key-value storage
-       (<xref target="publish"/>).
+       before being published in a distributed key-value storage (<xref 
target="publish"/>)
+       as illustrated in <xref target="figure_arch_publish"/>.
        In this process, unique zone identification is hidden from the network
        through the use of key blinding.
        Key blinding allows the creation of signatures for zone contents
@@ -347,9 +353,35 @@
        based on <xref target="RFC7363" />, <xref target="Kademlia" /> or
        <xref target="R5N" />.
      </t>
+     <figure anchor="figure_arch_publish" title="An example diagram of two 
hosts publishing GNS zones.">
+       <artwork name="" type="" align="left" alt=""><![CDATA[
+        Local Host     |  Distributed   |    Remote Host
+                       |   Storage      |
+                       |                |
+                       |    +--------+  |
+                       |   /        /|  |
+  +---------+ Publish  |  +--------+ |  |  Publish +---------+
+  |         | Zones    |  |        | |  |  Zones   |         |
+  |   GNS   |----------|->| Public | |<-|----------|   GNS   |
+  |         |          |  | Zones  | |  |          |         |
+  +---------+          |  |        |/   |          +---------+
+       A               |  +--------+    |               A
+       |               |                |               |
+    +---------+        |                |           +---------+
+   /   |     /|        |                |          /    |    /|
+  +---------+ |        |                |         +---------+ |
+  |         | |        |                |         |         | |
+  |  Local  | |        |                |         |  Local  | |
+  |  Zones  | |        |                |         |  Zones  | |
+  |         |/         |                |         |         |/
+  +---------+          |                |         +---------+
+         ]]></artwork>
+     </figure>
      <t>
+       Applications use the GNS implementation to lookup GNS names.
        Starting from a configurable start zone, names are resolved by 
following zone
-       delegations. For each label in a name, the recursive GNS resolver
+       delegations recursively as illustrated in <xref 
target="figure_arch_resolv"/>.
+       For each label in a name, the recursive GNS resolver
        fetches the respective record from the storage layer (<xref 
target="resolution"/>).
        Without knowledge of the label values and the zone keys, the
        different derived keys are unlinkable both to the original zone key and 
to each
@@ -363,6 +395,32 @@
        with the ability to verify the integrity of the published information
        without disclosing the originating zone.
      </t>
+     <figure anchor="figure_arch_resolv" title="High-level view of the GNS 
resolution process.">
+       <artwork name="" type="" align="left" alt=""><![CDATA[
+                           Local Host          |  Distributed
+                                               |   Storage
+                                               |
+                                               |    +--------+
+                                               |   /        /|
+                                               |  +--------+ |
++-----------+ Name     +---------+ Recursive   |  |        | |
+|           | Lookup   |         | Resolution  |  | Public | |
+|Application|----------|   GNS   |-------------|->| Zones  | |
+|           |<---------|         |<------------|--|        |/
++-----------+ Results  +---------+ Intermediate|  +--------+
+                          A        Results     |
+                          |                    |
+                       +---------+             |
+                      /   |     /|             |
+                     +---------+ |             |
+                     |         | |             |
+                     |  Start  | |             |
+                     |  Zones  | |             |
+                     |         |/              |
+                     +---------+               |
+         ]]></artwork>
+     </figure>
+
      <t>
        In the remainder of this document, the "implementer" refers to the 
developer building
        a GNS implementation including, for example, zone management tools and
@@ -509,8 +567,8 @@ ztype||zkey := Base32GNS-Decode(zTLD)
          the least significant bytes in the leftmost label of the resulting 
string. This allows the
          resolver to determine the ztype and zTLD length from the rightmost
          label and to subsequently determine how many labels the zTLD should 
span.
-         A GNS implementation <bcp14>MUST</bcp14> support the division of zTLD 
in DNS compatible
-         label lengths.
+         A GNS implementation <bcp14>MUST</bcp14> support the division of zTLDs
+         in DNS compatible label lengths.
          For example, assuming a zTLD of 130 characters, the division is:
        </t>
        <!-- FIXME: Is this really really necessary? Really? -->
@@ -791,7 +849,7 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
          evict then from the local store at any time.
        </t>
        <t>
-         Implementations <bcp14>MUST</bcp14> broadcast received revocations to
+         Implementations <bcp14>MUST</bcp14> broadcast received revocations
          if they are valid and not stale.
          Should the calculated validity period differ from the TTL field value,
          the calculated value <bcp14>MUST</bcp14> be used as TTL field value

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.