[lsd0001] branch master updated: be more consistent in use of root zone vs. start zone

[gnunet]

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

grothoff pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new e4cf445  be more consistent in use of root zone vs. start zone
e4cf445 is described below

commit e4cf44575e4b70d4a643aa9bed30774b4b7da16a
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Wed Feb 2 10:06:14 2022 +0100

    be more consistent in use of root zone vs. start zone
---
 draft-schanzen-gns.xml | 45 ++++++++++++++++++++++++---------------------
 1 file changed, 24 insertions(+), 21 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 8e08de7..cd3e1b3 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -157,7 +157,9 @@
        for Assigned Names and Numbers (ICANN).
        In DNS terminology, GNS roughly follows the idea of a hyperlocal root
        zone deployment, with the difference that it is not
-       expected that all deployments use the same local root zone.
+       expected that all deployments use the same local root zone,
+       and that users can easily delegate control of arbitrary domain names to
+       arbitrary zones.
      </t>
      <t>
        This document defines the normative wire format of resource records, 
resolution processes,
@@ -299,7 +301,7 @@
      </t>
      <t>
        Names in GNS are domain names as defined in <xref target="RFC8499"/>.
-       Starting from a configurable root zone, names are resolved by following 
zone
+       Starting from a configurable start zone, names are resolved by 
following zone
        delegations. 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
@@ -1811,15 +1813,15 @@ q := SHA-512 (ZKDF-Public(zk, label))
        is retrieved.
      </t>
      <section anchor="governance" numbered="true" toc="default">
-       <name>Root Zone</name>
+       <name>Start Zones</name>
        <t>
          The resolution of a GNS name must start in a given start zone
-         indicated to the resolver using any zone key.
-         The local resolver may have a local start zone configured/hard-coded
-         which points to a local or remote start zone key.
-         A resolver client may also determine the start zone from the
-         suffix of the name given for resolution or using information
-   retrieved out of band.
+         indicated to the resolution algorithm using any (public) zone key.
+         The local resolver may have one or more local start zones 
configured/hard-coded
+         which point to a local or remote start zone public keys.
+         A resolver may also determine the start zone from the
+         suffix of the name given for resolution, or using information
+         retrieved out of band.
          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
@@ -1832,19 +1834,19 @@ q := SHA-512 (ZKDF-Public(zk, label))
          In the following, we give examples how a local client resolver SHOULD
          discover the start zone.  The process given is not exhaustive and
          clients MAY supplement it with other mechanisms or ignore it if the
-   particular application requires a different process.
+         particular application requires a different process.
        </t>
        <t>
          GNS clients 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 is indicated to be a label representation of
-         a zone key with a supported zone type value, the root zone of
+         a zone key with a supported zone type value, the start zone of
          the resolution process is implicitly given by the suffix of the name:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 Example name: www.example.<zTLD>
-=> Root zone: zk of type ztype
-=> Name to resolve from root zone: www.example
+=> Start zone: zk of type ztype
+=> Name to resolve from start zone: www.example
          ]]></artwork>
        <t>
          In GNS, users MAY own and manage their own zones.
@@ -1861,8 +1863,8 @@ fr = (d0,zk0)
 org = (d1,zk1)
 com = (d2,zk2)
 ...
-=> Root zone: zk1
-=> Name to resolve from root zone: www.example
+=> Start zone: zk1
+=> Name to resolve from start zone: www.example
          ]]></artwork>
        <t>
          Finally, additional "suffix-to-zone" mappings MAY be configured.
@@ -1883,8 +1885,8 @@ org = zk0
 example.org = zk1
 example.com = zk2
 ...
-=> Root zone: zk1
-=> Name to resolve from root zone: www
+=> Start zone: zk1
+=> Name to resolve from start zone: www
          ]]></artwork>
      </section>
 
@@ -2276,13 +2278,14 @@ NICK: john (Supplemental)
            (as in <xref target="RFC6781" />) in order to provide usable 
security.
          </t>
          <t>
-           Similarly, users are required to manage their local root zone.
+           Similarly, users are required to manage their local start zone 
configuration.
            In order to ensure integrity and availability or names, users must
-           ensure that their local root zone information is not compromised or
+           ensure that their local start zone information is not compromised or
            outdated.
            It can be expected that the processing of zone revocations and an
-           initial root zone is provided with a GNS client implementation
-           ("drop shipping").
+           initial start zone is provided with a GNS client implementation
+           ("drop shipping").  Shipping an initial start zone with an entry for
+           the root (".") effectively establishes a root zone.
            Extension and customization of the zone is at the full discretion of
            the user.
          </t>

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