[lsd0001] branch master updated: adding FIXMEs to be discussed, might be reasonable optimizations...

[gnunet]

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

grothoff pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new cf3e1eb  adding FIXMEs to be discussed, might be reasonable 
optimizations...
cf3e1eb is described below

commit cf3e1eb44b6d8feb4e4e7db7f9a2e8ede337c274
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Tue Feb 1 21:30:35 2022 +0100

    adding FIXMEs to be discussed, might be reasonable optimizations...
---
 draft-schanzen-gns.xml | 24 +++++++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 5682f02..2f64c20 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1545,7 +1545,7 @@ NONCE := HKDF-Expand (PRK_n, label, 128 / 8)
      <t>
        Any API which allows storing a value under a 512-bit key and retrieving
        one or more values from the key can be used by an implementation for 
record storage.
-       To be useful, the API MUST permit storing at least 164 byte values
+       To be useful, the API MUST permit storing at least 176 byte values
        to be able to support the defined zone delegation record encodings,
        and SHOULD allow at least 1024 byte values.
        We assume that an implementation realizes two procedures on top of a
@@ -1645,20 +1645,23 @@ q := SHA-512 (ZKDF-Public(zk, label))
            ]]></artwork>
        </figure>
        <t>The RRBLOCK Wire Format.</t>
+       <!-- FIXME: Should we remove size and purpose from the wire format? 
They are entirely redundant, right?
+            I (CG) also think we should then move the expiration first (before 
ztype), so that it is aligned. -->
        <dl>
          <dt>ZONE TYPE</dt>
          <dd>
-           is the 32-bit zone type.
+           is the 32-bit ztype.
          </dd>
          <dt>ZONE KEY</dt>
          <dd>
            is the blinded zone key "ZKDF-Public(zk, label)"
            to be used to verify SIGNATURE.
+           The length and format of the public key depends on the ztype.
          </dd>
          <dt>SIGNATURE</dt>
          <dd>
            The signature is computed over the data following
-           this field.
+           this field.  The length and format of the signature depends on the 
ztype.
            The signature is created using the Sign() function of
            the cryptosystem of the zone and the derived private key
            "ZKDF-Private(d, label)" (see <xref target="zones" />).
@@ -1673,6 +1676,12 @@ q := SHA-512 (ZKDF-Public(zk, label))
            size significantly below 4 GB. However, a minimum block size of
            62 kilobytes MUST be supported.
            <!-- See GNUNET_CONSTANTS_MAX_BLOCK_SIZE -->
+           <!-- FIXME: I (CG) think for storage we should go for the minimum
+                as an embedded system may not be able to handle 62k and may
+                still find utility in GNS with smaller records; for the
+                client-side resolver, we MAY choose to require a higher limit;
+                but it is unclear that this belongs here with this field!
+                (and I think we should kill the field! see above!) -->
          </dd>
          <dt>PURPOSE</dt>
          <dd>
@@ -1706,6 +1715,15 @@ q := SHA-512 (ZKDF-Public(zk, label))
          The wire format of the RDATA is illustrated in
          <xref target="figure_rdata"/>.
        </t>
+       <!-- FIXME: I (CG) think we can do better here:
+            use the canonical TYPE-LENGTH-(FLAGS-EXPR)-VALUE
+            (as in TLV) instead of LENGTH-TYPE-(FLAGS-EXPR)-VALUE;
+            we should consider using 16 bit for DATA SIZE and
+            FLAGS (improves alignment, hardly a good use for 32-bit
+            flags or values);
+            We MAY also consider removing RRCOUNT, just bad
+            for alignment, and --- strictly speaking --- redundant,
+            just causes another error check for implementations.  -->
        <figure anchor="figure_rdata">
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0     8     16    24    32    40    48    56

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