[RAM] Re: ID/loc mapping distribution protocol

jnc@mercury.lcs.mit.edu (Noel Chiappa) Sat, 21 April 2007 10:50 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 1HfDAZ-00074p-Gv; Sat, 21 Apr 2007 06:50:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfDAY-000728-AB for ram@iab.org; Sat, 21 Apr 2007 06:50:18 -0400
Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfDAX-0003rL-4E for ram@iab.org; Sat, 21 Apr 2007 06:50:18 -0400
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A6F48872E6; Sat, 21 Apr 2007 06:50:12 -0400 (EDT)
To: ram@iab.org
Message-Id: <20070421105012.A6F48872E6@mercury.lcs.mit.edu>
Date: Sat, 21 Apr 2007 06:50:12 -0400
From: jnc@mercury.lcs.mit.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: jnc@mercury.lcs.mit.edu
Subject: [RAM] Re: ID/loc mapping distribution protocol
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: Jari Arkko <jari.arkko@piuha.net>

    > the properties of the mapping system and protocol than to make a
    > decision on reuse vs. new protocol. Push vs. pull, dynamics, security
    > properties, trust model, scalability requirements, aggregated vs.
    > flat, etc. .. are the important questions now. ...
    > .. but lets not get hang up on the protocol selection just yet.

Definitely. First we should figure out what the optimal design would be,
and then we can look at what we already have and decide if we can reuse or
adapt something we already have. At that point, we will be in a position to
decide if what we save by reusing something outweighs the costs of using
something that's not exactly what we need.

Frankly, when I look at the lifetime these things will be deployed over (if
they are successful), along with the size of the deployed base if so, the
amount to be saved looks pretty miniscule in comparison. However,
realistically, the resources we might save over the life-cycle aren't
necessariliy available now, so we may be forced to incur costs down the
line by using something non-optimal.

	Noel

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