Re: [nbs] Preparing for a BoF about name-based sockets.

[Javier Ubillos <[e-mail]>]

(sorry for sending double copies, I messed up the recipient list on the
previous one).

On Wed, 2010-09-15 at 10:24 -0700, Dan Wing wrote:
> Here's the problem I see to get this going:  the only applications
> that have referral problems are applications that do referrals.  This
> is not a general problem for HTTP.  It is a general problem for 
> SIP/XMPP/RTSP, which have a separate signaling channel from their
> data channel.  The problem I see is how does "Grandma's computer"
> get a name?
> 
> All the APIs to *use* that name are neat, and absolutely necessary.  
> But if the computer doesn't have a way to get a name...  aren't
> we missing the important bootstrapping function? 

The way I see it, the lookup substrate is still undefined, and there is
not a single solution.

Today, in the draft we have:

"
   Names can be provided in any of three ways.

   o  FQDN.  The Fully Qualified Domain Name of the host.  This will
      allow e.g.  DNSsec to provide authenticity of the name.

   o  ip6.arpa.  Using one of the hosts interfaces addresses as a name.

   o  Nonce.  A one-use only session identifier.
"

This might very well be extended to include

   o  "Naming convention of your own choice."

The API can include a field indicating what kind of name this is (and
hopefully also have some sensible default).

This way, an application can choose lookup its substrate from a palette
of solutions.

Granma's computer can either be referred to by FQDN, IP, your favorite
lookup system and so on. Pick your favorite.

Method of NAT penetration would be coupled with this.
A naive example:
Let name-based sockets include Teredo, insert your name + teredo-address
into Kademlia. 
Without making any claims about performance, there's a recipe for
arbitrary name + NA(P)T transparency.

I don't think we'll have a silver-bullet solution that works for all.
We need to provide a set of solutions.

// Javier