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

jnc@mercury.lcs.mit.edu (Noel Chiappa) Mon, 14 December 2009 21:43 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
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 732C83A6887 for <rrg@core3.amsl.com>; Mon, 14 Dec 2009 13:43:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.213
X-Spam-Level:
X-Spam-Status: No, score=-5.213 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
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 POGozhkfVpgN for <rrg@core3.amsl.com>; Mon, 14 Dec 2009 13:43:37 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id AECDD3A6894 for <rrg@irtf.org>; Mon, 14 Dec 2009 13:43:37 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 93DE66BE562; Mon, 14 Dec 2009 16:43:23 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20091214214323.93DE66BE562@mercury.lcs.mit.edu>
Date: Mon, 14 Dec 2009 16:43:23 -0500
From: jnc@mercury.lcs.mit.edu
Cc: 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: Mon, 14 Dec 2009 21:43:38 -0000

    > From: Brian E Carpenter <brian.e.carpenter@gmail.com>

    > I have a feeling that the mapping system should be very general in
    > nature, in case the first cut at either the locator or identifier space
    > proves to fall short.

There's an even better reason: to allow migration to new syntax (or new
namespaces) for each type of name. Consider: it's easier to start deployment
of a split in an existing namespace if both new namespaces have the same
syntax as the original one. It minimizes the number of things you have to
change, and also the cost of deployment, which makes it more likely you can
get a positive cost/benefit on the change - without which the deployment will
never happen. Once the split is more-or-less complete, then you can start to
think about changing the syntax, or having a new (parallel in function)
namespace.

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.

	Noel