diff options
author | Martin Schanzenbach <schanzen@gnunet.org> | 2022-12-25 13:21:44 +0900 |
---|---|---|
committer | Martin Schanzenbach <schanzen@gnunet.org> | 2022-12-25 13:21:44 +0900 |
commit | f4899881724fd7d22524cfcc2eb62c9c8880a080 (patch) | |
tree | d619647b7c57a490a902b906c9fc78a6ca702cc3 | |
parent | 0c12e2863ba403bb365eb0049f17cf20b8bf4484 (diff) | |
download | lsd0004-f4899881724fd7d22524cfcc2eb62c9c8880a080.tar.gz lsd0004-f4899881724fd7d22524cfcc2eb62c9c8880a080.zip |
I have so many questions.
-rw-r--r-- | draft-schanzen-r5n.xml | 31 |
1 files changed, 30 insertions, 1 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml index 607171e..f195c5f 100644 --- a/draft-schanzen-r5n.xml +++ b/draft-schanzen-r5n.xml | |||
@@ -405,6 +405,7 @@ Connectivity | |Underlay| |Underlay| | |||
405 | API: | 405 | API: |
406 | </t> | 406 | </t> |
407 | <dl> | 407 | <dl> |
408 | <!-- FIXME: Not used anywhere in draft --> | ||
408 | <dt> | 409 | <dt> |
409 | <tt>TRY_CONNECT(N, A)</tt> | 410 | <tt>TRY_CONNECT(N, A)</tt> |
410 | </dt> | 411 | </dt> |
@@ -414,6 +415,7 @@ Connectivity | |Underlay| |Underlay| | |||
414 | When the connection attempt is successful, information on the new | 415 | When the connection attempt is successful, information on the new |
415 | peer is offered through the <tt>PEER_CONNECTED</tt> signal. | 416 | peer is offered through the <tt>PEER_CONNECTED</tt> signal. |
416 | </dd> | 417 | </dd> |
418 | <!-- FIXME: Not used anywhere in draft --> | ||
417 | <dt> | 419 | <dt> |
418 | <tt>HOLD(P)</tt> | 420 | <tt>HOLD(P)</tt> |
419 | </dt> | 421 | </dt> |
@@ -423,6 +425,7 @@ Connectivity | |Underlay| |Underlay| | |||
423 | of active connections. With this function the DHT can indicate to the | 425 | of active connections. With this function the DHT can indicate to the |
424 | underlay which connections should preferably be preserved. | 426 | underlay which connections should preferably be preserved. |
425 | </dd> | 427 | </dd> |
428 | <!-- FIXME: Not used anywhere in draft --> | ||
426 | <dt> | 429 | <dt> |
427 | <tt>DROP(P)</tt> | 430 | <tt>DROP(P)</tt> |
428 | </dt> | 431 | </dt> |
@@ -526,6 +529,8 @@ Connectivity | |Underlay| |Underlay| | |||
526 | While details on how the first connection is established <bcp14>MAY</bcp14> | 529 | While details on how the first connection is established <bcp14>MAY</bcp14> |
527 | depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done | 530 | depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done |
528 | by an out-of-band exchange of the information from a HELLO block. | 531 | by an out-of-band exchange of the information from a HELLO block. |
532 | <!-- FIXME: Is this really an encoding of a block? It seems to me that "HELLO" | ||
533 | is not properly defined. --> | ||
529 | For this, section <xref target="hello_url"/> specifies a URL format for encoding HELLO | 534 | For this, section <xref target="hello_url"/> specifies a URL format for encoding HELLO |
530 | blocks as text strings which <bcp14>SHOULD</bcp14> be supported by implementations. | 535 | blocks as text strings which <bcp14>SHOULD</bcp14> be supported by implementations. |
531 | </t> | 536 | </t> |
@@ -539,10 +544,14 @@ Connectivity | |Underlay| |Underlay| | |||
539 | Furthermore, the Underlay <bcp14>SHOULD</bcp14> provide the implementation with one or more | 544 | Furthermore, the Underlay <bcp14>SHOULD</bcp14> provide the implementation with one or more |
540 | addresses signalled through <tt>ADDRESS_ADDED</tt>. Zero addresses <bcp14>MAY</bcp14> be | 545 | addresses signalled through <tt>ADDRESS_ADDED</tt>. Zero addresses <bcp14>MAY</bcp14> be |
541 | provided if a peer can only establish outgoing connections and is otherwise unreachable. | 546 | provided if a peer can only establish outgoing connections and is otherwise unreachable. |
547 | <!-- FIXME: What about HelloMessages? What is the distinction between HELLO blocks | ||
548 | and HELLO messages? --> | ||
542 | The implementation periodically advertises all | 549 | The implementation periodically advertises all |
543 | active addresses in a HELLO block <xref target="hello_block"/>. | 550 | active addresses in a HELLO block <xref target="hello_block"/>. |
544 | </t> | 551 | </t> |
545 | <t> | 552 | <t> |
553 | <!-- FIXME: Maybe make this a SHOULD and explain what happens if the implementation | ||
554 | does not. We should allow a minimal implementation of the protocol. --> | ||
546 | In order to fill its routing table by finding close peers in the network, an | 555 | In order to fill its routing table by finding close peers in the network, an |
547 | implementation <bcp14>MUST</bcp14> now periodically send peer discovery messages | 556 | implementation <bcp14>MUST</bcp14> now periodically send peer discovery messages |
548 | <xref target="find_peer"/>. | 557 | <xref target="find_peer"/>. |
@@ -555,6 +564,9 @@ Connectivity | |Underlay| |Underlay| | |||
555 | the developer. | 564 | the developer. |
556 | </t> | 565 | </t> |
557 | <t> | 566 | <t> |
567 | <!-- FIXME: This whole section is a bit odd and I think we should breat it up | ||
568 | into an overview and the below explanaton should be part of message | ||
569 | processing --> | ||
558 | Any implementation encountering a HELLO GET request <bcp14>MUST</bcp14> respond | 570 | Any implementation encountering a HELLO GET request <bcp14>MUST</bcp14> respond |
559 | with its own HELLO block except if that block is | 571 | with its own HELLO block except if that block is |
560 | filtered by the request's result filter (see <xref target="result_filter"/>). | 572 | filtered by the request's result filter (see <xref target="result_filter"/>). |
@@ -601,6 +613,10 @@ maybe generate proper test vector. | |||
601 | is reachable via "udp" at 127.0.0.1 on port 2086 until | 613 | is reachable via "udp" at 127.0.0.1 on port 2086 until |
602 | 1647134480 seconds after the Epoch. Note that "udp" | 614 | 1647134480 seconds after the Epoch. Note that "udp" |
603 | here is underspecified and just used as a simple example. | 615 | here is underspecified and just used as a simple example. |
616 | <!-- FIXME: Must be supported by which underlay? | ||
617 | This does not make sense. I may be able to generate | ||
618 | addr-names that my underlay supports, but there is not | ||
619 | way to guarantee that all underlays support it. --> | ||
604 | In practice, the key (addr-name) | 620 | In practice, the key (addr-name) |
605 | <bcp14>MUST</bcp14> refer to a scheme supported by a | 621 | <bcp14>MUST</bcp14> refer to a scheme supported by a |
606 | DHT Underlay. | 622 | DHT Underlay. |
@@ -844,6 +860,12 @@ BEGIN | |||
844 | return 1 + (RM1 / (L2NSE + RM1 * HOPCOUNT)) | 860 | return 1 + (RM1 / (L2NSE + RM1 * HOPCOUNT)) |
845 | ]]></artwork> | 861 | ]]></artwork> |
846 | </figure> | 862 | </figure> |
863 | <!-- FIXME: WTF? So much wrong here. | ||
864 | 1. Why is this not part of code if necessary? | ||
865 | 2. Why is this necessary? | ||
866 | 3. Why probabillistic? | ||
867 | |||
868 | Implementations are bound to get this wrong. --> | ||
847 | <t> | 869 | <t> |
848 | The above calculation may yield values that are | 870 | The above calculation may yield values that are |
849 | not discrete. Hence, the result <bcp14>MUST</bcp14> be | 871 | not discrete. Hence, the result <bcp14>MUST</bcp14> be |
@@ -1205,6 +1227,9 @@ BEGIN | |||
1205 | <section anchor="p2p_hello" numbered="true" toc="default"> | 1227 | <section anchor="p2p_hello" numbered="true" toc="default"> |
1206 | <name>HelloMessage</name> | 1228 | <name>HelloMessage</name> |
1207 | <t> | 1229 | <t> |
1230 | <!-- FIXME: While it is discussed here how to hangle HelloMessages | ||
1231 | nowhere in the draft is a HelloMessage created at the | ||
1232 | initiator so it is completely irrelevant atm --> | ||
1208 | <tt>HelloMessage</tt>s are used to inform neighbors of | 1233 | <tt>HelloMessage</tt>s are used to inform neighbors of |
1209 | a peer about the sender's available addresses. The | 1234 | a peer about the sender's available addresses. The |
1210 | recipients use these messages to inform their respective | 1235 | recipients use these messages to inform their respective |
@@ -2233,7 +2258,11 @@ gnunet+tcp://12.3.4.5/ | |||
2233 | Bloom filter following the definition from <xref target="bloom_filters"/> | 2258 | Bloom filter following the definition from <xref target="bloom_filters"/> |
2234 | and consists of a variable number of buckets <tt>L</tt>. | 2259 | and consists of a variable number of buckets <tt>L</tt>. |
2235 | <tt>L</tt> depends on the number of elements <tt>|E|</tt> known to be filtered at the | 2260 | <tt>L</tt> depends on the number of elements <tt>|E|</tt> known to be filtered at the |
2236 | initiator. If <tt>|E|</tt> is zero, the size <tt>L</tt> is set to 32 bits to provide some minimum | 2261 | initiator. |
2262 | <!-- FIXME: Minimum space for used for what? There is no example given anywhere in the | ||
2263 | spec how this becomes relevant. Again, this is not some abstract block, | ||
2264 | but specifically a HELLO (see above). --> | ||
2265 | If <tt>|E|</tt> is zero, the size <tt>L</tt> is set to 32 bits to provide some minimum | ||
2237 | space (to be used by peers when forwarding the request after | 2266 | space (to be used by peers when forwarding the request after |
2238 | returning local results). | 2267 | returning local results). |
2239 | Otherwise, <tt>L</tt> is set to the minimum of | 2268 | Otherwise, <tt>L</tt> is set to the minimum of |