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

[Ari Keranen <[e-mail]>]

On 07/12/2010 07:55 PM, Henderson, Thomas R wrote:
> All, This is the last call for comments on the HIP DHT Interface
> (draft-irtf-hiprg-dht-00). 
> http://tools.ietf.org/html/draft-irtf-hiprg-dht-00
> 
> The last call expires on July 26, 2010.  Please provide your input by
> then.  The goal is to prepare this document for IRSG review for
> publication as an IRTF stream RFC.
> 

Here's some comments on the draft. I read it only up to section 4, but I 
can see if I have time later to read the remaining sections too.


Cheers,
Ari

---

Abbreviations in the title and abstract are not expanded.


2. The OpenDHT interface

    While the Bamboo
    project provides the actual software running on the servers, here we
    will refer only to OpenDHT, which uses a certain defined interface
    for the XML-RPC calls.

s/provides/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?


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


      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?


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?

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


    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.

    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?


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


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.

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.


    |                | pusblished contained in the LOCATOR    |         |

typo: pusblished


    The application and client_library fields are used for logging in
    OpenDHT.  The client_library may vary between different
    implementations, specifying the name of the XML-RPC library used or
    the application that directly makes XML-RPC calls.

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


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.


    The Responder
    HIT (Receiver's HIT, DST HIT) MUST be NULL (all zeroes) since the
    data is intended for any host.

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