Re: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc.

JFC Morfin <jefsey@jefsey.com> Wed, 08 August 2007 19:14 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 1IIqzC-0003qb-NV; Wed, 08 Aug 2007 15:14:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIqzB-0003qW-Rp for ram@iab.org; Wed, 08 Aug 2007 15:14:25 -0400
Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIqzA-0000UA-C0 for ram@iab.org; Wed, 08 Aug 2007 15:14:25 -0400
Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id CB2481A3AD; Wed, 8 Aug 2007 21:14:23 +0200 (CEST)
Received: from asus.free.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id 8054B1A360; Wed, 8 Aug 2007 21:14:23 +0200 (CEST)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 08 Aug 2007 18:25:08 +0200
To: Thomas Narten <narten@us.ibm.com>
From: JFC Morfin <jefsey@jefsey.com>
Subject: Re: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc.
In-Reply-To: <200708081436.l78EaopY023696@cichlid.raleigh.ibm.com>
References: <46B294D6.7070700@firstpr.com.au> <20070803095100.GF69215@Space.Net> <46B8971C.3020008@firstpr.com.au> <46B89D78.8090407@uclouvain.be> <46B8ABA9.3090209@firstpr.com.au> <20070807184914.GG69215@Space.Net> <20070808091452.GA12605@nic.fr> <20070808092346.GT69215@Space.Net> <20070808120915.3EF841A359@smtp7-g19.free.fr> <200708081436.l78EaopY023696@cichlid.raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-Id: <20070808191423.8054B1A360@smtp7-g19.free.fr>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: 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

At 16:36 08/08/2007, Thomas Narten wrote:
>JFC Morfin <jefsey@jefsey.com> writes:
>
> > 2) Thomas, I think there is something missing in your summary: a
> > calendar. Time to get a solution, and how long it is expected to
> > stay. This will say if what is looked for at this stage has to be a
> > patch or can be an architecture. We need to see that clarified first.
>
>I'm not sure it makes sense to ask whether a "patch" or an
>"architecture change" is the way to go.

Dear Thomas,
You talk of change. I do not. As you know I think the Internet can 
sustain the difficulty with the existing machines and architecture, 
but not in the way it is understood (paradigme) today by most of IETF 
participants, with their resulting solutions. Ex. the early XXth 
century did not build big high-ways to support huge cavalcades to 
transport an increasing number of people, they accomodated cars.

This is why things must be organised. Not only between the IETF 
refinement you propose to avoid IPvnat solutions. Also, a paradigme 
change must be studied in parallel for a part of the time we have. If 
there is no time table for that, you know this will not happen (this 
would have happened already). This study must be conceived as a 
possible solution path but also as a way to further the other 
solutions through a better knowledge of the real needs evolution, of 
the hidden capacities of the existing solutions.  At the end of the 
period there will be a decision: to drop the issue and to focus on 
the then consensual possibility or to pursue in the best way which 
will have been discovered.

Otherwise, the new paradigme (distributed vs. decentralised) will 
continue to develop by its own, in diverse places, and the day it is 
accepted by the market it may result into a dramatic investment waste 
if the solution IETF developped does not match its growth orientations.
jfc


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