[lsd0001] branch master updated: update

[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 5954b08  update
5954b08 is described below

commit 5954b083d9d5e2e902a509e72347a8c86e0f89d7
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Mon Dec 16 11:04:17 2019 +0100

    update
---
 draft-schanzen-gns.html | 10 +++++-----
 draft-schanzen-gns.txt  | 14 +++++++-------
 draft-schanzen-gns.xml  | 10 +++++-----
 3 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 425cf38..ae07a8b 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -2244,16 +2244,16 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
          In the following, we give some examples how a local client resolver 
may
          discover the root zone.
          Any of the examples below may be exchanged with other mechanisms
-         an are not normative.
+         and are not normative.
          Possible high-level mechanisms to discover the root zone for a given
          name are:<a href="#section-8-2" class="pilcrow">¶</a></p>
 <ol start="1" type="1" class="normal" id="section-8-3">
-        <li id="section-8-3.1">Top-level domain is an encoded local zone 
key.<a href="#section-8-3.1" class="pilcrow">¶</a>
+        <li id="section-8-3.1">The top-level domain is an encoded local zone 
key.<a href="#section-8-3.1" class="pilcrow">¶</a>
 </li>
-        <li id="section-8-3.2">Local configuration exists that allow to map a 
name suffix
+        <li id="section-8-3.2">A local configuration exists that allow to map 
a name suffix
            to a zone key.<a href="#section-8-3.2" class="pilcrow">¶</a>
 </li>
-        <li id="section-8-3.3">Out-of-band mechnism exists that allow to 
determine the
+        <li id="section-8-3.3">An out-of-band mechnism exists that allow to 
determine the
            authoritative root zone for a given name.<a href="#section-8-3.3" 
class="pilcrow">¶</a>
 </li>
       </ol>
@@ -2274,7 +2274,7 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
          In GNS, users may own and manage their own zones.
          Each local zone may be associated with a single GNS label.
          If this label is the top-level domain of the name
-         to resolve, resolution can from the local zone:<a href="#section-8-6" 
class="pilcrow">¶</a></p>
+         to resolve, resolution starts from the respective local zone:<a 
href="#section-8-6" class="pilcrow">¶</a></p>
 <div class="artwork art-text alignLeft" id="section-8-7">
 <pre>
          Example name: www.example.gnu
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index 7e04c44..d0d7d26 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -1028,15 +1028,15 @@ Internet-Draft             The GNU Name System          
   November 2019
 
    In the following, we give some examples how a local client resolver
    may discover the root zone.  Any of the examples below may be
-   exchanged with other mechanisms an are not normative.  Possible high-
-   level mechanisms to discover the root zone for a given name are:
+   exchanged with other mechanisms and are not normative.  Possible
+   high-level mechanisms to discover the root zone for a given name are:
 
-   1.  Top-level domain is an encoded local zone key.
+   1.  The top-level domain is an encoded local zone key.
 
-   2.  Local configuration exists that allow to map a name suffix to a
+   2.  A local configuration exists that allow to map a name suffix to a
        zone key.
 
-   3.  Out-of-band mechnism exists that allow to determine the
+   3.  An out-of-band mechnism exists that allow to determine the
        authoritative root zone for a given name.
 
    The resolver client may try to interpret the top-level domain of a
@@ -1050,8 +1050,8 @@ Internet-Draft             The GNU Name System            
 November 2019
 
    In GNS, users may own and manage their own zones.  Each local zone
    may be associated with a single GNS label.  If this label is the top-
-   level domain of the name to resolve, resolution can from the local
-   zone:
+   level domain of the name to resolve, resolution starts from the
+   respective local zone:
 
 
 
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 02ae129..cae3809 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1062,15 +1062,15 @@
          In the following, we give some examples how a local client resolver 
may
          discover the root zone.
          Any of the examples below may be exchanged with other mechanisms
-         an are not normative.
+         and are not normative.
          Possible high-level mechanisms to discover the root zone for a given
          name are:
        </t>
        <ol>
-         <li>Top-level domain is an encoded local zone key.</li>
-         <li>Local configuration exists that allow to map a name suffix
+         <li>The top-level domain is an encoded local zone key.</li>
+         <li>A local configuration exists that allow to map a name suffix
            to a zone key.</li>
-         <li>Out-of-band mechnism exists that allow to determine the
+         <li>An out-of-band mechnism exists that allow to determine the
            authoritative root zone for a given name.</li>
        </ol>
        <t>
@@ -1089,7 +1089,7 @@
          In GNS, users may own and manage their own zones.
          Each local zone may be associated with a single GNS label.
          If this label is the top-level domain of the name
-         to resolve, resolution can from the local zone:
+         to resolve, resolution starts from the respective local zone:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
          Example name: www.example.gnu

-- 
To stop receiving notification emails like this one, please contact
address@hidden.