Re: [EME] First cut at eme requirements

Rémi Després <remi.despres@wanadoo.fr> Tue, 05 December 2006 10:05 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrXAj-0004P7-W7; Tue, 05 Dec 2006 05:05:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrXAi-0004OA-Pk for eme@irtf.org; Tue, 05 Dec 2006 05:05:08 -0500
Received: from smtp8.orange.fr ([193.252.22.23] helo=smtp-msa-out08.orange.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrXAg-0000VN-B4 for eme@irtf.org; Tue, 05 Dec 2006 05:05:08 -0500
Received: from [127.0.0.1] (APuteaux-152-1-18-102.w82-120.abo.wanadoo.fr [82.120.80.102]) by mwinf0808.orange.fr (SMTP Server) with ESMTP id 8904F1C00251; Tue, 5 Dec 2006 11:05:02 +0100 (CET)
X-ME-UUID: 20061205100502561.8904F1C00251@mwinf0808.orange.fr
Message-ID: <4575444D.2080903@wanadoo.fr>
Date: Tue, 05 Dec 2006 11:05:01 +0100
From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@wanadoo.fr>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Paul Francis <francis@cs.cornell.edu>
Subject: Re: [EME] First cut at eme requirements
References: <E6F7A586E0A3F94D921755964F6BE00672E280@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <E6F7A586E0A3F94D921755964F6BE00672E280@EXCHANGE2.cs.cornell.edu>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Cc: eme <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>
Content-Type: multipart/mixed; boundary="===============1404192120=="
Errors-To: eme-bounces@irtf.org

I wonder whether an easy characterization of EME middleboxes couldn't be 
that they may modify IP packets.
("IP Packets" are no longer E2E. Only part of their semantics is.)

RD

Paul Francis wrote :
> These are all reasonable comments...happy to incorporate them in the next
> revision.
>
> PF
>
>  
>
> -----Original Message-----
> From: Scott W Brim [mailto:swb@employees.org] 
> Sent: Tuesday, November 28, 2006 2:39 PM
> To: Paul Francis
> Cc: eme
> Subject: Re: [EME] First cut at eme requirements
>
> On 11/28/2006 10:30 AM, Paul Francis wrote:
>   
>>    Middlebox:  A middlebox refers to a network element assisting
>>       endpoints to communicate through that network.  A middlebox may
>>       keep per-flow state or may be stateless.  Like endpoints,
>>       middleboxes may also have local policy governing which endpoints
>>       may communicate over the particular network.
>>     
>
> This isn't an easy definition.  Not all middleboxes "assist"
> communication -- some either restrict it or allow it.  Also I believe we want
> to exclude routers from the definition.  Finally, some middleboxes are pure
> control, some are pure data plane, some are mixed.  What about pure policy
> boxes?
>
>   
>   
_______________________________________________
EME mailing list
EME@irtf.org
https://www1.ietf.org/mailman/listinfo/eme