1 files changed, 17 insertions, 12 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 5310211..3e70da3 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -829,13 +829,14 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
        future protocol versions.
        If an application or implementation encounters a flag which it does not
        recognize, it MUST be ignored.
+       Any combination of the flags specified below are valid.
        <xref target="figure_flag"/>
        illustrates the flag distribution in the 16-bit flag field of a
        resource record:
      </t>
      <figure anchor="figure_flag" title="The Resource Record Flag Wire Format.">
        <artwork name="" type="" align="left" alt=""><![CDATA[
-0           13            14      15        16
+0           13            14      15
 +--------...+-------------+-------+---------+
 | Reserved  |SUPPLEMENTAL |SHADOW |CRITICAL |
 +--------...+-------------+-------+---------+
@@ -846,12 +847,12 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
        <dd>
          If this flag is set, it indicates that processing is critical.
          Implementations that do not support the record type or are otherwise
-         unable to process the record must abort resolution upon encountering
+         unable to process the record MUST abort resolution upon encountering
          the record in the resolution process.
        </dd>
        <dt>SHADOW</dt>
        <dd>
-         If this flag is set, this record should be ignored by resolvers unless all (other)
+         If this flag is set, this record MUST be ignored by resolvers unless all (other)
          records of the same record type have expired.  Used to allow zone publishers to
          facilitate good performance when records change by allowing them to put future
          values of records into the storage.
@@ -863,8 +864,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
          This is a supplemental record. It is provided in addition to the
          other records. This flag indicates that this record is not explicitly
          managed alongside the other records under the respective name but
-         may be useful for the application. This flag should only be encountered
-         by a resolver for records obtained from the storage.
+         may be useful for the application.
        </dd>
      </dl>
    <section anchor="gnsrecords_delegation" numbered="true" toc="default">
@@ -876,7 +876,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
        the GNU Name System Record Types registry (see <xref target="gana"/>).
        Zone delegation records MUST have the CRTITICAL flag set.
        Not supporting some zone types MAY result in resolution failures. This
-       MAY BE a valid choice if some zone delegation record types have been
+       MAY be a valid choice if some zone delegation record types have been
        determined to be cryptographically insecure.
        Zone delegation records MUST NOT be stored and published
        under the apex label.
@@ -1439,7 +1439,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
        </dl>
        <t>
          NOTE: If an application uses DNS names obtained from GNS2DNS records
-         in a DNS request they must first be converted to an IDNA punycode
+         in a DNS request they MUST first be converted to an IDNA punycode
          representation <xref target="RFC5891" />.
        </t>
      </section>
@@ -1454,6 +1454,9 @@ S-Decrypt(zk,label,expiration,ciphertext):
      <section anchor="gnsrecords_leho" numbered="true" toc="default">
        <name>LEHO</name>
        <t>
+         This record is used to provide LEgacy HOstnames.
+       </t>
+       <t>
          Applications can use the GNS to lookup IPv4 or IPv6 addresses of
          internet services.
          However, sometimes connecting to such services does not only require
@@ -1466,10 +1469,12 @@ S-Decrypt(zk,label,expiration,ciphertext):
          Using a GNS name for the "Host"-header may not work as
          it may not be globally unique. Furthermore, even if uniqueness is
          not an issue, the legacy service might not even be aware of GNS.
-
+       </t>
+       <t>
          A LEHO resource record is expected to be found together in a single
          resource record with an IPv4 or IPv6 address.
-         A LEHO DATA entry is illustrated in <xref target="figure_lehorecord"/>.</t>
+           A LEHO DATA entry is illustrated in <xref target="figure_lehorecord"/>.
+       </t>
        <figure anchor="figure_lehorecord" title="The LEHO DATA Wire Format.">
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0     8     16    24    32    40    48    56
@@ -1496,8 +1501,8 @@ S-Decrypt(zk,label,expiration,ciphertext):
      <section anchor="gnsrecords_nick" numbered="true" toc="default">
        <name>NICK</name>
        <t>
-         Nickname records can be used by zone administrators to publish an
-         the label that a zone prefers to have used when it is referred to.
+         Nickname records can be used by zone administrators to publish a
+         label that a zone prefers to have used when it is referred to.
          This is a suggestion to other zones what label to use when creating a
          delegation record (<xref target="gnsrecords_delegation" />) containing
          this zone key.
@@ -1522,7 +1527,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
          <dt>NICKNAME</dt>
          <dd>
            A UTF-8 string (which is not 0-terminated) representing the preferred
-           label of the zone. This string MUST NOT include a "." character.
+           label of the zone. This string MUST be a valid GNS label.
          </dd>
        </dl>
      </section>