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

[Javier Ubillos <[e-mail]>]

On Wed, 2010-09-15 at 07:46 -0400, Ran Atkinson wrote:
> On 14  Sep 2010, at 22:07 , Dave Thaler wrote:
> > I think splitting the draft is a good thing,
> > and I have feedback on at least the API portion.  
> > Specifically, the API needs to use service names,
> > not integer port numbers.   getaddrinfo() already does so,
> > and section 7.2 of draft-ietf-tsvwg-iana-ports-06
> > will only make this more important.
> 
> Agreed.  
> 
> One hopes that any new API will be entirely name-based 
> (i.e. no "magic numbers").  One hopes the I-D will be 
> updated soon to reflect this.
> 
> Offering some entirely name-based APIs, as some programming
> languages (e.g. Java) already have done, enables well-behaved
> applications to work equally well not only over IPv4 and IPv6, 
> but also over SHIM6, LISP, MP/TCP, ILNP, or whatever else 
> might appear in future.
> 
> Yours,
> 
> Ran

That is exactly the plan! :)

To provide a thin naming convention, allowing arbitrary fun things
beneath it. Things that provide cool features I need not know about.
It also allows higher abstractions, as the Java one, to just pass the
name down to the socket layer, and reap the benefits of the available
features.

I'm also playing with a thought for the future:
Some form of "feature-negotiation" between two nodes. Where they e.g.
agree to use MP/TCP and/or ILNP.
This might be something for the BoF.

Out of scope for the BoF, but this might lead to some
"feature-arbitration framework". Perhaps as a part of larger "name-based
stack"-architecture. But, we will eventually need a way of having
different features play nicely with each other. For example the case
where we have Shim6, ILNP and MPTCP available, it wouldn't make sense to
stack INLP & Shim6 for each MPTCP (sub) flow.

// Javier