Handle most of the fixmes, add one more.

1 files changed, 58 insertions, 65 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 9e7dd1a..200f28d 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -19,6 +19,7 @@
 <!ENTITY RFC8032 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml">
 <!ENTITY RFC8126 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
 <!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
+<!ENTITY RFC8324 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8324.xml">
 <!ENTITY I-D.schanzen-gns PUBLIC '' "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.schanzen-gns.xml">
 ]>
 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
@@ -445,7 +446,6 @@ Connectivity | |Underlay|  |Underlay|
           When the connection attempt is successful, information on the new
           peer is offered through the <tt>PEER_CONNECTED</tt> signal.
         </dd>
-             If PEER_CONNECT and put in routing table, then HOLD -->
         <dt>
           <tt>HOLD(P)</tt>
         </dt>
@@ -641,14 +641,6 @@ Connectivity | |Underlay|  |Underlay|
           of <tt>HELLO</tt>s.
         </t>
         <t>
-          <!-- FIXME REPL_LVL unclear, RF_SIZE unclear. Sections like this make me wonder how
-               we can avoid using prose to specify message creation.
-               REPL_LVL: For hello it is 4 => RECOMMENDED to 4
-               RF_SIZE: Specified in HELLO block as connected peers = |E|.
-               RF: All peers I am already connected to should be included in the RF BF
-               XQUERY: => nil
-               Flags? FindApproximate
-          -->
           To discover peers for its routing table, a peer will initiate <tt>GetMessage</tt> requests
           <xref target="p2p_get"/> asking for blocks of type  <tt>HELLO</tt>  using its own peer address as
           <tt>QUERY_HASH</tt>.
@@ -678,12 +670,13 @@ Connectivity | |Underlay|  |Underlay|
           already in the routing table, it must cache it as long as that peer is in its routing table
           (or until the <tt>HELLO</tt> expires) and serve it in response to
           GET requests for <tt>HELLO</tt> blocks (see <xref target="p2p_get_processing"/>).
+          This behaviour makes it unnecessary to initiate dedicated <tt>PutMessages</tt> containing
+          <tt>HELLO</tt> blocks by the implementation.
         </t>
       </section>
       <section anchor="routing_bloomfilter">
         <name>Peer Bloom Filter</name>
         <t>
-          <!-- FIXME HArdcoded to 128 bytes = L/8 -->
           As DHT <tt>GetMessage</tt>s and <tt>PutMessage</tt>s traverse a random path through the network for the
           first N hops, it is essential that routing loops are avoided.
           This peer Bloom filter is constant in size at <tt>L=1024</tt> buckets (128 bytes) and
@@ -1302,8 +1295,11 @@ BEGIN
               is in the future. If the signature is invalid, the message is discarded.
             </li>
             <li>
-              The <tt>HELLO</tt> information is cached in the routing table until it expires,
-              the peer is removed from the routing table, or the information is replaced by another message from the peer.
+              The information contained in the <tt>HelloMessage</tt> can be used to synthesize a
+              block of type <tt>HELLO</tt> (<xref target="hello_block"/>).
+              The block is cached in the routing table until it expires,
+              the peer is removed from the routing table, or the information is replaced by another message
+              from the peer.
               The implementation <bcp14>SHOULD</bcp14> instruct the Underlay to connect to all now available addresses
               using <tt>TRY_CONNECT</tt> in order to make the underlay aware of alternative addresses for this connection and
               to maintain optimal connectivity.
@@ -1510,8 +1506,10 @@ BEGIN
             <li>
               If the local peer is the closest peer
               (cf. <tt>IsClosestPeer(SELF, BLOCK_KEY, PeerFilter)</tt>) or the <tt>DemultiplexEverywhere</tt>
-              flag ist set, the message <bcp14>MUST</bcp14>
+              flag ist set, the message <bcp14>SHOULD</bcp14>
               be stored locally in the block storage if possible.
+              The implementation <tt>MAY</tt> choose not store the block if external factors or configurations
+              prevent this, such as limited (alottted) disk space. 
             </li>
             <li>
               If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the
@@ -1522,8 +1520,9 @@ BEGIN
               connection to the peer indicated in the <tt>HELLO</tt> block using
               the address information
               from the <tt>HELLO</tt> block and the Underlay function <tt>TRY_CONNECT</tt>.
-              The implementation <bcp14>MUST</bcp14> instruct the Underlay to connect to all provided addresses
-              using <tt>TRY_CONNECT</tt> in order to make the underlay aware of multiple addresses for this connection.
+              The implementation <bcp14>MUST</bcp14> instruct the Underlay to try to connect to all
+              provided addresses using <tt>TRY_CONNECT</tt> in order to make the underlay aware of
+              multiple addresses for this connection.
               When a connection is established, the signal <tt>PEER_CONNECTED</tt> will cause
               the peer to be added to the respective k-bucket of the routing table (<xref target="routing"/>).
             </li>
@@ -1700,21 +1699,25 @@ BEGIN
             </li>
             <li>
               <t>
-                If the local peer is the closest peer
-                (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
+                The local peer <bcp14>MUST</bcp14> try to produce a reply in any of the following cases:
+                (1) If the local peer is the closest peer
+                (cf. <tt>IsClosestPeer (SELF, QueryHash, PeerFilter)</tt>, or (2)
+                if the <tt>DemultiplexEverywhere</tt> flag is set, or (3)
+                if the local peer is not the closest and the <tt>GetRequest</tt> was answered previously
+              resulting in a cached reply (<xref target="p2p_result_processing"/>). 
+              </t>
+              <t>
+                The reply is produced (if one is available) using the following
                 steps:
               </t>
               <ol type="%c)">
-                <!-- FIXME it seems to me as if some blocks need to be "synthesized", e.g.
-                     HELLOs from HelloMessages... this needs to be specified.-->
                 <li>
                   If the <tt>BTYPE</tt> does not indicate a request for a <tt>HELLO</tt> block or
                   <tt>ANY</tt>,
-                  the implementation <bcp14>MUST</bcp14> only consider blocks in the local block storage.
-                  Otherwise, the implementation <bcp14>MUST</bcp14> only consider its own <tt>HELLO</tt> and
-                  the <tt>HELLO</tt>s it has cached for the peers in its routing table as blocks.
+                  the implementation <bcp14>MUST</bcp14> only consider blocks in the local block storage
+                  and previously cached <tt>ResultMessage</tt>s.
+                  Otherwise, the implementation <bcp14>MUST</bcp14> only consider its own addresses and
+                  the addresses it has cached for the peers in its routing table.
                 </li>
                 <li>
                   If <tt>FLAGS</tt> indicate a <tt>FindApproximate</tt> request,
@@ -1725,16 +1728,19 @@ BEGIN
                   with a <tt>BLOCK_KEY</tt> that matches the <tt>QUERY_HASH</tt> exactly and that is
                   not filtered by the <tt>RESULT_BF</tt>.
                 </li>
+                <li>
+                  Any resulting (synthesized) block <bcp14>MUST</bcp14> be encapsulated in a
+                  <tt>ResultMessage</tt>.
+                  The cached or created <tt>ResultMessage</tt> <bcp14>SHOULD</bcp14> be transmitted to the
+                  neighbor from which the request was received.
+                </li>
               </ol>
 	      <t>
-               The resulting block, if any, <bcp14>MUST</bcp14> be encapsulated in a
-               <tt>ResultMessage</tt> and <bcp14>SHOULD</bcp14> be transmitted to the
-               neighbor from which the request was received.
-               Implementations <bcp14>MAY</bcp14> drop messages if they are resource-constrained.
-	       However, <tt>ResultMessage</tt>s <bcp14>MUST</bcp14> be given the
-	       highest priority among competing transmissions.
+                Implementations <bcp14>MAY</bcp14> not to reply if they are resource-constrained.
+	        However, <tt>ResultMessage</tt>s <bcp14>MUST</bcp14> be given the
+	        highest priority among competing transmissions.
               </t>
-	      <t>
+              <t>
 	       If the <tt>BTYPE</tt> is supported and <tt>ValidateBlockReply</tt> for the given
 	       query has yielded a status of <tt>FILTER_LAST</tt>, processing
 	       <bcp14>MUST</bcp14> end and not continue with forwarding of
@@ -1756,6 +1762,9 @@ BEGIN
               to, <tt>SEND(P, GetMessageP)</tt> is called.  Here, <tt>GetMessageP</tt>
 	      is the original message with the updated fields for <tt>HOPCOUNT</tt> (incremented
               by 1), <tt>PEER_BF</tt> and <tt>RESULT_FILTER</tt>.
+              <!-- FIXME: For how long? what exactly must be stored? -->
+              The implementation <tt>MUST</tt> cache the originator peer address and the
+              <tt>GetMessage</tt> in order to correctly process any <tt>ResultMessage</tt>s.
             </li>
           </ol>
         </section>
@@ -1951,8 +1960,6 @@ BEGIN
 	      does not have to match the <tt>QUERY_HASH</tt>.
 	    </li>
             <li>
-              <!-- FIXME: Discuss: Changed from MUST to SHOULD --
-                   same change as above  - MSC -->
               If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the
               peer <bcp14>SHOULD</bcp14> be considered for the local routing
 	      table by using the peer address computed from the block using<tt>DeriveBlockKey</tt>.
@@ -2015,13 +2022,12 @@ BEGIN
 	      </t>
             </li>
 	    <li>
-              <!-- FIXME: If that is the case, then this also needs to be in the
-                   processing of GetMessage: I think we shoul dmove this to some
-                   performance considerations instead.
-                   => same formulation as for PUT to store if possible (MUST)
-                   usr 1-to-1-->
-	      Finally, the implementation <bcp14>MAY</bcp14> choose to
-	      cache data from <tt>ResultMessage</tt>s.
+	      Finally, the implementation <bcp14>SHOULD</bcp14> cache
+              <tt>ResultMessage</tt>s in order to provide already seen replies to
+              future <tt>GetMessage</tt>s.
+              The implementation <bcp14>MAY</bcp14> choose not no cache any or
+              a limited number of <tt>ResultMessage</tt>s for reasons such as resource
+              limitations.
             </li>
           </ol>
         </section>
@@ -2291,26 +2297,12 @@ BEGIN
           <dt>SetupResultFilter(FilterSize, Mutator) -&gt; RF</dt>
           <dd>
 	  <t>
-            <!-- FIXME: I do not understand this. Isn't the element set E known
-                 for <tt>HELLO</tt> blocks? Isn't it H_ADDRS XOR MUTATOR?
-                 E => conected peers in routing table
-                 K => is 16
-            -->
 	    The RESULT_FILTER for <tt>HELLO</tt> blocks is implemented using a
             Bloom filter following the definition from <xref target="bloom_filters"/>
             and consists of a variable number of buckets <tt>L</tt>.
-            <tt>L</tt> depends on the number of elements <tt>|E|</tt> known to be filtered at the
-	    initiator.
-            <!-- FIXME: Minimum space for used for what? There is no example given anywhere in the
-                 spec how this becomes relevant. Again, this is not some abstract block,
-                 but specifically a <tt>HELLO</tt> (see above).
-                 E is the number of currently connected peers (neighbors)!
-                 E is no really ever 0 so the following sentence should be amended.
-            -->
-            If <tt>|E|</tt> is zero, the size <tt>L</tt> is set to 32 bits to provide some minimum
-	    space (to be used by peers when forwarding the request after
-	    returning local results).
-	    Otherwise, <tt>L</tt> is set to the minimum of
+            <tt>L</tt> depends on the number of connected peers <tt>|E|</tt> known to
+            the peer creating a <tt>HELLO</tt> block from its own addresses:
+	    <tt>L</tt> is set to the minimum of
 	    2<sup>18</sup> bits (2<sup>15</sup> bytes) and the lowest power
 	    of 2 that is strictly larger than <tt>2*K*|E|</tt> bits (<tt>K*|E|/4</tt> bytes).
           </t>
@@ -2538,12 +2530,12 @@ BEGIN
           control such as <xref target="RFC6940"/> which, like R<sup>5</sup>N, provides
           a peer-to-peer (P2P) signaling protocol with extensible routing and topology
           mechanisms.
-          <!-- FIXME: Can we give examples here?
-               Centralization DNS roots fixed through GNS.
-          -->
-          Some decentralized applications require a more open system that
-          enables ad-hoc participation and other means to prevent common attacks
-          on P2P overlays.
+          Some decentralized applications such as the GNU Name System (<xref target="I-D.schanzen-gns"/>)
+          require a more open system that enables ad-hoc participation and other means to prevent common
+          attacks on P2P overlays.
+          GNS, for example, would be in conflict with its goals of providing a solution to the issues of a
+          "Single Hierarchy with a Centrally Controlled Root" and "Distribution and Management of Root Servers"
+          in DNS as raised in <xref target="RFC8324"/>.
         </t>
       </section>
     </section>
@@ -2600,7 +2592,7 @@ BEGIN
         Served", as described in <xref target="RFC8126"/>.
         GANA created the registry as follows:
       </t>
-      <!-- FIXME changed GNS Reference to This.I-D because we either need to define it here
+      <!-- NOTE: changed GNS Reference to This.I-D because we either need to define it here
            or in the GNS RFC. And I think here is better or in a separate document
            => not in here. Use separate document for NAMERECORD draft.
            -MSC -->
@@ -2609,8 +2601,8 @@ BEGIN
 Number| Name           | References | Description
 ------+----------------+------------+-------------------------
 0       ANY              [This.I-D]   Reserved
-11      GNS_NAMERECORD   [This.I-D]   Block for GNS records
 13      DHT_HELLO        [This.I-D]   Address data for a peer
+
 Contact: r5n-registry@gnunet.org
 ]]></artwork>
       </figure>
@@ -2702,6 +2694,7 @@ Type    | Name            | References | Description
         &RFC6940;
         &RFC8126;
         &RFC8174;
+        &RFC8324;
         &I-D.schanzen-gns;
 
       <reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9"><front><title>High-Speed High-Security Signatures</title><author initials="D." surname="Bernstein" fullname="Daniel Bernstein"><organization>University of Illinois at Chicago</organization></author><author initials="N." surname="Duif" fullname="Niels Duif"><organization>Technische Universiteit Eindhoven</organization></author><author initials="T." surname="Lange" fullname="Tanja Lange"><organization>Technische Universiteit Eindhoven</organization></author><author initials="P." surname="Schwabe" fullname="Peter Schwabe"><organization>National Taiwan University</organization></author><author initials="B." surname="Yang" fullname="Bo-Yin Yang"><organization>Academia Sinica</organization></author><date year="2011"/></front></reference>