ietf
[Top] [All Lists]

RE: WG Review: Open Pluggable Edge Services (opes)

2001-06-18 17:20:02
IMHO OPES can offer a standard way of defining and running services but
cannot prevent people from mis-using it. The trust model including security,
policy, etc. is one of OPES' biggest challenge.

Christian

-----Original Message-----
From: Mark Nottingham [mailto:mnot(_at_)akamai(_dot_)com]
Sent: Monday, June 18, 2001 3:30 PM
To: Maciocco, Christian
Cc: 'Daniel Senie'; Scott Brim; ietf(_at_)ietf(_dot_)org
Subject: Re: WG Review: Open Pluggable Edge Services (opes)


How is this enforced? I.e., what prevents an ISP from running an 
ad-insertion service using OPES mechanisms in transparent proxies?

I know that the group working on OPES doesn't intend these uses. 
However, there isn't anything in the design that will prevent them 
(please tell me if I've missed something), and everything I've seen 
indicates that interposition of services by access providers 
is by far 
the largest market for this technology.

Cheers,


Maciocco, Christian wrote:

Publishers care if their content is damaged in flight (e.g. 
proxies which remove or alter content, which includes AOL's 
mangling of 
graphics). They also may care to know how many people and 
which people are


accessing content.


One advantages offered by OPES is that the publisher only 
allows their
trusted services to be run at the edge(s) of the network. 
Services are run
explicitely, not transparently.


I think OPES will further the sale of SSL accelerator boxes and web 
certificates. If the only way to protect content from 
uninvited third-party intermediaries, then content which is 
not otherwise 
confidential is going to be encrypted.

It's one thing if the publisher purposely buys the services 
of a content delivery network, it's quite something else 
when someone

inserts a 

transparent proxy, especially one which alters the content.


See above.

Christian


-----Original Message-----
From: Daniel Senie [mailto:dts(_at_)senie(_dot_)com]
Sent: Monday, June 18, 2001 2:01 PM
To: Scott Brim; Mark Nottingham
Cc: ietf(_at_)ietf(_dot_)org
Subject: RE: WG Review: Open Pluggable Edge Services (opes)


At 04:23 PM 6/18/01, Scott Brim wrote:

Publishers lose control of how a resource is treated but still
(optionally) retain control over the resource itself, e.g. through
watermarks.  I doubt that publishers care if their content 
is carried
over Ethernet or ATM today.



How much do publishers care how their
content is encapsulated, routed, encoded, etc.?

Publishers care if their content is damaged in flight (e.g. 
proxies which 
remove or alter content, which includes AOL's mangling of 
graphics). They 
also may care to know how many people and which people are 
accessing content.


What do you think OPES
could do that a publisher (1) would be concerned about, 
and (2) could
not protect against?

I think OPES will further the sale of SSL accelerator boxes and web 
certificates. If the only way to protect content from 
uninvited third-party 
intermediaries, then content which is not otherwise 
confidential is going 
to be encrypted.

It's one thing if the publisher purposely buys the services 
of a content 
delivery network, it's quite something else when someone inserts a 
transparent proxy, especially one which alters the content.


On 18 Jun 2001 at 12:51 -0700, Mark Nottingham apparently wrote:

As such, the OPES goals break end-to-end transparency at the
application layer. As a result, (using HTTP as an 

example, because it

seems the first target of OPES), the publisher loses 

control over a

resource once it leaves their server. It then becomes 

impossible to

makes statements about that resource (e.g., P3P, Semantic 

Web, legal

status of a resource, etc.).

-----------------------------------------------------------------
Daniel Senie                                        dts(_at_)senie(_dot_)com
Amaranth Networks Inc.                    http://www.amaranth.com






-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)





<Prev in Thread] Current Thread [Next in Thread>