Return-Path: Received: from murder ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.2.8-Mandrake-RPM-2.2.8-4.2.101mdk) with LMTPA; Wed, 03 Aug 2005 03:50:13 +0200 X-Sieve: CMU Sieve 2.2 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C7EF3200B8 for ; Wed, 3 Aug 2005 03:50:13 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19191-04 for ; Wed, 3 Aug 2005 03:50:09 +0200 (CEST) X-Greylist: domain auto-whitelisted by SQLgrey-1.4.8 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id E5D6C3200B5 for ; Wed, 3 Aug 2005 03:50:04 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E08L7-0000X9-FC; Tue, 02 Aug 2005 21:46:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E08L4-0000X1-U9 for ietf@megatron.ietf.org; Tue, 02 Aug 2005 21:46:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00301 for ; Tue, 2 Aug 2005 21:46:32 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E08rf-0004Iq-Re for ietf@ietf.org; Tue, 02 Aug 2005 22:20:16 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E08Kv-0003AH-91; Tue, 02 Aug 2005 18:46:25 -0700 Message-Id: <6.2.1.2.2.20050803010230.0581ce20@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 03 Aug 2005 01:38:40 +0200 To: "Hallam-Baker, Phillip" , "IETF General Discussion Mailing List" From: "JFC (Jefsey) Morfin" In-Reply-To: <198A730C2044DE4A96749D13E167AD375A29CA@MOU1WNEXMB04.vcorp. ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD375A29CA@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA00301 Cc: Subject: RE: I'm not the microphone police, but ... X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org X-Virus-Scanned: by amavisd-new at alvestrand.no Interesting: I like you piercing spirit. But, I am afraid you are too muc= h=20 legacy intoxicated :-) what I think surprising. I suppose we agree but yo= u=20 have odd ways of seeing it. At 18:58 02/08/2005, Hallam-Baker, Phillip wrote: > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > > Except if you can grab a BCP. I am not sure you are actually > > right. You certainly know a few cases. > >The lack of an IETF endorsed spec from MARID did not stop Microsoft from >holding an industry gala two weeks ago in NYC. Nobody commented or >appeared to care that the spec was not ratified. > >Think of it as a recess appointment. > > > The problem with IETF is there is no architectural common vision. > >No, that is its strength. The Web was not part of the IETF common >vision. SSL was diametrically opposed to the IETF security vision. I am afraid you speak of details. These are applications. There is no=20 common vision of the reality of the digital ecosystem nature. IETF has fu= n=20 over layer 8 and 9. Layer 8 to 12 have a precise meaning, as has layer 0.= =20 Sharing this meaning would help a common analysis and avoid confusing=20 Multilingual Internet with a bunch of typewritters, using typographer ISO= =20 tables to document it. > > IETF and IANA have a defacto monopoly on the architecture. > >No they don't. W3C and OASIS are both more influential as standards >bodies at this point, particularly once we get above the session layer. Again you speak of details. Of applications. I am speaking of the network= =20 architecture. The evolution of the architecture is very very slow. What I say is that in the real world, users are not interested in all tha= t.=20 This is for application providers and applications are decided by the=20 users. Who known the W3C and SGML 10 years ago. Will we still know them 1= 0=20 years from now? >The URI identifier architecture introduced in PICS and since adopted in >XML eliminates the need for fixed registries like the IANA. That was the >whole point, to eliminate the control point. I did not want a central >registry of PICS censorship schemes. Of course other people did, mostly >the people who used euphemisms like 'content selection' rather than >censorship. Agree. But IMHO this is a way to introduce at application level the very=20 basic "root name" principle introduced by Robert Tr=E9hin and Joe Rinde i= n=20 1977 which founded the International Network, in part the OSI and default= ed=20 to "root" with the Internet defaulting its architectural parameter to=20 "mono" from "multiple" in Tymnet and from "separated" in OSI. This is wha= t=20 we have to correct now. I would phrase it another way. The IANA is one of the many roots in the=20 International Network forest. But that trunc of that root hidden the=20 forest. The Multilingual Internet is probably the best application to for= ce=20 and fund the necessary effort to look at the forests. But some suspect th= at=20 the resulting user-centric architecture (each one having its many roots)=20 has a different economical model. And status quo is the best target for dominant one. At ICANN they use to=20 call the "stakeholders" .... > > For example the whole IPv6 issue is that they did not understand that > > their current deployement (2001) is disposable. > >The failure to get the deployment stakeholders round the table to ask >the question 'what will it take to make this happen' is in my view the >root cause. I do not. Because what will make it to happen is the disappearance of=20 "stakeholders". Let understand, the current network is made of people who= =20 want to organise, to sell, etc. it. The future stable IPv6 network by=20 nature (it would not be an evolution otherwise) will be made of people=20 wanting just want to use it. And the first thing they want to get rid of = is=20 the artificial limitations of the stakeholders. Take care. I am quite interested in your security factor in relations. Di= d=20 you work on that (I did not recall exactly how you termed it: we called=20 "delta sec", and people grab the idea quick). I suppose that network=20 security could be discussed in a similar way to network value? jfc _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf