[nbs] Naming details for the API

Ran Atkinson <ran.atkinson@gmail.com> Thu, 02 December 2010 16:46 UTC

Return-Path: <ran.atkinson@gmail.com>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 2315F28C18D for <nbs@core3.amsl.com>; Thu, 2 Dec 2010 08:46:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id aSJNJ+fRg-nL for <nbs@core3.amsl.com>; Thu, 2 Dec 2010 08:46:55 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com []) by core3.amsl.com (Postfix) with ESMTP id B337D28C154 for <nbs@ietf.org>; Thu, 2 Dec 2010 08:46:55 -0800 (PST)
Received: by gxk28 with SMTP id 28so4132666gxk.31 for <nbs@ietf.org>; Thu, 02 Dec 2010 08:48:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=7cnHvchCZ8haHia/mgF7wCcxEIPa01iWRjMMn88gcaU=; b=KfPhfRbGQCph7yP6gkGK8WNh6y8lvdaOpQa4YjP3D32Z1ZInTa+NOMn9kgeAq+xTZy L8dGOawJNxOsQ6arnA6sI7aoJ+EDQ3opYJozZxa/vMuSUyja/CeTKBajxkTgveOiWKUC SqpK4VrNC4dhzoSpkTSHi7+ODvKn5IeDbKHKM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=PbxJPWbFQm12CR3zD+GI8vhy7XG06MteB4vGqPVN88zBqs38dd+Me3jJfi3CBMl9zn hUKrJflUizSSPObi5NoYG53kRNkFbmu40NCxW6CogHYrgOQYKjlVZ+emUyTl/vvYsSXe A3Thop4ltkEUPIdBMeMbTi1u3M8uCDCvw+MXc=
Received: by with SMTP id y14mr220788qck.157.1291308491114; Thu, 02 Dec 2010 08:48:11 -0800 (PST)
Received: from [] (pool-96-225-170-25.nrflva.fios.verizon.net []) by mx.google.com with ESMTPS id x9sm479873qco.46.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Dec 2010 08:48:10 -0800 (PST)
From: Ran Atkinson <ran.atkinson@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Thu, 2 Dec 2010 11:48:07 -0500
Message-Id: <3D421B6B-6324-4C3F-BD92-9FF2BD145923@gmail.com>
To: nbs@ietf.org
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
Subject: [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: Thu, 02 Dec 2010 16:46:57 -0000


(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

    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.

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




[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