Re: [EME] EME charter

Melinda Shore <mshore@cisco.com> Mon, 13 November 2006 19:04 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjh6f-0007mR-T9; Mon, 13 Nov 2006 14:04:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjh6e-0007mF-2e for eme@irtf.org; Mon, 13 Nov 2006 14:04:32 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjh6c-0007Fo-Ne for eme@irtf.org; Mon, 13 Nov 2006 14:04:32 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 13 Nov 2006 11:04:29 -0800
X-IronPort-AV: i="4.09,418,1157353200"; d="scan'208"; a="2250323:sNHT467304282"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kADJ4Sat010759; Mon, 13 Nov 2006 14:04:28 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kADJ4SDO019989; Mon, 13 Nov 2006 14:04:28 -0500 (EST)
Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 14:04:28 -0500
Received: from 128.107.177.244 ([128.107.177.244]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Nov 2006 19:04:27 +0000
User-Agent: Microsoft-Entourage/11.2.3.060209
Date: Mon, 13 Nov 2006 14:04:26 -0500
Subject: Re: [EME] EME charter
From: Melinda Shore <mshore@cisco.com>
To: Saikat Guha <saikat@cs.cornell.edu>
Message-ID: <C17E2BEA.17FCA%mshore@cisco.com>
Thread-Topic: [EME] EME charter
Thread-Index: AccHVomSyFLDq3NJEduQBwAKleNSdA==
In-Reply-To: <1163444003.4894.67.camel@localhost.localdomain>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 13 Nov 2006 19:04:28.0234 (UTC) FILETIME=[8AE73AA0:01C70756]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1269; t=1163444668; x=1164308668; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20<mshore@cisco.com> |Subject:=20Re=3A=20[EME]=20EME=20charter |Sender:=20 |To:=20Saikat=20Guha=20<saikat@cs.cornell.edu>; bh=UQtj9Gge4tULBb/EP7An5xA/8ccvWMcE2MWxlyCE5Mg=; b=Gw+wQqFrAtgMibhRedHv6xLEB7A6EzXp2DVBE8jX7qOwnQA581K/55CbkdKBXgu+HFk8npUh sX7gs8L9sWrUYFUDjRa9laNpdna66h/mUY3XYn/FNVd6DuM053uqjFR5;
Authentication-Results: rtp-dkim-1; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: eme@irtf.org
X-BeenThere: eme@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: end-middle-end research group <eme.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/eme>
List-Post: <mailto:eme@irtf.org>
List-Help: <mailto:eme-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=subscribe>
Errors-To: eme-bounces@irtf.org

On 11/13/06 1:53 PM, "Saikat Guha" <saikat@cs.cornell.edu> wrote:
> Agreed. If the signaling destination is the other endpoint which in turn
> requires an end-to-end signaling plane, then there is an opportunity to
> discover the middleboxes that need to be signaled individually.

Arguably that's nsis (although the NAT problem remains).

I'm glad to see that this research group was chartered, myself, and
there are definitely areas that need attention and that do not overlap
with existing work.  Certainly the namespace issue needs attention -
there's some existing work but it tends to be application-specific and
if something can be done to make that coherent that would be a big
step forward.  Some of that involves lookup services.  Similarly,
there may be a need for rendez-vous services that are smarter than
application-specific SBCs and relays.  I think the tools that actually
do the communication with middleboxes are basically there, but some
problems remain unsolved (naming for NATted endpoints that have
established external reachability, for example) and there's a lack
of general coherence.  I'm optimistic that this group can provide
a forum for trying to develop some coherence.  Ad astra per aspera,
or something.

Melinda

_______________________________________________
EME mailing list
EME@irtf.org
https://www1.ietf.org/mailman/listinfo/eme