Re: "The IETF has difficulty solving complex problems" or alternatively Why IMS is a big fat ugly incomprehensiable protocol
Pekka Nikander <pekka.nikander@nomadiclab.com> Thu, 15 September 2005 13:45 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFu3T-0002lU-2l; Thu, 15 Sep 2005 09:45:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFu3R-0002lO-4F for ietf@megatron.ietf.org; Thu, 15 Sep 2005 09:45:33 -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 JAA10981 for <ietf@ietf.org>; Thu, 15 Sep 2005 09:45:30 -0400 (EDT)
Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFu8D-0001Hs-HA for ietf@ietf.org; Thu, 15 Sep 2005 09:50:32 -0400
Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0DFCC212C46; Thu, 15 Sep 2005 16:45:21 +0300 (EEST)
In-Reply-To: <6.2.3.4.2.20050915124120.0421ce00@mail.jefsey.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> <6.2.3.4.2.20050915124120.0421ce00@mail.jefsey.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <1E180221-A952-481A-8B0A-47304297CD91@nomadiclab.com>
Content-Transfer-Encoding: 7bit
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
Date: Thu, 15 Sep 2005 15:45:18 +0200
To: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
X-Mailer: Apple Mail (2.734)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
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
> ... 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 don't see any *necessary* changes to IP addressing; OTOH wide spread use of HIP would certainly open new possibilities, like easier network renumbering and easier interworking between IPv4 and IPv6. DNS, changes or at least extensions, definitely. That is an area of active research. The Hi3 paper covered that from one point of view briefly, but there are other proposals around. > 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 don't know what you mean with "transparent transition". > 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 don't understand why you call that "ISP rotation", but yes, based on your functional description, that should be fairly trivial. With IPv6 and RFC3014(bis) addresses you might even get some level of privacy, but see also our "BLIND" paper, on my publications page. > I note that you could also associate HI to predetermined paths as > well (anti-tapping protection)? Maybe, but I don't see any easy way to do that. One of the points in HIP is to loosen the currently tight binding between routing and transport. --Pekka _______________________________________________ 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