RE: The internet architecture

[Christian Huitema <huitema at windows.microsoft.com>]

> >> It ought to be, but unfortunately we have confounded the transport
> >> entity
> >> namespace with the network entity namespace with the point of
> attachment
> >> namespace.
> >
> > Not really. Many applications are actively managing their network
> connections, and for a good reason. A network connection is not an
> interface to an abstract "unified network". On the contrary, a network
> interface implements a contract with a specific network.
>
> It seems to me that you're agreeing with me. It's exactly because the
> three
> namespaces I mentioned are mashed together by TCP/IP that applications
> have
> to do what you describe, rather than just saying "open a connection to
> Christian's laptop."

If "Christian's laptop" is the "transport" name space, and if the network entity namespace use different network entity names tFrom ietf-bounces at ietf.org  Mon Dec 29 16:56:44 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 9BD3028C0F0;
	Mon, 29 Dec 2008 16:56:44 -0800 (PST)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 5C82628C2B6
	for <ietf at core3.amsl.com>; Mon, 29 Dec 2008 16:56:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.511
X-Spam-Level: 
X-Spam-Status: No, score=-110.511 tagged_above=-999 required=5
	tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8,
	USER_IN_WHITELIST=-100]
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 9aI5vNXMnJQM for <ietf at core3.amsl.com>;
	Mon, 29 Dec 2008 16:56:42 -0800 (PST)
Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212])
	by core3.amsl.com (Postfix) with ESMTP id 5AD4728C0F0
	for <ietf at ietf.org>; Mon, 29 Dec 2008 16:56:42 -0800 (PST)
Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by
	TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with
	Microsoft
	SMTP Server (TLS) id 8.1.291.1; Mon, 29 Dec 2008 16:56:26 -0800
Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com
	(157.54.18.32) by tk5-exhub-c103.redmond.corp.microsoft.com
	(157.54.88.96)
	with Microsoft SMTP Server id 8.1.291.1; Mon, 29 Dec 2008 16:56:25 -0800
Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com
	([fe80::8de9:51a2:cd62:f122]) by
	tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32])
	with mapi; Mon, 29 Dec 2008 16:57:33 -0800
From: Christian Huitema <huitema at windows.microsoft.com>
To: Brian E Carpenter <brian.e.carpenter at gmail.com>
Date: Mon, 29 Dec 2008 16:56:19 -0800
Subject: RE: The internet architecture
Thread-Topic: The internet architecture
Thread-Index: AclqGKmVR8cZMK7MThKbXIyMF/LtHgAADK7g
Message-ID: <8EFB68EAE061884A8517F2A755E8B60A19D2E66F4A at NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
References: <20081229162852.79C526BE581 at mercury.lcs.mit.edu>
	<49592B28.6060001 at gmail.com>
	<8EFB68EAE061884A8517F2A755E8B60A19D2E66F03 at NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
	<49596FEA.6040909 at gmail.com>
In-Reply-To: <49596FEA.6040909 at gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "ietf at ietf.org" <ietf at ietf.org>
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

> >> It ought to be, but unfortunately we have confounded the transport
> >> entity
> >> namespace with the network entity namespace with the point of
> attachment
> >> namespace.
> >
> > Not really. Many applications are actively managing their network
> connections, and for a good reason. A network connection is not an
> interface to an abstract "unified network". On the contrary, a network
> interface implements a contract with a specific network.
>
> It seems to me that you're agreeing with me. It's exactly because the
> three
> namespaces I mentioned are mashed together by TCP/IP that applications
> have
> to do what you describe, rather than just saying "open a connection to
> Christian's laptop."

If "Christian's laptop" is the "transport" name space, and if the network entity namespace use different network entity names to designo designate the various "network contracts", then, yes, we probably agree. Although I am not sure that we should place too much emphasis on the name of physical entities like "Christian's laptop". What if the application process migrates from my laptop to my desktop?

-- Christian Huitema



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


ate the various "network contracts", then, yes, we probably agree. Although I am not sure that we should place too much emphasis on the name of physical entities like "Christian's laptop". What if the application process migrates from my laptop to my desktop?

-- Christian Huitema



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf