[lsd0001] branch master updated (dac3a45 -> 118c584)

[gnunet]

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

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

    from dac3a45  bcp14 tags
     new d7fe59a  update
     new 118c584  fixes

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 draft-schanzen-gns.xml | 68 ++++++++++++++++++++++++--------------------------
 1 file changed, 33 insertions(+), 35 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 2a672c6..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>
-       A implementation <bcp14>SHOULD</bcp14> enable the user to create and 
manage zones.
+       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>

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