Re: [P2PSIP] New draft: HIP BONE

Tom,

> Pekka, thanks for your responses (some more discussion inline below)

For some reason, I almost enjoy these exchanges.  :-)  Maybe I'm  
finally getting over some of my past painful experiences with the  
I*.  :-)

>>> There have been proposals to use DHTs to provide this service,  
>>> but they do not presently accommodate the possibility of multiple  
>>> DHTs, which is pretty much a requirement to handle, from my  
>>> perspective.
>>
>> That issue Gonzalo and I have discussed extensively.  On my part I  
>> still don't quite understand the requirement (as is probably  
>> visible from the previous exchange of message between you Tom and  
>> me).
>
> For a given system provided by a provider (example.com), only one  
> overlay is necessary.  But what happens when the user concurrently  
> gets a second provider (example2.com)?  The problem is that the  
> layer trying to resolve the flat identifier doesn't know where to  
> try to resolve it, unless there is metadata about the system that  
> holds bindings for that identifier.  What happens when the user  
> wants to enforce policy on what applications use which overlay, at  
> any given time, to resolve the identifiers?

I think there are a few potential solution categories:

a) add such metadata as an overall system configuration data (IPsec  
SPD is an example of this)

b) allow communicating such metadata through the API

c) multicast the initial request to all overlays.

Of course, each of these has their benefits and drawbacks.

> The Balakrishan et. al paper in Sigcomm 2004 (Section 4.1)  
> elaborated on why multiple name service providers will proliferate  
> in an architecture based on flat names: http://nms.lcs.mit.edu/ 
> papers/layerednames-sigcomm04.pdf

That's on my my reading list.  Don't have time to read it in detail  
right now.

> I do not think it is a show stopper issue, but one that HIP hasn't  
> addressed yet.

We seem to agree.

<The rest of the message was discussed in a separate subthread with  
Spencer, I think.>

--Pekka

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip