[lsd0001] branch master updated: ise mostly done

[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 be8ace0  ise mostly done
be8ace0 is described below

commit be8ace04e2b38e5d7cb26f6b288adfa8c365325a
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Dec 20 21:14:56 2021 +0100

    ise mostly done
---
 draft-schanzen-gns.xml | 30 +++++++++++++++++-------------
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 79092c2..e376d2e 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -600,8 +600,8 @@ zk' := h mod L * zk
          "key-derivation" as salt and the public zone key as initial
          keying material.
          h is the 512-bit HKDF expansion result and must be interpreted in
-         network byte order. The expansion info input is
-         a concatenation of the label and string "gns".
+         network byte order. The expansion information input is
+         a concatenation of the label and the string "gns".
          The label is a UTF-8 string under which the resource records are
          published.
          The multiplication of zk with h is a point multiplication,
@@ -703,7 +703,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
            curve parameters of the twisted edwards representation
            of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519)
            with the Ed25519-SHA-512 scheme <xref target="ed25519" />.
-           Consequently , we use the following naming convention for our
+           Consequently, we use the following naming convention for our
            cryptographic primitives for EDKEY zones:
          </t>
          <dl>
@@ -785,8 +785,9 @@ zk' := h * zk
            PRK_h is key material retrieved using an HKDF using the string
            "key-derivation" as salt and the public zone key as initial
            keying material.
-           The blinding factor h is the 512-bit HKDF expansion result. The 
expansion info input is
-           a concatenation of the label and string "gns".
+           The blinding factor h is the 512-bit HKDF expansion result.
+           The expansion information input is
+           a concatenation of the label and the string "gns".
            The result of the HKDF must be clamped and interpreted in network
            byte order.
            a is the 256-bit integer corresponding to the 256-bit private zone
@@ -799,7 +800,7 @@ zk' := h * zk
          </t>
          <t>
            Signatures for EDKEY zones using the derived private key a'
-           are NOT compliant with <xref target="ed25519" />.
+           are not compliant with <xref target="ed25519" />.
            As the corresponding private key to the derived private scalar a'
            is not known, it is not possible to deterministically derive the
            signature part R according to <xref target="ed25519" />.
@@ -923,13 +924,14 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
        <dl>
          <dt>DNS NAME</dt>
          <dd>
-           The name to continue with in DNS (0-terminated).
+           The name to continue with in DNS. The value is UTF-8 encoded and
+           0-terminated.
          </dd>
          <dt>DNS SERVER NAME</dt>
          <dd>
            The DNS server to use. May be an IPv4/IPv6 address in dotted decimal
            form or a DNS name. It may also be a relative GNS name ending with a
-           "+" top-level domain. The value is UTF-8 encoded (also for DNS 
names)
+           "+" top-level domain. The value is UTF-8 encoded
            and 0-terminated.
          </dd>
        </dl>
@@ -938,7 +940,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
      <section anchor="gnsrecords_leho" numbered="true" toc="default">
        <name>LEHO</name>
        <t>Legacy hostname records can be used by applications that are expected
-         to supply a DNS name on the application layer. The most common use 
case
+         to supply a DNS name at the application layer. The most common use 
case
          is HTTP virtual hosting, which as-is would not work with GNS names as
          those may not be globally unique.
 
@@ -976,7 +978,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
        <name>NICK</name>
        <t>
          Nickname records can be used by zone administrators to publish an
-         indication on what label this zone prefers to be referred to.
+         the 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="zone_types" />) containing this 
zone's
          public zone key.
@@ -1246,8 +1248,10 @@ q := SHA512 (HDKD-Public(zk, label))
          </dd>
          <dt>PURPOSE</dt>
          <dd>
-           A 32-bit signature purpose flag. This field MUST be 15 (in network
-           byte order).
+           A 32-bit signature purpose flag. For a RRBLOCK the value of this
+           field MUST be 15. The value is encoded in network byte order.
+           The value of this field corresponds to an entry in the
+           GANA "GNUnet Signature Purpose" registry.
          </dd>
          <dt>EXPIRATION</dt>
          <dd>
@@ -1541,7 +1545,7 @@ example.com = zk2
            </t>
            <t>
              Otherwise, it is expected that the resolver first resolves the
-             IP(s) of the specified DNS name server(s). GNS2DNS records MAY
+             IP addresses of the specified DNS name servers. GNS2DNS records 
MAY
              contain numeric IPv4 or IPv6 addresses, allowing the resolver to
              skip this step.
              The DNS server names may themselves be names in GNS or DNS.

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