commit 8306b696288c82ecc1564c71425bd38e1ecdb228
parent 2b7153afaa54a302a9a9f2434393220144f68ff4
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Sun, 14 Jul 2024 10:01:56 +0200
imprive should may bcp14
Diffstat:
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -876,11 +876,12 @@ Connectivity | |Underlay| |Underlay| | Underlay | ...
interface</em>. This is commonly achieved through the
configuration of hardcoded bootstrap peers or bootstrap
servers either for the underlay or the R<sup>5</sup>N
- implementation. While details on how the first connection
- is established <bcp14>MAY</bcp14> depend on the specific
- implementation, this <bcp14>SHOULD</bcp14> usually be done
+ implementation. The first connection <bcp14>SHOULD</bcp14> be established
by an out-of-band exchange of the information from a
- <tt>HELLO</tt> block. <xref target="hello_url"/> specifies
+ <tt>HELLO</tt> block.
+ Implementations <bcp14>MAY</bcp14> have other means to achieve this
+ initial connection.
+ <xref target="hello_url"/> specifies
a URL format for encoding HELLO blocks as text strings. The
URL format thus provides a portable, human-readable,
text-based serialization format that can, for example, be
@@ -916,16 +917,18 @@ Connectivity | |Underlay| |Underlay| | Underlay | ...
<t>
In order to facilitate peers answering requests for
<tt>HELLOs</tt>, the underlay is expected to provide the
- implementation with one or more addresses signalled through
- <tt>ADDRESS_ADDED</tt>. Zero addresses <bcp14>MAY</bcp14> be
+ implementation with addresses signalled through
+ <tt>ADDRESS_ADDED</tt>. It is possible that no addresses are
provided if a peer can only establish outgoing connections
and is otherwise unreachable. An implementation
<bcp14>MUST</bcp14> advertise its addresses periodically to
its <em>neighbors</em> through <tt>HelloMessages</tt>. The
advertisement interval and expiration <bcp14>SHOULD</bcp14>
- be configurable or chosen at the discretion of the
- implementation based on external factors such as expiration
- of DHCP leases. The specific frequency of advertisements
+ be configurable.
+ If the values are chosen at the discretion of the
+ implementation, it is <bcp14>RECOMMENDED</bcp14> to choose external
+ factors such as expiration of DHCP leases to determine the values.
+ The specific frequency of advertisements
<bcp14>MAY</bcp14> depend on available bandwidth, the set of
already connected neighbors, the workload of the system and
other factors which are at the discretion of the developer,
