Re: [tae] The internet architecture
"Hallam-Baker, Phillip" <pbaker@verisign.com> Thu, 04 December 2008 22:11 UTC
Return-Path: <tae-bounces@ietf.org>
X-Original-To: tae-archive@ietf.org
Delivered-To: ietfarch-tae-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 16DA128C0E6;
Thu, 4 Dec 2008 14:11:49 -0800 (PST)
X-Original-To: tae@core3.amsl.com
Delivered-To: tae@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 547F33A6951;
Thu, 4 Dec 2008 11:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.258
X-Spam-Level:
X-Spam-Status: No, score=-6.258 tagged_above=-999 required=5 tests=[AWL=0.340,
BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id FH+g-tFoQSCP; Thu, 4 Dec 2008 11:59:34 -0800 (PST)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74])
by core3.amsl.com (Postfix) with ESMTP id 3C0BE3A68FA;
Thu, 4 Dec 2008 11:59:34 -0800 (PST)
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com
[65.205.251.35])
by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id mB4JcXaw011494;
Thu, 4 Dec 2008 11:38:33 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by
MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft
SMTPSVC(6.0.3790.3959); Thu, 4 Dec 2008 11:59:27 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 4 Dec 2008 11:58:13 -0800
Message-ID: <2788466ED3E31C418E9ACC5C316615572FFBEF@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: The internet architecture
Thread-Index: AclWPYfu98wfuG9rSmiYn+IrZvPWBAADRvuP
References: <C15AE32B-E564-4C93-86FF-40EF203E673A@mpi-sws.org>
<49382030.5020704@network-heretics.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "Keith Moore" <moore@network-heretics.com>,
"Bryan Ford" <brynosaurus@gmail.com>
X-OriginalArrivalTime: 04 Dec 2008 19:59:27.0701 (UTC)
FILETIME=[D02DF050:01C9564A]
X-Mailman-Approved-At: Thu, 04 Dec 2008 14:11:47 -0800
Cc: tae@ietf.org, ietf@ietf.org
Subject: Re: [tae] The internet architecture
X-BeenThere: tae@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Architecture Evolution <tae.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tae>,
<mailto:tae-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/tae>
List-Post: <mailto:tae@ietf.org>
List-Help: <mailto:tae-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tae>,
<mailto:tae-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1566696829=="
Sender: tae-bounces@ietf.org
Errors-To: tae-bounces@ietf.org
I am trying to parse this claim. Are you saying that the DNS is fragile and raw IP relatively robust? If so I can show you mountains of evidence to show that you are completely wrong. -----Original Message----- From: ietf-bounces@ietf.org on behalf of Keith Moore Sent: Thu 12/4/2008 1:23 PM To: Bryan Ford Cc: tae@ietf.org; ietf@ietf.org Subject: Re: The internet architecture Bryan Ford wrote: > To throw in my quick $.02 (and perhaps invite more discussion :) ), I > think we absolutely need to migrate both networking APIs and transport > layer protocols themselves toward a model where an "endpoint" is an > opaque (to the transport/application) variable-length string of some > kind, and the transport/application shouldn't even care much if any what > exactly the string is. The string could potentially be a DNS name, a > dotted IPv4 address, a colonificated IPv6 address, a hex-encoded HIP > cryptographic host identifier, a UIA personal name, ... And sure, the > semantics of these different kinds of "endpoint strings" will vary > depending on what they actually are, and for network management purposes > they won't all be equivalent or interchangeable, but for purposes of > normal transport and application protocol operation - i.e., "gimme a > TCP-like connection to the endpoint named 'X'", why should transports > and applications need to care? Sigh. Maybe this is unfair, but it seems to me that people keep wanting to take (relatively) straightforward, bulletproof interfaces and replace them with fragile ones that depend on extra layers of indirection, and additional services that (a) can fail, (b) don't share fate with the endpoints and (c) are likely to be very sensitive to configuration errors, all for the sake of some notion of architectural purity. I won't claim that you can't do it, or that it's a fundamentally bad idea on its face. I *will* claim that it's a fundamentally bad idea if you don't do very careful engineering on it to make sure that the resulting system is as reliable was it would be without the extra layer of indirection - and that includes accounting for the ability of people to misconfigure things. > Just think how much easier the IPv4 to IPv6 transition would have been if nothing above the IP layer cared > exactly what an IP address looks like or how big it is. It wouldn't have made much difference at all, partly because due to other warts in the IPv6 architecture (like the desire to push the cost of multihoming to all endpoints rather than the core [*]), applications have even more need to deal directly with addresses in IPv6 than they do in IPv4 - even in a pure IPv6 world. The other reason it wouldn't have made much difference is because transitioning applications to IPv6 is actually much easier than transitioning networks. Keith [*] Not that I blame the routing guys for wanting to move the cost of multihoming out of the core. But pushing those costs onto hosts and applications was moving those costs even further away from those who benefit from multihoming, than was the case in IPv4. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ tae mailing list tae@ietf.org https://www.ietf.org/mailman/listinfo/tae
- Re: [tae] The internet architecture Bryan Ford
- Re: [tae] The internet architecture Keith Moore
- Re: [tae] The internet architecture Hallam-Baker, Phillip
- Re: [tae] The internet architecture Keith Moore
- Re: [tae] The internet architecture Hallam-Baker, Phillip
- Re: [tae] The internet architecture Keith Moore
- Re: [tae] The internet architecture John Leslie
- Re: [tae] The internet architecture Joe Touch
- Re: [tae] The internet architecture Keith Moore
- Re: [tae] The internet architecture Thomas Narten
- Re: [tae] The internet architecture Thomas Narten
- Re: [tae] The internet architecture Henning Schulzrinne
- Re: [tae] The internet architecture Dave CROCKER
- Re: [tae] The internet architecture Melinda Shore
- [tae] sockets vs. fds Dave CROCKER
- Re: [tae] The internet architecture John Day
- Re: [tae] sockets vs. fds Melinda Shore
- Re: [tae] The internet architecture John Day
- Re: [tae] The internet architecture John Day
- Re: [tae] The internet architecture Keith Moore
- Re: [tae] The internet architecture Keith Moore
- Re: [tae] The internet architecture Keith Moore
- Re: [tae] The internet architecture Keith Moore
- Re: [tae] The internet architecture Dave CROCKER
- Re: [tae] The internet architecture John Day
- Re: [tae] The internet architecture John Day
- Re: [tae] The internet architecture Thomas Narten
- Re: [tae] The internet architecture Keith Moore
- Re: [tae] The internet architecture Thomas Narten
- Re: [tae] The internet architecture Keith Moore
- Re: [tae] sockets vs. fds Tony Finch
- Re: [tae] The internet architecture David W. Hankins
- Re: [tae] The internet architecture Hallam-Baker, Phillip
- Re: [tae] sockets vs. fds Florian Weimer
- [tae] The Great Naming Debate (was Re: The intern… Bryan Ford
- Re: [tae] The Great Naming Debate (was Re: The in… Keith Moore
- Re: [tae] The Great Naming Debate (was Re: The in… Joe Baptista
- Re: [tae] The Great Naming Debate (was Re: The in… Hallam-Baker, Phillip
- Re: [tae] The Great Naming Debate (was Re: The in… Melinda Shore
- Re: [tae] The Great Naming Debate (was Re: The in… Hallam-Baker, Phillip
- Re: [tae] The Great Naming Debate (was Re: The in… Keith Moore
- Re: [tae] The internet architecture John Leslie