fixes

1 files changed, 32 insertions, 34 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 8ab4adc..147a94c 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -227,9 +227,7 @@
        </dd>
        <dt>Extension Label</dt>
        <dd>
-         If a name ends with the extension label the rest of the name
-         <bcp14>MUST</bcp14> be interpreted relative to the current zone in the resolution process.
-         The primary use for this is in redirections where the redirection
+         The primary use for the extension label is in redirections where the redirection
          target is defined relative to the authoritative zone of the redirection
          record (<xref target="gnsrecords_redirect"/>).
          The extension label is represented using the character U+002B ("+"
@@ -373,17 +371,15 @@
    <section anchor="zones" numbered="true" toc="default">
      <name>Zones</name>
      <t>
-       A zone in GNS is uniquely identified by its zone type and zone key.
-       Each zone can be represented by a Zone Top-Level Domain (zTLD) string.
-     </t>
-     <t>
        An 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"/>).
      </t>
      <t>
-       Each zone type (ztype) is a unique 32-bit number.
+       A zone in GNS is uniquely identified by its zone type and zone key.
+       Each zone can be represented by a Zone Top-Level Domain (zTLD) string.
+       A zone type (ztype) is a unique 32-bit number.
        This number corresponds to a resource record type number
        identifying a delegation record type
        in the GNUnet Assigned Numbers Authority <xref target="GANA" />.
@@ -676,9 +672,8 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
            denotes the relative 64-bit time to live of the record in
            microseconds also in network byte order.
            The field <bcp14>SHOULD</bcp14> be set to EPOCH * 1.1.
-           If the average number of leading zeros D' is larger than
-           D, then the field value <bcp14>MAY</bcp14> be increased up to
-           (D'-D) * EPOCH * 1.1.
+           Given an average number of leading zeros D', then the field value
+           <bcp14>MAY</bcp14> be increased up to (D'-D) * EPOCH * 1.1.
            The EPOCH is extended by
            10% in order to deal with unsynchronized clocks.
            This field is informational for a verifier.
@@ -774,7 +769,7 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
          <li>The set of POW values <bcp14>MUST</bcp14> NOT contain duplicates which <bcp14>MUST</bcp14> be checked by verifying that the values are strictly monotonically increasing.</li>
          <li>The average number of leading zeroes D' resulting from the provided
          POW values <bcp14>MUST</bcp14> be greater than and not equal to D.  Implementers
-         <bcp14>MUST</bcp14> NOT use an integer data type to calculate or represent D'.</li>
+         <bcp14>MUST NOT</bcp14> use an integer data type to calculate or represent D'.</li>
        <li>
            The validity period of the revocation is calculated as
            (D'-D) * EPOCH * 1.1. The EPOCH is extended by
@@ -785,8 +780,11 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
            the TTL field value, the verifier <bcp14>MUST</bcp14> continue and
            use the calculated value when forwarding the revocation.
          </li>
-         <li>The current time <bcp14>SHOULD</bcp14> be between TIMESTAMP and
-           TIMESTAMP + validity period. Implementations <bcp14>MAY</bcp14> process the revocation without validating this.</li>
+         <li>
+           The current time <bcp14>SHOULD</bcp14> be between TIMESTAMP and
+           TIMESTAMP + validity period.
+           Implementations <bcp14>MAY</bcp14> process the revocation without validating this.
+         </li>
        </ol>
      </section>
 
@@ -859,9 +857,9 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
      </dl>
      <t>
        Flags indicate metadata surrounding the resource record.
-       Applications creating resource records <bcp14>MUST</bcp14> set all bits which are
-       not defined as a flag to 0. Additional flags may be defined in
-       future protocol versions.
+       An application creating resource records <bcp14>MUST</bcp14> set all bits
+       to 0 unless it wants to set the respective flag.
+       Additional flags may be defined in future protocol versions,
        If an application or implementation encounters a flag which it does not
        recognize, it <bcp14>MUST</bcp14> be ignored.
        Any combination of the flags specified below are valid.
@@ -913,7 +911,7 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
        the respective zone type is encountered.
        This may be a valid choice if some zone delegation record types have been
        determined to be cryptographically insecure.
-       Zone delegation records <bcp14>MUST</bcp14> NOT be stored and published
+       Zone delegation records <bcp14>MUST NOT</bcp14> be stored and published
        under the apex label.
        A zone delegation record type value is the same as the respective ztype
        value.
@@ -921,8 +919,8 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
        being delegated to.
        A zone delegation record payload contains the public key of
        the zone to delegate to.
-       A zone delegation record <bcp14>MUST</bcp14> have the CRTITICAL flag set.
-       A zone delegation record <bcp14>MUST</bcp14> be the only record under a label.
+       A zone delegation record <bcp14>MUST</bcp14> have the CRTITICAL flag set
+       and <bcp14>MUST</bcp14> be the only record under a label.
        No other records are allowed.
      </t>
      <section anchor="gnsrecords_pkey" numbered="true" toc="default">
@@ -1378,11 +1376,11 @@ S-Decrypt(zk,label,expiration,ciphertext):
        and <bcp14>MAY</bcp14> support any number of additional redirection records defined in
        the GNU Name System Record Types registry (see Section <xref target="gana"/>).
        Redirection records <bcp14>MUST</bcp14> have the CRTITICAL flag set.
-       Not supporting some record types <bcp14>MAY</bcp14> result in resolution failures.
-       This <bcp14>MAY</bcp14> BE a valid choice if some redirection record types have been
+       Not supporting some record types may consequently result in resolution failures.
+       This may be a valid choice if some redirection record types have been
        determined to be insecure, or if an application has reasons to not
        support redirection to DNS for reasons such as complexity or security.
-       Redirection records <bcp14>MUST</bcp14> NOT be stored and published under the apex label.
+       Redirection records <bcp14>MUST NOT</bcp14> be stored and published under the apex label.
      </t>
      <section anchor="gnsrecords_rdr" numbered="true" toc="default">
        <name>REDIRECT</name>
@@ -1639,7 +1637,7 @@ GET(key) -> value
        record would require a revocation of the record.
        In GNS, zones can only be revoked as a whole. Records automatically
        expire and it is under the discretion of the storage as to when to delete
-       the record. The GNS implementation <bcp14>MUST</bcp14> NOT publish expired resource
+       the record. The GNS implementation <bcp14>MUST NOT</bcp14> publish expired resource
        records. Any GNS resolver <bcp14>MUST</bcp14> discard expired records returned from
        the storage.
      </t>
@@ -1856,7 +1854,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
            ignored on receipt.
            As a special exception, record sets with (only) a zone delegation
            record type are never padded.
-           Note that a record set with a delegation record <bcp14>MUST</bcp14> NOT
+           Note that a record set with a delegation record <bcp14>MUST NOT</bcp14>
            contain other records. If other records are encountered, the whole
            record block <bcp14>MUST</bcp14> be discarded.
          </dd>
@@ -1881,7 +1879,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
        For example, if a zone delegation record type is requested, the
        resolution of the apex label in that zone must be skipped, as
        the desired record is already found.
-       The resolver implementation <bcp14>MUST</bcp14> NOT filter results according to the desired
+       The resolver implementation <bcp14>MUST NOT</bcp14> filter results according to the desired
        record type.
        Filtering of record sets is typically done by the application.
      </t>
@@ -1931,7 +1929,7 @@ Example name: www.example.<zTLD>
          label separator.
          If multiple suffixes match the name to resolve, the longest
          matching suffix <bcp14>MUST</bcp14> be used. The suffix length of two results
-         <bcp14>MUST</bcp14> NOT be equal. This indicates a misconfiguration and the
+         <bcp14>MUST NOT</bcp14> be equal. This indicates a misconfiguration and the
          implementation <bcp14>MUST</bcp14> return an error.
          The following is a non-normative example mapping of start zones:
        </t>
@@ -2118,7 +2116,7 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
            <t>
              As the DNS servers
              specified are possibly authoritative DNS servers, the GNS resolver <bcp14>MUST</bcp14>
-             support recursive DNS resolution and <bcp14>MUST</bcp14> NOT delegate this to the
+             support recursive DNS resolution and <bcp14>MUST NOT</bcp14> delegate this to the
              authoritative DNS servers.
              The first successful recursive name resolution result
              is returned to the application.
@@ -2129,9 +2127,9 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
            <t>
              Once the transition from GNS into DNS is made through a
              GNS2DNS record, there is no "going back".
-             The (possibly recursive) resolution of the DNS name <bcp14>MUST</bcp14> NOT
+             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</bcp14> NOT be
+             For example, names contained in DNS CNAME records <bcp14>MUST NOT</bcp14> be
              interpreted as GNS names.
            </t>
            <t>
@@ -2174,11 +2172,11 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
              resolution <bcp14>MUST</bcp14> fail with an empty result set.
            </t>
            <t>
-             Implementations <bcp14>MUST</bcp14> NOT allow multiple different zone
+             Implementations <bcp14>MUST NOT</bcp14> allow multiple different zone
              delegations under a single label.
              Implementations <bcp14>MAY</bcp14> support any subset of ztypes.
              Handling of
-             Implementations <bcp14>MUST</bcp14> NOT process zone delegation for the apex
+             Implementations <bcp14>MUST NOT</bcp14> process zone delegation for the apex
              label "@". Upon encountering a zone delegation record under
              this label, resolution fails and an error <bcp14>MUST</bcp14> be returned. The
              implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure,
@@ -2288,7 +2286,7 @@ NICK: john (Supplemental)
            select a default ztype considered secure at the time of
            releasing the software.
            For applications targeting end users that are not expected to
-           understand cryptography, the application developer <bcp14>MUST</bcp14> NOT leave
+           understand cryptography, the application developer <bcp14>MUST NOT</bcp14> leave
            the ztype selection of new zones to end users.
          </t>
          <t>
@@ -2460,7 +2458,7 @@ NICK: john (Supplemental)
            to manage revocations accordingly.
          </t>
          <t>
-           Revocation payloads do NOT include a 'new' key for key replacement.
+           Revocation payloads do not include a 'new' key for key replacement.
            Inclusion of such a key would have two major disadvantages:
          </t>
          <ol>