John, it looks like there are two main differences in
our approach:
1. You are looking at OPES as enabling technology that makes possible
things that do not exist now. I look at OPES mainly as a technology
standard that may facilitate deployment of services that do already
exist but are deployed in a less efficient/controllable way (like
filters, edge services, etc.)
As a result you are more concerned with the ability of new OPES
entities to affect end-to-end interaction between content producers
and content consumers. On another hand I think that with the proper
architecture and taking into account IAB requirements (RFC3238),
especially requirement of explicit authorization, OPES does not
create a situation that is substantially different from the existing
one. OPES deals with the threats that already exist (Trojans, spyware,
server security flaws, etc.).
OPES development requires careful consideration of all possible
threats but as a result I'd really like to see new
security/authorization/tracing/reporting methods and standards that
are equally applicable to both OPES and non-OPES systems.
2. You are looking at "good guys" environment - both sides are
perusing legitimate goals but may have different interests.
I'm looking also at "bad guys" - viruses, worms, DDoS bots,
spyware, persistent distributors of unwanted information and
the like.
"Bad guys" can not be trusted and have no legitimate
interests that should be protected in any way. In situations
of conflict between protection of legitimate content
distributor rights and protection of end user from malicious
intents I usually sympathize with the end-user.
Oskar
-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of John
Morris
Sent: Monday, June 10, 2002 3:25 PM
To: Abbie Barbir
Cc: OPES Group
Subject: Re: Content Provider Notification: Summary: Please provide
feedback ASAP
At 12:44 PM -0400 6/10/02, Abbie Barbir wrote:
<snip>
Furtheremore, I think that the topic of general notification
should be delayed
for a later stage. This will be mentioned in the draft also.
I don't have any problem delaying the notification issue at this
point, but it does strike me that addressing the IAB's concerns on
notification could possibly require "architectural" elements -- but
also might possibly not. Some of Oskar Batuner's suggestions seem to
help and may not change any architecture.
I also agree with Oskar's concern that a server veto of a client-side
virus checking OPES service would not be acceptable -- unless the
server's veto was manifested by a simple refusal to serve the
requested content. In most cases, the server will want
viewers/users/visitors, and so will have an incentive NOT to veto
reasonable OPES services.
We obviously will have to think carefully about whether server
review/consent/veto of client-side OPES services will be viable. I
would suggest, however, that the WG not reject the concept entirely,
because I think it very likely that (a) client-side OPES services
will be used to do things that some servers/content-owners do not
like, and (b) those servers/content-owners will take action to block
or break those OPES services. The WG might well in the long run be
avoiding problems if it can devise a way to give servers appropriate
notice of client-side OPES services.
John