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

["Ahrenholz, Jeffrey M" <[e-mail]>]

Martin,
Thanks for your review. I've posted a -04 revision with changes mentioned here. Comments inline below.

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

Done: sections 3 and 4 are swapped, with a little introductory text (moved from the lookup section) at the beginning of the HDRR section.

> - 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 (?)

OK, I've added this sentence:
" For example,
  local policy may specify checking the name-to-HIT binding on a daily
  basis, while the address record is updated hourly for active peers."

Usually I keep HITs tied to a specific name for a long time (years), are there other thoughts on reasonable frequencies?  

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

I added a paragraph to the security considerations section. Is it enough? Any other thoughts on techniques the server should use to mitigate DoS?

> - 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. 
 
I re-worded this paragraph to include DHT slowness as impacting the latency.

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

Yes, more frequently than DNS, fixed.

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

Fixed.

> - Appendix A:
> Please add a note that this appendix should be removed by 
> the RFC editor (assuming that this is the intention).

OK, added the note to the appendix title.

-Jeff