gnunet-svn
[Top][All Lists]
Advanced

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

[lsd0001] branch master updated: add cite


From: gnunet
Subject: [lsd0001] branch master updated: add cite
Date: Sun, 10 May 2020 21:21:46 +0200

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 dc977d2  add cite
dc977d2 is described below

commit dc977d251ad745080e2bdc3fab2b54d430826dd2
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Sun May 10 21:16:46 2020 +0200

    add cite
---
 draft-schanzen-gns.html | 273 ++++++++++++++++--------------------------------
 draft-schanzen-gns.txt  | 152 +++++++++++++--------------
 draft-schanzen-gns.xml  |  21 +++-
 3 files changed, 187 insertions(+), 259 deletions(-)

diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index e86d37e..24283da 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -11,7 +11,7 @@
 <meta content="
        This document contains the GNU Name System (GNS) technical 
specification. 
     " name="description">
-<meta content="xml2rfc 2.43.0" name="generator">
+<meta content="xml2rfc 2.39.0" name="generator">
 <meta content="name systems" name="keyword">
 <meta content="draft-schanzen-gns-00" name="ietf.draft">
 <link href="draft-schanzen-gns.xml" rel="alternate" type="application/rfc+xml">
@@ -991,7 +991,7 @@ h1#rfcnum {
 }
 /* Make .olPercent look the same as <ol><li> */
 dl.olPercent > dd {
-  margin-bottom: 0.25em;
+  margin: 0 0 0.25em 0;
   min-height: initial;
 }
 /* Give aside some styling to set it apart */
@@ -1029,71 +1029,17 @@ aside > p {
     margin-bottom: 1em;
   }
 }
+/*
+  The margin-left: 0 on <dd> removes all distinction
+  between levels from nested <dl>s.  Undo that.
+*/
+dl.olPercent > dd,
+dd {
+  margin-left: revert;
+}
 /* Avoid narrow tables forcing too narrow table captions, which may render 
badly */
 table {
   min-width: 20em;
-}
-/* ol type a */
-ol.type-a { list-style-type: lower-alpha; }
-ol.type-A { list-style-type: upper-alpha; }
-ol.type-i { list-style-type: lower-roman; }
-ol.type-I { list-style-type: lower-roman; }
-/* Apply the print table and row borders in general, on request from the RPC,
-and increase the contrast between border and odd row background sligthtly */
-table {
-  border: 1px solid #ddd;
-}
-td {
-  border-top: 1px solid #ddd;
-}
-tr:nth-child(2n+1) > td {
-  background-color: #f8f8f8;
-}
-/* Use style rules to govern display of the TOC. */
-@media screen and (max-width: 1023px) {
-  #toc nav { display: none; }
-  #toc.active nav { display: block; }
-}
-/* Add support for keepWithNext */
-.keepWithNext {
-  break-after: avoid-page;
-  break-after: avoid-page;
-}
-/* Add support for keepWithPrevious */
-.keepWithPrevious {
-  break-before: avoid-page;
-}
-/* Change the approach to avoiding breaks inside artwork etc. */
-figure, pre, table, .artwork, .sourcecode  {
-  break-before: avoid-page;
-  break-after: auto;
-}
-/* Avoid breaks between <dt> and <dd> */
-dl {
-  break-inside: auto;
-}
-dt {
-  break-before: auto;
-  break-inside: avoid-page;
-  break-after: avoid-page;
-}
-dd {
-  break-before: avoid-page;
-  break-inside: avoid-page;
-  break-after: auto;
-}
-dd.break {
-  margin-bottom: 0;
-  min-height: 0;
-  break-before: auto;
-  break-inside: auto;
-  break-after: auto;
-}
-/* Undo break-before ToC */
-@media print {
-  #toc {
-    break-before: auto;
-  }
 }</style>
 <link href="rfc-local.css" rel="stylesheet" type="text/css">
 </head>
@@ -1197,16 +1143,16 @@ dd.break {
         </h2>
 <nav class="toc"><ul class="toc ulEmpty">
 <li class="toc ulEmpty" id="section-toc.1-1.1">
-            <p id="section-toc.1-1.1.1" class="keepWithNext"><a 
href="#section-1" class="xref">1</a>.  <a href="#name-introduction" 
class="xref">Introduction</a><a href="#section-toc.1-1.1.1" 
class="pilcrow">¶</a></p>
+            <p id="section-toc.1-1.1.1"><a href="#section-1" 
class="xref">1</a>.  <a href="#name-introduction" 
class="xref">Introduction</a><a href="#section-toc.1-1.1.1" 
class="pilcrow">¶</a></p>
 </li>
 <li class="toc ulEmpty" id="section-toc.1-1.2">
-            <p id="section-toc.1-1.2.1" class="keepWithNext"><a 
href="#section-2" class="xref">2</a>.  <a href="#name-zones" 
class="xref">Zones</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
+            <p id="section-toc.1-1.2.1"><a href="#section-2" 
class="xref">2</a>.  <a href="#name-zones" class="xref">Zones</a><a 
href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
 </li>
 <li class="toc ulEmpty" id="section-toc.1-1.3">
             <p id="section-toc.1-1.3.1"><a href="#section-3" 
class="xref">3</a>.  <a href="#name-resource-records" class="xref">Resource 
Records</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
 <ul class="toc ulEmpty">
 <li class="toc ulEmpty" id="section-toc.1-1.3.2.1">
-                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a 
href="#section-3.1" class="xref">3.1</a>.  <a href="#name-record-types" 
class="xref">Record Types</a><a href="#section-toc.1-1.3.2.1.1" 
class="pilcrow">¶</a></p>
+                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" 
class="xref">3.1</a>.  <a href="#name-record-types" class="xref">Record 
Types</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
 </li>
 <li class="toc ulEmpty" id="section-toc.1-1.3.2.2">
                 <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" 
class="xref">3.2</a>.  <a href="#name-pkey" class="xref">PKEY</a><a 
href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
@@ -1337,7 +1283,7 @@ dd.break {
        particular X.509 for the Web.<a href="#section-1-2" 
class="pilcrow">¶</a></p>
 <p id="section-1-3">
        This document contains the GNU Name System (GNS) technical specification
-       of the GNU Name System (GNS), a fully decentralized and 
censorship-resistant
+       of the GNU Name System <span>[<a href="#GNS" 
class="xref">GNS</a>]</span>, a fully decentralized and censorship-resistant
        name system. GNS provides a privacy-enhancing alternative to the Domain
        Name System (DNS). The design of GNS incorporates the capability to
        integrate and coexist with DNS. GNS is based on the principle of a 
petname
@@ -1379,24 +1325,20 @@ dd.break {
          In GNS, records are signed using a key derived from "d" as described 
in
          <a href="#publish" class="xref">Section 4</a>.<a 
href="#section-2-2.2" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-2-2.3">p</dt>
 <dd id="section-2-2.4">
          is the prime of edwards25519 as defined in <span>[<a href="#RFC7748" 
class="xref">RFC7748</a>]</span>, i.e.
          2^255 - 19.<a href="#section-2-2.4" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-2-2.5">B</dt>
 <dd id="section-2-2.6">
          is the group generator (X(P),Y(P)) of edwards25519 as defined in
          <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.<a 
href="#section-2-2.6" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-2-2.7">L</dt>
 <dd id="section-2-2.8">
          is the prime-order subgroup of edwards25519 in <span>[<a 
href="#RFC7748" class="xref">RFC7748</a>]</span>.<a href="#section-2-2.8" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-2-2.9">zk</dt>
 <dd id="section-2-2.10">
          is the ECDSA public key corresponding to d. It is defined in
@@ -1405,7 +1347,6 @@ dd.break {
          The public key is used to uniquely identify a GNS zone and is 
referred to
          as the "zone key".<a href="#section-2-2.10" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 </section>
 </div>
@@ -1438,7 +1379,7 @@ dd.break {
          +-----+-----+-----+-----+                       /
          /                                               /
          /                                               /
-</pre>
+         </pre>
 </div>
 <figcaption><a href="#figure-1" class="selfRef">Figure 
1</a></figcaption></figure>
 </div>
@@ -1450,13 +1391,11 @@ dd.break {
          In microseconds since midnight (0 hour), January 1, 1970 in network
          byte order.<a href="#section-3-5.2" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-3-5.3">DATA SIZE</dt>
 <dd id="section-3-5.4">
          denotes the 32-bit size of the DATA field in bytes and in network byte
          order.<a href="#section-3-5.4" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-3-5.5">TYPE</dt>
 <dd id="section-3-5.6">
          is the 32-bit resource record type. This type can be one of the GNS 
resource
@@ -1466,19 +1405,16 @@ dd.break {
          stored in network byte order. Note that values
          below 2^16 are reserved for allocation via IANA (<span>[<a 
href="#RFC6895" class="xref">RFC6895</a>]</span>).<a href="#section-3-5.6" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-3-5.7">FLAGS</dt>
 <dd id="section-3-5.8">
          is a 32-bit resource record flags field (see below).<a 
href="#section-3-5.8" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-3-5.9">DATA</dt>
 <dd id="section-3-5.10">
          the variable-length resource record data payload. The contents are 
defined
          by the
          respective type of the resource record.<a href="#section-3-5.10" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 <p id="section-3-6">
        Flags indicate metadata surrounding the resource record. A flag
@@ -1493,7 +1429,7 @@ dd.break {
          ------+--------+--------+--------+--------+--------+
          / ... | SHADOW | EXPREL | SUPPL  | PRIVATE|    /   |
          ------+--------+--------+--------+--------+--------+
-</pre>
+         </pre>
 </div>
 <figcaption><a href="#figure-2" class="selfRef">Figure 
2</a></figcaption></figure>
 </div>
@@ -1508,7 +1444,6 @@ dd.break {
          values of records into the DHT. This way, future values can propagate 
and may be
          cached before the transition becomes active.<a href="#section-3-9.2" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-3-9.3">EXPREL</dt>
 <dd id="section-3-9.4">
          The expiration time value of the record is a relative time (still in 
microseconds)
@@ -1516,7 +1451,6 @@ dd.break {
          for records obtained from the DHT, but might be present when a 
resolver looks up
          private records of a zone hosted locally.<a href="#section-3-9.4" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-3-9.5">
          SUPPL
         </dt>
@@ -1527,7 +1461,6 @@ dd.break {
          may be useful for the application. This flag should only be 
encountered
          by a resolver for records obtained from the DHT.<a 
href="#section-3-9.6" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-3-9.7">PRIVATE</dt>
 <dd id="section-3-9.8">
          This is a private record of this peer and it should thus not be
@@ -1536,7 +1469,6 @@ dd.break {
          Private records should still be considered just like
          regular records when resolving labels in local zones.<a 
href="#section-3-9.8" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 <div id="gnsrecords_numbers">
 <section id="section-3.1">
@@ -1571,7 +1503,7 @@ dd.break {
            |                                               |
            |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
-</pre>
+           </pre>
 </div>
 <figcaption><a href="#figure-3" class="selfRef">Figure 
3</a></figcaption></figure>
 </div>
@@ -1582,7 +1514,6 @@ dd.break {
 <dd id="section-3.2-4.2">
            A 256-bit ECDSA zone key.<a href="#section-3.2-4.2" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 </section>
 </div>
@@ -1612,7 +1543,7 @@ dd.break {
            /                                               /
            |                                               |
            +-----------------------------------------------+
-</pre>
+           </pre>
 </div>
 <figcaption><a href="#figure-4" class="selfRef">Figure 
4</a></figcaption></figure>
 </div>
@@ -1623,7 +1554,6 @@ dd.break {
 <dd id="section-3.3-4.2">
            The name to continue with in DNS (0-terminated).<a 
href="#section-3.3-4.2" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-3.3-4.3">DNS SERVER NAME</dt>
 <dd id="section-3.3-4.4">
            The DNS server to use. May be an IPv4/IPv6 address in dotted decimal
@@ -1631,7 +1561,6 @@ dd.break {
            "+" top-level domain. The value is UTF-8 encoded (also for DNS 
names)
            and 0-terminated.<a href="#section-3.3-4.4" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 </section>
 </div>
@@ -1659,7 +1588,7 @@ dd.break {
            /                                               /
            |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
-</pre>
+           </pre>
 </div>
 <figcaption><a href="#figure-5" class="selfRef">Figure 
5</a></figcaption></figure>
 </div>
@@ -1670,7 +1599,6 @@ dd.break {
 <dd id="section-3.4-4.2">
            A UTF-8 string (which is not 0-terminated) representing the legacy 
hostname.<a href="#section-3.4-4.2" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 <p id="section-3.4-5">
          NOTE: If an application uses a LEHO value in an HTTP request header
@@ -1705,7 +1633,7 @@ dd.break {
            /                                               /
            |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
-</pre>
+           </pre>
 </div>
 <figcaption><a href="#figure-6" class="selfRef">Figure 
6</a></figcaption></figure>
 </div>
@@ -1717,7 +1645,6 @@ dd.break {
            A UTF-8 string (which is not 0-terminated) representing the 
preferred
            label of the zone. This string MUST NOT include a "." character.<a 
href="#section-3.5-4.2" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 </section>
 </div>
@@ -1752,7 +1679,7 @@ dd.break {
            /                                               /
            |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
-</pre>
+           </pre>
 </div>
 <figcaption><a href="#figure-7" class="selfRef">Figure 
7</a></figcaption></figure>
 </div>
@@ -1763,24 +1690,20 @@ dd.break {
 <dd id="section-3.6-4.2">
            the 16-bit protocol number, e.g. 6 for tcp. In network byte 
order.<a href="#section-3.6-4.2" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-3.6-4.3">SVC</dt>
 <dd id="section-3.6-4.4">
            the 16-bit service value of the boxed record, i.e. the port number.
            In network byte order.<a href="#section-3.6-4.4" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-3.6-4.5">TYPE</dt>
 <dd id="section-3.6-4.6">
            is the 32-bit record type of the boxed record. In network byte 
order.<a href="#section-3.6-4.6" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-3.6-4.7">RECORD DATA</dt>
 <dd id="section-3.6-4.8">
            is a variable length field containing the "DATA" format of TYPE as
            defined for the respective TYPE in DNS.<a href="#section-3.6-4.8" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 </section>
 </div>
@@ -1808,7 +1731,7 @@ dd.break {
            /                                               /
            |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
-</pre>
+           </pre>
 </div>
 <figcaption><a href="#figure-8" class="selfRef">Figure 
8</a></figcaption></figure>
 </div>
@@ -1820,19 +1743,16 @@ dd.break {
            is a 256-bit EdDSA public key identifying the peer hosting the
            service.<a href="#section-3.7-4.2" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-3.7-4.3">PROTO</dt>
 <dd id="section-3.7-4.4">
            the 16-bit protocol number, e.g. 6 for TCP. In network byte 
order.<a href="#section-3.7-4.4" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-3.7-4.5">SERVICE NAME</dt>
 <dd id="section-3.7-4.6">
            a shared secret used to identify the service at the hosting peer,
            used to derive the port number requird to connect to the service.
            The service name MUST be a 0-terminated UTF-8 string.<a 
href="#section-3.7-4.6" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 </section>
 </div>
@@ -1865,7 +1785,7 @@ dd.break {
          d_h := h * d mod L
          zk_h := h mod L * zk
          q := SHA512 (zk_h)
-</pre><a href="#section-4.1-2" class="pilcrow">¶</a>
+         </pre><a href="#section-4.1-2" class="pilcrow">¶</a>
 </div>
 <p id="section-4.1-3">
          We use a hash-based key derivation function (HKDF) as defined in
@@ -1878,40 +1798,33 @@ dd.break {
            "key-derivation" as salt and the public zone key "zk" as initial
            keying material.<a href="#section-4.1-4.2" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-4.1-4.3">h</dt>
 <dd id="section-4.1-4.4">
            is the 512-bit HKDF expansion result. The expansion info input is a
            concatenation of the label and string "gns".<a 
href="#section-4.1-4.4" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-4.1-4.5">d</dt>
 <dd id="section-4.1-4.6">
            is the 256-bit private zone key as defined in <a href="#zones" 
class="xref">Section 2</a>.<a href="#section-4.1-4.6" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-4.1-4.7">label</dt>
 <dd id="section-4.1-4.8">
            is a UTF-8 string under which the resource records are published.<a 
href="#section-4.1-4.8" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-4.1-4.9">d_h</dt>
 <dd id="section-4.1-4.10">
            is a 256-bit private key derived from the "d" using the
            keying material "h".<a href="#section-4.1-4.10" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-4.1-4.11">zk_h</dt>
 <dd id="section-4.1-4.12">
            is a 256-bit public key derived from the zone key "zk" using the
            keying material "h".<a href="#section-4.1-4.12" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-4.1-4.13">L</dt>
 <dd id="section-4.1-4.14">
            is the prime-order subgroup as defined in <a href="#zones" 
class="xref">Section 2</a>.<a href="#section-4.1-4.14" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-4.1-4.15">q</dt>
 <dd id="section-4.1-4.16">
            Is the 512-bit DHT key under which the resource records block is
@@ -1919,7 +1832,6 @@ dd.break {
            It is the SHA512 hash over the public key "zk_h" corresponding to 
the
            derived private key "d_h".<a href="#section-4.1-4.16" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 <p id="section-4.1-5">
          We point out that the multiplication of "zk" with "h" is a point 
multiplication,
@@ -1970,7 +1882,7 @@ dd.break {
            /                                               /
            /                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
-</pre>
+           </pre>
 </div>
 <figcaption><a href="#figure-9" class="selfRef">Figure 
9</a></figcaption></figure>
 </div>
@@ -1984,14 +1896,12 @@ dd.break {
            The signature is created using the derived private key "d_h" (see
            <a href="#publish" class="xref">Section 4</a>).<a 
href="#section-4.2-4.2" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-4.2-4.3">PUBLIC KEY</dt>
 <dd id="section-4.2-4.4">
            is the 256-bit public key "zk_h" to be used to verify SIGNATURE. The
            wire format of this value is defined in <span>[<a href="#RFC8032" 
class="xref">RFC8032</a>]</span>,
            Section 5.1.5.<a href="#section-4.2-4.4" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-4.2-4.5">SIZE</dt>
 <dd id="section-4.2-4.6">
            A 32-bit value containing the length of the signed data following 
the
@@ -2002,13 +1912,11 @@ dd.break {
            size significantly below 4 GB. However, a minimum block size of
            62 kilobytes MUST be supported.<a href="#section-4.2-4.6" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-4.2-4.7">PURPOSE</dt>
 <dd id="section-4.2-4.8">
            A 32-bit signature purpose flag. This field MUST be 15 (in network
            byte order).<a href="#section-4.2-4.8" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-4.2-4.9">EXPIRATION</dt>
 <dd id="section-4.2-4.10">
            Specifies when the RRBLOCK expires and the encrypted block
@@ -2023,12 +1931,10 @@ dd.break {
            This is a 64-bit absolute date in microseconds since midnight
            (0 hour), January 1, 1970 in network byte order.<a 
href="#section-4.2-4.10" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-4.2-4.11">BDATA</dt>
 <dd id="section-4.2-4.12">
            The encrypted resource records with a total size of SIZE - 16.<a 
href="#section-4.2-4.12" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 </section>
 </div>
@@ -2068,7 +1974,7 @@ dd.break {
            +-----------------------+                       /
            /                     PADDING                   /
            /                                               /
-</pre>
+           </pre>
 </div>
 <figcaption><a href="#figure-10" class="selfRef">Figure 
10</a></figcaption></figure>
 </div>
@@ -2080,7 +1986,6 @@ dd.break {
            records which are
            following after this field in network byte order.<a 
href="#section-4.3-4.2" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-4.3-4.3">EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA</dt>
 <dd id="section-4.3-4.4">
            These fields were defined
@@ -2088,7 +1993,6 @@ dd.break {
            There MUST be a total of RR COUNT of these resource records
            present.<a href="#section-4.3-4.4" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-4.3-4.5">PADDING</dt>
 <dd id="section-4.3-4.6">
            The padding MUST contain the value 0 in all octets.
@@ -2098,7 +2002,6 @@ dd.break {
            are never padded. Note that a record set with a PKEY record MUST NOT
            contain other records.<a href="#section-4.3-4.6" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 <p id="section-4.3-5">
          The symmetric keys and initialization vectors are derived from the
@@ -2111,7 +2014,7 @@ dd.break {
          PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
          K := HKDF-Expand (PRK_k, label, 512 / 8);
          IV := HKDF-Expand (PRK_iv, label, 256 / 8)
-</pre><a href="#section-4.3-6" class="pilcrow">¶</a>
+         </pre><a href="#section-4.3-6" class="pilcrow">¶</a>
 </div>
 <p id="section-4.3-7">
          HKDF is a hash-based key derivation function as defined in
@@ -2138,7 +2041,7 @@ dd.break {
            |                                               |
            |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
-</pre>
+           </pre>
 </div>
 <figcaption><a href="#figure-11" class="selfRef">Figure 
11</a></figcaption></figure>
 </div>
@@ -2157,7 +2060,7 @@ dd.break {
            |                  TWOFISH IV                   |
            |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
-</pre>
+           </pre>
 </div>
 <figcaption><a href="#figure-12" class="selfRef">Figure 
12</a></figcaption></figure>
 </div>
@@ -2171,7 +2074,7 @@ dd.break {
                       TWOFISH(K[32:63], IV[16:31], BDATA))
          BDATA := TWOFISH(K[32:63], IV[16:31],
                           AES(K[0:31], IV[0:15], RDATA))
-</pre><a href="#section-4.3-12" class="pilcrow">¶</a>
+         </pre><a href="#section-4.3-12" class="pilcrow">¶</a>
 </div>
 </section>
 </div>
@@ -2225,7 +2128,7 @@ dd.break {
            is empty, it is interpreted as the apex label "@".<a 
href="#section-6.1-1" class="pilcrow">¶</a></p>
 <p id="section-6.1-2">
            From here, the following steps are recursively executed, in 
order:<a href="#section-6.1-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-6.1-3">
+<ol start="1" type="1" class="normal" id="section-6.1-3">
           <li id="section-6.1-3.1">Extract the right-most label from the name 
to look up.<a href="#section-6.1-3.1" class="pilcrow">¶</a>
 </li>
 <li id="section-6.1-3.2">Calculate q using the label and zk as defined in
@@ -2256,7 +2159,7 @@ dd.break {
            that the RRBLOCK has been cryptographically verified and decrypted.
            At this point, we must first determine if we have received a valid
            record set in the context of the name we are trying to resolve:<a 
href="#section-6.2-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-6.2-2">
+<ol start="1" type="1" class="normal" id="section-6.2-2">
           <li id="section-6.2-2.1">
            Case 1:
            If the remainder of the name to resolve is empty and the record set
@@ -2443,7 +2346,7 @@ dd.break {
            Result:
            A: 1.2.3.4
            NICK: eve
-</pre>
+         </pre>
 </div>
 <figcaption><a href="#figure-13" class="selfRef">Figure 
13</a></figcaption></figure>
 <p id="section-6.2.6-4">
@@ -2460,7 +2363,7 @@ dd.break {
            Result:
            A: 1.2.3.4
            NICK: john (Supplemental)
-</pre>
+         </pre>
 </div>
 <figcaption><a href="#figure-14" class="selfRef">Figure 
14</a></figcaption></figure>
 <p id="section-6.2.6-6">
@@ -2510,7 +2413,7 @@ dd.break {
          v := 0x13 /* Version */
          y := 0 /* Type (Argon2d) */
          X, K is unused
-</pre><a href="#section-7-4" class="pilcrow">¶</a>
+         </pre><a href="#section-7-4" class="pilcrow">¶</a>
 </div>
 <p id="section-7-5">
          The following is the message string "P" on which the PoW is
@@ -2530,7 +2433,7 @@ dd.break {
            |                                               |
            |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
-</pre>
+           </pre>
 </div>
 <figcaption><a href="#figure-15" class="selfRef">Figure 
15</a></figcaption></figure>
 </div>
@@ -2540,14 +2443,12 @@ dd.break {
 <dd id="section-7-8.2">
            A 64-bit solution to the PoW.<a href="#section-7-8.2" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-7-8.3">TIMESTAMP</dt>
 <dd id="section-7-8.4">
            denotes the absolute 64-bit expiration date of the record.
            In microseconds since midnight (0 hour), January 1, 1970 in network
            byte order.<a href="#section-7-8.4" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-7-8.5">PUBLIC KEY</dt>
 <dd id="section-7-8.6">
            A 512-bit ECDSA deterministic signature compliant with
@@ -2556,7 +2457,6 @@ dd.break {
            The signature is created using the private zone key "d" (see
            <a href="#zones" class="xref">Section 2</a>).<a 
href="#section-7-8.6" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 <p id="section-7-9">
          Traditionally, PoW schemes require to find a "POW" such that
@@ -2579,15 +2479,12 @@ dd.break {
         <dt id="section-7-12.1">Z</dt>
 <dd id="section-7-12.2">The number of PoWs required is fixed at 32.<a 
href="#section-7-12.2" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-7-12.3">D</dt>
 <dd id="section-7-12.4">The difficulty is fixed at 25.<a 
href="#section-7-12.4" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-7-12.5">EPOCH</dt>
 <dd id="section-7-12.6">A single epoch is fixed at 365 days.<a 
href="#section-7-12.6" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 <p id="section-7-13">
          Given that proof has been found, a revocation data object is defined
@@ -2622,7 +2519,7 @@ dd.break {
            |                                               |
            |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
-</pre>
+           </pre>
 </div>
 <figcaption><a href="#figure-16" class="selfRef">Figure 
16</a></figcaption></figure>
 </div>
@@ -2634,7 +2531,6 @@ dd.break {
            In microseconds since midnight (0 hour), January 1, 1970 in network
            byte order.<a href="#section-7-16.2" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-7-16.3">TTL</dt>
 <dd id="section-7-16.4">
            denotes the relative 64-bit time to live of of the record in
@@ -2644,13 +2540,11 @@ dd.break {
            revocation must be determined by examining the leading zeros in the
            proof of work calculation.<a href="#section-7-16.4" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-7-16.5">POW_i</dt>
 <dd id="section-7-16.6">
            The values calculated as part of the PoW. Each POW_i MUST
            be unique in the set of POW values.<a href="#section-7-16.6" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-7-16.7">SIGNATURE</dt>
 <dd id="section-7-16.8">
            A 512-bit ECDSA deterministic signature compliant with
@@ -2659,7 +2553,6 @@ dd.break {
            The signature is created using the private zone key "d" (see
            <a href="#zones" class="xref">Section 2</a>).<a 
href="#section-7-16.8" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-7-16.9">PUBLIC KEY</dt>
 <dd id="section-7-16.10">
            is the 256-bit public key "zk" of the zone which is being revoked 
and
@@ -2667,7 +2560,6 @@ dd.break {
            wire format of this value is defined in <span>[<a href="#RFC8032" 
class="xref">RFC8032</a>]</span>,
            Section 5.1.5.<a href="#section-7-16.10" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 <p id="section-7-17">
          The signature over the public key covers a 32 bit pseudo header
@@ -2688,7 +2580,7 @@ dd.break {
            +-----+-----+-----+-----+-----+-----+-----+-----+
            |                   TIMESTAMP                   |
            +-----+-----+-----+-----+-----+-----+-----+-----+
-</pre>
+           </pre>
 </div>
 <figcaption><a href="#figure-17" class="selfRef">Figure 
17</a></figcaption></figure>
 </div>
@@ -2699,17 +2591,14 @@ dd.break {
            A 32-bit value containing the length of the signed data in bytes
            (48 bytes) in network byte order.<a href="#section-7-20.2" 
class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-7-20.3">PURPOSE</dt>
 <dd id="section-7-20.4">
            A 32-bit signature purpose flag. This field MUST be 3 (in network
            byte order).<a href="#section-7-20.4" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 <dt id="section-7-20.5">PUBLIC KEY / TIMESTAMP</dt>
 <dd id="section-7-20.6">Both values as defined in the revocation data object 
above.<a href="#section-7-20.6" class="pilcrow">¶</a>
 </dd>
-<dd class="break"></dd>
 </dl>
 <div id="revocation_verification">
 <section id="section-7.1">
@@ -2719,7 +2608,7 @@ dd.break {
 <p id="section-7.1-1">
            In order to verify a revocation the following steps must be taken,
            in order:<a href="#section-7.1-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-7.1-2">
+<ol start="1" type="1" class="normal" id="section-7.1-2">
           <li id="section-7.1-2.1">The current time MUST be between TIMESTAMP 
and
              TIMESTAMP+TTL.<a href="#section-7.1-2.1" class="pilcrow">¶</a>
 </li>
@@ -2780,7 +2669,7 @@ dd.break {
          Example name: www.example.&lt;Base32(zk)&gt;
          =&gt; Root zone: zk
          =&gt; Name to resolve from root zone: www.example
-</pre><a href="#section-8-5" class="pilcrow">¶</a>
+         </pre><a href="#section-8-5" class="pilcrow">¶</a>
 </div>
 <p id="section-8-6">
          In GNS, users MAY own and manage their own zones.
@@ -2800,7 +2689,7 @@ dd.break {
          ...
          =&gt; Entry zone: zk1
          =&gt; Name to resolve from entry zone: www.example
-</pre><a href="#section-8-7" class="pilcrow">¶</a>
+         </pre><a href="#section-8-7" class="pilcrow">¶</a>
 </div>
 <p id="section-8-8">
          Finally, additional "suffix to zone" mappings MAY be configured.
@@ -2822,7 +2711,7 @@ dd.break {
          ...
          =&gt; Entry zone: zk1
          =&gt; Name to resolve from entry zone: www
-</pre><a href="#section-8-9" class="pilcrow">¶</a>
+         </pre><a href="#section-8-9" class="pilcrow">¶</a>
 </div>
 </section>
 </div>
@@ -2901,7 +2790,7 @@ The registry shall record for each entry:<a 
href="#section-10-1" class="pilcrow"
            65539    | VPN             | N/A     | [This.I-D]
            65540    | GNS2DNS         | N/A     | [This.I-D]
            65541    | BOX             | N/A     | [This.I-D]
-</pre>
+           </pre>
 </div>
 <figcaption><a href="#figure-18" class="selfRef">Figure 
18</a></figcaption></figure>
 </div>
@@ -2917,7 +2806,7 @@ The registry shall record for each entry:<a 
href="#section-10-1" class="pilcrow"
          under the label "test".<a href="#section-11-1" 
class="pilcrow">¶</a></p>
 <div class="artwork art-text alignLeft" id="section-11-2">
 <pre>
-
+         
 Zone private key (d):
 WGb/eoy8BDWvaK2vRab0xTlqvS0+PeS5HG5Rh4z4cWI=
 Zone public key (zk):
@@ -2962,14 +2851,14 @@ 
AAAAlAAAAA8ABaVLL0pgzeXufd+n7bSlOtRgcrJV2r+e2YIuK2nNjdBelSQiguzV
 Z9WDycoi/9Pn9r2UlHx6ZGX0T7/XJWIMzuJvj3UXGBaZBtL6pqxZwzSUEXf8vVdl
 n4OLnfNhStwk/ZXDKbuknX22chPD5i+3Mkn3TGv0bDVglQBEvfFDrzSewmgQyZWN
 pm+ogA==
-
-</pre><a href="#section-11-2" class="pilcrow">¶</a>
+           
+       </pre><a href="#section-11-2" class="pilcrow">¶</a>
 </div>
 <p id="section-11-3">
          The following is an example revocation for a zone:<a 
href="#section-11-3" class="pilcrow">¶</a></p>
 <div class="artwork art-text alignLeft" id="section-11-4">
 <pre>
-
+         
 Zone private key (d):
 SLZnT2NK3cusTfuI0CM+XJiP4U43ZsCAv+Lk3FbIXHc=
 
@@ -2987,8 +2876,8 @@ 
ukeHTXSPGL26R4dNdI8ZJLpHh010jxlTukeHTXSPGsa6R4dNdI8bfLpHh010jxuV
 ukeHTXSPHCi6R4dNdI8eC7pHh010jx4VukeHTXSPHhsJejeXmcDe4jcfEkWLqwIA
 8zG/gFIxNYu34usglSp+7w8bbtTgMD5hLGiR+xxhgpPh36dGz1KBZ9kAh9pz77yS
 bEclYC3aE2+fjSDDfRpdnv3gGHMckMceVbgymHZDlfA=
-
-</pre><a href="#section-11-4" class="pilcrow">¶</a>
+         
+       </pre><a href="#section-11-4" class="pilcrow">¶</a>
 </div>
 </section>
 <section id="section-12">
@@ -2999,67 +2888,54 @@ bEclYC3aE2+fjSDDfRpdnv3gGHMckMceVbgymHZDlfA=
 <dt id="RFC1034">[RFC1034]</dt>
 <dd>
 <span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain 
names - concepts and facilities"</span>, <span class="seriesInfo">STD 
13</span>, <span class="seriesInfo">RFC 1034</span>, <span 
class="seriesInfo">DOI 10.17487/RFC1034</span>, <time 
datetime="1987-11">November 1987</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc1034";>https://www.rfc-editor.org/info/rfc1034</a>&gt;</span>.
 </dd>
-<dd class="break"></dd>
 <dt id="RFC1035">[RFC1035]</dt>
 <dd>
 <span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain 
names - implementation and specification"</span>, <span class="seriesInfo">STD 
13</span>, <span class="seriesInfo">RFC 1035</span>, <span 
class="seriesInfo">DOI 10.17487/RFC1035</span>, <time 
datetime="1987-11">November 1987</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc1035";>https://www.rfc-editor.org/info/rfc1035</a>&gt;</span>.
 </dd>
-<dd class="break"></dd>
 <dt id="RFC2782">[RFC2782]</dt>
 <dd>
 <span class="refAuthor">Gulbrandsen, A.</span><span class="refAuthor">, Vixie, 
P.</span><span class="refAuthor">, and L. Esibov</span>, <span 
class="refTitle">"A DNS RR for specifying the location of services (DNS 
SRV)"</span>, <span class="seriesInfo">RFC 2782</span>, <span 
class="seriesInfo">DOI 10.17487/RFC2782</span>, <time 
datetime="2000-02">February 2000</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc2782";>https://www.rfc-editor.org/info/rfc2782</a>&gt;</span>.
 </dd>
-<dd class="break"></dd>
 <dt id="RFC2119">[RFC2119]</dt>
 <dd>
 <span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words 
for use in RFCs to Indicate Requirement Levels"</span>, <span 
class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, 
<span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time 
datetime="1997-03">March 1997</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc2119";>https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>.
 </dd>
-<dd class="break"></dd>
 <dt id="RFC3629">[RFC3629]</dt>
 <dd>
 <span class="refAuthor">Yergeau, F.</span>, <span class="refTitle">"UTF-8, a 
transformation format of ISO 10646"</span>, <span class="seriesInfo">STD 
63</span>, <span class="seriesInfo">RFC 3629</span>, <span 
class="seriesInfo">DOI 10.17487/RFC3629</span>, <time 
datetime="2003-11">November 2003</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc3629";>https://www.rfc-editor.org/info/rfc3629</a>&gt;</span>.
 </dd>
-<dd class="break"></dd>
 <dt id="RFC3826">[RFC3826]</dt>
 <dd>
 <span class="refAuthor">Blumenthal, U.</span><span class="refAuthor">, Maino, 
F.</span><span class="refAuthor">, and K. McCloghrie</span>, <span 
class="refTitle">"The Advanced Encryption Standard (AES) Cipher Algorithm in 
the SNMP User-based Security Model"</span>, <span class="seriesInfo">RFC 
3826</span>, <span class="seriesInfo">DOI 10.17487/RFC3826</span>, <time 
datetime="2004-06">June 2004</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc3826";>https://www.rfc-editor.org/ [...]
-<dd class="break"></dd>
 <dt id="RFC5869">[RFC5869]</dt>
 <dd>
 <span class="refAuthor">Krawczyk, H.</span><span class="refAuthor"> and P. 
Eronen</span>, <span class="refTitle">"HMAC-based Extract-and-Expand Key 
Derivation Function (HKDF)"</span>, <span class="seriesInfo">RFC 5869</span>, 
<span class="seriesInfo">DOI 10.17487/RFC5869</span>, <time 
datetime="2010-05">May 2010</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc5869";>https://www.rfc-editor.org/info/rfc5869</a>&gt;</span>.
 </dd>
-<dd class="break"></dd>
 <dt id="RFC5890">[RFC5890]</dt>
 <dd>
 <span class="refAuthor">Klensin, J.</span>, <span 
class="refTitle">"Internationalized Domain Names for Applications (IDNA): 
Definitions and Document Framework"</span>, <span class="seriesInfo">RFC 
5890</span>, <span class="seriesInfo">DOI 10.17487/RFC5890</span>, <time 
datetime="2010-08">August 2010</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc5890";>https://www.rfc-editor.org/info/rfc5890</a>&gt;</span>.
 </dd>
-<dd class="break"></dd>
 <dt id="RFC5891">[RFC5891]</dt>
 <dd>
 <span class="refAuthor">Klensin, J.</span>, <span 
class="refTitle">"Internationalized Domain Names in Applications (IDNA): 
Protocol"</span>, <span class="seriesInfo">RFC 5891</span>, <span 
class="seriesInfo">DOI 10.17487/RFC5891</span>, <time datetime="2010-08">August 
2010</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc5891";>https://www.rfc-editor.org/info/rfc5891</a>&gt;</span>.
 </dd>
-<dd class="break"></dd>
 <dt id="RFC6895">[RFC6895]</dt>
 <dd>
 <span class="refAuthor">Eastlake 3rd, D.</span>, <span 
class="refTitle">"Domain Name System (DNS) IANA Considerations"</span>, <span 
class="seriesInfo">BCP 42</span>, <span class="seriesInfo">RFC 6895</span>, 
<span class="seriesInfo">DOI 10.17487/RFC6895</span>, <time 
datetime="2013-04">April 2013</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc6895";>https://www.rfc-editor.org/info/rfc6895</a>&gt;</span>.
 </dd>
-<dd class="break"></dd>
 <dt id="RFC6979">[RFC6979]</dt>
 <dd>
 <span class="refAuthor">Pornin, T.</span>, <span 
class="refTitle">"Deterministic Usage of the Digital Signature Algorithm (DSA) 
and Elliptic Curve Digital Signature Algorithm (ECDSA)"</span>, <span 
class="seriesInfo">RFC 6979</span>, <span class="seriesInfo">DOI 
10.17487/RFC6979</span>, <time datetime="2013-08">August 2013</time>, 
<span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc6979";>https://www.rfc-editor.org/info/rfc6979</a>&gt;</span>.
 </dd>
-<dd class="break"></dd>
 <dt id="RFC7748">[RFC7748]</dt>
 <dd>
 <span class="refAuthor">Langley, A.</span><span class="refAuthor">, Hamburg, 
M.</span><span class="refAuthor">, and S. Turner</span>, <span 
class="refTitle">"Elliptic Curves for Security"</span>, <span 
class="seriesInfo">RFC 7748</span>, <span class="seriesInfo">DOI 
10.17487/RFC7748</span>, <time datetime="2016-01">January 2016</time>, 
<span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc7748";>https://www.rfc-editor.org/info/rfc7748</a>&gt;</span>.
 </dd>
-<dd class="break"></dd>
 <dt id="RFC8032">[RFC8032]</dt>
 <dd>
 <span class="refAuthor">Josefsson, S.</span><span class="refAuthor"> and I. 
Liusvaara</span>, <span class="refTitle">"Edwards-Curve Digital Signature 
Algorithm (EdDSA)"</span>, <span class="seriesInfo">RFC 8032</span>, <span 
class="seriesInfo">DOI 10.17487/RFC8032</span>, <time 
datetime="2017-01">January 2017</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc8032";>https://www.rfc-editor.org/info/rfc8032</a>&gt;</span>.
 </dd>
-<dd class="break"></dd>
 <dt id="RFC8126">[RFC8126]</dt>
 <dd>
 <span class="refAuthor">Cotton, M.</span><span class="refAuthor">, Leiba, 
B.</span><span class="refAuthor">, and T. Narten</span>, <span 
class="refTitle">"Guidelines for Writing an IANA Considerations Section in 
RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span 
class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 
10.17487/RFC8126</span>, <time datetime="2017-06">June 2017</time>, 
<span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc8126";>https://www.rfc-editor.org/ [...]
-<dd class="break"></dd>
 <dt id="TWOFISH">[TWOFISH]</dt>
 <dd>
 <span class="refAuthor">Schneier, B.</span>, <span class="refTitle">"The 
Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition"</span>, 
<time datetime="1999-03">March 1999</time>. </dd>
-<dd class="break"></dd>
+<dt id="GNS">[GNS]</dt>
+<dd>
+<span class="refAuthor">Wachs, M.</span><span class="refAuthor">, 
Schanzenbach, M.</span><span class="refAuthor">, and C. Grothoff</span>, <span 
class="refTitle">"A Censorship-Resistant, Privacy-Enhancing and Fully 
Decentralized Name System"</span>, <time datetime="2014">2014</time>, 
<span>&lt;<a 
href="https://doi.org/10.1007/978-3-319-12280-9_9";>https://doi.org/10.1007/978-3-319-12280-9_9</a>&gt;</span>.
 </dd>
 <dt id="Argon2">[Argon2]</dt>
 <dd>
 <span class="refAuthor">Biryukov, A.</span><span class="refAuthor">, Dinu, 
D.</span><span class="refAuthor">, Khovratovich, D.</span><span 
class="refAuthor">, and S. Josefsson</span>, <span class="refTitle">"The 
memory-hard Argon2 password hash and proof-of-work function"</span>, <time 
datetime="2020-03">March 2020</time>, <span>&lt;<a 
href="https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/";>https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/</a>&gt;</span>.
 </dd>
-<dd class="break"></dd>
 </dl>
 </section>
 <div id="authors-addresses">
@@ -3084,7 +2960,8 @@ bEclYC3aE2+fjSDDfRpdnv3gGHMckMceVbgymHZDlfA=
         <div dir="auto" class="left"><span class="fn nameRole">Christian 
Grothoff</span></div>
 <div dir="auto" class="left"><span class="org">Berner 
Fachhochschule</span></div>
 <div dir="auto" class="left"><span class="street-address">Hoeheweg 
80</span></div>
-<div dir="auto" class="left">CH-<span class="postal-code">2501</span> <span 
class="locality">Biel/Bienne</span>
+<div dir="auto" class="left">
+<span class="postal-code">2501</span> <span class="locality">Biel/Bienne</span>
 </div>
 <div dir="auto" class="left"><span 
class="country-name">Switzerland</span></div>
 <div class="email">
@@ -3107,13 +2984,45 @@ bEclYC3aE2+fjSDDfRpdnv3gGHMckMceVbgymHZDlfA=
 </address>
 </section>
 </div>
-<script>const toc = document.getElementById("toc");
-toc.querySelector("h2").addEventListener("click", e => {
-  toc.classList.toggle("active");
-});
-toc.querySelector("nav").addEventListener("click", e => {
-  toc.classList.remove("active");
+<script>var toc = document.getElementById("toc");
+var tocToggle = toc.querySelector("h2");
+var tocNav = toc.querySelector("nav");
+
+// mobile menu toggle
+tocToggle.onclick = function(event) {
+    if (window.innerWidth < 1024) {
+ var tocNavDisplay = tocNav.currentStyle ? tocNav.currentStyle.display : 
getComputedStyle(tocNav, null).display;
+ if (tocNavDisplay == "none") {
+     tocNav.style.display = "block";
+ } else {
+     tocNav.style.display = "none";
+ }
+    }
+}
+
+// toc anchor scroll to anchor
+tocNav.addEventListener("click", function (event) {
+    event.preventDefault();
+    if (event.target.nodeName == 'A') {
+ if (window.innerWidth < 1024) {
+     tocNav.style.display = "none";
+ }
+ var href = event.target.getAttribute("href");
+ var anchorId = href.substr(1);
+ var anchor =  document.getElementById(anchorId);
+ anchor.scrollIntoView(true);
+ window.history.pushState("","",href);
+    }
 });
+
+// switch toc mode when window resized
+window.onresize = function () {
+    if (window.innerWidth < 1024) {
+ tocNav.style.display = "none";
+    } else {
+ tocNav.style.display = "block";
+    }
+}
 </script>
 </body>
 </html>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index 782d5c3..9557480 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -82,9 +82,9 @@ Table of Contents
        6.2.2.  GNS2DNS . . . . . . . . . . . . . . . . . . . . . . .  17
        6.2.3.  CNAME . . . . . . . . . . . . . . . . . . . . . . . .  18
        6.2.4.  BOX . . . . . . . . . . . . . . . . . . . . . . . . .  18
-       6.2.5.  VPN . . . . . . . . . . . . . . . . . . . . . . . . .  19
+       6.2.5.  VPN . . . . . . . . . . . . . . . . . . . . . . . . .  18
        6.2.6.  NICK  . . . . . . . . . . . . . . . . . . . . . . . .  19
-   7.  Zone Revocation . . . . . . . . . . . . . . . . . . . . . . .  20
+   7.  Zone Revocation . . . . . . . . . . . . . . . . . . . . . . .  19
      7.1.  Verification  . . . . . . . . . . . . . . . . . . . . . .  23
    8.  Determining the Root Zone and Zone Governance . . . . . . . .  24
    9.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
@@ -126,7 +126,7 @@ Internet-Draft             The GNU Name System             
November 2019
    Infrastructures, in particular X.509 for the Web.
 
    This document contains the GNU Name System (GNS) technical
-   specification of the GNU Name System (GNS), a fully decentralized and
+   specification of the GNU Name System [GNS], a fully decentralized and
    censorship-resistant name system.  GNS provides a privacy-enhancing
    alternative to the Domain Name System (DNS).  The design of GNS
    incorporates the capability to integrate and coexist with DNS.  GNS
@@ -214,10 +214,10 @@ Internet-Draft             The GNU Name System            
 November 2019
    DATA SIZE  denotes the 32-bit size of the DATA field in bytes and in
       network byte order.
 
-
-
-
-
+   TYPE  is the 32-bit resource record type.  This type can be one of
+      the GNS resource records as defined in Section 3 or a DNS record
+      type as defined in [RFC1035] or any of the complementary
+      standardized DNS resource record types.  This value must be stored
 
 
 
@@ -226,10 +226,6 @@ Schanzenbach, et al.       Expires 13 May 2020             
     [Page 4]
 Internet-Draft             The GNU Name System             November 2019
 
 
-   TYPE  is the 32-bit resource record type.  This type can be one of
-      the GNS resource records as defined in Section 3 or a DNS record
-      type as defined in [RFC1035] or any of the complementary
-      standardized DNS resource record types.  This value must be stored
       in network byte order.  Note that values below 2^16 are reserved
       for allocation via IANA ([RFC6895]).
 
@@ -272,7 +268,11 @@ Internet-Draft             The GNU Name System             
November 2019
       should only be encountered by a resolver for records obtained from
       the DHT.
 
-
+   PRIVATE  This is a private record of this peer and it should thus not
+      be published in the DHT.  Thus, this flag should never be
+      encountered by a resolver for records obtained from the DHT.
+      Private records should still be considered just like regular
+      records when resolving labels in local zones.
 
 
 
@@ -282,12 +282,6 @@ Schanzenbach, et al.       Expires 13 May 2020             
     [Page 5]
 Internet-Draft             The GNU Name System             November 2019
 
 
-   PRIVATE  This is a private record of this peer and it should thus not
-      be published in the DHT.  Thus, this flag should never be
-      encountered by a resolver for records obtained from the DHT.
-      Private records should still be considered just like regular
-      records when resolving labels in local zones.
-
 3.1.  Record Types
 
    A registry of GNS Record Types is described in Section 10.  The
@@ -333,6 +327,12 @@ Internet-Draft             The GNU Name System             
November 2019
 
 
 
+
+
+
+
+
+
 Schanzenbach, et al.       Expires 13 May 2020                  [Page 6]
 
 Internet-Draft             The GNU Name System             November 2019
@@ -938,22 +938,6 @@ Internet-Draft             The GNU Name System             
November 2019
    resolution fails and an emtpy record set is returned as the record
    set is invalid.
 
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 17]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
    Once the IP addresses of the DNS servers have been determined, the
    DNS name from the GNS2DNS record is appended to the remainder of the
    name to be resolved, and resolved by querying the DNS name server(s).
@@ -962,6 +946,14 @@ Internet-Draft             The GNU Name System             
November 2019
    delegate this to the authoritative DNS servers.  The first successful
    recursive name resolution result is returned to the client.  In
    addition, the resolver returns the queried DNS name as a supplemental
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 17]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    LEHO record (Section 3.4) with a relative expiration time of one
    hour.
 
@@ -1001,15 +993,6 @@ Internet-Draft             The GNU Name System            
 November 2019
    do not require a separate network request, and TLSA records become
    inseparable from the corresponding address records.
 
-
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 18]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
 6.2.5.  VPN
 
    At the end of the recursion, if the queried record type is either A
@@ -1019,6 +1002,14 @@ Internet-Draft             The GNU Name System           
  November 2019
    contents of the VPN record data.  The VPN record MUST be returned if
    the resolver implementation does not support setting up a tunnnel.
 
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 18]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
 6.2.6.  NICK
 
    NIICK records are only relevant to the recursive resolver if the
@@ -1053,19 +1044,6 @@ Internet-Draft             The GNU Name System           
  November 2019
 
                                  Figure 14
 
-
-
-
-
-
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 19]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
    In this case, the NICK record is marked as supplemental.  This means
    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
@@ -1080,6 +1058,14 @@ Internet-Draft             The GNU Name System           
  November 2019
    key has been revoked.  If the zone key was revoked, the resolution
    MUST fail with an empty result set.
 
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 19]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    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
@@ -1115,13 +1101,6 @@ Internet-Draft             The GNU Name System           
  November 2019
               |                                               |
               +-----+-----+-----+-----+-----+-----+-----+-----+
 
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 20]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
                                  Figure 15
 
    where:
@@ -1134,6 +1113,15 @@ Internet-Draft             The GNU Name System           
  November 2019
 
    PUBLIC KEY  A 512-bit ECDSA deterministic signature compliant with
       [RFC6979] over the public zone zk of the zone which is revoked and
+
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 20]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
       corresponds to the key used in the PoW.  The signature is created
       using the private zone key "d" (see Section 2).
 
@@ -1169,6 +1157,18 @@ Internet-Draft             The GNU Name System           
  November 2019
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -1223,8 +1223,8 @@ Internet-Draft             The GNU Name System            
 November 2019
    POW_i  The values calculated as part of the PoW.  Each POW_i MUST be
       unique in the set of POW values.
 
-
-
+   SIGNATURE  A 512-bit ECDSA deterministic signature compliant with
+      [RFC6979] over the public zone zk of the zone which is revoked and
 
 
 
@@ -1234,8 +1234,6 @@ Schanzenbach, et al.       Expires 13 May 2020            
     [Page 22]
 Internet-Draft             The GNU Name System             November 2019
 
 
-   SIGNATURE  A 512-bit ECDSA deterministic signature compliant with
-      [RFC6979] over the public zone zk of the zone which is revoked and
       corresponds to the key used in the PoW.  The signature is created
       using the private zone key "d" (see Section 2).
 
@@ -1285,6 +1283,8 @@ Internet-Draft             The GNU Name System            
 November 2019
 
 
 
+
+
 Schanzenbach, et al.       Expires 13 May 2020                 [Page 23]
 
 Internet-Draft             The GNU Name System             November 2019
@@ -1611,13 +1611,13 @@ Internet-Draft             The GNU Name System          
   November 2019
    [TWOFISH]  Schneier, B., "The Twofish Encryptions Algorithm: A
               128-Bit Block Cipher, 1st Edition", March 1999.
 
+   [GNS]      Wachs, M., Schanzenbach, M., and C. Grothoff, "A
+              Censorship-Resistant, Privacy-Enhancing and Fully
+              Decentralized Name System", 2014,
+              <https://doi.org/10.1007/978-3-319-12280-9_9>.
+
    [Argon2]   Biryukov, A., Dinu, D., Khovratovich, D., and S.
               Josefsson, "The memory-hard Argon2 password hash and
-              proof-of-work function", March 2020,
-              <https://datatracker.ietf.org/doc/draft-irtf-cfrg-
-              argon2/>.
-
-
 
 
 
@@ -1626,6 +1626,10 @@ Schanzenbach, et al.       Expires 13 May 2020           
      [Page 29]
 Internet-Draft             The GNU Name System             November 2019
 
 
+              proof-of-work function", March 2020,
+              <https://datatracker.ietf.org/doc/draft-irtf-cfrg-
+              argon2/>.
+
 Authors' Addresses
 
    Martin Schanzenbach
@@ -1669,10 +1673,6 @@ Authors' Addresses
 
 
 
-
-
-
-
 
 
 
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index c368e5e..16bb1bf 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -101,7 +101,7 @@
      </t>
      <t>
        This document contains the GNU Name System (GNS) technical specification
-       of the GNU Name System (GNS), a fully decentralized and 
censorship-resistant
+       of the GNU Name System <xref target="GNS" />, a fully decentralized and 
censorship-resistant
        name system. GNS provides a privacy-enhancing alternative to the Domain
        Name System (DNS). The design of GNS incorporates the capability to
        integrate and coexist with DNS. GNS is based on the principle of a 
petname
@@ -1611,6 +1611,25 @@ bEclYC3aE2+fjSDDfRpdnv3gGHMckMceVbgymHZDlfA=
            <date year="1999" month="March"/>
          </front>
        </reference>
+       <reference anchor="GNS" 
target="https://doi.org/10.1007/978-3-319-12280-9_9";>
+         <front>
+           <title>A Censorship-Resistant, Privacy-Enhancing and Fully 
Decentralized Name System</title>
+          <author initials="M." surname="Wachs" fullname="Matthias Wachs">
+            <organization>Technische Universität München</organization>
+          </author>
+
+          <author initials="M." surname="Schanzenbach" fullname="Martin 
Schanzenbach">
+            <organization>Technische Universität München</organization>
+          </author>
+
+          <author initials="C." surname="Grothoff"
+            fullname="Christian Grothoff">
+          <organization>Technische Universität München</organization>
+          </author>
+           <date year="2014"/>
+         </front>
+       </reference>
+
        <reference anchor="Argon2" 
target="https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/";>
          <front>
            <title>The memory-hard Argon2 password hash and proof-of-work 
function</title>

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



reply via email to

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