lsd0004

commit a4d1d012678e339cc7b5d29386ea20aa3790444b
parent f7225f3c31dbd24ac994c0e0cb747bfd141229c9
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date:   Sun, 14 Jul 2024 09:29:27 +0200

bcp

Diffstat:
M
draft-schanzen-r5n.xml
 | 
5
+++--

1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -583,7 +583,8 @@ Connectivity | |Underlay|  |Underlay|  | Underlay | ...
       <name>Underlay</name>
       <t>
         A peer <bcp14>MUST</bcp14> implement one or more underlay
-        protocols. Peers supporting multiple underlays effectively
+        protocols.
+        Peers supporting multiple underlays effectively
         create a bridge between different networks.  How peers are
         addressed in a specific underlay is out of scope of this
         document.  For example, a peer may have a TCP/IP address, or
@@ -906,7 +907,7 @@ Connectivity | |Underlay|  |Underlay|  | Underlay | ...
           cause each peer on the path to respond if it has relevant
           information. The combination of these flags is thus likely
           to yield <tt>HELLOs</tt> of peers that are useful somewhere
-          in the initiator's routing table.  The <tt>RECOMMENDED</tt>
+          in the initiator's routing table.  The <bcp14>RECOMMENDED</bcp14>
           replication level to be set in the <tt>REPL_LVL</tt> field
           is 4.  The size and format of the result filter is specified
           in <xref target="hello_block"/>.  The <tt>XQUERY</tt>