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

Ari Keranen <> Fri, 16 July 2010 13:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D11843A6A0B for <>; Fri, 16 Jul 2010 06:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.211
X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, J_CHICKENPOX_47=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DNIiff9SsXMX for <>; Fri, 16 Jul 2010 06:38:15 -0700 (PDT)
Received: from (unknown [IPv6:2001:14b8:400:101::2]) by (Postfix) with ESMTP id 1AF8A3A68FC for <>; Fri, 16 Jul 2010 06:38:14 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B9B54E6D5; Fri, 16 Jul 2010 16:38:23 +0300 (EEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fagSm6LE2t7e; Fri, 16 Jul 2010 16:38:22 +0300 (EEST)
Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by (Postfix) with ESMTP id E177C4E6BF; Fri, 16 Jul 2010 16:38:21 +0300 (EEST)
Message-ID: <>
Date: Fri, 16 Jul 2010 16:38:21 +0300
From: Ari Keranen <>
User-Agent: Thunderbird (X11/20100411)
MIME-Version: 1.0
To: "Henderson, Thomas R" <>, "Ahrenholz, Jeffrey M" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [hiprg] RG last call on the DHT draft
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Jul 2010 13:38:17 -0000

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



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

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 

      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 

    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

          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.