some typos; peer filter

1 files changed, 8 insertions, 8 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index cf67d50..ac74024 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -938,7 +938,7 @@ bchar = *(ALPHA / DIGIT)
             <tt>SelectClosestpeer(K, B)</tt> otherwise.
           </dd>
           <dt>
-            <tt>IsClosestpeer(N, K, B) -&gt; true | false</tt>
+            <tt>IsClosestPeer(N, K, B) -&gt; true | false</tt>
           </dt>
           <dd>
             This function checks if <tt>N</tt> is the closest peer for <tt>K</tt>
@@ -1611,12 +1611,12 @@ BEGIN
             </li>
             <li>
               If the local peer is the closest peer
-              (cf. <tt>IsClosestpeer(SELF, BLOCK_KEY)</tt>) or the <tt>DemultiplexEverywhere</tt>
+              (cf. <tt>IsClosestPeer(SELF, BLOCK_KEY, PeerFilter)</tt>) or the <tt>DemultiplexEverywhere</tt>
               flag ist set, the message <bcp14>MUST</bcp14>
               be stored locally in the block storage.
             </li>
             <li>
-              If the <tt>MTYPE</tt> of the message indicates a HELLO block, the
+              If the <tt>BTYPE</tt> of the message indicates a HELLO block, the
               peer <bcp14>MUST</bcp14> be considered for the local routing
               table if the respective k-bucket is not yet full. In this case,
               the local peer <bcp14>MUST</bcp14> try to establish a connection
@@ -1628,7 +1628,7 @@ BEGIN
             </li>
             <li>
               Given the value in <tt>REPL_LVL</tt>, <tt>HOPCOUNT</tt> and the
-              result of <tt>IsClosestpeer(SELF, BLOCK_KEY)</tt> the number of peers to
+              result of <tt>IsClosestPeer(SELF, BLOCK_KEY, PeerFilter)</tt> the number of peers to
               forward to <bcp14>MUST</bcp14> be calculated
               using <tt>ComputeOutDegree()</tt>.
               The implementation <bcp14>SHOULD</bcp14> select up to this
@@ -1763,7 +1763,7 @@ BEGIN
           </t>
           <ol>
             <li>
-              The <tt>QUERY_KEY</tt> and <tt>XQUERY</tt> fields are validated
+              The <tt>QUERY_HASH</tt> and <tt>XQUERY</tt> fields are validated
               against the requested <tt>BTYPE</tt> as defined by its respective
               <tt>ValidateBlockQuery</tt> procedure.
               If validation
@@ -1779,7 +1779,7 @@ BEGIN
             <li>
               <t>
                 If the local peer is the closest peer
-                (cf. <tt>IsClosestpeer (SELF, QueryHash)</tt>) or the
+                (cf. <tt>IsClosestPeer (SELF, QueryHash, PeerFilter)</tt>) or the
                 <tt>DemultiplexEverywhere</tt> flag is set, a reply
                 <bcp14>MUST</bcp14> be produced (if one is available) using the following
                 steps:
@@ -2007,7 +2007,7 @@ BEGIN
               does not have to match the <tt>QUERY_HASH</tt>.
             </li>
             <li>
-              If the <tt>MTYPE</tt> of the message indicates a HELLO block, the
+              If the <tt>BTYPE</tt> of the message indicates a HELLO block, the
               peer <bcp14>MUST</bcp14> be considered for the local routing
               table if the respective k-bucket is not yet full. In this case,
               the local peer <bcp14>MUST</bcp14> try to establish a connection
@@ -2178,7 +2178,7 @@ BEGIN
               </dl>
               <t>
               If the main evaluation result is <tt>FILTER_MORE</tt>, the function also returns
-              and updated result filter where the block is added to the set of
+              an updated result filter where the block is added to the set of
               filtered replies.  An implementation is not expected to actually differenciate
               between the <tt>FILTER_DUPLICATE</tt> and <tt>FILTER_IRRELEVANT</tt> return
               values: in both cases the block is ignored for this query.