1 files changed, 97 insertions, 61 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 7216641..f71d413 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -199,6 +199,92 @@ Connectivity | |Underlay|  |Underlay|
        </dd>
      </dl>
    </section>
+   <section anchor="overlay" numbered="true" toc="default">
+     <name>Overlay</name>
+     <t>
+       In the DHT overlay, a peer is addressable by its Peer ID.
+       The Peer ID is the 256-bit hash of the peer public key.
+       The peer public key is the public key of the corresponding
+       Ed25519<xref target="ed25519" /> peer private key.
+     </t>
+     <t>
+       Any implementation of this specification MUST expose the two API
+       procedures "GET" and "PUT".
+     </t>
+     <section>
+       <name>The GET procedure</name>
+       <t>
+         The GET procedure is defined as follows:
+       </t>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+GET(key[, options]) -> RESULTS as List
+           or
+GET(key[, options], callbackFunction)
+         ]]></artwork>
+       <t>
+         The procedure takes two arguments. The first argument is the query
+         key and is mandatory. The GET procedure may also allow the caller
+         to specifiy query options.
+       </t>
+       <t>
+         The procedure either returns a list of results or allows the caller
+         to provide a callback function which is called for any result
+         received from the DHT until the procedure is cancelled.
+       </t>
+     </section>
+     <section>
+       <name>The PUT procedure</name>
+       <t>
+         The PUT procedure is defined as follows:
+       </t>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+PUT(key[, options], BLOCK)
+         ]]></artwork>
+       <t>
+         The procedure takes three arguments. The first argument is the query
+         key and is mandatory. The PUT procedure may also allow the caller
+         to specifiy put options. The third argument is the payload data which
+         is to be stored under the provided put key.
+       </t>
+     </section>
+   </section>
+   <section anchor="blockstorage" numbered="true" toc="default">
+     <name>Block Storage</name>
+     <section>
+       <name>Block Types</name>
+       <t>
+         Applications can and should define their own block types.
+         The block type determines the format and handling of the block
+         payload by peers in PUT and RESULT messages.
+         Block types MUST be registered with GANA <xref target="gana"/>.
+       </t>
+       <t>
+         For bootstrapping and peer discovery, the DHT implementation uses
+         its own block type called "HELLO". A block with this block type
+         contains the peer ID of the peer initiating the GET request.
+       </t>
+       <section>
+         <name>HELLO</name>
+         <t>
+           The HELLO block type wire format is illustrated in
+           <xref target="figure_hellobt"/>. A 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>
+         <t>
+           A HELLO reply block MAY be empty. Otherwise, it contains the
+           HELLO URI of a peer.
+         </t>
+         <figure anchor="figure_hellobt">
+           <artwork name="" type="" align="left" alt=""><![CDATA[
+         FIXME: Wire format
+         ]]></artwork>
+         </figure>
+       </section>
+     </section>
+   </section>
+
    <section anchor="underlay" numbered="true" toc="default">
      <name>Underlay</name>
      <t>
@@ -338,60 +424,6 @@ see how we can offer even the most minimal protections against peer
      </dl>
    </section>
 
-   <section anchor="overlay" numbered="true" toc="default">
-     <name>Overlay</name>
-     <t>
-       In the DHT overlay, a peer is addressable by its Peer ID.
-       The Peer ID is the 256-bit hash of the peer public key.
-       The peer public key is the public key of the corresponding
-       Ed25519<xref target="ed25519" /> peer private key.
-     </t>
-     <t>
-       Any implementation of this specification MUST expose the two API
-       procedures "GET" and "PUT".
-     </t>
-     <section>
-       <name>The GET procedure</name>
-       <t>
-         The GET procedure is defined as follows:
-       </t>
-         <artwork name="" type="" align="left" alt=""><![CDATA[
-GET(key[, options]) -> RESULTS as List
-           or
-GET(key[, options], callbackFunction)
-         ]]></artwork>
-       <t>
-         The procedure takes two arguments. The first argument is the query
-         key and is mandatory. The GET procedure may also allow the caller
-         to specifiy query options.
-       </t>
-       <t>
-         The procedure either returns a list of results or allows the caller
-         to provide a callback function which is called for any result
-         received from the DHT until the procedure is cancelled.
-       </t>
-     </section>
-     <section>
-       <name>The PUT procedure</name>
-       <t>
-         The PUT procedure is defined as follows:
-       </t>
-         <artwork name="" type="" align="left" alt=""><![CDATA[
-PUT(key[, options], PAYLOAD)
-         ]]></artwork>
-       <t>
-         The procedure takes three arguments. The first argument is the query
-         key and is mandatory. The PUT procedure may also allow the caller
-         to specifiy put options. The third argument is the payload data which
-         is to be stored under the provided put key.
-       </t>
-     </section>
-   </section>
-   <section anchor="blockstorage" numbered="true" toc="default">
-     <name>Block Storage</name>
-     <t>
-     </t>
-   </section>
    <section anchor="routing" numbered="true" toc="default">
      <name>Routing</name>
      <section anchor="peer_selection" numbered="true" toc="default">
@@ -532,7 +564,7 @@ END
 +-----+-----+-----+-----+-----+-----+-----+-----+
 /              PUTPATH (variable length)        /
 +-----+-----+-----+-----+-----+-----+-----+-----+
-/              PAYLOAD (variable length)        /
+/              BLOCK (variable length)        /
 +-----+-----+-----+-----+-----+-----+-----+-----+
          ]]></artwork>
      </figure>
@@ -593,11 +625,10 @@ END
          the variable-length PUT path.
          The path consists of a list of PATH_LEN peer IDs.
        </dd>
-       <dt>PAYLOAD</dt>
+       <dt>BLOCK</dt>
        <dd>
-         the variable-length resource record data payload. The contents are defined
-         by the
-         respective type of the resource record.
+         the variable-length block payload. The contents are determined
+         by the BTYPE field.
        </dd>
      </dl>
 
@@ -706,7 +737,7 @@ END
 /                    GETPATH                    /
 /                 (variable length)             /
 +-----+-----+-----+-----+-----+-----+-----+-----+
-/                   PAYLOAD                     /
+/                   BLOCK                       /
 /              (variable length)                /
 +-----+-----+-----+-----+-----+-----+-----+-----+
          ]]></artwork>
@@ -765,7 +796,7 @@ END
          the variable-length PUT path.
          The path consists of a list of PATH_LEN peer IDs.
        </dd>
-       <dt>PAYLOAD</dt>
+       <dt>BLOCK</dt>
        <dd>
          the variable-length resource record data payload.
          The contents are defined by the respective type of the resource record.
@@ -773,6 +804,11 @@ END
      </dl>
      </section>
    </section>
+   <section>
+     <name>Bootstrapping</name>
+     <t>
+     </t>
+   </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <!-- FIXME: Here we should (again) discuss how the system is open and