Re: [hiprg] draft-ahrenholz-hiprg-dht-05

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

> -----Original Message-----
> From: Ahrenholz, Jeffrey M
> Sent: Wednesday, September 09, 2009 12:10 PM
> To: [e-mail]
> Subject: [hiprg] draft-ahrenholz-hiprg-dht-05
>
> The DHT draft has been updated to
> draft-ahrenholz-hiprg-dht-05. Here are
> the changes:
> - Reordered Sections 3.2 and 3.1, since the HIT lookup normally occurs
>   before the address lookup.
> - Added text about why two separate lookups are defined.
> - Added text pertaining to the OpenDHT service retiring.

Jeff,
Here are a few questions/comments on the DHT draft:

1) "The current DNS system does not provide a suitable lookup mechanism for these flat, random values, and has been heavily optimized for address lookup."

Oleg Ponomarev's draft (draft-ponomarev-hip-hit2ip-04.txt) suggests that DNS could be used in some situations, so maybe this statement needs to be relaxed, and a reference added.

2) In section 3, regarding the HIT lookup service, should we allow somehow for the possible extension that a user could put a name record that also had a certificate that bound the name to a HIT?  This may allow security to be introduced into this service, such as:  1) when the server authenticates the put() based on certificate, or 2) when the client authenticates the name-to-HIT binding based on certificate retrieved.

3) is it possible for a put() to fail?  If so, how should an implementation handle that event?

4) Section 4:  "Note that this HDRR format is different than the HIP RR used by the Domain Name System as defined in [RFC5205]."  It may be helpful to mention here that the reason it is different is that it is a different record from a functional point of view:  in DNS, the query key is a FQDN, and the return value is a HIT, while here, the query key is a HIT.

5) Should the reader of this HDRR verify that the SRC HIT and DST HIT values are correct, and discard if not, or be permissive about these values?

6) In the last paragraph of section 4, it starts to describe HIP-aware DHT behavior, but then says that it is out of scope.  What would be required to go ahead and specify the HIP aware interface in this draft?  In this case, the put() may fail (see #3 above) and this failure would need to be conveyed to the client somehow.  Is there anything else required to extend the scope to also allow for HIP-aware DHT servers?

7) Section 5's title could probably just be simplified to read "Use Cases"

- Tom