Re: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc.
JFC Morfin <jefsey@jefsey.com> Wed, 08 August 2007 22:58 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 1IIuTv-0005NM-DN; Wed, 08 Aug 2007 18:58:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIuTt-0005Mq-V8 for ram@iab.org; Wed, 08 Aug 2007 18:58:21 -0400
Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIuTs-0004em-GI for ram@iab.org; Wed, 08 Aug 2007 18:58:21 -0400
Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 916981A31F; Thu, 9 Aug 2007 00:58:19 +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 3E43018312; Thu, 9 Aug 2007 00:58:15 +0200 (CEST)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 09 Aug 2007 00:58:16 +0200
To: Gert Doering <gert@space.net>
From: JFC Morfin <jefsey@jefsey.com>
Subject: Re: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc.
In-Reply-To: <20070808180833.GG69215@Space.Net>
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> <20070808180833.GG69215@Space.Net>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Message-Id: <20070808225815.3E43018312@smtp7-g19.free.fr>
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: Robin Whittle <rw@firstpr.com.au>, Olivier.Bonaventure@uclouvain.be, 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 20:08 08/08/2007, Gert Doering wrote: >Guess why IPv6 (with "dedicated networks of incredible size!!") wasn't >a huge success with end users? Because they *don't care* about how >the network works, and whether they have a static for dynamic IP address. I am really sorry Gert, but this is not the case. This is a recurrent disagreement I have with the "technical" side of the TF, and a support from the user side (and leadership). The reason why the users are not interested in IPv6 is because they have no incentive to use their addressing part because it is not protected by any standard, what shows them the IETF has not understood their need so it is not an exciting thing to consider as it is not supported. And ROAP is the proof. You are concerned by the number of address for the network, they are concerned by the number of their own addresses and how they can distributed them across the world. I know we disagree. Even Thomas who asks for inputs for his summary does not want to take into account an UP (User Protected) addressing area. This is why I ask if we want more than a patch. (But I also way that the current technology under a different paradigm should support the need, because the need is for more and more addresses, not for traffic). This is why I do not mind much about the solution you will find - all I need is virtual bandwidth we can organise with the true addressing we need. Obviously this will inelegantly and costly pile unnecessary layers ... I work on semantic addressing, distributed translation memories, referential systems. Address grids are certainly every user most demanding IP¨v6 address applications I know - right now. Billions of metadata having its own ID in thousands of languages (have you only considered what the RFC 4646 or a semantic network may require in terms of hardware access to be workable). This is where the IETF decentralized paradigm is totally outdated. At most the entire network may need 30 billions of user addresses. This is very small when compared with plug and play multilingual semantic sub-addressing grids on a family SNHN (small network home network). SNHN are the core of the Internet. And you doubt they only need a single IP ..... Please think distributed fractal networking, and stop thinking decentralized host access supporting unified Google information in a single language and a single presentation layer. That was academic test 30 years ago. You certainly heard about what is an ontology and a thesaurus. The largest taxonomy is probably a Dutch dictionary with 450.000 words. Add all the names of all the people, all the possible conceptual adjencies, etc. This is what every user need just to talk with his own computer, like Hall in Space Odyssey, at a low cost and acceptable robust rusticity. Not in 3010, but in 2001 (we are probably 15 years late). Translation memory/semantic addressing call for each Semantic Being to have an IP address. An ontology is built by a person using a taxonomy to describe her vision of the world. I suppose that a few years from now you will have your own and your own knowledge base on your mobile. We still are on the same planet, but in different worlds. Cheers ! 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