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
- [RAM] revised draft proposed definitions RJ Atkinson
- Re: [RAM] revised draft proposed definitions Eliot Lear
- Re: [RAM] revised draft proposed definitions Tony Li
- [RAM] Re: revised draft proposed definitions Stephane Bortzmeyer
- Re: [RAM] revised draft proposed definitions HeinerHummel
- Re: [RAM] Re: revised draft proposed definitions Brian E Carpenter
- Re: [RAM] revised draft proposed definitions Brian E Carpenter
- Re: [RAM] revised draft proposed definitions Russ White
- Re: [RAM] revised draft proposed definitions RJ Atkinson
- Re: [RAM] revised draft proposed definitions JFC Morfin
- Re: [RAM] Re: revised draft proposed definitions Scott W Brim
- Re: [RAM] revised draft proposed definitions Russ White
- [RAM] Re: revised draft proposed definitions Stephane Bortzmeyer
- Re: [RAM] revised draft proposed definitions Noel Chiappa
- Re: [RAM] revised draft proposed definitions Russ White
- Re: [RAM] revised draft proposed definitions Tony Li
- Re: [RAM] revised draft proposed definitions Michael