1 files changed, 210 insertions, 210 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 7b88e35..5dd9bd2 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -1143,225 +1143,225 @@ Connectivity | |Underlay|  |Underlay|
             Applications can and should define their own block types.
             The block type determines the format and handling of the block
             payload by nodes in PUT and RESULT messages.
-              Block types MUST be registered with GANA <xref target="gana"/>.
+            Block types MUST be registered with GANA <xref target="gana"/>.
+          </t>
+          <t>
+            For bootstrapping and node discovery, the DHT implementation uses
+            its own block type called "HELLO". A block with this block type
+            contains the NodeID of the node initiating the GET request.
+          </t>
+          <section anchor="hello_block">
+            <name>HELLO</name>
+            <t>
+              The HELLO block type wire format is illustrated in
+              <xref target="figure_hello"/>. A query for block of type HELLO MUST
+              NOT include extended query data (XQuery). Any implementation
+              encountering a HELLO block with XQuery data MUST consider the
+              block invalid and ignore it.
+            </t>
+            <figure anchor="figure_hello">
+              <artwork name="" type="" align="left" alt=""><![CDATA[
+0   8     16    24    32    40    48    56
++---+-----+-----+-----+-----+-----+-----+-----+
+| TYPE    |   SIZE    |         NODEID        /
++---+-----+-----+-----+   (variable length)   /
+/                                             /
++---+-----+-----+-----+-----+-----+-----+-----+
+|                 ADDRESSES                   /
+/             (variable length)               |
++---+-----+-----+-----+-----+-----+-----+-----+
+]]/artwork>
+            </figure>
+            <dl>
+              <dt>TYPE</dt>
+              <dd>
+                is the type of HELLO. A 16-bit number in network byte order.
+                This value determines the type of the NODEID field.
+              </dd>
+              <dt>SIZE</dt>
+              <dd>
+                is the SIZE of the following fields NODEID and ADDRESSES in bytes.
+                In network byte order.
+              </dd>
+              <dt>NODEID</dt>
+              <dd>
+                is the Node ID of the node which has generated this HELLO.
+                The length content of this field is determined by the TYPE.
+                Usually, this is a cryptographic public key which allows the
+                Underlay to uniquely identify and authenticate the node.
+              </dd>
+              <dt>ADDRESSES</dt>
+              <dd>
+                is a list of UTF-8 strings <xref target="RFC3629"/> which can be
+                used as addresses to contact the node.
+                The strings MUST be 0-terminated.
+                FIXME: Examples? Format determined?
+              </dd>
+            </dl>
+            <t>
+              A HELLO reply block MAY be empty. Otherwise, it contains the
+              HELLO of a node.
             </t>
             <t>
-              For bootstrapping and node discovery, the DHT implementation uses
-              its own block type called "HELLO". A block with this block type
-              contains the NodeID of the node initiating the GET request.
+              For the string representation of the node public key,
+              the base-32 encoding "StringEncode" is used.
+              However, instead of following <xref target="RFC4648"/> the
+              character map is based on the optical character recognition friendly
+              proposal of Crockford <xref target="CrockfordB32"/>.
+              The only difference to Crockford is that the letter
+              "U" decodes to the same base-32 value as the letter "V" (27).
             </t>
-            <section anchor="hello_block">
-              <name>HELLO</name>
-              <t>
-                The HELLO block type wire format is illustrated in
-                <xref target="figure_hello"/>. A query for block of type HELLO MUST
-                NOT include extended query data (XQuery). Any implementation
-                encountering a HELLO block with XQuery data MUST consider the
-                block invalid and ignore it.
-              </t>
-              <figure anchor="figure_hello">
-                <artwork name="" type="" align="left" alt=""><![CDATA[
-0     8     16    24    32    40    48    56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|   TYPE    |   SIZE    |         NODEID        /
-+-----+-----+-----+-----+   (variable length)   /
-/                                               /
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|                   ADDRESSES                   /
-/               (variable length)               |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-]]></artwork>
-              </figure>
-              <dl>
-                <dt>TYPE</dt>
-                <dd>
-                  is the type of HELLO. A 16-bit number in network byte order.
-                  This value determines the type of the NODEID field.
-                </dd>
-                <dt>SIZE</dt>
-                <dd>
-                  is the SIZE of the following fields NODEID and ADDRESSES in bytes.
-                  In network byte order.
-                </dd>
-                <dt>NODEID</dt>
-                <dd>
-                  is the Node ID of the node which has generated this HELLO.
-                  The length content of this field is determined by the TYPE.
-                  Usually, this is a cryptographic public key which allows the
-                  Underlay to uniquely identify and authenticate the node.
-                </dd>
-                <dt>ADDRESSES</dt>
-                <dd>
-                  is a list of UTF-8 strings <xref target="RFC3629"/> which can be
-                  used as addresses to contact the node.
-                  The strings MUST be 0-terminated.
-                  FIXME: Examples? Format determined?
-                </dd>
-              </dl>
-              <t>
-                A HELLO reply block MAY be empty. Otherwise, it contains the
-                HELLO of a node.
-              </t>
-              <t>
-                For the string representation of the node public key,
-                the base-32 encoding "StringEncode" is used.
-                However, instead of following <xref target="RFC4648"/> the
-                character map is based on the optical character recognition friendly
-                proposal of Crockford <xref target="CrockfordB32"/>.
-                The only difference to Crockford is that the letter
-                "U" decodes to the same base-32 value as the letter "V" (27).
-              </t>
-              <t>
-                The <tt>ADDRESSES</tt> part of the <tt>HELLO</tt> indicate endpoints
-                which can be used by the Underlay in order to establish a connection
-                with the node identified by <tt>NODEKEY</tt>.
-                An example of an addressing scheme used throughout
-                this document is "ip+tcp", which refers to a standard TCP/IP socket
-                connection. The "hier"-part of the URI must provide a suitable
-                address for the given addressing scheme.
-                The following is a non-normative example of address strings:
-              </t>
-              <figure>
-                <artwork name="" type="" align="left" alt=""><![CDATA[
-ip+tcp://1.2.3.4:6789 \
-gnunet+tcp://12.3.4.5/ \
-i2p+udp://1.2.4.5:424/ \
-tor+onionv3://rasdflkjasdfliasduf.onion/
-]]></artwork>
-              </figure>
-            </section>
+            <t>
+              The <tt>ADDRESSES</tt> part of the <tt>HELLO</tt> indicate endpoints
+              which can be used by the Underlay in order to establish a connection
+              with the node identified by <tt>NODEKEY</tt>.
+              An example of an addressing scheme used throughout
+              this document is "ip+tcp", which refers to a standard TCP/IP socket
+              connection. The "hier"-part of the URI must provide a suitable
+              address for the given addressing scheme.
+              The following is a non-normative example of address strings:
+            </t>
+            <figure>
+              <artwork name="" type="" align="left" alt=""><![CDATA[
+ipcp://1.2.3.4:6789 \
+gnet+tcp://12.3.4.5/ \
+i2udp://1.2.4.5:424/ \
+toonionv3://rasdflkjasdfliasduf.onion/
+]]/artwork>
+            </figure>
           </section>
         </section>
-        <section anchor="security" numbered="true" toc="default">
-          <name>Security Considerations</name>
-          <!-- FIXME: Here we should (again) discuss how the system is open and
-            does not have/require a trust anchor a priori. This is (again) in contrast
-          to RELOAD -->
-        </section>
-        <section anchor="gana" numbered="true" toc="default">
-          <name>GANA Considerations</name>
-          <t>
-            GANA <xref target="GANA"/>
-            is requested to create a "DHT Block Types" registry.
-            The registry shall record for each entry:
-          </t>
-          <ul>
-            <li>Name: The name of the block type (case-insensitive ASCII
-              string, restricted to alphanumeric characters</li>
-            <li>Number: 32-bit</li>
-            <li>Comment: Optionally, a brief English text describing the purpose of
-              the block type (in UTF-8)</li>
-            <li>Contact: Optionally, the contact information of a person to contact for
-              further information</li>
-            <li>References: Optionally, references describing the record type
-              (such as an RFC)</li>
-          </ul>
-          <t>
-            The registration policy for this sub-registry is "First Come First
-            Served", as described in <xref target="RFC8126"/>.
-            GANA is requested to populate this registry as follows:
-          </t>
-          <figure anchor="figure_btypenums">
-            <artwork name="" type="" align="left" alt=""><![CDATA[
-Number | Name   | Contact | References | Description
--------+--------+---------+------------+-------------------------
-0       ANY      N/A       [This.I-D]   Reserved
-7       HELLO    N/A       [This.I-D]   Type of a block that contains
-a HELLO for a node
-11      GNS      N/A       GNS          Block for storing record data
-]]></artwork>
-          </figure>
-          <t>
-            GANA is requested to amend the "GNUnet Signature Purpose" registry
-            as follows:
-          </t>
-          <figure anchor="figure_purposenums">
-            <artwork name="" type="" align="left" alt=""><![CDATA[
-Purpose | Name            | References | Description
---------+-----------------+------------+--------------------------
-]]></artwork>
-          </figure>
-        </section>
-        <!-- gana -->
-        <section>
-          <name>Test Vectors</name>
-        </section>
-      </middle>
-      <back>
-        <references><name>Normative References</name>
+      </section>
+      <section anchor="security" numbered="true" toc="default">
+        <name>Security Considerations</name>
+        <!-- FIXME: Here we should (again) discuss how the system is open and
+          does not have/require a trust anchor a priori. This is (again) in contrast
+        to RELOAD -->
+      </section>
+      <section anchor="gana" numbered="true" toc="default">
+        <name>GANA Considerations</name>
+        <t>
+          GANA <xref target="GANA"/>
+          is requested to create a "DHT Block Types" registry.
+          The registry shall record for each entry:
+        </t>
+        <ul>
+          <li>Name: The name of the block type (case-insensitive ASCII
+            string, restricted to alphanumeric characters</li>
+          <li>Number: 32-bit</li>
+          <li>Comment: Optionally, a brief English text describing the purpose of
+            the block type (in UTF-8)</li>
+          <li>Contact: Optionally, the contact information of a person to contact for
+            further information</li>
+          <li>References: Optionally, references describing the record type
+            (such as an RFC)</li>
+        </ul>
+        <t>
+          The registration policy for this sub-registry is "First Come First
+          Served", as described in <xref target="RFC8126"/>.
+          GANA is requested to populate this registry as follows:
+        </t>
+        <figure anchor="figure_btypenums">
+          <artwork name="" type="" align="left" alt=""><![CDATA[
+Nuer | Name   | Contact | References | Description
+-----+--------+---------+------------+-------------------------
+0     ANY      N/A       [This.I-D]   Reserved
+7     HELLO    N/A       [This.I-D]   Type of a block that contains
+a LLO for a node
+11    GNS      N/A       GNS          Block for storing record data
+]]/artwork>
+        </figure>
+        <t>
+          GANA is requested to amend the "GNUnet Signature Purpose" registry
+          as follows:
+        </t>
+        <figure anchor="figure_purposenums">
+          <artwork name="" type="" align="left" alt=""><![CDATA[
+Puose | Name            | References | Description
+------+-----------------+------------+--------------------------
+]]/artwork>
+        </figure>
+      </section>
+      <!-- gana -->
+      <section>
+        <name>Test Vectors</name>
+      </section>
+    </middle>
+    <back>
+      <references><name>Normative References</name>
 
-            &RFC2119;
-            &RFC3629;
-            &RFC4634;
-            &RFC4648;
-            &RFC6940;
-            &RFC8126;
-            &RFC8174;
+          &RFC2119;
+          &RFC3629;
+          &RFC4634;
+          &RFC4648;
+          &RFC6940;
+          &RFC8126;
+          &RFC8174;
 
-          <reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9"><front><title>High-Speed High-Security Signatures</title><author initials="D." surname="Bernstein" fullname="Daniel Bernstein"><organization>University of Illinois at Chicago</organization></author><author initials="N." surname="Duif" fullname="Niels Duif"><organization>Technische Universiteit Eindhoven</organization></author><author initials="T." surname="Lange" fullname="Tanja Lange"><organization>Technische Universiteit Eindhoven</organization></author><author initials="P." surname="Schwabe" fullname="Peter Schwabe"><organization>National Taiwan University</organization></author><author initials="B." surname="Yang" fullname="Bo-Yin Yang"><organization>Academia Sinica</organization></author><date year="2011"/></front></reference>
+        <reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9"><front><title>High-Speed High-Security Signatures</title><author initials="D." surname="Bernstein" fullname="Daniel Bernstein"><organization>University of Illinois at Chicago</organization></author><author initials="N." surname="Duif" fullname="Niels Duif"><organization>Technische Universiteit Eindhoven</organization></author><author initials="T." surname="Lange" fullname="Tanja Lange"><organization>Technische Universiteit Eindhoven</organization></author><author initials="P." surname="Schwabe" fullname="Peter Schwabe"><organization>National Taiwan University</organization></author><author initials="B." surname="Yang" fullname="Bo-Yin Yang"><organization>Academia Sinica</organization></author><date year="2011"/></front></reference>
 
-          <reference anchor="CrockfordB32" target="https://www.crockford.com/base32.html"><front><title>Base32</title><author initials="D." surname="Douglas" fullname="Crockford">
-          </author><date year="2019" month="March"/></front></reference>
+        <reference anchor="CrockfordB32" target="https://www.crockford.com/base32.html"><front><title>Base32</title><author initials="D." surname="Douglas" fullname="Crockford">
+        </author><date year="2019" month="March"/></front></reference>
 
-          <reference anchor="GANA" target="https://gana.gnunet.org/"><front><title>GNUnet Assigned Numbers Authority (GANA)</title><author><organization>GNUnet e.V.</organization></author><date month="April" year="2020"/></front></reference>
+        <reference anchor="GANA" target="https://gana.gnunet.org/"><front><title>GNUnet Assigned Numbers Authority (GANA)</title><author><organization>GNUnet e.V.</organization></author><date month="April" year="2020"/></front></reference>
 
 
 
-        </references>
-        <references>
-          <name>Informative References</name>
-          <reference anchor="R5N" target="https://doi.org/10.1109/ICNSS.2011.6060022">
-            <front>
-              <title>R5N: Randomized recursive routing for restricted-route networks</title>
-              <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
-                <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="2011"/>
-            </front>
-          </reference>
-          <reference anchor="Kademlia" target="http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf">
-            <front>
-              <title>Kademlia: A peer-to-peer information system based on the xor metric.</title>
-              <author initials="P." surname="Maymounkov" fullname="Petar Maymounkov">
-              </author>
-              <author initials="D." surname="Mazieres" fullname="David Mazieres">
-              </author>
-              <date year="2002"/>
-            </front>
-          </reference>
-          <reference anchor="cadet" target="https://doi.org/10.1109/MedHocNet.2014.6849107">
-            <front>
-              <title>CADET: Confidential ad-hoc decentralized end-to-end transport</title>
-              <author initials="B." surname="Polot" fullname="Bartlomiej Polot">
-                <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="I-D.draft-schanzen-gns" target="https://datatracker.ietf.org/doc/draft-schanzen-gns/">
-            <front>
-              <title>The GNU Name System</title>
-              <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach">
-                <organization>GNUnet e.V.</organization>
-              </author>
-              <author initials="C." surname="Grothoff" fullname="Christian Grothoff">
-                <organization>GNUnet e.V.</organization>
-              </author>
-              <author initials="B." surname="Fix" fullname="Bernd Fix">
-                <organization>GNUnet e.V.</organization>
-              </author>
-              <date year="2021"/>
-            </front>
-          </reference>
-        </references>
-        <!-- Change Log
-          v00 2017-07-23  MS   Initial version
-        -->
-      </back>
-    </rfc>
+      </references>
+      <references>
+        <name>Informative References</name>
+        <reference anchor="R5N" target="https://doi.org/10.1109/ICNSS.2011.6060022">
+          <front>
+            <title>R5N: Randomized recursive routing for restricted-route networks</title>
+            <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
+              <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="2011"/>
+          </front>
+        </reference>
+        <reference anchor="Kademlia" target="http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf">
+          <front>
+            <title>Kademlia: A peer-to-peer information system based on the xor metric.</title>
+            <author initials="P." surname="Maymounkov" fullname="Petar Maymounkov">
+            </author>
+            <author initials="D." surname="Mazieres" fullname="David Mazieres">
+            </author>
+            <date year="2002"/>
+          </front>
+        </reference>
+        <reference anchor="cadet" target="https://doi.org/10.1109/MedHocNet.2014.6849107">
+          <front>
+            <title>CADET: Confidential ad-hoc decentralized end-to-end transport</title>
+            <author initials="B." surname="Polot" fullname="Bartlomiej Polot">
+              <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="I-D.draft-schanzen-gns" target="https://datatracker.ietf.org/doc/draft-schanzen-gns/">
+          <front>
+            <title>The GNU Name System</title>
+            <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach">
+              <organization>GNUnet e.V.</organization>
+            </author>
+            <author initials="C." surname="Grothoff" fullname="Christian Grothoff">
+              <organization>GNUnet e.V.</organization>
+            </author>
+            <author initials="B." surname="Fix" fullname="Bernd Fix">
+              <organization>GNUnet e.V.</organization>
+            </author>
+            <date year="2021"/>
+          </front>
+        </reference>
+      </references>
+      <!-- Change Log
+        v00 2017-07-23  MS   Initial version
+      -->
+    </back>
+  </rfc>