[lsd0001] branch master updated: pass

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new 66b1d77  pass
66b1d77 is described below

commit 66b1d7711b8a5d104559e3a46f09c730d451defa
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Dec 20 21:02:39 2021 +0100

    pass
---
 draft-schanzen-gns.xml | 35 ++++++++++++++++++-----------------
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 0b1e901..79092c2 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1012,7 +1012,8 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
      <section anchor="gnsrecords_box" numbered="true" toc="default">
        <name>BOX</name>
        <t>
-         In GNS, every "." in a name delegates to another zone, and
+         In GNS, with the notable exception of zTLDs, every "." in a name
+         delegates to another zone, and
          GNS lookups are expected to return all of the required useful
          information in one record set.  This is incompatible with the
          special labels used by DNS for SRV and TLSA records.  Thus, GNS
@@ -1121,9 +1122,9 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
    <section anchor="publish" numbered="true" toc="default">
      <name>Record Storage</name>
      <t>
-       In general any API which allows storing a value under a key and 
retrieving
+       Any API which allows storing a value under a key and retrieving
        a value from the key can be used by an implementation for record 
storage.
-       It is expected that a GNS implementations use distributed or 
decentralized
+       It is expected that GNS implementations use distributed or decentralized
        storages such as distributed hash tables (DHT) in order to facilitate
        availability within a network without the need of servers.
        Specification of such a distributed or decentralized storage is out of
@@ -1141,8 +1142,8 @@ value := GET(key)
      <t>
        In GNS, resource records are grouped by their respective labels,
        encrypted and published together in a single resource records block
-       (RRBLOCK) in the storage under a key "q": PUT(q, RRBLOCK).
-       The key "q" is derived from the Zone Key and the respective
+       (RRBLOCK) in the storage under a key q: PUT(q, RRBLOCK).
+       The key q is derived from the zone key and the respective
        label of the contained records. The storage key derivation and records
        block creation is specified in the following sections.
        A client implementation must enable the user the manage zones and use 
the
@@ -1151,7 +1152,7 @@ value := GET(key)
      <section anchor="blinding" numbered="true" toc="default">
        <name>Storage Key</name>
        <t>
-         Given a label, the storage key "q" is derived as follows:
+         Given a label, the storage key q is derived as follows:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 q := SHA512 (HDKD-Public(zk, label))
@@ -1385,9 +1386,9 @@ q := SHA512 (HDKD-Public(zk, label))
        </t>
        <t>
          GNS clients MUST first try to interpret the top-level domain of
-         a GNS name as a zone key representation ("zTLD").
+         a GNS name as a zone key representation (i.e. a zTLD).
          If the top-level domain is indicated to be a label representation of
-         a public zone key with a well-defined "ztype" value, the root zone of
+         a public zone key with a supported zone type value, the root zone of
          the resolution process is implicitly given by the suffix of the name:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
@@ -1414,7 +1415,7 @@ com = (d2,zk2)
 => Name to resolve from entry zone: www.example
          ]]></artwork>
        <t>
-         Finally, additional "suffix to zone" mappings MAY be configured.
+         Finally, additional "suffix-to-zone" mappings MAY be configured.
          Suffix to zone key mappings MUST be configurable through a local
          configuration file or database by the user or system administrator.
          The suffix MAY consist of multiple GNS labels concatenated with a
@@ -1459,7 +1460,7 @@ example.com = zk2
            Upon receiving the RRBLOCK from the storage, apart from verifying 
the
            provided signature, the resolver MUST check that the authoritative
            zone key was used to sign the record:
-           The derived zone key "h*zk" MUST match the public key provided in
+           The derived zone key zk' MUST match the public key provided in
            the RRBLOCK, otherwise the RRBLOCK MUST be ignored and the storage
            lookup GET(q) MUST continue.
          </t>
@@ -1764,24 +1765,24 @@ NICK: john (Supplemental)
          </dd>
          <dt>PUBLIC KEY</dt>
          <dd>
-           is the 256-bit public key "zk" of the zone which is being revoked 
and
+           is the 256-bit public key zk of the zone which is being revoked and
            the key to be used to verify SIGNATURE. The
            wire format of this value is defined in <xref target="RFC8032" />,
            Section 5.1.5.
          </dd>
        </dl>
        <t>
-         Traditionally, PoW schemes require to find a "POW" such that
+         Traditionally, PoW schemes require to find a POW such that
          at least D leading zeroes are found in the hash result.
-         D is then referred to as the "difficulty" of the PoW.
+         D is then referred to as the difficulty of the PoW.
          In order to reduce the variance in time it takes to calculate the
-         PoW, we require that a number "Z" different PoWs must be
-         found that on average have "D" leading zeroes.
+         PoW, we require that a number Z different PoWs must be
+         found that on average have D leading zeroes.
        </t>
        <t>
          The resulting proofs may then published and disseminated. The concrete
          dissemination and publication methods are out of scope of this
-         document. Given an average difficulty of "D", the proofs have an
+         document. Given an average difficulty of D, the proofs have an
          expiration time of EPOCH. With each additional bit difficulty, the
          lifetime of the proof is prolonged for another EPOCH.
          Consequently, by calculating a more difficult PoW, the lifetime of the
@@ -1861,7 +1862,7 @@ NICK: john (Supplemental)
          </dd>
          <dt>ZONE PUBLIC KEY</dt>
          <dd>
-           is the public key "zk" of the zone which is being revoked and
+           is the public key zk of the zone which is being revoked and
            the key to be used to verify SIGNATURE.
          </dd>
          <dt>SIGNATURE</dt>

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.