some notes on usage

1 files changed, 109 insertions, 0 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 897ca3e..5456628 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -3329,6 +3329,115 @@ Value       Symbol            Symbol
            <li>Return record set to application.</li>
          </ol>
        </section>
+       <section anchor="day_in_zoneowner">
+         <name>A Day in the Life of a Zone Owner</name>
+         <t>
+           In order to become a zone owner, it is sufficient to generate
+           a zone key and a corresponding secret key.
+           At this point, the zone owner can manage GNS resource records in a
+           local zone database.
+           The resource records can then be published by a GNS implementation
+           as defined in <xref target="publish"/>.
+         </t>
+         <t>
+           In order for other users to resolve the resource records, respective
+           zone information must be disseminated first.
+           The zone owner may decide to make the zone key and labels known
+           to a selected set of users only or to make this information available
+           to the general public.
+         </t>
+         <t>
+           Sharing zone information directly with specific users not only allows
+           to potentially preserve zone and record privacy, but also allows
+           the zone owner and the user to establish strong trust relationships.
+           For example, a bank may send a customer letter with a QR code which
+           contains the GNS zone of the bank.
+           This allows the user to scan the QR code and establish a strong
+           link to the zone of the bank and with it, for example, the IP address
+           of the online banking web site.
+         </t>
+         <t>
+           Most Internet services likely want to make their zones available
+           to the general public as efficiently as possible.
+           First, it is reasonable to assume that zones which are commanding
+           high levels of reputation and trust are likely included in the
+           default suffix-to-zone mappings of implementations.
+           Hence dissemination of a zone through delegation under such zones
+           can be a viable path in order to disseminate a zone publicly.
+           For example, it is conceivable that organizations such as ICANN
+           or country-code top-level domain registrars also manage GNS zones
+           and offer registration or delegation services.
+         </t>
+         <t>
+           Following best practices in particularly those relating to
+           security and abuse mitigation are methods which allow zone owners
+           and aspiring registrars to gain a good reputation and eventually
+           trust.
+           This includes, of course, diligent protection of private zone key
+           material.
+           Formalizing such best practices is out of scope of this
+           specification and should be addressed in a separate document addressing
+           <xref target="security"/>.
+         </t>
+       </section>
+       <section>
+         <name>User-centric zone management</name>
+         <t>
+           A user is expected to install a GNS implementation if it is not already
+           provided through other means such as the operating system
+           or the browser.
+         </t>
+         <t>
+           It is expected that in any case, the implementation likely ships
+           with a configurable default suffix-to-name mapping.
+           This means that the user is able to resolve GNS names ending on a
+           zTLD or ending on a configured suffix-to-name mapping.
+         </t>
+         <t>
+           At this point the user may modify the implementation's default
+           suffix-to-name mapping.
+           This includes:
+          </t>
+          <ul>
+            <li>Deletion of mappings.</li>
+            <li>Modification of a mapping</li>
+            <li>Addition of a new mapping</li>
+          </ul>
+          <t>
+            The user may delete mappings. This may become necessary of the
+            zone owner referenced by the mapping has lost the trust of the user.
+            For example, this could be due to lax registration policies resulting
+            in phishing activities.
+          </t>
+          <t>
+            Modification and addition of new mappings are means to heal the
+            namespace perforation which would occur in the case of a deletion
+            or to simply establish a strong direct trust relationship.
+            However, this requires the user's knowledge of respective zone
+            information.
+            This information must be retrieved out of band, as illustrated in
+            <xref target="day_in_zoneowner"/>:
+            A bank may send the user a letter with a QR code which contains the
+            GNS zone of the bank.
+            Other examples include scanning the QR off the device of a friend,
+            from a storefront, or an advertisement.
+            The level of trust in the respective zone is contextual and likely
+            varies from user to user.
+            Trust in a zone provided through a letter from a bank which
+            may also include a credit card is certainly different from a zone
+            found on a random advertisement in the streets.
+            However, this trust is immediately tangible to the user and can
+            be reflected in the local naming as well.
+          </t>
+          <t>
+            User clients should facilitate the suffix-to-name modification
+            process and are ideally implemented
+            according to best practices, particular addressing applicable points
+            from <xref target="security"/>.
+            Formalizing such best practices is out of scope of this
+            specification.
+         </t>
+       </section>
      </section>
      <section>
        <name>Test Vectors</name>