[nbs] Naming details for the API

RJ Atkinson <rja.lists@gmail.com> Thu, 02 December 2010 19:14 UTC

Return-Path: <rja.lists@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 18B393A69C9 for <nbs@core3.amsl.com>; Thu, 2 Dec 2010 11:14:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.141
X-Spam-Status: No, score=-3.141 tagged_above=-999 required=5 tests=[AWL=0.458, 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 mjrRNfpC0cqM for <nbs@core3.amsl.com>; Thu, 2 Dec 2010 11:14:05 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com []) by core3.amsl.com (Postfix) with ESMTP id D81A63A697A for <nbs@ietf.org>; Thu, 2 Dec 2010 11:14:04 -0800 (PST)
Received: by qwg5 with SMTP id 5so7639317qwg.31 for <nbs@ietf.org>; Thu, 02 Dec 2010 11:15:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=XipBkKh3f+LpZXNuGIWAJrTyrVCzbbJDZE8mzXWfQlY=; b=vi+MyvfmLNmvG46RFkQ6ZzHEEUs6GStbhwUb+mnFc0IMI/9X8ElNtLyT+QI385csXT RtgeFn/ZkDDL71x1LA/KBZAY1IgH7R6JQawPe8TgZTsBsf9kBLFgJbmDc7wTBcD1vkwj OgSPSWlNV62eRQ0a+uoMiOt+n8zMzE9XJl4BI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=LHNLYFis452nuSPCleVIJhNvhdEOIEjWkT9kBAspXXRB+WI4RO/M0hYkzu+qSEFvPS GXIbb2dJQGqsEtdP2JYQqPzr5o8XJqo1RlNK8Wj6r6tkr8zNYc5pb+C2eh0kjwSlquNo YFu10FiTphaY7kQaLNG1wsV7cEQ95AQdCeBxA=
Received: by with SMTP id r9mr352427qar.85.1291317320557; Thu, 02 Dec 2010 11:15:20 -0800 (PST)
Received: from [] (pool-96-225-170-25.nrflva.fios.verizon.net []) by mx.google.com with ESMTPS id m7sm579103qck.13.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Dec 2010 11:15:19 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: RJ Atkinson <rja.lists@gmail.com>
In-Reply-To: <3D421B6B-6324-4C3F-BD92-9FF2BD145923@gmail.com>
Date: Thu, 2 Dec 2010 14:15:16 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <0E053676-0258-45A9-9607-F4623D529D33@gmail.com>
References: <3D421B6B-6324-4C3F-BD92-9FF2BD145923@gmail.com>
To: nbs@ietf.org
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 19:14:06 -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