[lsd0001] branch master updated: update start zones

[gnunet]

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 e6ac2a7  update start zones
e6ac2a7 is described below

commit e6ac2a76e9377686995b6cb6c2c6211e96f6aab8
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Sat Feb 19 23:35:58 2022 +0100

    update start zones
---
 draft-schanzen-gns.xml | 64 +++++++++++++++++++++++++++++---------------------
 1 file changed, 37 insertions(+), 27 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 7f426ea..b8cab31 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -382,6 +382,11 @@
        If this functionality is not implemented, names can still be resolved
        if zone keys for the initial step in the name resolution are available
        (see <xref target="resolution"/>).
+       As users can own and manage their own zones, each local zone SHOULD be
+       associated with a single GNS label, but users MAY choose to use longer
+       names consisting of multiple labels.
+       The associated labels or names are used in order to discover starting
+       zones in the resolution process (see <xref target="governance"/>).
      </t>
      <t>
        Each zone type (ztype) is a unique 32-bit number.
@@ -801,9 +806,10 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
        records.
        A new local zone is established by selecting a zone type and creating a
        zone key pair.
-       If this mechanism is not implemented, name resolution is
-       limited to non-local start zones (<xref target="governance"/>)
-       and no zones can be published in the storage (<xref target="publish"/>).
+       If this mechanism is not implemented, 
+       and no zones can be published in the storage (<xref target="publish"/>)
+       and name resolution is limited to non-local start zones
+       (<xref target="governance"/>).
      </t>
      <t>
        A GNS resource record holds the data of a specific record in a zone.
@@ -1898,9 +1904,6 @@ q := SHA-512 (ZKDF-Public(zk, label))
      <section anchor="governance" numbered="true" toc="default">
        <name>Start Zones</name>
        <t>
-         <!-- FIXME: This is a mess. Does the resolver know the configuration
-         or only the client? Because the resolver needs to know the zones for
-         redirects, for example -->
          The resolution of a GNS name starts in an initial start zone.
          The resolver may have one or more local start zones configured
          which point to local or remote zone keys.
@@ -1911,23 +1914,29 @@ q := SHA-512 (ZKDF-Public(zk, label))
        <t>
          The governance model of any zone is at the sole discretion
          of the zone owner.
-         However, the choice of start zone(s) is at the sole
+         However, the choice of available start zone(s) is at the sole
          discretion of the local system administrator or user.
          This property addresses the issue of a single hierarchy with a
          centrally controlled root and the related issue of distribution and
          management of root servers in DNS (see <xref target="RFC8324"/>, 
Section 3.10 and 3.12).
+         The only exception to this rule are names ending with a zTLD.
+         In this case the start zone is explicitly given in the rightmost
+         label of the name to resolve.
+         In order to ensure uniqueness of names with zTLDs any
+         implementation MUST use the given zone as start zone.
        </t>
-        <t>
-         Below examples can be found how a resolver SHOULD
-         discover the start zone.  The process given is not exhaustive and
-         resolvers MAY supplement it with other mechanisms or ignore it if the
-         particular application requires a different process.
+       <t>
+         A GNS resolver MUST follow the steps below in order to discover
+         the start zone.
+         The process given is not exhaustive and resolvers MAY supplement it
+         with other mechanisms if the particular application
+         requires a different process:
        </t>
        <t>
-         GNS implementations MUST first try to interpret the top-level domain 
of
-         a GNS name as a zone key representation (i.e. a zTLD).
-         If the top-level domain can be converted to a valid ztype and zone
-         key value, the resulting zone key is used as the start zone:
+         First, any implementation MUST try to interpret the top-level domain 
of
+         the given name zTLD.
+         If the rightmost label can be converted to a valid ztype and zone
+         key, it MUST be used as the start zone:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 Example name: www.example.<zTLD>
@@ -1935,10 +1944,7 @@ Example name: www.example.<zTLD>
 => Name to resolve from start zone: www.example
          ]]></artwork>
        <t>
-         In GNS, users MAY own and manage their own zones.
-         Each local zone SHOULD be associated with a single GNS label,
-         but users MAY choose to use longer names consisting of
-         multiple labels.
+         An implementation MAY allow the user to manage local zones.
          If the name of a locally managed zone matches the suffix
          of the name to be resolved, resolution MUST start from the
          respective local zone with the longest matching suffix:
@@ -1954,10 +1960,11 @@ com = (d2,zk2)
 => Name to resolve from start zone: www.example
          ]]></artwork>
        <t>
-         Finally, additional "suffix-to-zone" mappings MAY be configured.
-         Suffix to zone key mappings MUST be configurable through a local
+         Finally, an implementation MAY support the configuration of additional
+         "suffix-to-zTLD" mappings.
+         Suffix-to-zTLD mappings MUST be configurable through a local
          configuration file or database by the user or system administrator.
-         The suffix MAY consist of multiple GNS labels concatenated with a
+         A suffix MAY consist of multiple GNS labels concatenated with a
          label separator.
          If multiple suffixes match the name to resolve, the longest
          matching suffix MUST be used. The suffix length of two results
@@ -1969,15 +1976,18 @@ com = (d2,zk2)
        <artwork name="" type="" align="left" alt=""><![CDATA[
 Example name: www.example.org
 Local suffix mappings:
-org = zk0
-example.org = zk1
-example.com = zk2
+org = zTLD0 (ztype0||zk0)
+example.org = zTLD1 (ztype1||zk1)
+example.com = zTLD2 (ztype2||zk2)
 ...
 => Start zone: zk1
 => Name to resolve from start zone: www
          ]]></artwork>
+       <t>
+         If no start zone can be discovered, resolution MUST fail and an
+         error MUST be returned to the application.
+       </t>
      </section>
-
        <section anchor="recursion" numbered="true" toc="default">
          <name>Recursion</name>
          <t>

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