Re: "The IETF has difficulty solving complex problems" or alternatively Why IMS is a big fat ugly incomprehensiable protocol
"JFC (Jefsey) Morfin" <jefsey@jefsey.com> Thu, 15 September 2005 13:17 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtcb-0001fn-Hu; Thu, 15 Sep 2005 09:17:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtcZ-0001c1-B7 for ietf@megatron.ietf.org; Thu, 15 Sep 2005 09:17:47 -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 JAA09645 for <ietf@ietf.org>; Thu, 15 Sep 2005 09:17:45 -0400 (EDT)
Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFthL-0000Sj-NH for ietf@ietf.org; Thu, 15 Sep 2005 09:22:46 -0400
Received: from i01m-62-35-167-26.d4.club-internet.fr ([62.35.167.26] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EFtcI-00071c-Ne; Thu, 15 Sep 2005 06:17:32 -0700
Message-Id: <6.2.3.4.2.20050915124120.0421ce00@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Thu, 15 Sep 2005 15:17:22 +0200
To: Pekka Nikander <pekka.nikander@nomadiclab.com>, Iljitsch van Beijnum <iljitsch@muada.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <4A09791C-AF36-4C86-923A-D38343C2E037@nomadiclab.com>
References: <20050804050502.GB6084@sbrim-wxp01> <42F89F9F.5070008@zurich.ibm.com> <C5A01F62-A076-46C7-8C67-6568E752A1E7@nomadiclab.com> <4321D5E9.9010609@shockey.us> <151701c5b570$052a25a0$0500a8c0@china.huawei.com> <C0DE65F6343F8BD987425795@B50854F0A9192E8EC6CDA126> <43249A80.3020303@piuha.net> <4324A849.4060509@cs.columbia.edu> <BB8C050D-B298-4A8A-9325-45B149FC04AD@nomadiclab.com> <4A763861-D4E9-44DD-A193-8E73EC4E03A7@muada.com> <4A09791C-AF36-4C86-923A-D38343C2E037@nomadiclab.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 - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA09645
Cc: IETF Discussion <ietf@ietf.org>
Subject: Re: "The IETF has difficulty solving complex problems" or alternatively Why IMS is a big fat ugly incomprehensiable protocol
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
Dear Pekka, I went through a few of your documents to better understand the basic of HIP. When I told you I prefer models: your proposition could fit my model. But if I see identification, authentication and routing matters being addressed, I see proposed changes enough to suspect that this will affect the level above (DNS) and below (IP addressing). I would suggest you try to think of simple, robust, scalable global Internet architecture which would include your proposition and permit a transparent transition. I think this is possible in what I call the "multi-Internet", I do not know if this is possible in the "mono-Internet" you refer to. Because I feel you add an intelligence on the wire? May I suggest a test? How would you support "ISP rotation": your Elm Street person has several addresses and wants to rotate them with a defined pattern within the same relation, for example for security purposes? (you might call this a directed multi-homing?) I note that you could also associate HI to predetermined paths as well (anti-tapping protection)? jfc At 09:57 15/09/2005, Pekka Nikander wrote: >>>So, as I state in my little web page, I think we really should >>>work hard to create a new waist for the architecture. I, of >>>course, have my own theory where the new waist should be and how >>>it should be implemented, >> >>Well, don't be shy: where can we absorb these insights? > >Since you ask: > >Unfortunately I don't have any concise summary of my "theory", but >wading through my academic papers (available through my home page) >should give a fairly good view. I would focus on the following three >papers, roughly in this order: > >1. Pekka Nikander, Jukka Ylitalo, and Jorma Wall, "Integrating >Security, Mobility, and Multi-Homing in a HIP Way," in Proceedings of >Network and Distributed Systems Security Symposium (NDSS'03), >February 6-7, 2003, San Diego, CA, pp. 87-99, Internet Society, >February, 2003. > >2. Jukka Ylitalo, Pekka Nikander, "A new Name Space for End-Points: >Implementing secure Mobility and Multi-homing across the two versions >of IP," in Proceedings of the Fifth European Wireless Conference, >Mobile and Wireless Systems beyond 3G (EW2004), pp. 435-441, >Barcelona, Spain, February 24-27, 2004. > >3. Pekka Nikander, Jari Arkko, and Börje Ohlman, Host Identity >Indirection Infrastructure (Hi3)," in Proceedings of The Second >Swedish National Computer Networking Workshop 2004 (SNCNW2004), >Karlstad University, Karlstad, Sweden, Nov 23-24, 2004. > >Especially the last one is pretty dense; it takes time to understand >all that we are trying to say there. > >All three (and more) are available at >http://www.tml.tkk.fi/~pnr/publications/index.html > >If you prefer slideware, see our IETF 62 plenary slides: >http://www3.ietf.org/proceedings/05mar/plenaryt.html >http://www3.ietf.org/proceedings/05mar/slides/plenaryt-1.pdf > >But, as I wrote, I am trying to take distance from these and trying >to understand alternative approaches, like "virtualising IP" or >"domain-based internetworking" that some people are thinking about. >It is now mostly other people that are continuing the HIP-based work, >for example, at the CEC funded Ambient Networks project and at the >IRTF HIP Research Group. > >--Pekka Nikander > > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- "The IETF has difficulty solving complex problems" Scott W Brim
- Re: "The IETF has difficulty solving complex prob… JFC (Jefsey) Morfin
- RE: "The IETF has difficulty solving complex prob… Hallam-Baker, Phillip
- Re: "The IETF has difficulty solving complex prob… Brian E Carpenter
- Re: "The IETF has difficulty solving complex prob… JFC (Jefsey) Morfin
- Re: "The IETF has difficulty solving complex prob… Pekka Nikander
- Re: "The IETF has difficulty solving complex prob… Richard Shockey
- Re: "The IETF has difficulty solving complex prob… Spencer Dawkins
- Re: "The IETF has difficulty solving complex prob… Richard Shockey
- Re: "The IETF has difficulty solving complex prob… Harald Tveit Alvestrand
- Re: "The IETF has difficulty solving complex prob… Jari Arkko
- Re: "The IETF has difficulty solving complex prob… Henning Schulzrinne
- Re: "The IETF has difficulty solving complex prob… Harald Tveit Alvestrand
- Re: "The IETF has difficulty solving complex prob… Masataka Ohta
- Re: "The IETF has difficulty solving complex prob… Pekka Nikander
- Re: "The IETF has difficulty solving complex prob… Iljitsch van Beijnum
- Re: "The IETF has difficulty solving complex prob… Pekka Nikander
- Re: "The IETF has difficulty solving complex prob… JFC (Jefsey) Morfin
- Re: "The IETF has difficulty solving complex prob… Pekka Nikander
- HIP new possibilities JFC (Jefsey) Morfin
- Re: "The IETF has difficulty solving complex prob… Iljitsch van Beijnum
- Re: "The IETF has difficulty solving complex prob… Pekka Nikander