commit edc361ed669205c0e37cff8e7a216a2198c1ef6e
parent 112cb457e64f6b118c9ee01523d5ae8e6919d064
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Sun, 7 Aug 2022 18:06:37 +0200
wording
Diffstat:
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -128,23 +128,21 @@
particular X.509 for the Web.
</t>
<t>
- The design of GNS incorporates the capability to interoperate with the
- DNS protocol.
- It is based on the principle of a petname system where users can assign
- names to zones.
+ 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.
+ </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.
</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 defined here does not mandate that all deployments use
- the same root zone.
- Users can easily delegate control of arbitrary domain names to
- arbitrary zones through their local configurations.
- </t>
- <t>
This document defines the normative wire format of resource records, resolution processes,
cryptographic routines and security considerations for use by implementers.
</t>
