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

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

Tom,

Thanks for your comments, all should be addressed by draft-ahrenholz-hiprg-dht-06.

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

relaxed that statement and referenced Oleg's draft

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

changed the HIT lookup service to use a HDRR with optional CERT TLV

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

added a failure code for the case when HIT verification fails; the other OpenDHT return codes are also covered in the draft
 
> 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.

added this clarification text

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

yes, SRC HIT must match HIT_KEY and HI, and DST HIT is NULL

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

added such text to the latest draft
for the put(HIT, HDRR), the server verifies that the HIT and SIGNATURE match the include HOST_ID; the server can also verify the optional certificate for the name lookup

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

fixed

-Jeff