Re: [rrg] Next revision

Tony Li <tony.li@tony.li> Thu, 25 February 2010 18:27 UTC

Return-Path: <tony.li@tony.li>
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 9B71428C1E1 for <rrg@core3.amsl.com>; Thu, 25 Feb 2010 10:27:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.356
X-Spam-Level:
X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599]
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 rTTCb2kQjgzx for <rrg@core3.amsl.com>; Thu, 25 Feb 2010 10:27:38 -0800 (PST)
Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id C689428C16F for <rrg@irtf.org>; Thu, 25 Feb 2010 10:27:35 -0800 (PST)
Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta03.emeryville.ca.mail.comcast.net with comcast id mE0B1d0030QkzPwA3JVoFt; Thu, 25 Feb 2010 18:29:48 +0000
Received: from [171.70.245.129] ([171.70.245.129]) by omta02.emeryville.ca.mail.comcast.net with comcast id mJVY1d00H2oE8hF8NJVeYS; Thu, 25 Feb 2010 18:29:46 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Thu, 25 Feb 2010 10:29:31 -0800
From: Tony Li <tony.li@tony.li>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>, rrg@irtf.org
Message-ID: <C7AC018B.3AD5%tony.li@tony.li>
Thread-Topic: [rrg] Next revision
Thread-Index: Acq2SHiOe3J287LWCU6uwTVNq14hag==
In-Reply-To: <20100225034932.01C346BE61B@mercury.lcs.mit.edu>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [rrg] Next revision
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: Thu, 25 Feb 2010 18:27:39 -0000

Hi Noel,


> Some suggested improvements on a couple of them:

Thanks much.
 
> Yes, I know in some ways there are aspects of these that are problematic.

Agreed.  In fact, in our two previous attempts to get some kind of consensus
on terminology, we foundered right here.  This is exactly why I'm just
trying to expand abbreviations.

Of course, if we were to instantly and miraculously get consensus on
definitions, I'd be happy to incorporate them.

> If you think the second sentences in each are too problematic, feel free to
> drop them, but I would suggest keeping the extended first sentence, to give
> naive readers _some_ sort of vague idea of what an EID and RLOC are, beyond
> just saying "the precise definition varies depending on the proposal".

I'm inclined to do this, are other folks ok with this?

> And two more:
> 
> PA - Provider Assigned: Addresses which cannot be 'taken with you' when a
> site moves to a different location on the network connectivity
> structure; usually assigned by a service provider (hence the name).
> 
> PI - Provider Independent: Addresses which 'belong to' a site, and which stay
> with the site when it moves to a different location on the network
> connectivity structure; independent of any service provider (hence the
> name).
> 
> This gets to the _technical_ attributes of PI and PA, which are what is most
> important to us, rather than the _policy_ aspects.


The ARIN lawyers will freak over 'belong to'.

Tony