1 files changed, 8 insertions, 8 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 5f38d97..49faeeb 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -422,7 +422,7 @@
        <dt>Sign(d,message) -> signature, Sign(d',message) -> signature</dt>
        <dd>
          is a function to sign a message (typically encrypted record data) using the (blinded) private
-         key d (d'), yielding an unforgable cryptographic signature.
+         key d (d'), yielding an unforgeable cryptographic signature.
          In order to leverage performance-enhancing caching features of certain
          underlying storages, in particular DHTs, a deterministic signature
          scheme is recommended.
@@ -432,7 +432,7 @@
          is a function to verify the signature was created by
          the private key d (or derived key d') corresponding to
          the zone key zk (or derived zone key zk')
-         where d,zk := Keygen(). If deriviations were used, they
+         where d,zk := Keygen(). If derivations were used, they
          must have used the same label.
          The function returns a boolean value of "TRUE" if the signature is valid,
          and otherwise "FALSE".
@@ -687,7 +687,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
          <dd>
            denotes the absolute 64-bit date when the revocation was computed.
            In microseconds since midnight (0 hour), January 1, 1970 UTC in network
-           byte order. This is the same value as the timestamp used in the
+           byte order. This is the same value as the time stamp used in the
            individual PoW calculations.
          </dd>
          <dt>TTL</dt>
@@ -719,7 +719,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
          </dd>
          <dt>SIGNATURE</dt>
          <dd>
-           A signature over a timestamp and the zone zk of the zone
+           A signature over a time stamp and the zone zk of the zone
            which is revoked and corresponds to the key used in the PoW.
            The signature is created using the Sign() function of
            the cryptosystem of the zone and the private key
@@ -729,7 +729,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
        <!-- FIXME Do we really need a purpose? -->
       <t>
         The signature over the public key covers a 32-bit header
-        prefixed to the timestamp and public key fields.
+        prefixed to the time stamp and public key fields.
         The header includes the key length and signature purpose.
         The wire format is illustrated
         in <xref target="figure_revsigwithpseudo"/>.
@@ -779,7 +779,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
          <li>The signature MUST be verified against the zone key.</li>
          <li>The set of POW values MUST NOT contain duplicates which MUST 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 MUST be greater than and not equal to D.  Implementors
+         POW values MUST be greater than and not equal to D.  Implementers
          MUST NOT use an integer data type to calculate or represent D'.</li>
          <li>The validation period (TTL) of the revocation is calculated as
            (D'-D) * EPOCH * 1.1. The EPOCH is extended by
@@ -1451,7 +1451,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
        <t>
          NOTE: If an application uses DNS names obtained from GNS2DNS records
          in a DNS request they must first be converted to a punycode representation
-         <xref target="RFC5890" />.
+         <xref target="RFC5890" />. <!-- punycode or IDNA? -->
        </t>
      </section>
    </section>
@@ -2462,7 +2462,7 @@ NICK: john (Supplemental)
            via a revocation message would only be secure as long as both
            cryptosystems are still secure against forgery. Such a planned,
            non-emergency migration to another cryptosystem should be done by
-           running zones for both ciphersystems in parallel for a while. The
+           running zones for both cipher systems in parallel for a while. The
            migration would conclude by revoking the legacy zone key only once
            it is deemed no longer secure, and hopefully after most users have
            migrated to the replacement.