Re: [nbs] Naming details for the API

Javier Ubillos <jav@sics.se> Mon, 06 December 2010 15:31 UTC

Return-Path: <jav@sics.se>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 685AE3A6826 for <nbs@core3.amsl.com>; Mon, 6 Dec 2010 07:31:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.218
X-Spam-Level:
X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[AWL=-1.957, BAYES_00=-2.599, FRT_STOCK2=3.988, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 929B5ilfmU5a for <nbs@core3.amsl.com>; Mon, 6 Dec 2010 07:31:12 -0800 (PST)
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 7D4EC3A6816 for <nbs@ietf.org>; Mon, 6 Dec 2010 07:31:12 -0800 (PST)
Received: from [193.10.66.63] (bit.sics.se [193.10.66.63]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 1417540005; Mon, 6 Dec 2010 16:32:35 +0100 (CET)
From: Javier Ubillos <jav@sics.se>
To: RJ Atkinson <rja.lists@gmail.com>
In-Reply-To: <0E053676-0258-45A9-9607-F4623D529D33@gmail.com>
References: <3D421B6B-6324-4C3F-BD92-9FF2BD145923@gmail.com> <0E053676-0258-45A9-9607-F4623D529D33@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-byfQtS7hzckawKPqtZLP"
Date: Mon, 06 Dec 2010 16:32:33 +0100
Message-ID: <1291649553.2046.42.camel@bit>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Cc: nbs@ietf.org
Subject: Re: [nbs] Naming details for the API
X-BeenThere: nbs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nbs>
List-Post: <mailto:nbs@ietf.org>
List-Help: <mailto:nbs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Dec 2010 15:31:15 -0000

On Thu, 2010-12-02 at 14:15 -0500, RJ Atkinson wrote:
> Hi,
> 
> (I apologise if this entire note is too obvious and
> redundant with the existing text.)
> 
> 
> A) Service Names
> 
>  I would urge that any name-oriented API use "Service Names", 
>  in lieu of transport-protocol and port number.
> 
>  Section 5 of [1] provides a workable formal definition -- 
>  both for the set of valid "Service Name" values and also 
>  for the mapping of "Service Name" to a specific 
>  (transport-protocol + port number).
> 
>  It would also be good if the NBS API documentation urged
>  implementations of the API to use DNS SRV records and also
>  to look for mDNS/DNS-SD advertisement traffic.  Both mDNS
>  & DNS-SD are widely deployed already, for all major OSs 
>  (Windows, BSD Unix, Linux, Solaris, MacOS X, iOS, etc.).
>  I believe the IETF is currently in Last Call to publish
>  both of those specifications on the IETF standards-track.
>  In this light, it is probably also worth citing [2] and [3].

I think using SRV records is generally a great idea.
Ofcourse, it shouldn't be a requirement. But fetching a couple of
defaults from the SRV record which may be allowed to be overridden in
the API sounds very healthy.

> 
> 2) End-point Names
> 
> A) UNICAST:
>    DNS FQDNs are the obvious choice here, where local-scope 
>    DNS names are also allowed (e.g. host-name.local) -- for
>    use with mDNS/DNS-SD.

Agreed.
About local-scope or not. We need some method of handling referrals, but
in general, the scope is defined by the name-space. NATs are an obvious
problem, but I'm convinced it's solvable.
Either per definition in the application (the app explicitly asks for
NAT to be penetrated) or implicitly through some internal logic.
I'd like to see that the default behavior includes the use of STUN, ICE,
Teredo or some alternative.

> B) MULTICAST:
>    I'm not sure what to do about naming IP multicasting.  
>    Clearly multicasting needs to be supported, but the best 
>    way to name dynamic IP multicast groups isn't obvious to me.
>    I think some convention either exists (or could be created)
>    for standardised IP multicast groups (e.g. All routers,
>    All hosts, All OSPF routers).
> 

Can't you "just" put a 244. address in DNS (A-record?) and let the
socket deduce multi-cast from that?

> 3) Network-Layer Details
> 
>  I'd suggest that any name-oriented API be devoid of 
>  version-specific or network-protocol-specific details.
> 
>  That is, the exact same API ought to work well for all
>  of the network-layer protocols active in the IETF/IRTF
>  universe these days (e.g. HIP, ILNP, IPv4, IPv6, SHIM6
>  [what did I miss ?] -- listed in alphabetical order).
> 
>  Omission of CLNP/TP* from the above list is deliberate,
>  but only because it has negligible deployment now, and 
>  will have less (or zero) deployment in future.

I completely agree. That's the whole point. Today, we have
setsockopts() ,getsockopts() and ioctl() which are typically used for
all that functionality which is not grasped by the traditional socket
interface.
I think that we need to retain this kind of functionality, where the
application can get and set non-conventional options. This probably also
means that some call-back like functionality is needed. E.g. to let an
application know that the IPs used have changed. 

> 
> 4) Other topics
> 
>  I need to think more about things like support for use
>  of [ESP, AH], and maybe some other specialised things
>  (e.g. transport-protocol-specific nonces).

Again I completely agree. I think this can be managed by a set of
control mechanisms similar to get/setsockopt().

Is any one out there aware of some taxonomy/ontology of communication.
It would be nice, if it was possible, to classify all possible
communication. If it turns out to be impossible, a rich API should still
be able to handle unforeseen extensions using the get/set parts of the
interface.

// Javier