Re: [rrg] belated msg: further description of the recommendation process

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 15 December 2009 22:17 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 1F20F3A6B11 for <rrg@core3.amsl.com>; Tue, 15 Dec 2009 14:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level:
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 Gi-5LoIuS5fH for <rrg@core3.amsl.com>; Tue, 15 Dec 2009 14:17:37 -0800 (PST)
Received: from mail-pw0-f48.google.com (mail-pw0-f48.google.com [209.85.160.48]) by core3.amsl.com (Postfix) with ESMTP id B185C3A6894 for <rrg@irtf.org>; Tue, 15 Dec 2009 14:17:37 -0800 (PST)
Received: by pwi6 with SMTP id 6so238277pwi.7 for <rrg@irtf.org>; Tue, 15 Dec 2009 14:17:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=lu0L7JLxJyQW4SHqKl+5rTXAFPaWc4tP3HXm3LUeefU=; b=KrOoJaR2rwNbFaRha+FTW8XDJLHFSYEtkgPVoLXvKRjjWwRjBmcCb5WxBS+BcAO8p7 URBDmerPUFHcBD2Qi45Dey7aZ0Wac1n+HnQV1mPYOXUvoNyhaIga9Zx6jJOLgSNWH/bZ g6vsXKtWy6nrrghZUXgwA5AcgtRx45lwJdLDE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=gfEyVVatVRMot2G6D7dv6IxOSXYFVzMbPgw8OKyUm/07Luuh1qXv6otM2xZ3m5cn20 V99NRRu/mhSEw1BlvvR3WVyD8RRrcfJQcyjsKrEswC/bjqYp1B8K48Mn254CocisI2x8 1COeLjDuIHn0OygbXgPQiRWF1ssZaJq3k+Keo=
Received: by 10.141.100.5 with SMTP id c5mr99332rvm.87.1260915444178; Tue, 15 Dec 2009 14:17:24 -0800 (PST)
Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 20sm174689pzk.5.2009.12.15.14.17.22 (version=SSLv3 cipher=RC4-MD5); Tue, 15 Dec 2009 14:17:23 -0800 (PST)
Message-ID: <4B280AF1.6060200@gmail.com>
Date: Wed, 16 Dec 2009 11:17:21 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Lixia Zhang <lixia@cs.ucla.edu>
References: <20091214214323.93DE66BE562@mercury.lcs.mit.edu> <4B26FB62.9020903@gmail.com> <038E0D74-27E8-480C-8CD8-664487B52CCE@cs.ucla.edu>
In-Reply-To: <038E0D74-27E8-480C-8CD8-664487B52CCE@cs.ucla.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: rrg@irtf.org, Noel Chiappa <jnc@mercury.lcs.mit.edu>
Subject: Re: [rrg] belated msg: further description of the recommendation process
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: Tue, 15 Dec 2009 22:17:40 -0000

Several replies in one message:

On 2009-12-15 19:30, Lixia Zhang wrote:
> 
> On Dec 14, 2009, at 6:58 PM, Brian E Carpenter wrote:
>> ......
>>
>>>
>>> Or, at least, that's my theory - and I'm sticking to it! :-)
>>>
>>>> Also I feel it should support hierarchy, even if we don't need a
>>>> hierarchy from the start.
>>>
>>> Hierarchy in the names in the namespaces, or a hierarchy _of_
>>> namespaces?
>>> Sorry, wasn't quite clear from your brief comment.
>>
>> I was thinking about a hierarchy of namespaces, but in fact we probably
>> need the generality to support hierarchical names too. I don't think that
>> needs to make the simple case inefficient. Just make a couple of the
>> basic
>> data definitions recursive, and you've got both hierarchies.
>>
>>   Brian
> 
> a clarification question: wonder what is the "name space" referred to in
> the above?

I was interpreting Noel to mean what we colloquially call an "address space",
whether identifier-addresses or locator-addresses. But namespace is
an abstract concept. I have a little trouble with the IEN19 definition,
since it clearly uses "name" for what we now call identifier and
"address" for what we now call locator.

On 2009-12-15 22:52, Tony Li wrote:

> Our recommendation is focused on providing an alternative routing architecture.  A mapping system is a fine component, but would not seem to provide a credible architecture by itself.

I agree, but what it means is that a routing proposal that requires a
mapping solution needs to specify it. I'm arguing that it needs to specify
it as a separable component.

On 2009-12-16 03:55, Noel Chiappa wrote:

>     >>> Also I feel it should support hierarchy, even if we don't need a
>     >>> hierarchy from the start.
> 
>     > I was thinking about a hierarchy of namespaces
> 
> To help me understand how this would work, could you give an example?

http://www.cs.auckland.ac.nz/~brian/layers.pdf

> 
>     > Just make a couple of the basic data definitions recursive, and you've
>     > got both hierarchies.
> 
> And an example of this too...

Oh, I was just thinking in BNF terms, or defining the namespaces
like DNS does. Not intended to be a profound statement.

But it does get you to variable length addresses,
locator = prefix suffix [locator]
or something like that.

   Brian