1 files changed, 37 insertions, 5 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 6096c24..cc59f22 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -408,7 +408,7 @@ Connectivity | |Underlay|  |Underlay|
           <dd>
             is a signed path of the IDs of peers which the query
             traversed through the network. The DHT will try to make
-            the path available if the RecordRoute flag was set by
+            the path available if the <tt>RecordRoute</tt> flag was set by
             the application calling the PUT procedure. The reported
             path may have been silently truncated from the beginning.
           </dd>
@@ -416,7 +416,7 @@ Connectivity | |Underlay|  |Underlay|
           <dd>
             is a signed path of the IDs of peers which the
             result message traversed.  The DHT will try to make the
-            path available if the RecordRoute flag was set for the GET procedure.
+            path available if the <tt>RecordRoute</tt> flag was set for the GET procedure.
             The reported path may have been silently truncated from the beginning.
             As the block was cached by the node at the end of this
             path, this path is more likely to be stale compared to the
@@ -1420,7 +1420,18 @@ bchar = *(ALPHA / DIGIT)
             <li>
               If the <tt>RecordRoute</tt> flag is set in FLAGS,
               the local peer address <bcp14>MUST</bcp14> be appended to the <tt>PUTPATH</tt>
-              of the message.
+              of the message.  If the flag is not set, the <tt>PATH_LEN</tt> 
+              <bcp14>MUST</bcp14> be set to zero.
+            </li>
+            <li>
+              If the <tt>PATH_LEN</tt> is non-zero, 
+              the local peer <bcp14>SHOULD</bcp14> verify the signatures from the <tt>PUTPATH</tt>.
+              Verification <bcp14>MAY</bcp14> involve checking all signatures or any random
+              subset of the signatures.  It is <bcp14>RECOMMENDED</bcp14> that peers adapt 
+              their behavior to available computational resources so as to not make signature
+              verification a bottleneck.  If an invalid signature is found, the
+              <tt>PUTPATH</tt> <bcp14>MUST</bcp14> be truncated to only include the elements
+              following the invalid signature.
             </li>
             <li>
               If the local peer is the closest peer
@@ -1737,7 +1748,7 @@ bchar = *(ALPHA / DIGIT)
               is a 32-bit block type field. The block type indicates the content
               type of the payload. In network byte order.
             </dd>
-            <dt>PUTPATH_L</dt>
+            <dt>PUTPATH_LEN</dt>
             <dd>
               is a 16-bit number indicating the length of the PUT path recorded
               in <tt>PUTPATH</tt>. As <tt>PUTPATH</tt> is optional, this value may be zero
@@ -1798,6 +1809,18 @@ bchar = *(ALPHA / DIGIT)
               If the result is <tt>BLOCK_INVALID</tt>, the message <bcp14>MUST</bcp14> be
               discarded.
             </li>
+            <li>
+              If the <tt>PUT_PATH_LEN</tt> or the <tt>GET_PATH_LEN</tt> are non-zero, 
+              the local peer <bcp14>SHOULD</bcp14> verify the signatures from the <tt>PUTPATH</tt>
+              and the <tt>GETPATH</tt>.
+              Verification <bcp14>MAY</bcp14> involve checking all signatures or any random
+              subset of the signatures.  It is <bcp14>RECOMMENDED</bcp14> that peers adapt 
+              their behavior to available computational resources so as to not make signature
+              verification a bottleneck.  If an invalid signature is found, the
+              path <bcp14>MUST</bcp14> be truncated to only include the elements
+              following the invalid signature.  In particular, any invalid signature
+              on the <tt>GETPATH</tt> will cause <tt>PUT_PATH_LEN</tt> to be set to 0.
+            </li>
             <li>
               The peer also attempts to compute the
               key using <tt>DeriveBlockKey</tt>.  This may result in <tt>NONE</tt>.
@@ -1823,7 +1846,7 @@ bchar = *(ALPHA / DIGIT)
               </t>
               <ol type="%c)">
                 <li>
-                  If the approximate flag was not set in the query and the <tt>BTYPE</tt> allowed the
+                  If the <tt>FindApproximate</tt> flag was not set in the query and the <tt>BTYPE</tt> allowed the
                   implementation to compute the key from the block, the computed key must
                   exactly match the <tt>QUERY_HASH</tt>, otherwise the result does
                   not match the pending query and processing continues with the next pending query.               
@@ -1845,6 +1868,15 @@ bchar = *(ALPHA / DIGIT)
                   The result of this duplicate filtering is always either
                   <tt>FILTER_MORE</tt> or <tt>FILTER_DUPLICATE</tt>.
                 </li>
+                <li>
+                  If the <tt>RecordRoute</tt> flag is set in FLAGS,
+                  the local peer address <bcp14>MUST</bcp14> be appended to the <tt>GETPATH</tt>
+                  of the message and the respective signature <bcp14>MUST</bcp14> be
+                  set using the query origin as the <tt>PEER SUCCESSOR</tt> and the
+                  response origin as the <tt>PEER PREDECESSOR</tt>.  If the flag is not set, 
+                  the <tt>GET_PATH_LEN</tt> and <tt>PUT_PATH_LEN</tt> 
+                  <bcp14>MUST</bcp14> be set to zero when forwarding the result.
+                </li>
               </ol>
               <t>
                 If the result is either <tt>FILTER_MORE</tt> or <tt>FILTER_LAST</tt>,