Re: [RAM] revised draft proposed definitions

Tony Li <tli@cisco.com> Tue, 12 June 2007 18:22 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 1HyB0F-0007u7-I9; Tue, 12 Jun 2007 14:22:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyB0E-0007tX-A3 for ram@iab.org; Tue, 12 Jun 2007 14:22:02 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyB0B-0001kV-24 for ram@iab.org; Tue, 12 Jun 2007 14:22:02 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 12 Jun 2007 14:21:58 -0400
X-IronPort-AV: i="4.16,412,1175486400"; d="scan'208"; a="62565078:sNHT45788714"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5CILwK8019068; Tue, 12 Jun 2007 14:21:58 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5CILe63014367; Tue, 12 Jun 2007 18:21:54 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 14:21:40 -0400
Received: from [192.168.0.101] ([10.82.217.158]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 14:21:39 -0400
In-Reply-To: <466E5B78.4090501@gmail.com>
References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> <466D69FC.3010003@cisco.com> <715690CE-8527-4123-9A09-101FC7EDF5EC@cisco.com> <466E5B78.4090501@gmail.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <538E4FBC-D624-4221-945C-7D1BACBB481A@cisco.com>
Content-Transfer-Encoding: 7bit
From: Tony Li <tli@cisco.com>
Subject: Re: [RAM] revised draft proposed definitions
Date: Tue, 12 Jun 2007 11:21:35 -0700
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 12 Jun 2007 18:21:40.0015 (UTC) FILETIME=[85495BF0:01C7AD1E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=976; t=1181672518; x=1182536518; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20<tli@cisco.com> |Subject:=20Re=3A=20[RAM]=20revised=20draft=20proposed=20definitions |Sender:=20 |To:=20Brian=20E=20Carpenter=20<brian.e.carpenter@gmail.com>; bh=FP93absRVoagPUdXY1mouseF18aiFuV4FpeCLA9PfmA=; b=f6pvOnX/7GucMMoVHez5Y7CkLr8+ERbH3zWJ4U0VXSLo+z+H5oiXqXgbJ5gmbBGPkN6o6ksO D7d1DG+mTdYhvaCKvrmSaGYzmbRFZOC2mh8JOLBTV2juIKOb+1qsVhEY;
Authentication-Results: rtp-dkim-2; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: RJ Atkinson <rja@extremenetworks.com>, ram@iab.org
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

>    Identifier: A binary quantity (not necessarily an IP Address) that
>    can be used by a Stack "A" to uniquely identify another Stack "B"
>    both for bilateral communication and for informing a third Stack  
> "C"
>    that it should communicate with Stack "B".  (Note that there is an
>    assumption in this definition that a Stack is the entity we require
>    to identify; in this era of virtualized servers with failover
>    capabilities, and of mobile clients, this seems to be a reasonable
>    assumption.)

Brian,

I have a minor quibble with this, in that it's really defining a  
stack identifier, not a generic identifier.

Any given proposal may choose to have identifiers at many levels  
(e.g. transport connection identifiers, interface identifiers, host  
identifiers, etc.) and the definition needs to either be sufficiently  
abstract so as to encompass all of these, or the term being defined  
needs to be qualified.

Tony

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