Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
draft-ietf-p2psip-service-discovery-15

I was surprised that I could follow all of this document. Good job by
the authors!

I have no objection to its publication, but I note a couple of points
below that I think could improve the document. I shouldn't be surprised
if the Security ADs pounce on something similar to the last point.

---

The scaling problem described in Section 1 is real in as much as it is
clearly a problem that deteriorates in a linear fashion with the number
of services. Furthermore, the problem worsens in the product of the
number of services and the number of nodes making discovery requests.

This is all as described in the text.

What is missing, however, is an explanaiton of why this is perceived to
be a problem that needs to be solved. For example, if there is only
ever going to be one service provided by one server, and only five nodes
requesting the service then clearly nothing sophisticated is needed. The
text in this section calls out four example services which suggests to 
the naif reader that growth to twelve service types might not be 
unreasonable. No clue is given as to the size of the cohort requesting
discovery, nor to the multiplicity of service-providing nodes.


It might, therefore, be interesting to enhance this section with some
clues about current expectations of scaling requirements and also with
an observation that we usually under-estimate scaling requirements in 
the Internet.

---

If this document uses terminology from [I-D.ietf-p2psip-concepts], don't
I need to read that document to understand this one? If so, that makes 
it a normative reference.

---

In Section 4.5 the following text was slightly confusing...
       The
       fetched tree node is then analyzed and the next action determined
       by checking conditions 1-3.
...because (I think) this text is embedded in condition 1 of the 3 
conditions.

Perhaps "...by checking the three conditions set out here" or even 
"...MUST determine the next action by starting to check the conditions
listed here starting at condition 1."

Or maybe I was just confused and the text is OK :-)

---

Why are there no security considerations? You are using existing 
(securable) protocol mechanisms to achieve a new function. Attacks on
service discovery are likely to have "interesting" effects either
denying services or redirecting traffic requesting a service to a
false server. That means that you have defined some new threats 
(including, I think, the fact that requesting service discovery reveals
a certain amount of information about the requester).

Surely you need to describe these threats and explain how existing 
security mechanisms in the protocol are adequate protection.

Version -15 addresses my comments, and thanks for discussing them with me.

Nice read. Thanks.

Please Address the concerns pointed out in the SecDir Review:
http://www.ietf.org/mail-archive/web/secdir/current/msg04958.html

- 4.3 step 5 - this implies that anyone can rewrite the Redir
information for anyone else. Is that right? If so, why is that
ok? I do see section 5, but I didn't get how that really works
- can you explain? (To someone who's forgotten RELOAD mostly;-)

- ISTM that the first sentence of section 9 is contradicted by
the 2nd paragraph of section 9. I'd say just delete the first
sentence there. (As noted by others.)

- WRT the secdir review, I'm not sure SHA-1 is ok for the
access control policy - can you explain why it is? (If we
assume SHA-1 is broken for collisions.)

   Since RedirServiceProvider records are expiring and registrations are
   being refreshed periodically, there can be certain rare situations in
   which a service lookup may fail even if there is a valid successor
   present in the ReDiR tree.  An example is a case in which a ReDiR
   tree node is fetched just after a RedirServiceProvider entry of the
   only successor of k present in the tree node has expired and just
   before a Store request that has been sent to refresh the entry
   reaches the peer storing the tree node.  In this rather unlikely
   scenario, the successor that should have been present in the tree
   node is temporarily missing.  Thus, the service lookup will fail and
   needs to be carried out again.

Why not just require that the node registering a service update its entry in the service table at some fraction of the expiry time, rather than after it has expired or when it expires?   E.g., 90%, or 50%, or something like that.