The meaning of the term "namespace" in addressing, computer
networking etc.
Established
2009-04-22 Robin Whittle rw@firstpr.com.au
Last
update 2009-07-31 Jump to the update
below. But with a new sub-page added 2011-11-02.
../ To
the main Ivip page, with background on scalable routing..
To a companion page: ../loc-id-sep-vs-ces/
, added 2010-01-12, on why Locator / Identifier Separation is not the
same thing as Core-Edge Separation, and why LISP, in spite of its name,
is an example of the latter and not the former.
Added 2011-11-02:
As part of the IETF discussion
LISP is not a Loc-ID Separation Protocol, here is a
page
lisp-not-loc-id/ on why the LISP protocol does not involve a new namespace and
so why it is not a Locator - Identifier Separation protocol. See also other threads
around this time, including "The death of John McCarthy - LISP, HIP & GSE". This
discussion began with criticism of the LISP protocol's name being the same as that of
the LISP programming language. To this discussion, Brian Carpenter
add:
Especially since the IETF "LISP" is a misnomer; it is not a
locator/identifier split. It's a global locator to site locator
mapping. This was pointed out some time ago...
Version
08
The
first version was 01. To see an
older version xx, use this directory name with index-xx.html added.
Please don't link to these.
Please suggest improvements and
let me know your critiques. I will incorporate them, link to them
or note them in some way.
Contents
>>>
Summary
>>>
Background
and links to mailing list discussions
>>> Formal
definitions of the term "namespace"
>>> IRTF
Name Space Research Group (NSRG) ca. 1999 to 2003
>>> IRTF
use of the term "namespace" in RFC 3869
>>> Use
of "namespace" in Noel Chiappa's late 1990's endpoints.txt and other
documents
Summary
The exact
meaning of the term "namespace"
has been the subject of debate on the LISP mailing list in March 2009.
This
page is primarily an attempt to analyse previous uses and definitions
of the term "namespace" in contexts similar to the current discussion.
Other
than the particular uses of "namespace" which I am critiquing,
I can find no use of the term which is incompatible with the definition
I assume for it. So I see no reason to believe there is some
other
significantly different definition of the term. I found two uses
of
the term which I regard as "misuses", one of them only a borderline
misuse. It is typical to find terms occasionally misused, or used
in a
way in which their meaning in the sentence tends to resemble something
for which another term would be more apt. But that doesn't
suggest to
me a meaning different to the widely accepted meaning was intended.
The
best definition I can find is listed below #best.
Since the people who used the term "namespace" regarding LISP in
ways I
am critiquing have not yet supplied an alternative definition, I stand
by my critique of these specific instances. |
Background and
links to mailing list discussions
I think the term "namespace" has been used
incorrectly in some discussions regarding the Internet's scalable
routing problem - in a way which is misleading to the reader. I
am not suggesting this was done on purpose, but since scalable routing
is hard enough to understand, I am keen to identify what I regard as
mis-statements which would, ideally, be corrected.
The
concern I have is that there have been
explicit claims
that LISP (which I assume is intended to be a practical solution to the
routing scaling problem) would or may involve separate namespaces for
"Locators" (RLOCs) and "Identifiers" (EIDs). My current
critique is linked to immediately below
#20090319
. First, I link to discussions which precede this.
Sometimes
this has been explicitly stated about LISP when I am sure it is not the
case (assuming LISP is to be a practical solution to the routing
scaling problem) .
In other cases I think the the term "namespace" is used in a way
regarding
LISP which
implies there are separate
namespaces for RLOCs and EIDs - but which
could simply be misusing the term
namespace
as if it was a synonym for "range of addresses" or something
similar.
For instance, 20.0.0.0/16 is a range of addresses, or subnet,
within the IPv4 global unicast address range, but it does not have a
separate
namespace from the
IPv4 global unicast namespace
.I
first raised
this in the Routing Research Group (
RRG) in
2007:
[RRG]
draft-irtf-rrg-design-goals-01
Other messages along these lines
were:
Re: [RRG] On "jack-down"
models
[RRG]
Hosts, DFZ, purity & incremental deployment
There were some threads:
Re: [RRG] On "jack-down" models -
independent namespaces
[RRG] Not
separate namespaces: Loc-ID-separation, map-encap etc.
#20090319 On
2009, on the LISP list:
Re:
[lisp] WG Review: Locator/ID Separation
Protocol (lisp)
Re:
[lisp] [ipdir] LISP WG:
Loc/ID
separation - not separate namespaces (and some other threads)
msg00273.html
RW 2009-03-18 Current
Critique part 1 Including
links to two current LISP I-Ds, an IETF Journal article, a NANOG
presentation and a mailing list message which all state or imply that
LISP involves separate namespaces for EIDs and RLOCs.
msg00274.html
Noel Chiappa
msg00275.html
Dino Farinacci
msg00288.html
RW 2009-03-19
msg00289.html
Dino Farinacci
msg00290.html
RW
msg00291.html
Dino Farinacci
msg00292.html
RW Current
Critique part 2, with links to where I think
namespace is used incorrectly,
including in two LISP Internet Drafts.
I should also have mentioned two other
presentations which are currently linked to from the
LISP site which state that LISP
involves separate namespaces for EIDs and RLOCs:
Both of them state:
Why Separate Location from ID?
Level of Indirection allows us to: Keep either ID or
Location fixed while changing the other Create
separate namespaces which can have different allocation
properties |
msg00293.html
John Zwiebel
msg00294.html
Sam Hartman (Co-chair of forthcoming LISP WG.)
msg00295.html
Sam Hartman
msg00296.html
Scott Brim
msg00298.html
RW << More specific now: The
IPv4/6 global unicast namespace.
msg00299.html
Sam Hartman
Links to this discussion continued below.
As
part of this discussion, Sam Hartman wrote(
msg00299.html 2009-03-20),
in part:
You've presented one definition of namespace. I strongly suspect that
there are a lot of other definitions floating around and that the term
was being used loosely. I have not seen a lot of support for your
strict definition of namespaces. However, I think that addressing
Bryan, Lixia and Margaret's concern needs to be addressed by making
this distinction clear. I think that avoiding the term namespace or
defining what we mean by namespace will be more productive than an
argument over its definition and whether we have found the clearly
correct definition for our field. At least as I understand it, your
proposed charter text change in this area seems to do this.
#20090322
In
response I wrote this web page, wrote to the LISP list and continued
the discussion:
msg00307.html
RW 2009-03-22 I can find only one definition of "namespace"
msg00309.html
RW
msg00310.html
Noel Chiappa
msg00325.html
RW, including a "mathematical" argument why LISP etc. can't be
practical with different namespaces for EID and RLOC.
msg00332.html
Noel Chiappa, stating that he believes that
one IP address ("bit pattern")
could be used both as an EID and as an RLOC:
So if it's
_possible_ to use the same bit pattern as
both an EID and an
RLOC, my guess is people
will do it,
no matter what the documents say. And my take is that,
because
of _other_ concerns (e.g. limiting routing
overhead), it will be
technically possible, which means
people probably will do it no matter what we say
in any
documents.
msg00335.html
RW: Noel has yet to explain how one IP address could be
used as an EID and as an RLOC. The statement that a single
address would typically not be used in both EID and RLOC roles is not
strong enough.
msg00336.html
Sam Hartman
Sam states "the rough consensus of
the participants so far is that there will be cases where the same IP
stands both as an EID and a RLOC."
This can only work if
there are separate namespaces for EIDs and RLOCs - read on where I
disagree that rough consensus can be seen to exist via the list
messages.
msg00338.html
RW 2009-03-25 "Consensus? EID and RLOC use of the same address =
separate namespace debate"
msg00339.html
RW 2009-03-25 "
EIDs MUST NOT be
used as LISP RLOCs." (Quoted from
draft-farinacci-lisp-12
.)
msg00356.html
John Zwiebel ("This does not say you can't use the same IP
address for an EID and for an RLOC.")
msg00365.html
Sam Hartman ("What do you mean that no EID is also an RLOC?
It's not clear to me that in interworking cases this is always true.")
msg00367.html
RW Response to above 2 messages and a link to a new LISP
presentation
lisp-2.ppt
which mentions separate namespaces.
msg00368.html
Dino Farinacci
msg00369.html
RW
msg00370.html
RW Response to Dow Street's suggested changes to draft Charter
which discusses namespaces.
msg00371.html
RW (2009-03-26) Radio silence on the LISP list for a week.
On
the LISP, IETF and IESG lists:
msg00380.html
Sam Hartman - draft Charter for review by IESG after discussion
on LISP list and in IETF 74 meeting.
(The next 3 are on the IETF
list.)
msg56375.html
RW (2009-03-30) Links to previous drafts. Draft still
contains erroneous statement about EIDs potentially being used as RLOCs.
msg56378.html
Sam Hartman. Noting (correctly) that LISP list participants
do not support my critique.
msg56379.html
RW (2009-03-31)
No-one has shown how
using an EID as an RLOC could work or where it is allowed for or
required in the LISP I-Ds.
Latest
messages here:
http://www.ietf.org/mail-archive/web/lisp/current/maillist.html
#20090730 The
debate sprang up again on the LISP list in late July 2009:
msg00747.html
RW (2009-07-30) to Noel Chiappa.
msg00748.html
Noel Chiappa responds, referring to the Mobile LISP I-D, which I
critique
here
and in other messages in that thread.
msg00751.html
RW (2009-07-30): "EID" and "RLOC" are roles - they have
never been and are not separate namespaces. Before Mobile LISP,
the set of addresses which could be used in an RLOC role was disjoint
from the set which could be used in an EID role. With Mobile
LISP, these are potentially overlapping sets.
Five messages and
my reply:
Formal definitions
of the
term namespace
The word
namespace does not appear in the
dictionaries I have to hand: Macquarie
Australian Encyclopedic Dictionary 2006; Concise Oxford 1982 or
Websters
International Dictionary 1890.
The earliest books in Google
Books (
search
term) I could find which used "namespace" in its modern,
data-processing sense, were Artificial Intelligence volumes from 1969.
(A 1918 Act of Parliament in Britain
here
used the term to describe something about ticking a candidate's name on
a ballot paper.)
Readily accessible web-based
definitions are:
As a noun:
A conceptual space that
groups classes, identifiers, etc. to avoid conflicts with items in
unrelated code that have the same names. |
(I think that in this
context, "code" means computer program source code.)
In general, a namespace is an
abstract
container providing context for the items (names, or technical terms,
or words) it holds and allowing disambiguation of items having the same
name (residing in different namespaces).
As a rule, names in a
namespace
cannot have more than one meaning, that is, two or more
things cannot share the same name. A namespace is also
called a
context, as
the valid meaning of a name can change depending on what
namespace
applies. ... |
#best
The
following seems like the
best
definition I have encountered:
A
namespace is
an abstract
container or environment created to hold a logical grouping of unique
identifiers or symbols (i.e., names). An identifier defined in a
namespace is associated with that namespace. The same identifier can be
independently defined in multiple namespaces. That is, the meaning
associated with an identifier defined in one namespace may or may not
have the same meaning as the same identifier defined in another
namespace. Languages that support namespaces specify the rules
that
determine to which namespace an identifier (i.e., not its definition)
belongs.
For
example, Bill works for company X and his employee
ID is 123. John works for company Y and his employee ID is also 123.
The reason Bill and John can be identified by the same ID number is
because they work for different companies. The different companies in
this case would symbolize different namespaces. There would be serious
confusion if the two men worked for the same company, and still had the
same employee ID. ...
|
However, for the last
section, I would write:
The
different companies in this case both use numeric names for employee
numbers, but each company has a different namespace in which those
numbers are interpreted.Some definitions in
formal documents:
.. An
expanded name is a pair
consisting of a namespace name and a local name. ... |
For
the purposes of URNs, a "namespace" is a collection of
uniquely-assigned identifiers. |
All
the above references concern
namespace
within the context of either computer programming or the process of a
system deciding which of multiple namespaces within which to interpret
text strings.
Google supposedly finds 39,000
pages in ietf.org which mention the term
namespace - so it is widely used in
this field. Generally, it seems, it is used for names which are
textual, including URNs and DNS names. I was unable to find
a formal IETF definition of the term.
IRTF Name Space Research Group (NSRG) ca.
1999 to 2003
The archived Charter
for the NSRG is:
The
NSRG was a closed group, with no public mailing list archives,
apparently
started in 1999.
The latest version of their I-D is from
September 2003:
According
to the RFC 3869 (below) and here
http://tools.ietf.org/html/draft-irtf-hip-experiment-05
, the NSRG did not reach sufficient consensus to make a final
recommendation, so the above mentioned expired I-D is all that seems to
remain from this work.
The above
mentioned
I-D does not contain any definition or use of "namespace" but there are
several uses of the term "name space", with no definition. In a
separate page, I highlight these:
irtf-isrg/
.
IRTF
use of the term "namespace" in RFC 3869
In this RFC, from August 2004, "namespace"
is used in a manner which enables some inferences to be made about the
meaning the authors ascribed to it:
Here
is some of the text:
3.2. Naming
The Internet currently
has several different namespaces, including IP
addresses, sockets (specified by the IP address, upper-layer
protocol, and upper-layer port number), Autonomous System (AS)
number, and the Fully-Qualified Domain Name (FQDN). Many of the
Internet's namespaces are supported by the widely deployed
Domain Name System [RFC-3467] or
by various Internet applications [RFC-2407,
Section 4.6.2.1]
3.2.1.
Domain Name System (DNS)
(...)
3.2.2.
New Namespaces
Additionally, the
Namespace Research Group (NSRG) of the Internet
Research Task Force (IRTF) studied adding one or more additional
namespaces to the Internet Architecture [LD2002]. Many members of
the IRTF NSRG believe that there would be significant architectural
benefit to adding one or more additional namespaces
to the Internet Architecture.
Because smooth consensus on that question or on the
properties of a new namespace
was not obtained, the IRTF NSRG did not
make a formal recommendation to the IETF community regarding
namespaces. The IAB believes that this is an open research
question worth examining further.
Finally, we believe that
future research into the evolution of
Internet-based distributed computing might well benefit from studying
adding additional namespaces
as part of a new approach to distributed
computing.
|
Use
of "namespace" in Noel Chiappa's late 1990's endpoints.txt and other
documents
Noel Chiappa's
unpublished draft of an
Internet Draft is cited in a number of documents and mailing list
discussions.
Its only location on the Net seems to be at his old
site:
There are at
least 44 instances of the word "namespace" in this document and in
my view,
they are all entirely consistent with the definitions above.
For
example:
2 Terminology of Naming and Binding
Before proceeding
to the technical details, it is important to understand
some definitions about objects, names, and related subjects.
The terms "object"
and "name" are hopefully self-explanatory: it
is crucial to differentiate between the thing itself, and any identifier
(in the generic sense) by which we refer to it. In this paper,
whenever the term "name" is used, unless otherwise explicitly indicated,
the meaning given to it is the generic one of "an identifier (of
no specific syntax or properties) for an object".
Thus, the phrase "name of a host" does *not* refer to an existing
system of printable strings (e.g "lcs.mit.edu"), or somesuch; it
refers, instead, to the abstract concept of an identifier for a host.
(The term "host-name" is used to refer to such printable strings, at
the possible risk of some confusion, because it is of long-standing use
in the networking community.)
This may seem confusing (and some might suggest use of a different
term for "name"), but the use of the term "name" in this manner
is established in the literature (along with subsidiary terminology
such as "namespace"),
and while use of the term "name" has perhaps
been confused in the networking community, it seems a major distraction
to try and tackle that issue now.
2.1 Bindings and Namespaces
The association
between a name and an object is called a "binding";
bindings may also map from one kind of name for an given object,
to another name. It is important to
realize that a single instance of an object (i.e.
a member of an "object class") may have more than one name. Moreover,
each of those names may be drawn from the same class of names (or
"namespace"),
i.e. a many-to-one binding; alternatively, each of the
names may be from a different namespace, i.e. multiple one-to-one bindings.
For example, the person writing this document is an instance of the
object class of humans, and has several names, from different kinds of
namespaces,
such as his 'name' name ('J. Noel Chiappa'), his Social Security
Number (a government supplied personal identification number in
the U.S.A.), etc. However, all the names refer to the same object; the
author.
2.2
Structure and Representation of Names
The *form* of the
names in a namespace
is usually driven by the use to which the name will be put. Any
structure in the name is usually intended
to make some operation on or with the name (be it looking it up
in a directory, or whatever) easier. For example, Unix filenames and DNS
names have hierarchical levels, indicated in the name, to allow them
to be looked up in hierachical directories. IP addresses have structure
in them to help them be routed.
Names may also have multiple "representations", or ways of encoding
the same individual name. For instance, the IP address "18.8.0.8"
(in decimal, printed notation) is the same exact name as the bit
string "00010010 00001000 00000000 00001000" in an IP packet header;
they are just different ways of encoding the exact same information,
just as 12 base 8, and 10 base 10, are the same number.
A collection of
bindings in which a system records and looks up the
connections is called a "context" (sometimes loosely referred to as a
"directory", although this term has other meanings). A context may either
map from names for objects to a direct attachment to the object, or
from one class of name for an object to another kind of name for the same
object, or perhaps some other useful mapping.
3
Existing Objects and Namespaces
in the TCP/IP Architecture
The TCP/IP architecture did not make a clear distinction between
objects and the names of those objects; it also used basically those
namespaces
which were in the existing NCP protocol architecture; i.e.
addresses, and
host-names.
3.1
IP Addresses
In fact, however, IP addresses are basically the *only* name used
throughout the TCP/IP architecture, however. They are:
(...)
3.2
IP Host-Names
The other existing namespace
in the TCP/IP architecture is that of
host-names. Host-names were, and remain, fairly peripheral in the TCP/IP
architecture. Host-names are human-readable strings, which now contain
built in hierarchical structure, and can be looked up in a distributed,
replicated, database called the Domain Name System [Mockapetris],
which maps from DNS names to IP addresses. |
#misuse1
Here is what I consider to be a misused of the term, from 1993 or 1994:
The only namespace
for nodes which
appears to be useful is a relatively short, fixed length,
pseudo-flat binary identifier.
|
I think this is a misuse of the term
according to the definitions above. The sentence concerns the
format of the names, which is quite a different concept from the more
abstract notion of a namespace as providing context by which names can
be interpreted. For any given format, such as a 32 bit binary
number, and including for any particular way of structuring the
meanings of the 2^32 individual names in this range (such as "flat" =
without hierarchical structure), there could be multiple separate
namespaces by which names of this format could be given meaning.
In practice, the only prominent namespace in computer networking
for 32 bit binary numbers is the IPv4 namespace.
Another usage which seems to be consistent
with the definitions above is:
One proposal is that each network attachment point be given a unique binary
flat identifier; this would allow the creation of multiple, independant,
structured namespaces
(i.e. address spaces), each of which have a separate mapping into
the first namespace
which identifies all attachment points. The claimed advantages are
that it would be possible to experiment with new addressing schemes,
or introduce a new one, or even operate with several different ones
in use at the same time.
|
a chunk of namespace might be allocated to an
organization, but it might further subdivide that chunk, and
allocate one part to an office in one location,
and another part to an office elsewhere. |
I am not at all trying to criticize Noel or
what he wrote. Just pointing out that like many terms,
"namespace" can sometimes be used in ways which may be technically
wrong, but look sort-of OK, or which are technically correct but also
suggestive (to me at least) that in some way the word is being used as
a synonym for something else, such as a "range of" addresses within a
linear "space".
(Noel has been contributing highly detailed
analysis on namespaces and Internet addressing since before I had ever
heard of the Internet.)
My point is that these occasional
borderline or (I think) incorrect usages of the term do not indicate
there is another meaning for the term. It is just too loose
a use of the term.
In my critique of LISP I-Ds, I think the term
has been used so loosely as to be misleading in the context of the
highly precise language expected in an I-D.
In my critique of
the IETF Journal article, an old 2007 NANOG presentation about
LISP-CONS
http://www.nanog.org/mtg-0710/presentations/LISP-cons.pdf
and the mailing list
message, I believe the statements are just plain wrong. There is
no evidence of there being another meaning of "namespace" which is
compatible with these statements being truthful. The usage is
either extremely sloppy or ill-informed, since in all my efforts to
understand LISP and the widely accepted meaning of "namespace" I cannot
see that a practical application of LISP to the scalable routing
problem really could involve separate namespaces for EIDs and RLOCs.
.