1 files changed, 15 insertions, 11 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index c4474e1..096c0d2 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -19,7 +19,7 @@
 <!ENTITY RFC6895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml">
 <!ENTITY RFC6979 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml">
 <!ENTITY RFC7363 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7363.xml">
-<!ENTITY RFC7706 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7706.xml">
+<!ENTITY RFC8806 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8806.xml">
 <!ENTITY RFC7748 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml">
 <!ENTITY RFC8032 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml">
 <!ENTITY RFC8126 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
@@ -35,13 +35,13 @@
 <?rfc sortrefs="yes" ?>
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>
-<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-11" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
+<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-12" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 2.26.0 -->
  <front>
   <title abbrev="The GNU Name System">
    The GNU Name System
   </title>
-  <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-11"/>
+  <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-12"/>
   <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
    <organization>Fraunhofer AISEC</organization>
    <address>
@@ -158,7 +158,7 @@
        where root zone governance is centralized at the Internet Corporation
        for Assigned Names and Numbers (ICANN).
        In DNS terminology, GNS roughly follows the idea of a local
-       root zone deployment (see <xref target="RFC7706"/>), with the difference that it is not
+       root zone deployment (see <xref target="RFC8806"/>), with the difference that it is not
        expected that all deployments use the same root zone,
        and that users can easily delegate control of arbitrary domain names to
        arbitrary zones.
@@ -227,7 +227,8 @@
          special purposes in the resolution protocol which are defined
          in the rest of the document.
          Zone administrators <bcp14>MAY</bcp14> disallow certain labels that
-         might be easily confused with other labels through registration policies.
+         might be easily confused with other labels through registration policies
+         (see also <xref target="security_abuse"/>).
        </dd>
        <dt>Apex Label</dt>
        <dd>
@@ -443,7 +444,8 @@
    <section anchor="zones" numbered="true" toc="default">
      <name>Zones</name>
      <t>
-       An implementation <bcp14>SHOULD</bcp14> enable the user to create and manage zones.
+       A zone master implementation <bcp14>SHOULD</bcp14> enable the user to
+       create and manage zones.
        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"/>).
@@ -2195,7 +2197,7 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
            <t>
              Otherwise, it is expected that the resolver first resolves the
              IP addresses of the specified DNS name servers.
-             The DNS name may have to be converted to an IDNA compliant
+             The DNS name <bcp14>MUST</bcp14> be converted to an IDNA compliant
              representation <xref target="RFC5890" /> for resolution in DNS.
              GNS2DNS records <bcp14>MAY</bcp14>
              contain numeric IPv4 or IPv6 addresses, allowing the resolver to
@@ -2213,7 +2215,9 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
              in which case the resolver <bcp14>MUST</bcp14> try all of them.
              The resolver <bcp14>MAY</bcp14> try them in any order or even in parallel.
              If multiple GNS2DNS records are present, the DNS name <bcp14>MUST</bcp14> be
-             identical for all of them, if not the resolution fails and an
+             identical for all of them. Otherwise, it is not clear which name
+             the resolver is supposed to follow. If multiple DNS names are
+             present the resolution fails and an
              appropriate error is <bcp14>SHOULD</bcp14> be returned to the application.
            </t>
            <t>
@@ -2252,7 +2256,7 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
              The (possibly recursive) resolution of the DNS name <bcp14>MUST NOT</bcp14>
              delegate back into GNS and should only follow the DNS specifications.
              For example, names contained in DNS CNAME records <bcp14>MUST NOT</bcp14> be
-             interpreted as GNS names.
+             interpreted by resolvers that support both DNS and GNS as GNS names.
            </t>
            <t>
              GNS resolvers <bcp14>SHOULD</bcp14> offer a configuration
@@ -2343,7 +2347,7 @@ NICK: eve (non-Supplemental)
           In this example, the returned NICK record is non-supplemental.
           For the application, this means that the NICK belongs to the zone
           "alice.example" and is published under the apex label along with an A
-          record. The NICK record should be interpreted as: The zone defined by
+          record. The NICK record is interpreted as: The zone defined by
           "alice.example" wants to be referred to as "eve".
           In contrast, consider the following:
         </t>
@@ -2925,7 +2929,7 @@ Purpose | Name            | References | Comment
        <!--  &RFC6781; -->
          &RFC7363;
          &RFC8324;
-         &RFC7706;
+         &RFC8806;
          &RFC6761;
 
        <!--         &RFC3912;-->