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

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

> Well, I'm not so sure the OpenDHT interface is ideal for this sort of
> application, but it is reasonably simple, and there is software out
> there that has been written to use it.  It's good for getting started
> with.

what is the ideal interface?
...that would be a great discussion for this list.

> In the introduction, mentioning that OpenLookup is not a DHT might
> avoid some misunderstandings.  Maybe something like this: "OpenLookup,
> while not a DHT, is another deployment of open source software
> compatible with the OpenDHT interface."

OK, good point, will add such text.

> Near the end of Section 3.1, the text incorrectly indicates that
> OpenDHT does not promise to honor the time-to-live.  I'll quote from
> "OpenDHT: A Public DHT Service and Its Uses"
> (http://opendht.org/f230-rhea.pdf):

this text about TTL was added due to concerns voiced by Stephane Bortzmeyer:
http://www.ietf.org/mail-archive/web/hiprg/current/msg00473.html

I don't know whether or not the server honors the TTL under heavy load. From that 2005 paper you quoted clearly they intended the TTL to be guaranteed. It seems that the server is supposed to return the "over capacity" code in that situation. I'd be fine with removing that text, it is only one or two sentences.

> Finally, the first paragraph of Section 6 incorrectly assumes that get
> operations return values in the order in which they were put into the
> DHT:
...
> Actually, the ordering of the returned values is determined by a
> cursor based on just the value and the secret hash.  That's how
> placemarks work.
> 
> Ken
> 

we may need to include something like the SEQ TLV in the HDRR, so that each record has an update id; then clients may retrieve all available values and use the most recent one

-Jeff