1 files changed, 55 insertions, 41 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 25cd8fb..673db6d 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -135,6 +135,14 @@
        useful to other users while operating under a very strong adversary model.
      </t>
      <t>
+       This is an important distinguishing factor from the Domain Name System
+       where root zone governance is centralized at the Internet Corporation
+       for Assigned Names and Numbers (ICANN).
+       In DNS terminology, GNS roughly follows the idea of a hyper-hyper
+       local root zone deployment, with the difference that it is not
+       expected that all deployments use the same local root zone.
+     </t>
+     <t>
        This document defines the normative wire format of resource records, resolution processes,
        cryptographic routines and security considerations for use by implementors.
      </t>
@@ -228,29 +236,29 @@
          blinding zk with different values for the label must result
          in unlinkable different resulting values for zk'.
        </dd>
-       <dt>S-Encrypt(zk,label,nonce,expiration,rdata) -> bdata</dt>
+       <dt>S-Encrypt(zk,label,nonce,expiration,message) -> ciphertext</dt>
        <dd>
          is a deterministic symmetric encryption function which encrypts the record
-         data rdata based on key material derived from the public zone key,
+         data based on key material derived from the public zone key,
          a label, a nonce and an expiration.
          In order to leverage performance-enhancing caching features of certain
          underlying storages, in particular DHTs, a deterministic encryption
          scheme is recommended.
        </dd>
-       <dt>S-Decrypt(zk,label,nonce,expiration,bdata) -> rdata</dt>
+       <dt>S-Decrypt(zk,label,nonce,expiration,ciphertext) -> message</dt>
        <dd>
          is a symmetric encryption function which decrypts the encrypted record
-         data bdata based on key material derived from the public zone key,
+         data based on key material derived from the public zone key,
          a label, a nonce an expiration.
        </dd>
-       <dt>Sign(d',bdata) -> sig</dt>
+       <dt>Sign(d',message) -> signature</dt>
        <dd>
-         is a function to sign bdata using the (blinded) private key
-         d', yielding an unforgable cryptographic signature.
+         is a function to sign encrypted record data using the (blinded) private
+         key d', yielding an unforgable cryptographic signature.
        </dd>
-       <dt>Verify(zk',bdata,sig) -> valid</dt>
+       <dt>Verify(zk',message,signature) -> valid</dt>
        <dd>
-         is a function to verify the signature sig was created by
+         is a function to verify the signature was created by
          the a private key d' derived from d and a label if
          zk' was derived from the corresponding zone key
          zk := Public-Keygen(d) and same label.
@@ -375,7 +383,8 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
      </t>
      <t>
        A GNS resource record holds the data of a specific record in a zone.
-       The resource record format is defined in <xref target="figure_gnsrecord"/>.
+       The resource record format is defined in
+       <xref target="figure_gnsrecord"/>.
      </t>
      <figure anchor="figure_gnsrecord">
        <artwork name="" type="" align="left" alt=""><![CDATA[
@@ -428,9 +437,14 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
      </dl>
      <t>
        Flags indicate metadata surrounding the resource record. A flag
-       value of 0 indicates that all flags are unset. <xref target="figure_flag"/>
+       value of 0 indicates that all flags are unset.
+       Any GNS implementation MUST process all flags which are set in the
+       FLAGS field. If an implementation encounters a flag which it does not
+       recognize, the resource record is not valid and MUST be discarded.
+       <xref target="figure_flag"/>
        illustrates the flag distribution in the 32-bit flag value of a
-       resource record:</t>
+       resource record:
+     </t>
      <figure anchor="figure_flag">
        <artwork name="" type="" align="left" alt=""><![CDATA[
  0        1        2        3        4        5...
@@ -482,7 +496,9 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
        This section defines the initial set of zone delegation record types.
        Any implementation MUST support at least one of the zone types and
        MAY support any number of additional delegation records defined in
-         the GNU Name System Record Types registry <xref target="gana"/>.
+       the GNU Name System Record Types registry <xref target="gana"/>.
+       Zone delegation records MUST NOT be stored and published under the
+       empty label.
      </t>
      <section anchor="gnsrecords_pkey" numbered="true" toc="default">
        <name>PKEY</name>
@@ -600,8 +616,8 @@ zk' := h mod L * zk
          as defined in <xref target="MODES" /> (CTR-AES-256):
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
-RDATA := CTR-AES256(K, IV, BDATA)
-BDATA := CTR-AES256(K, IV, RDATA)
+DATA := CTR-AES256(K, IV, CIPHERTEXT)
+CIPHERTEXT := CTR-AES256(K, IV, DATA)
          ]]></artwork>
        <t>
          The key K and counter IV are derived from
@@ -812,15 +828,15 @@ S * G == R + SHA512(R, zk', M) * zk'
            (XSalsa20-Poly1305):
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
-RDATA := XSalsa20(K, IV, BDATA)
-BDATA := XSalsa20(K, IV, RDATA) = CIPHERTEXT | TAG
+DATA := XSalsa20(K, IV, CIPHERTEXT)
+CIPHERTEXT := XSalsa20(K, IV, DATA) = CIPHERTEXT | TAG
            ]]></artwork>
          <t>
            The result of the XSalsa20 encryption function is the encrypted
            ciphertext concatenated with the 128-bit authentication
            tag TAG.
-           Accordingly, the length of BDATA equals the length of the
-           RDATA plus the 16 bytes of the authentication tag.
+           Accordingly, the length of encrypted data equals the length of the
+           data plus the 16 bytes of the authentication tag.
          </t>
          <t>
            The key K and counter IV are derived from
@@ -1128,7 +1144,7 @@ value := GET(key)
        PUT storage procedure in order to update the zone contents.
      </t>
      <section anchor="blinding" numbered="true" toc="default">
-       <name>Storage Key</name>
+       <name>The Storage Key</name>
        <t>
          Given a label, the storage key q is derived as follows:
        </t>
@@ -1152,7 +1168,7 @@ q := SHA512 (HDKD-Public(zk, label))
        </dl>
      </section>
      <section anchor="records_block" numbered="true" toc="default">
-       <name>Records Block</name>
+       <name>The Records Block (RRBLOCK)</name>
        <t>
          GNS records are grouped by their labels and published as a single
          block in the storage. The grouped record sets MAY be paired with any
@@ -1244,7 +1260,7 @@ q := SHA512 (HDKD-Public(zk, label))
          </dd>
          <dt>BDATA</dt>
          <dd>
-           The encrypted resource records with a total size of SIZE - 16.
+           The encrypted RDATA with a total size of SIZE - 16.
          </dd>
        </dl>
        <t>
@@ -1597,15 +1613,7 @@ q := SHA512 (HDKD-Public(zk, label))
          of the zone owner. However, the choice of start zone(s) is at the sole
          discretion of the local system administrator or user.
        </t>
-       <t>
-         This is an important distinguishing factor from the Domain Name System
-         where root zone governance is centralized at the Internet Corporation
-         for Assigned Names and Numbers (ICANN).
-         In DNS terminology, GNS roughly follows the idea of a hyper-hyper
-   local root zone deployment, with the difference that it is not
-   expected that all deployments use the same local root zone.
-       </t>
-       <t>
+        <t>
          In the following, we give examples how a local client resolver SHOULD
          discover the start zone.  The process given is not exhaustive and
          clients MAY supplement it with other mechanisms or ignore it if the
@@ -1635,11 +1643,11 @@ Example name: www.example.<zTLD>
 Example name: www.example.org
 Local zones:
 fr = (d0,zk0)
-gnu = (d1,zk1)
+org = (d1,zk1)
 com = (d2,zk2)
 ...
-=> Entry zone: zk1
-=> Name to resolve from entry zone: www.example
+=> Root zone: zk1
+=> Name to resolve from root zone: www.example
          ]]></artwork>
        <t>
          Finally, additional "suffix-to-zone" mappings MAY be configured.
@@ -1648,9 +1656,10 @@ com = (d2,zk2)
          The suffix MAY consist of multiple GNS labels concatenated with a
          ".". If multiple suffixes match the name to resolve, the longest
          matching suffix MUST be used. The suffix length of two results
-         cannot be equal, as this would indicate a misconfiguration.
-   If both a locally managed zone and a configuration entry exist
-   for the same suffix, the locally managed zone MUST have priority.
+         MUST NOT be equal. This indicates a misconfiguration and the
+         implementation MUST return an error.
+         If both a locally managed zone and a configuration entry exist
+         for the same suffix, the locally managed zone MUST have priority.
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 Example name: www.example.org
@@ -1659,8 +1668,8 @@ gnu = zk0
 example.org = zk1
 example.com = zk2
 ...
-=> Entry zone: zk1
-=> Name to resolve from entry zone: www
+=> Root zone: zk1
+=> Name to resolve from root zone: www
          ]]></artwork>
      </section>
 
@@ -1700,7 +1709,7 @@ example.com = zk2
            At this point, we must first determine if we have received a valid
            record set in the context of the name we are trying to resolve:
          </t>
-   <ol>
+   <ul>
          <li>
            Case 1:
            If the remainder of the name to resolve is empty and the record set
@@ -1730,7 +1739,7 @@ example.com = zk2
      for the record type MUST be considered and possible conversions such as
            defined in <xref target="vpn_processing" /> MUST be performed.
      </li>
-   </ol>
+   </ul>
          <section anchor="delegation_processing" numbered="true" toc="default">
            <name>Zone Delegation Records</name>
            <t>
@@ -1748,6 +1757,11 @@ example.com = zk2
              unknown SHOULD be returned in the error description. The
              implementation MAY choose not to return the reason for the failure,
              merely impacting troubleshooting information for the user.
+             Implementations MUST NOT process zone delegation for the empty
+             apex label "@". Upon encountering a zone delegation record under
+             this label, resolution fails and an error MUST be returned. The
+             implementation MAY choose not to return the reason for the failure,
+             merely impacting troubleshooting information for the user.
            </t>
            <t>
              If the remainder of the name to resolve is empty and we have