gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lsd0001] branch master updated: attempt clarify supplemental #2


From: gnunet
Subject: [lsd0001] branch master updated: attempt clarify supplemental #2
Date: Sat, 15 Feb 2020 19:44:04 +0100

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 bdfea14  attempt clarify supplemental #2
bdfea14 is described below

commit bdfea14f7efe6c9f6a130461da085b1aed7a50f8
Author: Martin Schanzenbach <address@hidden>
AuthorDate: Sat Feb 15 19:40:11 2020 +0100

    attempt clarify supplemental #2
---
 draft-schanzen-gns.html |  21 +++---
 draft-schanzen-gns.txt  | 170 ++++++++++++++++++++++++------------------------
 draft-schanzen-gns.xml  |  21 +++---
 3 files changed, 111 insertions(+), 101 deletions(-)

diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 11a1bb8..4a1e86f 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -2341,32 +2341,37 @@ table {
 <figure id="figure-14">
             <div class="artwork art-text alignLeft" id="section-6.2.6-3.1">
 <pre>
-           Query: alice.bob (type=A)
+           Query: alice.doe (type=A)
            Result:
            A: 1.2.3.4
-           NICK: Alice
+           NICK: eve
          </pre>
 </div>
 <figcaption><a href="#figure-14" class="selfRef">Figure 
14</a></figcaption></figure>
 <p id="section-6.2.6-4">
           In this example, the returned NICK record is non-supplemental.
           For the client, this means that the NICK belongs to the zone
-          "alice.bob" and is published under the empty label along with an A
-          record. In contrast, if the resolution yields the following:<a 
href="#section-6.2.6-4" class="pilcrow">¶</a></p>
+          "alice.doe" and is published under the empty label along with an A
+          record. The NICK record should be interpreted as: The zone defined by
+          "alice.doe" wants to be referred to as "eve".
+          In contrast, consider the following:<a href="#section-6.2.6-4" 
class="pilcrow">¶</a></p>
 <figure id="figure-15">
             <div class="artwork art-text alignLeft" id="section-6.2.6-5.1">
 <pre>
-           Query: alice.bob (type=A)
+           Query: alice.doe (type=A)
            Result:
            A: 1.2.3.4
-           NICK: Bob (Supplemental)
+           NICK: john (Supplemental)
          </pre>
 </div>
 <figcaption><a href="#figure-15" class="selfRef">Figure 
15</a></figcaption></figure>
 <p id="section-6.2.6-6">
        In this case, the NICK record is marked as supplemental. This means that
-       the NICK record belongs to the zone "bob" and is published under the
-       label "alice" along with an A record.<a href="#section-6.2.6-6" 
class="pilcrow">¶</a></p>
+       the NICK record belongs to the zone "doe" and is published under the
+       label "alice" along with an A record. The NICK record should be
+       interpreted as: The zone defined by "doe" wants to be referred to as
+       "john". This distinction is likely useful for other records published as
+       supplemental.<a href="#section-6.2.6-6" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index d6aa536..a0010df 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -84,13 +84,13 @@ Table of Contents
        6.2.4.  BOX . . . . . . . . . . . . . . . . . . . . . . . . .  18
        6.2.5.  VPN . . . . . . . . . . . . . . . . . . . . . . . . .  18
        6.2.6.  Supplemental Records  . . . . . . . . . . . . . . . .  19
-   7.  Zone Revocation . . . . . . . . . . . . . . . . . . . . . . .  19
-   8.  Determining the Root Zone and Zone Governance . . . . . . . .  20
+   7.  Zone Revocation . . . . . . . . . . . . . . . . . . . . . . .  20
+   8.  Determining the Root Zone and Zone Governance . . . . . . . .  21
    9.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
    10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
    11. Test Vectors  . . . . . . . . . . . . . . . . . . . . . . . .  22
    12. Normative References  . . . . . . . . . . . . . . . . . . . .  24
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26
 
 1.  Introduction
 
@@ -1025,39 +1025,39 @@ Internet-Draft             The GNU Name System          
   November 2019
    record allows the client to match the record to the authoritative
    zone.  Consider the following example:
 
-              Query: alice.bob (type=A)
+              Query: alice.doe (type=A)
               Result:
               A: 1.2.3.4
-              NICK: Alice
+              NICK: eve
 
                                  Figure 14
 
    In this example, the returned NICK record is non-supplemental.  For
-   the client, this means that the NICK belongs to the zone "alice.bob"
-   and is published under the empty label along with an A record.  In
-   contrast, if the resolution yields the following:
+   the client, this means that the NICK belongs to the zone "alice.doe"
+   and is published under the empty label along with an A record.  The
+   NICK record should be interpreted as: The zone defined by "alice.doe"
+   wants to be referred to as "eve".  In contrast, consider the
+   following:
 
-              Query: alice.bob (type=A)
+              Query: alice.doe (type=A)
               Result:
               A: 1.2.3.4
-              NICK: Bob (Supplemental)
+              NICK: john (Supplemental)
 
                                  Figure 15
 
    In this case, the NICK record is marked as supplemental.  This means
-   that the NICK record belongs to the zone "bob" and is published under
-   the label "alice" along with an A record.
+   that the NICK record belongs to the zone "doe" and is published under
+   the label "alice" along with an A record.  The NICK record should be
+   interpreted as: The zone defined by "doe" wants to be referred to as
+   "john".  This distinction is likely useful for other records
+   published as supplemental.
+
+
+
 
-7.  Zone Revocation
 
-   Whenever a recursive resolver encounters a new GNS zone, it MUST
-   check against the local revocation list whether the respective zone
-   key has been revoked.  If the zone key was revoked, the resolution
-   MUST fail with an empty result set.
 
-   In order to revoke a zone key, a signed revocation object SHOULD be
-   published.  This object MUST be signed using the private zone key.
-   The revocation object is flooded in the overlay network.  To prevent
 
 
 
@@ -1066,6 +1066,16 @@ Schanzenbach, et al.       Expires 13 May 2020           
      [Page 19]
 Internet-Draft             The GNU Name System             November 2019
 
 
+7.  Zone Revocation
+
+   Whenever a recursive resolver encounters a new GNS zone, it MUST
+   check against the local revocation list whether the respective zone
+   key has been revoked.  If the zone key was revoked, the resolution
+   MUST fail with an empty result set.
+
+   In order to revoke a zone key, a signed revocation object SHOULD be
+   published.  This object MUST be signed using the private zone key.
+   The revocation object is flooded in the overlay network.  To prevent
    flooding attacks, the revocation message MUST contain a proof-of-
    work.  The revocation message including the proof-of-work MAY be
    calculated ahead of time to support timely revocation.
@@ -1103,6 +1113,15 @@ Internet-Draft             The GNU Name System           
  November 2019
             p := 2 /* Parallelization parameter */
             dkLen := 512 /* Intended output length */
 
+
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 20]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    The above function is called with different values for the "NONCE" in
    "REVDAT" until the amount of leading zeroes is greater or equal 25.
 
@@ -1114,14 +1133,6 @@ Internet-Draft             The GNU Name System           
  November 2019
    points to a local or remote start zone key.  A resolver client may
    also determine the start zone from the suffix of the name given for
    resolution or using information retrieved out of band.  The
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 20]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
    governance model of any zone is at the sole discretion of the zone
    owner.  However, the choice of start zone(s) is at the sole
    discretion of the local system administrator or user.
@@ -1153,6 +1164,20 @@ Internet-Draft             The GNU Name System           
  November 2019
    locally managed zone matches the suffix of the name to be resolved,
    resolution SHOULD start from the respective local zone:
 
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 21]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
             Example name: www.example.gnu
             Local zones:
             fr = (d0,zk0)
@@ -1169,15 +1194,6 @@ Internet-Draft             The GNU Name System           
  November 2019
    ".".  If multiple suffixes match the name to resolve, the longest
    matching suffix MUST BE used.  The suffix length of two results
    cannot be equal, as this would indicate a misconfiguration.  If both
-
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 21]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
    a locally managed zone and a configuration entry exist for the same
    suffix, the locally managed zone MUST have priority.
 
@@ -1211,6 +1227,13 @@ Internet-Draft             The GNU Name System           
  November 2019
             f89333903b284fe8
             1878bf47f3b39da0
 
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 22]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
             zk (public zone key) :=
             dff911496d025d7e
             0885c03d19153e99
@@ -1227,13 +1250,6 @@ Internet-Draft             The GNU Name System           
  November 2019
             6668e9f684f4dc33
             6d656b27392b0fee
 
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 22]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
             d_h :=
             01fb61f482c17633
             77611c4c2509e0f3
@@ -1266,6 +1282,14 @@ Internet-Draft             The GNU Name System           
  November 2019
             3425e8a811ae59d2
             99e2747285d2a479
 
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 23]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
             TWOFISH_IV :=
             071be189a9d236f9
             b4a3654bb8c281d4
@@ -1282,14 +1306,6 @@ Internet-Draft             The GNU Name System           
  November 2019
             00000000
 
 
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 23]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
             RRBLOCK :=
             055cb070e05fe6de SIGNATURE
             ad694a50e5b4dedd
@@ -1321,6 +1337,15 @@ Internet-Draft             The GNU Name System           
  November 2019
               STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
               <https://www.rfc-editor.org/info/rfc1034>.
 
+
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 24]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    [RFC1035]  Mockapetris, P., "Domain names - implementation and
               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
               November 1987, <https://www.rfc-editor.org/info/rfc1035>.
@@ -1339,13 +1364,6 @@ Internet-Draft             The GNU Name System           
  November 2019
               10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
               2003, <https://www.rfc-editor.org/info/rfc3629>.
 
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 24]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
    [RFC3826]  Blumenthal, U., Maino, F., and K. McCloghrie, "The
               Advanced Encryption Standard (AES) Cipher Algorithm in the
               SNMP User-based Security Model", RFC 3826,
@@ -1376,6 +1394,14 @@ Internet-Draft             The GNU Name System           
  November 2019
               Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
               2013, <https://www.rfc-editor.org/info/rfc6979>.
 
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 25]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
               for Security", RFC 7748, DOI 10.17487/RFC7748, January
               2016, <https://www.rfc-editor.org/info/rfc7748>.
@@ -1394,14 +1420,6 @@ Internet-Draft             The GNU Name System           
  November 2019
 
 Authors' Addresses
 
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 25]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
    Martin Schanzenbach
    GNUnet e.V.
    Boltzmannstrasse 3
@@ -1432,24 +1450,6 @@ Internet-Draft             The GNU Name System           
  November 2019
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
 
 
 
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index da0ead1..e75a815 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1090,30 +1090,35 @@
            </t>
        <figure>
          <artwork name="" type="" align="left" alt=""><![CDATA[
-           Query: alice.bob (type=A)
+           Query: alice.doe (type=A)
            Result:
            A: 1.2.3.4
-           NICK: Alice
+           NICK: eve
          ]]></artwork>
         </figure>
         <t>
           In this example, the returned NICK record is non-supplemental.
           For the client, this means that the NICK belongs to the zone
-          "alice.bob" and is published under the empty label along with an A
-          record. In contrast, if the resolution yields the following:
+          "alice.doe" and is published under the empty label along with an A
+          record. The NICK record should be interpreted as: The zone defined by
+          "alice.doe" wants to be referred to as "eve".
+          In contrast, consider the following:
         </t>
        <figure>
          <artwork name="" type="" align="left" alt=""><![CDATA[
-           Query: alice.bob (type=A)
+           Query: alice.doe (type=A)
            Result:
            A: 1.2.3.4
-           NICK: Bob (Supplemental)
+           NICK: john (Supplemental)
          ]]></artwork>
      </figure>
      <t>
        In this case, the NICK record is marked as supplemental. This means that
-       the NICK record belongs to the zone "bob" and is published under the
-       label "alice" along with an A record.
+       the NICK record belongs to the zone "doe" and is published under the
+       label "alice" along with an A record. The NICK record should be
+       interpreted as: The zone defined by "doe" wants to be referred to as
+       "john". This distinction is likely useful for other records published as
+       supplemental.
       </t>
 
 

-- 
To stop receiving notification emails like this one, please contact
address@hidden.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]