Subject: [nbs] Naming details for the API

From: Ran Atkinson <[email-masked]>
Date: Thu, 2 Dec 2010 11:48:07 -0500

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].

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.

 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).

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.

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).

Cheers,

Ran

REFERENCES:

[1] http://www.ietf.org/id/draft-ietf-tsvwg-iana-ports-09.txt
[2] http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt
[3] http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 2 Dec 2010 14:15:16 -0500

Hi,

A) Service Names

2) End-point Names

A) UNICAST:

B) MULTICAST:

3) Network-Layer Details

4) Other topics

Cheers,

Ran

REFERENCES:

---

From: Javier Ubillos <[email-masked]>
Date: Mon, 06 Dec 2010 16:32:33 +0100

>  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.

>    DNS names are also allowed (e.g. host-name.local) -- for

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.

>    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?

>  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. 

>  (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