[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0004] branch master updated (88dcd3b -> c6ca26a)
From: |
gnunet |
Subject: |
[lsd0004] branch master updated (88dcd3b -> c6ca26a) |
Date: |
Mon, 26 Dec 2022 03:18:58 +0100 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a change to branch master
in repository lsd0004.
from 88dcd3b typo
new 05bb198 Fix GANA for block types to include specifications.
new c6ca26a Improve structure and wording.
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
draft-schanzen-r5n.xml | 33 +++++++++++++++------------------
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 8adcfae..9bbebfc 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -633,14 +633,15 @@ Connectivity | |Underlay| |Underlay|
While details on how the first connection is established
<bcp14>MAY</bcp14>
depend on the specific implementation, this <bcp14>SHOULD</bcp14>
usually be done
by an out-of-band exchange of the information from a <tt>HELLO</tt>
block.
- <!-- FIXME: Is this really an encoding of a block? It seems to me
that "HELLO"
- is not properly defined.
- FIXME: Should? Isn't this part of the HelloMessage? -->
+ <!-- FIXME It is unclear why this is needed and why it is here. THis
is a serialization format
+ of the HELLO block that is not used anywhere in the draft. I
already moved the formati itself
+ into the appendix. -->
For this, section <xref target="hello_url"/> specifies a URL format
for encoding HELLO
blocks as text strings which <bcp14>SHOULD</bcp14> be supported by
implementations.
</t>
<t>
- <!-- FIXME REPL_LVL unclear, RF_SIZE unclear -->
+ <!-- FIXME REPL_LVL unclear, RF_SIZE unclear. Sections like this
make me wonder how
+ we can avoid using prose to specify message creation -->
To discover peers for its routing table, a peer will initiate
<tt>GetMessage</tt> requests
<xref target="p2p_get"/> asking for blocks of type <tt>HELLO</tt>
using its own peer address as
<tt>QUERY_HASH</tt>, filtering all of its neighbors via the Bloom
filter described
@@ -676,10 +677,7 @@ Connectivity | |Underlay| |Underlay|
Whenever a peer receives such a <tt>HELLO</tt> message from
another peer that is
already in the routing table, it must cache it as long as that peer
is in its routing table
(or until the <tt>HELLO</tt> expires) and serve it in response to
- <!-- FIXME wat is a Peer Discovery request??
- maybe a <tt>HELLO</tt> GET request?
- -->
- Peer Discovery requests.
+ GET requests for <tt>HELLO</tt> blocks (see <xref
target="p2p_get_processing"/>).
</t>
</section>
<section anchor="routing_bloomfilter">
@@ -1329,7 +1327,7 @@ BEGIN
the peer is removed from the routing table, or the information
is replaced by another message from the peer.
<!-- FIXME same problem as for <tt>HELLO</tt> blocks: We do not
need to TRY_CONNECT here because we already have
a connection, obviously. But we may want to TRY_CONNECT on
the new addresses? Adding for now -->
- The implementation <bcp14>MAY</bcp14> instruct the Underlay to
connect to all now available addresses
+ The implementation <bcp14>SHOULD</bcp14> instruct the Underlay
to connect to all now available addresses
using <tt>TRY_CONNECT</tt> in order to make the underlay aware
of alternative addresses for this connection and
to maintain optimal connectivity.
</li>
@@ -1572,16 +1570,15 @@ BEGIN
number of peers to forward the message to. The implementation
<bcp14>MAY</bcp14>
forward to fewer or no peers in order to handle resource
constraints
such as limited bandwidth.
- <!-- FIXME: From above. it seems to me that here we need to add
a new putpath
- signature element (as we know the successor now)-->
- For each selected peer with peer address <tt>P</tt> a dedicated
<tt>PutMessage'</tt>
+ For each selected peer with peer address <tt>P</tt> a dedicated
<tt>PutMessage_P</tt>
is created containing the original (and where applicable already
updated) fields
of the received <tt>PutMessage</tt>.
In each message the local peer address <bcp14>MUST</bcp14> be
added to the
<tt>PEER_BF</tt> and the <tt>HOPCOUNT</tt> is incremented by 1.
If the <tt>RecordRoute</tt> flag is set, a new Path Element is
created and added
to the <tt>PUTPATH</tt> fields and the <tt>PATH_LEN</tt> field
is incremented by 1.
- Finally, <tt>SEND(P, PutMessage')</tt> is called.
+ The successor in the new Path Element is the recipient peer
<tt>P</tt> of the <tt>PutMessageP</tt>.
+ Finally, the messages are sent using <tt>SEND(P,
PutMessageP)</tt> each recipient.
</li>
</ol>
</section>
@@ -1706,9 +1703,8 @@ BEGIN
filter because of a false-positive test.
</t>
<t>
- <!-- FIXME: then this should be part of the registration policy -->
How exactly a block result is added to a result filter
- <bcp14>MUST</bcp14> be specified as part of the definition of a
block type.
+ is specified as part of the definition of a block type (cf. <xref
target="hello_block"/>).
</t>
</section>
<section anchor="p2p_get_processing">
@@ -2619,20 +2615,21 @@ BEGIN
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>
+ <li>References: Required, references (such as an RFC) specifying the
block type and its block functions</li>
</ul>
<t>
The registration policy for this sub-registry is "First Come First
Served", as described in <xref target="RFC8126"/>.
GANA created the registry as follows:
</t>
+ <!-- FIXME changed GNS Reference to This.I-D because we either need to
define it here
+ or in the GNS RFC. And I think here is better or in a separate
document -MSC -->
<figure anchor="figure_btypenums" title="The Block Type Registry.">
<artwork name="" type="" align="left" alt=""><![CDATA[
Number| Name | References | Description
------+----------------+------------+-------------------------
0 ANY [This.I-D] Reserved
-11 GNS_NAMERECORD GNS Block for GNS records
+11 GNS_NAMERECORD [This.I-D] Block for GNS records
13 DHT_HELLO [This.I-D] Address data for a peer
Contact: r5n-registry@gnunet.org
]]></artwork>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [lsd0004] branch master updated (88dcd3b -> c6ca26a),
gnunet <=