Re: [nbs] I-D Action:draft-ubillos-name-based-sockets-03.txt

[Javier Ubillos <[e-mail]>]

Hi Brian!
Thanks for the comments :)

On Sun, 2010-10-17 at 16:49 +1300, Brian E Carpenter wrote:
> Hi,
> 
> A few comments on the draft:
> 
> 
> >    Once the name exchange has been performed successfully the complete
> >    feature set will be made available to the communication
> >    automatically.
> 
> That sentence makes me feel very hungry. What are those features
> and where are they discussed?

Hungry is good :)
A good storyteller knows when to stop to keep his audience wanting
more ;)

The short answer is: so far, it is only the potential features mentioned
in e.g. the abstract.

I'm planning to revise the document and make a division between
un-lateral features and bi-latera.
Un-lateral ones are e.g. the API and IPv4/IPv6 agosticism (application
does not need to bother) and bi-lateral are e.g. the shim6 extension or
some future NAT-traversal solution.


> > 4.1.  Name format
> > 
> >    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.
> 
> Actually, doesn't DNSSEC prove authenticity of the name==address(es)
> equivalence? The name itself is just a character string.

You're right. I'll make it more clear that what is authenticated is the
name -> address mapping.

> > 
> >    o  ip6.arpa.  Using one of the hosts interfaces addresses as a name.
> 
> Why would I want to use this?

Another thing I should be more explicit about.
This is a construct for when a host does not have a name associated with
it. Then a name can be synthesized for it.
API-wize, the scenario could be that the IP is provided in a canonical
(sockaddr?) way, and internally is represented by a string.
This is an issue we're discussing.

> 
> > 
> >    o  Nonce.  A one-use only session identifier.
> 
> That really needs a lot more explanation.
> 
> In general the draft can't stand alone; it needs an NBS
> architecture document to go with. I'm sure that can be built
> out of Christian's existing document.

I agree. I would like to have an architecture draft and a draft for
every separate function (where the API would be its own draft).
I have the intention of doing this, it's on the to-do list.

> 
> > 6.  Security Considerations
> 
> Maybe it doesn't belong here, but we need a threat analysis,
> so that we can figure what the security issues are, and
> to what extent DNSSEC solves them.

I completely agree.
Both on the need and on whether or not this is the correct place for it.
I think such an analysis should cover the situation with and without
DNSSEC.

Again, thanks for the comments!

// Javier