Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
RFC 7374

Note: This ballot was opened for revision 14 and is now closed.

Alissa Cooper Yes

(Spencer Dawkins) Yes

Comment (2014-08-05 for -14)
No email
send info
In this text appearing in 4.5.  Service Lookups

   1.  If there is no successor of node n present in the just fetched
       ReDiR tree node (note: within the entire tree node and not only
       within the current interval) responsible for I(level,, then
       the successor of node n must be present in a larger segment of
       the identifier space (i.e., further up in the ReDiR tree where
       each interval and tree node covers a larger range of the
       identifier space).  Therefore, node n MUST reduce the current
       level by one to level=level-1 and carry out a new Fetch operation
       for the tree node responsible for at that level.  The
       fetched tree node is then analyzed and the next action determined
       by checking conditions 1-3.

I'm guessing that "conditions 1-3" mean "this paragraph and the two following", but I'm guessing. If I'm guessing right, I wish that could be clearer ... perhaps it would help to label the three conditions as "Condition 1/2/3"?

In this text appearing in 4.6.  Removing Registrations

   Before leaving the RELOAD Overlay Instance, a service provider MUST
   remove the RedirServiceProvider records it has stored by storing
   exists=False values in their place, as described in [RFC6940].

Am I remembering that these records are soft state and will time out and be removed eventually anyway? If I'm remembering correctly, I'm wondering if this needs to be a MUST, or if it's just good advice.

(Jari Arkko) No Objection

Comment (2014-08-06 for -14)
No email
send info
Nice read. Thanks.

(Richard Barnes) No Objection

(Adrian Farrel) No Objection

Comment (2014-08-05 for -14)
No email
send info
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...
       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 

Perhaps " 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.

(Stephen Farrell) No Objection

Comment (2014-08-07 for -14)
No email
send info
- 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.)

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2014-08-14)
No email
send info
Version -15 addresses my comments, and thanks for discussing them with me.

(Ted Lemon) No Objection

Comment (2014-08-07 for -14)
No email
send info
   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.

(Kathleen Moriarty) No Objection

Comment (2014-08-07 for -14)
No email
send info
Please Address the concerns pointed out in the SecDir Review:

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection