Re: [hiprg] RG last call on the DHT draft

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

Ari,

Thanks for your comments! 

Below I've replied inline about some changes made based on your review. This covers comments from both of your emails.

-Jeff

> Abbreviations in the title and abstract are not expanded.

fixed - expanded DHT and HIT

> s/provides/provided/ ?

could go either way (Bamboo still exists but OpenDHT does not) but I changed to "provided"

>     The definitions below are taken from
>     <http://opendht.org/users-guide.html>.
> 
> Should also some explaining text be taken from there since that user 
> guide doc may not be available later on?

yes, I've added some explanatory text about the different fields

>      The return code 3
>      indicates "failure" and is used for a modified OpenDHT 
> server that
>                   performs signature and HIT verification.
> 
> I think this needs more details (or a reference to the 
> section with more details).

added reference to Section 4

>       The server replies with an integer -- 0 for "success", 
> 1 if it is
>                "over capacity", and 2 indicating "try again".
> 
> What does "over capacity" imply? Try again later?

I added text from the OpenDHT users guide to explain these.

> 3.1. HIP name to HIT lookup
> 
>           put(SHA-1("name", HDRR([CERT]), [SHA-1(secret)])
> 
> I suppose there should be a closing parenthesis after "name". 
> And same issue with rm?

yes, good catch! fixed

> By the way, why is SHA-1 of HDRR needed in remove? Some 
> OpenDHT specific feature?

yes it is strange, this is dictated by OpenDHT; the remove is stored persistently by the DHT, some reasoning is available at the end of this FAQ: http://opendht.org/faq.html

>     If a certificate is included in this HIT record, the name used for
>     the DHT key should be listed in the certificate.
> 
> Should define which certificate field should be used for the DHT key.

added text about using the CN field of the DN of X.509.v3 certificate

>     The ttl_sec field specifies the number of seconds requested by the
>     client that the entry should be stored by the DHT server, which is
>     implementation dependent.
> 
> Could the TTL be also policy dependent?

yes, good point! added text "implementation or policy dependent"

> 3.2. HIP address lookup
> 
>           HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG) = get(HIT_KEY)
>           put(HIT_KEY, HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG),
>               [SHA-1(secret)])
>           rm(HIT_KEY, SHA-1(HDRR), secret)
> 
> These API descriptions are a bit hard to parse if you are not 
> familiar 
> with the syntax. Perhaps having a short paragraph after each 
> operation 
> would help (slightly edited second paragraph of this section 
> would be OK 
> for the get).

I added some introductory text about the syntax. I mention that the DHT operation is described in greater detail following the summarized notation.

> Wouldn't the HIT_KEY be better simply defined as "last 100 
> bits of the 
> HIT appended with 60 zero bits"? The current text with RFC4843 
> definitions seems a bit confusing for such a simple thing.

yes, good point, I simplified this definition per your suggestion

> Overall, the definition of the "key" and HIT_KEY are somewhat 
> confusing. 
> The next table seems to imply that HIT_KEY simply the 100 
> bits but later 
> in the section (after the tables) it is explained again.

I removed all references to "100-bit HIT_KEY" and stuck with the one definition of HIT_KEY

> typo: pusblished

fixed

> This note would be better already in the (end of?) section 2 
> where the 
> "application" and "client_library" are used the first time.

fixed this with added text in section 2

> 4. HDRR - the HIP DHT Resource Record
> 
>       HIP Header:
>         Packet Type = 20 DHT Resource Record (this value is TBD)
> 
> This should probably be added to the IANA considerations section.

added to the IANA considerations section

> RFC 2119 language without the "terminology section". This 
> could also be 
> problematic considering the informational status of the draft.

I dropped this RFC 2119 language

> Missing a reference to the CERT draft.

added references to the CERT draft

> More instances of RFC 2119 language.

I dropped this RFC 2119 language

> If a secret value was not used, shouldn't the old HDRR be 
> still removed?

the HDRR cannot be removed without a secret value (OpenDHT protocol limitation)

> Abbreviations are not expanded (RVS, and perhaps NAT too) and 
> missing a 
> reference to the RVS RFC. Since we're talking about NATs, could also 
> mention HIP relay and RFC 5770.

expanded RVS and added reference to RFC 5204. Even though a NATted host is mentioned, I don't feel we need to discuss RFC 5770 here, since it is supposed to be a simple example