Re: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc.
Thomas Narten <narten@us.ibm.com> Wed, 08 August 2007 14:37 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 1IImez-0002aU-6O; Wed, 08 Aug 2007 10:37:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IImew-0002a7-C4 for ram@iab.org; Wed, 08 Aug 2007 10:37:14 -0400
Received: from e34.co.us.ibm.com ([32.97.110.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IImeu-0001tx-Fb for ram@iab.org; Wed, 08 Aug 2007 10:37:14 -0400
Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l78EbAEX025368 for <ram@iab.org>; Wed, 8 Aug 2007 10:37:10 -0400
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l78Eb9Um259802 for <ram@iab.org>; Wed, 8 Aug 2007 08:37:09 -0600
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l78Eb95H000908 for <ram@iab.org>; Wed, 8 Aug 2007 08:37:09 -0600
Received: from cichlid.raleigh.ibm.com (wecm-9-67-180-16.wecm.ibm.com [9.67.180.16]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l78Eb7mP000754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2007 08:37:09 -0600
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id l78EaopY023696; Wed, 8 Aug 2007 10:36:56 -0400
Message-Id: <200708081436.l78EaopY023696@cichlid.raleigh.ibm.com>
To: JFC Morfin <jefsey@jefsey.com>
Subject: Re: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc.
In-reply-to: <20070808120915.3EF841A359@smtp7-g19.free.fr>
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>
Comments: In-reply-to JFC Morfin <jefsey@jefsey.com> message dated "Wed, 08 Aug 2007 14:02:51 +0200."
Date: Wed, 08 Aug 2007 10:36:50 -0400
From: Thomas Narten <narten@us.ibm.com>
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
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
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 don't believe putting in a concrete timetable is possible. My sense from having participated in many discussions with many different people is that there just is no concensus on this point. TO make predictions, one has to make assumptions about future growth and trends that we have little confidence in, and that different people have very different views on. I'm not sure it makes sense to ask whether a "patch" or an "architecture change" is the way to go. IMO, the right answer is that we go with a solution that solves the problem in a meaningful way, and that we believe can actually be deployed. Whether or not that involves an "architecture change" or not is sort of an academic point. Let's see proposed solutions please, evaluate them on their merits, and then chose the approach that makes the most sense. Thomas _______________________________________________ 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