[lsd0001] branch master updated: obsolete reference

[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 92b4681  obsolete reference
92b4681 is described below

commit 92b46818b0f5a6375781cfb74d551d8c121b0068
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Sat Mar 26 13:34:28 2022 +0100

    obsolete reference
---
 draft-schanzen-gns.xml | 26 +++++++++++++++-----------
 1 file 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;-->

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