Re: [RAM] revised draft proposed definitions

jnc@mercury.lcs.mit.edu (Noel Chiappa) Tue, 12 June 2007 14:21 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7Fa-0005cM-Qs; Tue, 12 Jun 2007 10:21:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7Fa-0005cG-0o for ram@iab.org; Tue, 12 Jun 2007 10:21:38 -0400
Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy7FZ-0006lk-Pa for ram@iab.org; Tue, 12 Jun 2007 10:21:37 -0400
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0D73087328; Tue, 12 Jun 2007 10:21:37 -0400 (EDT)
To: ram@iab.org
Subject: Re: [RAM] revised draft proposed definitions
Message-Id: <20070612142137.0D73087328@mercury.lcs.mit.edu>
Date: Tue, 12 Jun 2007 10:21:37 -0400
From: jnc@mercury.lcs.mit.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: jnc@mercury.lcs.mit.edu
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

    > From: Russ White <riw@cisco.com>

    >> Ok, but a locator does NOT denote reachability. Thus, a locator is a
    >> string of bits that indicates a topological location.

    > I think we should, perhaps, leave reachability out? It seems like both
    > a locator and and id indicate some element of reachability (?).

Russ, reachability is a very different kind of thing, more an operational
property (i.e. a property of a name in particular circumstances in an
functioning system) , rather than a semantic one (i.e. an inherent property
of a particular name).


To give some examples, let's use 'IPvN address', which has relatively well
understood properties (since differing definitions are a real problem in this
discussion), but has the same "indicates a topological location" property as
"locator". Assume I have a host H at a site S, which is connected to the rest
of the Internet via router R; H, S and R all have an IPvN addresses.

For the first example, if the cable which connects H to the rest of the world
is unplugged, it still has a correct and authorized IPvN address, but it is
no longer reachable (from anywhere). For a slightly more complex example,
consider the situation, but this time the link connecting R and the rest of
the world is unplugged. In this case, H is still reachable from hosts inside
S, but not from the rest of the world.


So we can see that "reachability" is not a property of an address, but a
property of a tuple, (source, reachable_destination). Moreover, depending on
the actual network connectivity, and the contents of the routing tables,
reachability of a particular (source, reachable_destination) tuple can vary
over time.

So, yes, because reachabilty is an operational property, and not an inherent
semantic property, it definitely should be placed in a separate category
(although any definitions document might useful explain the above).

	Noel

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram