[hiprg] FW: Review of draft-irtf-hiprg-dht-03

["Henderson, Thomas R" <[e-mail]>]

Please see below Martin Stiemerling's IRSG review of the HIP DHT interface draft.  We will address these comments on the list and, once all comments are addressed, will initiate an IRSG Poll on the revised document.

- Tom

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Martin Stiemerling
Sent: Friday, June 24, 2011 3:40 AM
To: [e-mail]; Ahrenholz, Jeffrey M
Subject: [irsg] Review of draft-irtf-hiprg-dht-03

Dear all,

Here is my IRSG expert review of draft-irtf-hiprg-dht-03. 

In see the need for an updated of the draft to address my comments below.

General:
The draft is in a good shape, clearly describing the HIP DHT interface. It is a good source for somebody who wants to program this. 
Only the currently missing deployment of OpenDHT hurts a bit, as this is not yet usable anymore. However, this is out of reach of the authors. 

Structural:
I would swap the Section 3 and Section 4. Section 3 is relying on the knowledge about what the HDRRs are, but all of this is introduced in Section 4. This would improve the readability of the draft. 

Issues:
- Section 3, page 8, first paragraph on that page:
How often should a HIP peer check whether the name to HIT binding is still valid? The text only says that a check if needed, but there is no hint to the frequency, e.g., years, days, hours, minutes, seconds (?)
- Section 4, page 15, last paragraph:
This proposed server side checking could be source of a denial of service attack, as the DHT server would need to do some processing on its own. I would either remove this or document it well in the security section. 
- Section 6, page 18, 4th paragraph:
This latency considerations neglect the processing impact of the DHT itself. DHTs are not the fastest lookup mechanism in the world. This should also be documented as an impacting factor. 
 


Nits:
- Section 1, first paragraph:
"DHTs are also designed to support frequently updating"
What is frequently in this case? I would understand frequently in the range of seconds, but this may not be true for DHTs. DHTs can be updated more frequently than a DNS based approach and that is what you are probably trying to say here.
- Section 2, 3rd paragraph, 1st sentence:
" OpenDHT stores values using (hash) keys." 
This is incomplete. I would suggest to write
"OpenDHT stores values and indexes those by using (hash) keys."
- Appendix A:
Please add a note that this appendix should be removed by the RFC editor (assuming that this is the intention).

I'm available for any question or comment to my review.

With best regards

  Martin

[e-mail]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014