restructure intro

1 files changed, 30 insertions, 32 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 7f99a2b..a90c318 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -111,45 +111,43 @@
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
-       The Domain Name System (DNS) <xref target="RFC1035" /> is a unique
-       distributed database and a vital service for most Internet applications.
-       However, it was not designed with security in mind. This makes it very
-       vulnerable, especially to attackers that have the technical capabilities
-       of an entire nation state at their disposal.
+       This specification describes the GNU Name System (GNS), a
+       censorship-resistant, privacy-preserving and decentralized
+       domain name resolution protocol.  GNS can bind names to any
+       kind of cryptographically secured token, enabling it to double
+       in some respects as an alternative to some of today’s public
+       key infrastructures.
      </t>
      <t>
-       This specification describes a censorship-resistant, privacy-preserving
-       and decentralized domain name resolution protocol:
-       The GNU Name System (GNS), a development continuation of
-       previous academic work on secure name systems <xref target="GNS" />.
-       GNS can bind names to any kind of
-       cryptographically secured token, enabling it to double in some respects as
-       an alternative to some of today’s Public Key Infrastructures, in
-       particular X.509 for the Web.
+       In the terminology of the Domain Name System (DNS) <xref
+       target="RFC1035" />, GNS roughly follows the idea of a local
+       root zone deployment (see <xref target="RFC8806"/>), with the
+       difference that the design encourages alternative roots and
+       does not expect all deployments use the same or any specific
+       root zone.  In the GNS reference implementation, users can
+       autonomously and freely delegate control of names to zones
+       through their local configurations.
      </t>
      <t>
-       In DNS terminology, GNS roughly follows the idea of a local
-       root zone deployment (see <xref target="RFC8806"/>), with the difference
-       that the protocol does not mandate that all deployments use the same
-       or any specific root zone.
-       Users can autonomously and freely delegate control of names to
-       zones through their local configurations.
+       Name resolution and zone dissemination is based on the
+       principle of a petname system where users can assign local
+       names to zones.  The GNS has its roots in ideas from the Simple
+       Distributed Security Infrastructure <xref target="SDSI" />,
+       enabling the decentralized mapping of secure identifiers to
+       memorable names.  A first academic description of the
+       cryptographic ideas behind GNS can be found in <xref
+       target="GNS" />.
      </t>
      <t>
-       Name resolution and zone dissemination is based on the principle of a
-       petname system where users can assign local names to zones.
-       It builds on ideas from the Simple Distributed Security
-       Infrastructure <xref target="SDSI" />, enabling the decentralized
-       mapping of secure identifiers to memorable names.
+       This document defines the normative wire format of resource
+       records, resolution processes, cryptographic routines and
+       security considerations for use by implementers.
      </t>
      <t>
-       This document defines the normative wire format of resource records, resolution processes,
-       cryptographic routines and security considerations for use by implementers.
-     </t>
-     <t>
-       This specification was developed outside the IETF and does not have
-       IETF consensus.  It is published here to guide implementation of GNS
-       and to ensure interoperability among implementations.
+       This specification was developed outside the IETF and does not
+       have IETF consensus.  It is published here to guide
+       implementers of GNS and to ensure interoperability among
+       implementations.
      </t>
      <section numbered="true" toc="default">
        <name>Requirements Notation</name>
@@ -2561,7 +2559,7 @@ NICK: john (Supplemental)
            by a single microsecond even if the user did not request a change.
            In case of deletion of all resource records under a label, the
            implementation <bcp14>MUST</bcp14> keep track of the last absolute expiration time
-           of the last published resource block.  Implementations <bcp14>MAY</bcp14> define 
+           of the last published resource block.  Implementations <bcp14>MAY</bcp14> define
            and use a special record type as a tombstone that preserves the last
            absolute expiration time, but then <bcp14>MUST</bcp14> take care to not publish a
            block with this record.