summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMartin Schanzenbach <schanzen@gnunet.org>2022-12-25 23:45:56 +0900
committerMartin Schanzenbach <schanzen@gnunet.org>2022-12-25 23:45:56 +0900
commite0b7c4a66155163ef8005ea1bd9d5db594390ec9 (patch)
tree27cd5f11f13d3de2db0f7a9d5dadba94e49e9a37
parent811fe601faf9753db1dede2b8cf0d66bd0beafba (diff)
downloadlsd0004-e0b7c4a66155163ef8005ea1bd9d5db594390ec9.tar.gz
lsd0004-e0b7c4a66155163ef8005ea1bd9d5db594390ec9.zip
tt for HELLO
-rw-r--r--draft-schanzen-r5n.xml90
1 files changed, 45 insertions, 45 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 33eb456..e5b8218 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -223,13 +223,13 @@ gnunet+tcp://12.3.4.5/
223 </dd> 223 </dd>
224 <dt>HELLO block</dt> 224 <dt>HELLO block</dt>
225 <dd> 225 <dd>
226 A HELLO block is a block with a dedicated block type and is specified in this document. 226 A <tt>HELLO</tt> block is a block with a dedicated block type and is specified in this document.
227 The HELLO block is used to store and retrieve Peer addresses. 227 The <tt>HELLO</tt> block is used to store and retrieve Peer addresses.
228 In this document, HELLO blocks are used by the peer discovery mechanism. 228 In this document, <tt>HELLO</tt> blocks are used by the peer discovery mechanism.
229 </dd> 229 </dd>
230 <dt>HELLO URL</dt> 230 <dt>HELLO URL</dt>
231 <dd> 231 <dd>
232 HELLO URLs are URL-formatted HELLO blocks. 232 <tt>HELLO</tt> URLs are URL-formatted <tt>HELLO</tt> blocks.
233 They can used for out-of-band exchanges of peer information and are used for 233 They can used for out-of-band exchanges of peer information and are used for
234 address update signalling messages to neighbours. 234 address update signalling messages to neighbours.
235 </dd> 235 </dd>
@@ -523,7 +523,7 @@ Connectivity | |Underlay| |Underlay|
523 local peer and that henceforth the peer may be reachable under this address. 523 local peer and that henceforth the peer may be reachable under this address.
524 This information is used to advertise 524 This information is used to advertise
525 connectivity information about the local peer to other peers. 525 connectivity information about the local peer to other peers.
526 <tt>A</tt> must be a URI suitable for inclusion in a HELLO payload 526 <tt>A</tt> must be a URI suitable for inclusion in a <tt>HELLO</tt> payload
527 <xref target="hello_block"/>. 527 <xref target="hello_block"/>.
528 </dd> 528 </dd>
529 <dt> 529 <dt>
@@ -679,10 +679,10 @@ Connectivity | |Underlay| |Underlay|
679 Furthermore, the Underlay <bcp14>SHOULD</bcp14> provide the implementation with one or more 679 Furthermore, the Underlay <bcp14>SHOULD</bcp14> provide the implementation with one or more
680 addresses signalled through <tt>ADDRESS_ADDED</tt>. Zero addresses <bcp14>MAY</bcp14> be 680 addresses signalled through <tt>ADDRESS_ADDED</tt>. Zero addresses <bcp14>MAY</bcp14> be
681 provided if a peer can only establish outgoing connections and is otherwise unreachable. 681 provided if a peer can only establish outgoing connections and is otherwise unreachable.
682 <!-- FIXME: What about HelloMessages? What is the distinction between HELLO blocks 682 <!-- FIXME: What about HelloMessages? What is the distinction between <tt>HELLO</tt> blocks
683 and HELLO messages? --> 683 and <tt>HELLO</tt> messages? -->
684 The implementation periodically advertises all 684 The implementation periodically advertises all
685 active addresses in a HELLO block <xref target="hello_block"/>. 685 active addresses in a <tt>HELLO</tt> block <xref target="hello_block"/>.
686 </t> 686 </t>
687 </section> 687 </section>
688 <section anchor="routing_bloomfilter"> 688 <section anchor="routing_bloomfilter">
@@ -1227,7 +1227,7 @@ BEGIN
1227 it <bcp14>MAY</bcp14> disseminate those changes to neighbors using 1227 it <bcp14>MAY</bcp14> disseminate those changes to neighbors using
1228 <tt>HelloMessage</tt>s. 1228 <tt>HelloMessage</tt>s.
1229 <!-- FIXME yesyes this is blabla and obvious when reading the processing section. 1229 <!-- FIXME yesyes this is blabla and obvious when reading the processing section.
1230 In contrast to a HELLO block, a 1230 In contrast to a <tt>HELLO</tt> block, a
1231 <tt>HelloMessage</tt> does not contain the ID of 1231 <tt>HelloMessage</tt> does not contain the ID of
1232 the peer the address information is about: in a 1232 the peer the address information is about: in a
1233 <tt>HelloMessage</tt>, the address information is always 1233 <tt>HelloMessage</tt>, the address information is always
@@ -1244,7 +1244,7 @@ BEGIN
1244 a peer about the sender's available addresses. The 1244 a peer about the sender's available addresses. The
1245 recipients use these messages to inform their respective 1245 recipients use these messages to inform their respective
1246 Underlays about ways to sustain the connections and to 1246 Underlays about ways to sustain the connections and to
1247 generate HELLO blocks (see <xref target="hello_block"/>) 1247 generate <tt>HELLO</tt> blocks (see <xref target="hello_block"/>)
1248 to answer peer discovery queries 1248 to answer peer discovery queries
1249 from other peers. 1249 from other peers.
1250 </t> 1250 </t>
@@ -1287,14 +1287,14 @@ BEGIN
1287 is a 64 byte EdDSA signature using the sender's private 1287 is a 64 byte EdDSA signature using the sender's private
1288 key affirming the information contained in the message. 1288 key affirming the information contained in the message.
1289 The signature is signing exactly the same data that is being 1289 The signature is signing exactly the same data that is being
1290 signed in a HELLO block as described in <xref target="hello_block"/>. 1290 signed in a <tt>HELLO</tt> block as described in <xref target="hello_block"/>.
1291 </dd> 1291 </dd>
1292 <dt>EXPIRATION</dt> 1292 <dt>EXPIRATION</dt>
1293 <dd> 1293 <dd>
1294 denotes the absolute 64-bit expiration date of the content. 1294 denotes the absolute 64-bit expiration date of the content.
1295 The value specified is microseconds since midnight (0 hour), 1295 The value specified is microseconds since midnight (0 hour),
1296 January 1, 1970, but must be a multiple of one million 1296 January 1, 1970, but must be a multiple of one million
1297 (so that it can be represented in seconds in a HELLO URL). 1297 (so that it can be represented in seconds in a <tt>HELLO</tt> URL).
1298 Stored in network byte order. 1298 Stored in network byte order.
1299 </dd> 1299 </dd>
1300 <dt>ADDRESSES</dt> 1300 <dt>ADDRESSES</dt>
@@ -1323,9 +1323,9 @@ BEGIN
1323 is in the future. If the signature is invalid, the message is discarded. 1323 is in the future. If the signature is invalid, the message is discarded.
1324 </li> 1324 </li>
1325 <li> 1325 <li>
1326 The HELLO information is cached in the routing table until it expires, 1326 The <tt>HELLO</tt> information is cached in the routing table until it expires,
1327 the peer is removed from the routing table, or the information is replaced by another message from the peer. 1327 the peer is removed from the routing table, or the information is replaced by another message from the peer.
1328 <!-- FIXME same problem as for HELLO blocks: We do not need to TRY_CONNECT here because we already have 1328 <!-- FIXME same problem as for <tt>HELLO</tt> blocks: We do not need to TRY_CONNECT here because we already have
1329 a connection, obviously. But we may want to TRY_CONNECT on the new addresses? Adding for now --> 1329 a connection, obviously. But we may want to TRY_CONNECT on the new addresses? Adding for now -->
1330 The implementation <bcp14>MAY</bcp14> instruct the Underlay to connect to all now available addresses 1330 The implementation <bcp14>MAY</bcp14> instruct the Underlay to connect to all now available addresses
1331 using <tt>TRY_CONNECT</tt> in order to make the underlay aware of alternative addresses for this connection. 1331 using <tt>TRY_CONNECT</tt> in order to make the underlay aware of alternative addresses for this connection.
@@ -1553,12 +1553,12 @@ BEGIN
1553 be stored locally in the block storage. 1553 be stored locally in the block storage.
1554 </li> 1554 </li>
1555 <li> 1555 <li>
1556 If the <tt>BTYPE</tt> of the message indicates a HELLO block, the 1556 If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the
1557 peer <bcp14>MUST</bcp14> be considered for the local routing 1557 peer <bcp14>MUST</bcp14> be considered for the local routing
1558 table if the respective k-bucket is not yet full. In this case, 1558 table if the respective k-bucket is not yet full. In this case,
1559 the local peer <bcp14>MUST</bcp14> try to establish a connection 1559 the local peer <bcp14>MUST</bcp14> try to establish a connection
1560 to the peer indicated in the HELLO block using the address information 1560 to the peer indicated in the <tt>HELLO</tt> block using the address information
1561 from the HELLO block and the Underlay function <tt>TRY_CONNECT</tt>. 1561 from the <tt>HELLO</tt> block and the Underlay function <tt>TRY_CONNECT</tt>.
1562 <!-- FIXME: The above behaviour has a catch: If the implementation only connects to one 1562 <!-- FIXME: The above behaviour has a catch: If the implementation only connects to one
1563 address from the hello using TRY_CONNECT, the Underlay also knows only about that connection 1563 address from the hello using TRY_CONNECT, the Underlay also knows only about that connection
1564 If that failes and PEER_DISCONNECT is called, this neighbor is dead. 1564 If that failes and PEER_DISCONNECT is called, this neighbor is dead.
@@ -1755,11 +1755,11 @@ BEGIN
1755 </t> 1755 </t>
1756 <ol type="%c)"> 1756 <ol type="%c)">
1757 <!-- FIXME: It is not clear that this is a fallthrough statement --> 1757 <!-- FIXME: It is not clear that this is a fallthrough statement -->
1758 <!-- FIXME: Are HELLO blocks according to the spec stored in block storage but never looked for? --> 1758 <!-- FIXME: Are <tt>HELLO</tt> blocks according to the spec stored in block storage but never looked for? -->
1759 <li> 1759 <li>
1760 If <tt>BTYPE</tt> indicates a request for a HELLO block or 1760 If <tt>BTYPE</tt> indicates a request for a <tt>HELLO</tt> block or
1761 <tt>ANY</tt>, 1761 <tt>ANY</tt>,
1762 the peer <bcp14>MUST</bcp14> consult its own HELLO as well as 1762 the peer <bcp14>MUST</bcp14> consult its own <tt>HELLO</tt> as well as
1763 the HELLOs it has cached for the 1763 the HELLOs it has cached for the
1764 peers in its routing table instead of the local block 1764 peers in its routing table instead of the local block
1765 storage (while continuing to respect flags like 1765 storage (while continuing to respect flags like
@@ -1998,12 +1998,12 @@ BEGIN
1998 does not have to match the <tt>QUERY_HASH</tt>. 1998 does not have to match the <tt>QUERY_HASH</tt>.
1999 </li> 1999 </li>
2000 <li> 2000 <li>
2001 If the <tt>BTYPE</tt> of the message indicates a HELLO block, the 2001 If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the
2002 peer <bcp14>MUST</bcp14> be considered for the local routing 2002 peer <bcp14>MUST</bcp14> be considered for the local routing
2003 table if the respective k-bucket is not yet full. In this case, 2003 table if the respective k-bucket is not yet full. In this case,
2004 the local peer <bcp14>MUST</bcp14> try to establish a connection 2004 the local peer <bcp14>MUST</bcp14> try to establish a connection
2005 to the peer indicated in the HELLO block using the address information 2005 to the peer indicated in the <tt>HELLO</tt> block using the address information
2006 from the HELLO block. If a connection is established, 2006 from the <tt>HELLO</tt> block. If a connection is established,
2007 the peer is added to the respective k-bucket of the routing table. 2007 the peer is added to the respective k-bucket of the routing table.
2008 Note that the k-bucket <bcp14>MUST</bcp14> be determined by the 2008 Note that the k-bucket <bcp14>MUST</bcp14> be determined by the
2009 key computed using <tt>DeriveBlockKey</tt> and not by the <tt>QUERY_HASH</tt>. 2009 key computed using <tt>DeriveBlockKey</tt> and not by the <tt>QUERY_HASH</tt>.
@@ -2186,18 +2186,18 @@ BEGIN
2186 <name>HELLO Blocks</name> 2186 <name>HELLO Blocks</name>
2187 <t> 2187 <t>
2188 For bootstrapping and peer discovery, the DHT implementation uses 2188 For bootstrapping and peer discovery, the DHT implementation uses
2189 its own block type called "HELLO". HELLO blocks are the only type 2189 its own block type called "HELLO". <tt>HELLO</tt> blocks are the only type
2190 of block that <bcp14>MUST</bcp14> be supported by every 2190 of block that <bcp14>MUST</bcp14> be supported by every
2191 R<sup>5</sup>N implementation. A block with this block type 2191 R<sup>5</sup>N implementation. A block with this block type
2192 contains the peer ID of the peer that published the HELLO together 2192 contains the peer ID of the peer that published the <tt>HELLO</tt> together
2193 with a set of addresses of this peer. The key of a HELLO block 2193 with a set of addresses of this peer. The key of a <tt>HELLO</tt> block
2194 is the SHA-512 of the peer ID and thus the peer's address in the DHT. 2194 is the SHA-512 of the peer ID and thus the peer's address in the DHT.
2195 </t> 2195 </t>
2196 <t> 2196 <t>
2197 The HELLO block type wire format is illustrated in 2197 The <tt>HELLO</tt> block type wire format is illustrated in
2198 <xref target="figure_hello"/>. A query for block of type HELLO <bcp14>MUST NOT</bcp14> 2198 <xref target="figure_hello"/>. A query for block of type <tt>HELLO</tt> <bcp14>MUST NOT</bcp14>
2199 include extended query data (XQuery). Any implementation 2199 include extended query data (XQuery). Any implementation
2200 encountering a request for a HELLO with non-empty XQuery 2200 encountering a request for a <tt>HELLO</tt> with non-empty XQuery
2201 data <bcp14>MUST</bcp14> consider the request invalid and ignore it. 2201 data <bcp14>MUST</bcp14> consider the request invalid and ignore it.
2202 </t> 2202 </t>
2203 <figure anchor="figure_hello" title="The HELLO Block Format."> 2203 <figure anchor="figure_hello" title="The HELLO Block Format.">
@@ -2235,7 +2235,7 @@ BEGIN
2235 denotes the absolute 64-bit expiration date of the content. 2235 denotes the absolute 64-bit expiration date of the content.
2236 The value specified is microseconds since midnight (0 hour), 2236 The value specified is microseconds since midnight (0 hour),
2237 January 1, 1970, but must be a multiple of one million (so that it 2237 January 1, 1970, but must be a multiple of one million (so that it
2238 can be represented in seconds in a HELLO URL). 2238 can be represented in seconds in a <tt>HELLO</tt> URL).
2239 Stored in network byte order. 2239 Stored in network byte order.
2240 </dd> 2240 </dd>
2241 <dt>ADDRESSES</dt> 2241 <dt>ADDRESSES</dt>
@@ -2250,7 +2250,7 @@ BEGIN
2250 <t> 2250 <t>
2251 is the signature of the HELLO. 2251 is the signature of the HELLO.
2252 It covers a 64-bit pseudo header 2252 It covers a 64-bit pseudo header
2253 derived from the information in the HELLO block. 2253 derived from the information in the <tt>HELLO</tt> block.
2254 The pseudo header includes 2254 The pseudo header includes
2255 the expiration time, a constant that uniquely 2255 the expiration time, a constant that uniquely
2256 identifies the purpose of the signature, 2256 identifies the purpose of the signature,
@@ -2299,24 +2299,24 @@ BEGIN
2299 <dd> 2299 <dd>
2300 a SHA-512 hash over the addresses in the HELLO. 2300 a SHA-512 hash over the addresses in the HELLO.
2301 H_ADDRS is generated over the ADDRESSES field 2301 H_ADDRS is generated over the ADDRESSES field
2302 as provided in the HELLO block using SHA-512 <xref target="RFC4634"/>. 2302 as provided in the <tt>HELLO</tt> block using SHA-512 <xref target="RFC4634"/>.
2303 </dd> 2303 </dd>
2304 </dl> 2304 </dl>
2305 </dd> 2305 </dd>
2306 </dl> 2306 </dl>
2307 <t> 2307 <t>
2308 The HELLO block functions <bcp14>MUST</bcp14> be implemented 2308 The <tt>HELLO</tt> block functions <bcp14>MUST</bcp14> be implemented
2309 as follows: 2309 as follows:
2310 </t> 2310 </t>
2311 <dl> 2311 <dl>
2312 <dt>ValidateBlockQuery(Key, XQuery) 2312 <dt>ValidateBlockQuery(Key, XQuery)
2313 -&gt; RequestEvaluationResult</dt> 2313 -&gt; RequestEvaluationResult</dt>
2314 <dd> 2314 <dd>
2315 To validate a block query for a HELLO is to simply check that the XQuery is empty. If it is empty, REQUEST_VALID ist returned. Otherwise, REQUEST_INVALID. 2315 To validate a block query for a <tt>HELLO</tt> is to simply check that the XQuery is empty. If it is empty, REQUEST_VALID ist returned. Otherwise, REQUEST_INVALID.
2316 </dd> 2316 </dd>
2317 <dt>DeriveBlockKey(Block) -&gt; Key | NONE</dt> 2317 <dt>DeriveBlockKey(Block) -&gt; Key | NONE</dt>
2318 <dd> 2318 <dd>
2319 To derive a block key for a HELLO is to simply 2319 To derive a block key for a <tt>HELLO</tt> is to simply
2320 hash the peer ID from the HELLO. The result of this function 2320 hash the peer ID from the HELLO. The result of this function
2321 is always the SHA-512 hash over the PEER-ID. 2321 is always the SHA-512 hash over the PEER-ID.
2322 </dd> 2322 </dd>
@@ -2333,15 +2333,15 @@ BEGIN
2333 <dd> 2333 <dd>
2334 <t> 2334 <t>
2335 <!-- FIXME: I do not understand this. Isn't the element set E known 2335 <!-- FIXME: I do not understand this. Isn't the element set E known
2336 for HELLO blocks? Isn't it H_ADDRS XOR MUTATOR? --> 2336 for <tt>HELLO</tt> blocks? Isn't it H_ADDRS XOR MUTATOR? -->
2337 The RESULT_FILTER for HELLO blocks is implemented using a 2337 The RESULT_FILTER for <tt>HELLO</tt> blocks is implemented using a
2338 Bloom filter following the definition from <xref target="bloom_filters"/> 2338 Bloom filter following the definition from <xref target="bloom_filters"/>
2339 and consists of a variable number of buckets <tt>L</tt>. 2339 and consists of a variable number of buckets <tt>L</tt>.
2340 <tt>L</tt> depends on the number of elements <tt>|E|</tt> known to be filtered at the 2340 <tt>L</tt> depends on the number of elements <tt>|E|</tt> known to be filtered at the
2341 initiator. 2341 initiator.
2342 <!-- FIXME: Minimum space for used for what? There is no example given anywhere in the 2342 <!-- FIXME: Minimum space for used for what? There is no example given anywhere in the
2343 spec how this becomes relevant. Again, this is not some abstract block, 2343 spec how this becomes relevant. Again, this is not some abstract block,
2344 but specifically a HELLO (see above). --> 2344 but specifically a <tt>HELLO</tt> (see above). -->
2345 If <tt>|E|</tt> is zero, the size <tt>L</tt> is set to 32 bits to provide some minimum 2345 If <tt>|E|</tt> is zero, the size <tt>L</tt> is set to 32 bits to provide some minimum
2346 space (to be used by peers when forwarding the request after 2346 space (to be used by peers when forwarding the request after
2347 returning local results). 2347 returning local results).
@@ -2354,7 +2354,7 @@ BEGIN
2354 The elements used in the Bloom filter 2354 The elements used in the Bloom filter
2355 consist of an XOR between the <tt>H_ADDRS</tt> field (as computed using 2355 consist of an XOR between the <tt>H_ADDRS</tt> field (as computed using
2356 SHA-512 over the <tt>ADDRESSES</tt>) and the SHA-512 2356 SHA-512 over the <tt>ADDRESSES</tt>) and the SHA-512
2357 hash of the <tt>MUTATOR</tt> field from a given HELLO block. 2357 hash of the <tt>MUTATOR</tt> field from a given <tt>HELLO</tt> block.
2358 The mapping function M(<tt>H_ADDRS XOR MUTATOR</tt>) is defined as follows: 2358 The mapping function M(<tt>H_ADDRS XOR MUTATOR</tt>) is defined as follows:
2359 </t> 2359 </t>
2360 <t> 2360 <t>
@@ -2365,8 +2365,8 @@ BEGIN
2365 This resulting byte string is interpreted as k=16 32-bit 2365 This resulting byte string is interpreted as k=16 32-bit
2366 integers in network byte order which are used to set and check the bucket bits in 2366 integers in network byte order which are used to set and check the bucket bits in
2367 <tt>B</tt> using <tt>BF-SET</tt> and <tt>BF-TEST</tt>. 2367 <tt>B</tt> using <tt>BF-SET</tt> and <tt>BF-TEST</tt>.
2368 The 32-bit Mutator is prepended to the L-bit Bloom filter bucket field <tt>HELLO_BF</tt> containing <tt>B</tt> 2368 The 32-bit Mutator is prepended to the L-bit Bloom filter bucket field <tt>HELLO_BF</tt> containing <tt>B</tt>
2369 to create the result filter for a HELLO block: 2369 to create the result filter for a <tt>HELLO</tt> block:
2370 </t> 2370 </t>
2371 <figure anchor="hello_rf" title="The HELLO Block Result Filter."> 2371 <figure anchor="hello_rf" title="The HELLO Block Result Filter.">
2372 <artwork name="" type="" align="left" alt=""><![CDATA[ 2372 <artwork name="" type="" align="left" alt=""><![CDATA[
@@ -2409,7 +2409,7 @@ BEGIN
2409 false-positives. 2409 false-positives.
2410 </t> 2410 </t>
2411 <t> 2411 <t>
2412 HELLO result filters can be merged if the 2412 <tt>HELLO</tt> result filters can be merged if the
2413 Bloom filters have the same size and 2413 Bloom filters have the same size and
2414 <tt>MUTATOR</tt> by setting all bits to 1 that are 2414 <tt>MUTATOR</tt> by setting all bits to 1 that are
2415 set in either Bloom filter. This is done whenever 2415 set in either Bloom filter. This is done whenever
@@ -2420,7 +2420,7 @@ BEGIN
2420 <dt>FilterResult(Block, Key, RF, XQuery) -&gt; (FilterEvaluationResult, RF')</dt> 2420 <dt>FilterResult(Block, Key, RF, XQuery) -&gt; (FilterEvaluationResult, RF')</dt>
2421 <dd> 2421 <dd>
2422 The <tt>H_ADDRS</tt> field is XORed with the SHA-512 2422 The <tt>H_ADDRS</tt> field is XORed with the SHA-512
2423 hash of the <tt>MUTATOR</tt> field from the HELLO block and the resulting 2423 hash of the <tt>MUTATOR</tt> field from the <tt>HELLO</tt> block and the resulting
2424 value is checked against the Bloom filter in RF. 2424 value is checked against the Bloom filter in RF.
2425 Consequently, HELLOs with completely identical sets of 2425 Consequently, HELLOs with completely identical sets of
2426 addresses will be filtered and FILTER_DUPLICATE is returned. 2426 addresses will be filtered and FILTER_DUPLICATE is returned.
@@ -2997,7 +2997,7 @@ Type | Name | References | Description
2997 <section anchor="hello_url"> 2997 <section anchor="hello_url">
2998 <name>HELLO URLs</name> 2998 <name>HELLO URLs</name>
2999 <t> 2999 <t>
3000 The general format of a HELLO URL uses "gnunet://" 3000 The general format of a <tt>HELLO</tt> URL uses "gnunet://"
3001 as the scheme, followed by "hello/" for the name 3001 as the scheme, followed by "hello/" for the name
3002 of the GNUnet subsystem, followed by "/"-separated values 3002 of the GNUnet subsystem, followed by "/"-separated values
3003 with the GNS Base32 encoding (<xref target="I-D.schanzen-gns"/>) of 3003 with the GNS Base32 encoding (<xref target="I-D.schanzen-gns"/>) of
@@ -3038,7 +3038,7 @@ maybe generate proper test vector.
3038 DHT Underlay. 3038 DHT Underlay.
3039 </t> 3039 </t>
3040 <t> 3040 <t>
3041 The general syntax of HELLO URLs specified using 3041 The general syntax of <tt>HELLO</tt> URLs specified using
3042 Augmented Backus-Naur Form (ABNF) of <xref target="RFC5234"/> is: 3042 Augmented Backus-Naur Form (ABNF) of <xref target="RFC5234"/> is:
3043 </t> 3043 </t>
3044 <figure> 3044 <figure>