Re: [EME] EME charter

Saikat Guha wrote:
> On Sun, 2006-11-12 at 21:52 -0800, Joe Touch wrote:
>> Problem-causing middleboxes don't *want* to be found; they want to be
>> "transparent".
>>
>> Resolving - or prohibiting - that transparency should be included and
>> addressed.
> 
> Middleboxes that are _truly transparent_ are not problematic (by
> definition almost). Translucent middleboxes, on the other hand, should
> indeed be addressed.

Transparent = router or link.

Non-transparent - in some way - is the definition of a middlebox. The
trouble is that middlebox designers use "transparent" when they mean "I
*think* the endpoint won't know", rather than "then endpoint cannot
know, and the difference cannot matter".

> One reason such translucent middleboxes exist is that there is no way
> for the middle to inform the end of policy much less require the end to
> enforce it (the corporate firewall case). Another reason is that the end
> cannot effectively direct the middle (the NAT case); perhaps NATs would
> have been less problematic if source route was a first class citizen in
> the Internet or DNS names carried end-to-end in packets. 

The real reason is that some middlebox designer somewhere thought they
knew better than the person at the endpoint about what an E2E
communication was supposed to do.

Although there are some designers who want to communicate with the
endpoint (if they only could), some (IMO most) *want* to be transparent
even in that case.

> 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?

Joe

Re: [EME] EME charter

Attachment: signature.asc