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
- [RAM] Renumbering impossibility: TSL/SSL certs, D… Robin Whittle
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Thomas Narten
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Gert Doering
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Stig Venaas
- [RAM] Re: Renumbering impossibility: TSL/SSL cert… Stephane Bortzmeyer
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Robin Whittle
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Olivier Bonaventure
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Robin Whittle
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Gert Doering
- [RAM] "End-users" & things I think warrant more a… Robin Whittle
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… JFC Morfin
- [RAM] Re: Renumbering impossibility: TSL/SSL cert… Stephane Bortzmeyer
- [RAM] Re: Renumbering impossibility: TSL/SSL cert… Stephane Bortzmeyer
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … Gert Doering
- [RAM] Re: Renumbering impossibility: TSL/SSL cert… Gert Doering
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … JFC Morfin
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … Thomas Narten
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … Gert Doering
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … JFC Morfin
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … JFC Morfin
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … Roland Dobbins
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … JFC Morfin
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Jari Arkko