Re: [rrg] Terminology (was: belated msg: further description of the recommendation process)

jnc@mercury.lcs.mit.edu (Noel Chiappa) Wed, 16 December 2009 01:08 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3077E3A6B33 for <rrg@core3.amsl.com>; Tue, 15 Dec 2009 17:08:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.408
X-Spam-Level:
X-Spam-Status: No, score=-6.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 pEwpiSiMXkRS for <rrg@core3.amsl.com>; Tue, 15 Dec 2009 17:07:59 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 2FA563A68A8 for <rrg@irtf.org>; Tue, 15 Dec 2009 17:07:59 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 772036BE58A; Tue, 15 Dec 2009 20:07:44 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20091216010744.772036BE58A@mercury.lcs.mit.edu>
Date: Tue, 15 Dec 2009 20:07:44 -0500
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [rrg] Terminology (was: belated msg: further description of the recommendation process)
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Dec 2009 01:08:00 -0000

    > From: Brian E Carpenter <brian.e.carpenter@gmail.com>

    > I was interpreting Noel to mean what we colloquially call an
    > "address space", whether identifier-addresses or locator-addresses.

Umm, to me "namespace" is a very general concept, implying _nothing_ about
either syntax, semantics, or what kind of things are being named. So, for
example, the set of legal variable names in C is a 'namespace'.

To me, an 'address space' is a more limited thing; although I can think of
two kinds: i) for a processor ('the PDP-11 had a 16-bit address space'),
and ii) for networking protocols ('PUP had a 16-bit address space' :-).


    > I have a little trouble with the IEN19 definition, since it clearly
    > uses "name" for what we now call identifier and "address" for what
    > we now call locator.

Well, it is 30+ years old! (And I don't think the author had had the
benfit of going through the Saltzer mill on generic naming concepts,
either... :-)

'Identifier' to me is still a very general term, implying _nothing_ about
either syntax, semantics, or what kind of things are being named (although
for me it tends to have a syntax bias towards 'not for human use', but
that's not absolute). Some people do seem to use it as close to a synonym
for what I call an 'Endpoint Identifier'; for others, it seems to mean
something close to the general concept 'name', except that to them it
means 'name with only identity semantics' (i.e. no location, etc).


I don't recall IEN-19 well enough to say with great certainty what I think
Shoch's terms "name" and "address" correspond to in modern (hopefully more
precise and widely-agreed-to) terms.

Quickly reading the first page, his use of 'name' ("The 'name' of a
resource indicates *what* we seek") could easily mean, for instance,
'service name'; it certainly seems to cover a very general group of kinds
of name. I'd almost say it's sort of a synonym for the 'identification'
property (i.e. names which have the property that they identify things).

Similarly, his 'address' ("an 'address' indicates *where* it is") is
almost a synonym for the class of names that have location semantics.

So, to me, his paper seems like it might run afoul of the classic Saltzer
maxim (RFC-1149):

  "trying to discuss the issues with too few well-defined concepts at
  hand"

in that he has too few terms defined.


The last couple of decades have, I think, shown us that by the time you
cross-product not just the syntax of the meta-names (i.e. a name for a class
of names), along with their semantics, but also _what_ kind of thing is being
named (interface, stack, etc, etc) we either need i) multi-part meta-names
(e.g. 'stack identifier'), or _lots_ of meta-names (e.g.  'locator' =
'topology-dependent interface name').

And even some of those can be divided further, e.g. by syntax: so we have
'fixed-length locators' (e.g. LISP RLOCs) and 'variable-length locators'...

	Noel