RE: [EME] EME charter

My take on recent threads:

1.  As Saikat said, EME different from midcom mainly in its involving both
endpoints as well as middleboxes.
2.  As Melinda said, EME different from NSIS in large part in that it deals
with higher level naming issues (in a sense, EME "off-path" signaling
mechanisms would occur before NSIS "on-path" mechanisms, though EME will
revisit on-path signaling in light of its off-path components).

3.  As for cooperating versus non-cooperating middleboxes...I'm very
reluctant to try to do something about non-cooperating middleboxes...I'm not
sure what we can do about them.  My hope is that many middleboxes don't want
to be transparent per se, but are so because there are no other deployment
options.  If the EME protocols are successful, the middleboxes would have a
way to become non-transparent, and I assume that many would do so.  Right
now, I'm thinking of middleboxes that refuse to cooperate as out of scope.

PF

-----Original Message-----
From: Joe Touch [mailto:touch@ISI.EDU] 
Sent: Monday, November 13, 2006 2:04 PM
To: Saikat Guha
Cc: eme@irtf.org
Subject: Re: [EME] EME charter

Saikat Guha wrote:
> On Mon, 2006-11-13 at 10:29 -0800, Joe Touch wrote:
>>> To the extent that the lack of middle-to-end and end-to-middle 
>>> communication prevents middleboxes from being truly transparent (to
>> the
>>> app layer) or fully visible (to the network layer), EME resolves to 
>>> address the problem IMHO.
>> That was (is) the goal of MIDCOM, as Melinda pointed out. What will 
>> this WG do beyond that?
> 
> EME is different from MIDCOM in that the MIDCOM model is of an 
> endpoint signaling *to the line of middle boxes* in front of it (i.e 
> E-M), while the the EME model is the endpoint signaling *to the other 
> endpoint* through the line of middle boxes in front of both of them (i.e.
E-M-E).

That'd be useful to bring out in the charter.

Joe

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