[nbs] Naming details for the API

[Ran Atkinson <[e-mail]>]

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