Diffstat (limited to 'draft-schanzen-gns.xml')
1 files changed, 21 insertions, 17 deletions
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index a90c318..01b0a05 100644
@@ -37,13 +37,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-20" 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-21" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 2.26.0 -->
<title abbrev="The GNU Name System">
The GNU Name System
- <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-20"/>
+ <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-21"/>
<author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
@@ -2749,16 +2749,20 @@ NICK: john (Supplemental)
"Single Hierarchy with a Centrally Controlled Root" and
"Distribution and Management of Root Servers" as raised in
- In the Domain Name System root zone governance is centralized at the
- Internet Corporation for Assigned Names and Numbers (ICANN).
- GNS can be used to leverage the transitivity in the SDSI design to
- replace the trusted root with secure delegation of authority thus
- making petnames useful to other users while operating under a very
- strong adversary model.
- By building on the ideas from SDSI, GNS allows to address a central
- issue with the decentralized mapping of secure identifiers to memorable
- names: namely the impossiblity of providing a global, secure and
- memorable mapping without a trusted authority.
+ In DNS, those issues are a direct result from the centralized root
+ zone governance at the Internet Corporation for Assigned Names and
+ Numbers (ICANN) which allows it to provide globally unique names.
+ In GNS, start zones give users local authority over their preferred
+ root zone governance.
+ It enables users to replace or enhance a trusted root zone
+ configuration provided by a third party (e.g. the implementer or a
+ multi-stakeholder governance body like ICANN) with secure delegation of
+ authority using local petnames while operating under a
+ very strong adversary model.
+ In combination with zTLDs, this provides users of GNS with a global,
+ secure and memorable mapping without a trusted authority.
Any GNS implementation <bcp14>MAY</bcp14> provide a default
@@ -2771,15 +2775,15 @@ NICK: john (Supplemental)
Technically, the GNS protocol can be used to resolve names in the
namespace of the global DNS.
However, this would require the respective governance bodies and
- stakeholders to standardize the use of GNS for this particular use
- case and publish their zones accordingly.
+ stakeholders (e.g. IETF and ICANN) to standardize the use of GNS for this particular use
- However, this capability means that by definition GNS names may be
+ However, this capability implies that GNS names may be
indistinguishable from DNS names in their
respective common display format <xref target="RFC8499"/> or
- other special-use domain names <xref target="RFC6761"/> given
- a local GNS start zone configuration that maps suffixes from the
+ other special-use domain names <xref target="RFC6761"/> if
+ a local start zone configuration maps suffixes from the
global DNS to GNS zones.
For applications, it is then ambiguous which name system should be
used in order to resolve a given name.