Re: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc.
Thomas Narten <narten@us.ibm.com> Fri, 03 August 2007 19:47 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 1IH37q-00048G-JE; Fri, 03 Aug 2007 15:47:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH37p-00048A-Vx for ram@iab.org; Fri, 03 Aug 2007 15:47:53 -0400
Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IH37p-0000NY-Ku for ram@iab.org; Fri, 03 Aug 2007 15:47:53 -0400
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l73Jlp46016357 for <ram@iab.org>; Fri, 3 Aug 2007 15:47:51 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l73JloAm475302 for <ram@iab.org>; Fri, 3 Aug 2007 15:47:50 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l73Jlofm013381 for <ram@iab.org>; Fri, 3 Aug 2007 15:47:50 -0400
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l73JlnOP013345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Aug 2007 15:47:50 -0400
Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id l73JljZ3027893; Fri, 3 Aug 2007 15:47:49 -0400
Message-Id: <200708031947.l73JljZ3027893@rotala.raleigh.ibm.com>
To: Robin Whittle <rw@firstpr.com.au>
Subject: Re: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc.
In-reply-to: <46B294D6.7070700@firstpr.com.au>
References: <46B294D6.7070700@firstpr.com.au>
Comments: In-reply-to Robin Whittle <rw@firstpr.com.au> message dated "Fri, 03 Aug 2007 12:37:10 +1000."
Date: Fri, 03 Aug 2007 15:47:45 -0400
From: Thomas Narten <narten@us.ibm.com>
X-Spam-Score: -4.0 (----)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
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
Robin Whittle <rw@firstpr.com.au> writes: > Here is something further to the discussion in the "First cut at > routing & addressing problem statement" thread on whether or not it > will ever be possible to have a completely automated method of > renumbering a network, here more arguments that it will never be > possible. > In that thread I argue that the RADIR Problem Statement should not > be written as if there was even a slight possibility that new > technologies could make today's networks reliably renumbered by some > automated means. Why is it important to do this? If it is feasible to do this, we shold. If it is not, we won't. Trying to rule it out as a possibility from the problem statement point of view makes no sense (IMO). The purpose of the problem statement is to define the problem, and not rule out _any_ solution, so long as it addresses the problem. (And no, I'm not about to argue that getting automatic/painless renumbering is about to happen. But let any proposed solution in that direction be evaluated on its merits please!). It's much more productive to focus on solution aproaches that folk think might be viable, than spending cycles trying to rule out approaches that aren't being pushed very heavily... > As far as I know, this notion of IPv6 end-users supposedly being > happy with PA space and automated renumbering has been going on for > ten years or so. Um, AFAIK, people have NOT been making this argument. 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