use US english

1 files changed, 18 insertions, 18 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index efa3994..65dc78f 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -208,9 +208,9 @@
           512-bit identifier of a location in the DHT. Multiple <tt>Block</tt>s can be
           stored under the same key. <tt>Peer Addresses</tt> are valid keys.
         </dd>
-        <dt>Neighbour:</dt>
+        <dt>Neighbor:</dt>
         <dd>
-          A neighbour is a peer which is directly able to communicate
+          A neighbor is a peer which is directly able to communicate
           with our peer via the <tt>Underlay Interface</tt>.
         </dd>
         <dt>Block:</dt>
@@ -652,7 +652,7 @@ Connectivity | |Underlay|  |Underlay|
       <t>
         The frequency of advertisement and peer discovery messages
         <bcp14>MAY</bcp14> be adapted according to network conditions, 
-        the set of already connected neighbours,
+        the set of already connected neighbors,
         the workload of the system and other factors which are at the discretion of
         the developer.
       </t>
@@ -766,16 +766,16 @@ bchar = *(ALPHA / DIGIT)
       </t>
       <t>
         To enable routing, any R<sup>5</sup>N implementation must keep 
-        information about its current set of neighbours.
+        information about its current set of neighbors.
         Upon receiving a connection notification from the Underlay through
-        <tt>PEER_CONNECTED</tt>, information on the new neighbour 
+        <tt>PEER_CONNECTED</tt>, information on the new neighbor 
         <bcp14>MUST</bcp14> be added, and similarly when
         a disconnect is indicated by the Underlay through
         <tt>PEER_DISCONNECTED</tt> the peer <bcp14>MUST</bcp14> be removed.
       </t>
       <t>
         In order to achieve O(log n) routing performance,
-        the data structure for managing neighbours and their
+        the data structure for managing neighbors and their
         metadata <bcp14>MUST</bcp14> be implemented using the k-buckets concept of
         <xref target="Kademlia"/>  as defined in <xref target="routing_table"/>.
         Maintenance of the routing table (after bootstrapping) is
@@ -792,11 +792,11 @@ bchar = *(ALPHA / DIGIT)
         <name>Routing Table</name>
         <t>
           The routing table consists of an array of k-buckets. Each
-          k-bucket contains a list of neighbours.
-          The i-th k-bucket stores neighbours whose 
+          k-bucket contains a list of neighbors.
+          The i-th k-bucket stores neighbors whose 
           identifiers are between distance 2^i and 2^(i+1) from the local peer.
           System constraints will typically force an implementation to impose some
-          upper limit on the number of neighbours kept per k-bucket.
+          upper limit on the number of neighbors kept per k-bucket.
         </t>
         <t>
           Implementations <bcp14>SHOULD</bcp14> try to keep at least
@@ -812,7 +812,7 @@ bchar = *(ALPHA / DIGIT)
           If a system hits constraints with respect to
           the number of active connections, an implementation
           <bcp14>MUST</bcp14> evict peers from those k-buckets with the
-          largest number of neighbours. The eviction strategy <bcp14>MUST</bcp14> be
+          largest number of neighbors. The eviction strategy <bcp14>MUST</bcp14> be
           to drop the shortest-lived connections first.
         </t>
       </section>
@@ -821,7 +821,7 @@ bchar = *(ALPHA / DIGIT)
         <t>
           To build its routing table, a peer will send out requests
           asking for blocks of type HELLO using its own location as the key,
-          but filtering all of its neighbours via the Bloom filter described
+          but filtering all of its neighbors via the Bloom filter described
           in <xref target="result_bloomfilter"/>. 
           These requests <bcp14>MUST</bcp14> use the FindApproximate and DemultiplexEverywhere
           flags. FindApproximate will ensure that other peers will reply
@@ -890,7 +890,7 @@ bchar = *(ALPHA / DIGIT)
             <tt>SelectClosestpeer(K, B) -&gt; N</tt>
           </dt>
           <dd>
-            This function selects the neighbour <tt>N</tt> from our
+            This function selects the neighbor <tt>N</tt> from our
             routing table with the shortest XOR-distance to the key <tt>K</tt>.
             This means that for all other peers <tt>N'</tt> in the routing table
             <tt>GetDistance(N, K) &lt; GetDistance(N',K)</tt>.
@@ -902,7 +902,7 @@ bchar = *(ALPHA / DIGIT)
           </dt>
           <dd>
             This function selects a random peer <tt>N</tt> from 
-            all neighbours.
+            all neighbors.
             Peers with a positive test in the peer Bloom 
             filter <tt>B</tt> are not considered.
           </dd>
@@ -910,7 +910,7 @@ bchar = *(ALPHA / DIGIT)
             <tt>Selectpeer(K, H, B) -&gt; N</tt>
           </dt>
           <dd>
-            This function selects a neighbour <tt>N</tt> depending on the
+            This function selects a neighbor <tt>N</tt> depending on the
             number of hops <tt>H</tt> parameter.
             If <tt>H &lt; NETWORK_SIZE_ESTIMATE</tt>
             this function <bcp14>MUST</bcp14> return <tt>SelectRandompeer(B)</tt> and
@@ -928,7 +928,7 @@ bchar = *(ALPHA / DIGIT)
             <tt>ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE) -&gt; Number</tt>
           </dt>
           <dd>
-            This function computes the number of neighbours
+            This function computes the number of neighbors
             that a message should be forwarded to.  The arguments
             are the desired replication level (<tt>REPL_LVL</tt>), the <tt>HOPCOUNT</tt> of the message so far, and
             the base-2 logarithm of the current network
@@ -1119,7 +1119,7 @@ bchar = *(ALPHA / DIGIT)
       <section anchor="p2p_hello" numbered="true" toc="default">
         <name>HelloMessage</name>
         <t>
-          <tt>HelloMessage</tt>s are used to inform neighbours of 
+          <tt>HelloMessage</tt>s are used to inform neighbors of 
           a peer about the sender's available addresses. The
           recipients use these messages to inform their respective
           Underlays about ways to sustain the connections and to
@@ -1220,7 +1220,7 @@ bchar = *(ALPHA / DIGIT)
             The address information about P should then also be made
             available to each respective Underlays to enable the
             Underlay to maintain optimal connectivity to the
-            neighbour.
+            neighbor.
           </t>
         </section>
       </section>
@@ -2160,7 +2160,7 @@ gnunet+tcp://12.3.4.5/ \
         does not have/require a trust anchor a priori. This is (again) in contrast
       to RELOAD -->
       <t>
-        If an upper bound to the maximum number of neighbours in a
+        If an upper bound to the maximum number of neighbors in a
         k-bucket is reached, the implementation <bcp14>MUST</bcp14>
         prefer to preserve the oldest working connections instead of
         new connections.  This makes Sybil attacks less effective