diff --git a/zip-0155.html b/zip-0155.html
index 94bcc09f..72b7a998 100644
--- a/zip-0155.html
+++ b/zip-0155.html
@@ -18,7 +18,7 @@ License: BSD-2-Clause
 Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/542">https://github.com/zcash/zips/issues/542</a>&gt;
 Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/543">https://github.com/zcash/zips/pull/543</a>&gt;</pre>
         <section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
-            <p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
+            <p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
             <p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">4</a></p>
             <p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
             <p>"P2P network" means the Zcash peer-to-peer network.</p>
@@ -128,7 +128,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/543">https://githu
                 </table>
             </blockquote>
             <p>Network ID <code>0x03</code> is intentionally not assigned. In BIP 155 <a id="id8" class="footnote_reference" href="#bip-0155">3</a> it was assigned to Tor v2 onion addresses, but those addresses are no longer supported by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.</p>
-            <p>Clients SHOULD gossip addresses from all known networks even if they are currently not connected to some of them. That could help multi-homed nodes and make it more difficult for an observer to tell which networks a node is connected to.</p>
+            <p>Clients SHOULD gossip valid, potentially routable addresses from all known networks, even if they are currently not connected to some of them. That could help multi-homed nodes and make it more difficult for an observer to tell which networks a node is connected to.</p>
             <p>Clients MUST NOT gossip addresses from unknown networks, because they have no means to validate those addresses and so can be tricked to gossip invalid addresses.</p>
             <p>Clients MUST reject messages that contain addresses that have a different length than specified in this table for a specific network ID, as these are meaningless.</p>
             <section id="network-address-encodings"><h3><span class="section-heading">Network address encodings</span><span class="section-anchor"> <a rel="bookmark" href="#network-address-encodings"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
diff --git a/zip-0155.rst b/zip-0155.rst
index 532ca924..71c8a8c3 100644
--- a/zip-0155.rst
+++ b/zip-0155.rst
@@ -16,8 +16,8 @@
 Terminology
 ===========
 
-The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY"
-in this document are to be interpreted as described in RFC 2119. [#RFC2119]_
+The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this
+document are to be interpreted as described in RFC 2119. [#RFC2119]_
 
 The term "network upgrade" in this document is to be interpreted as described in
 ZIP 200. [#zip-0200]_
@@ -111,9 +111,10 @@ Network ID ``0x03`` is intentionally not assigned. In BIP 155 [#bip-0155]_ it wa
 assigned to Tor v2 onion addresses, but those addresses are no longer supported
 by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.
 
-Clients SHOULD gossip addresses from all known networks even if they are currently
-not connected to some of them. That could help multi-homed nodes and make it more
-difficult for an observer to tell which networks a node is connected to.
+Clients SHOULD gossip valid, potentially routable addresses from all known
+networks, even if they are currently not connected to some of them. That could
+help multi-homed nodes and make it more difficult for an observer to tell which
+networks a node is connected to.
 
 Clients MUST NOT gossip addresses from unknown networks, because they have no means
 to validate those addresses and so can be tricked to gossip invalid addresses.