Subject: Content Provider Notification: Summary: Please provide feedback ASAP

From: "Abbie Barbir" <[email-masked]>
Date: Mon, 10 Jun 2002 12:44:06 -0400

All,

Following the thread on Content Provider Notification, it seems to me that
no 
conclusion could be made about the course of action.

There were proposals and counter proposals with no way of determining that a

general conclusion that the group could live with was reached.

However, it seems to me that if properly phrased, the following should be
added to 
the architecture document.

"
The presence of an OPES processor in the data request/responce flow SHALL
NOT 
interfere with the operations of non-OPES aware clients and servers. OPES 
processors, content server and content consumer MAY use OPES extensions to 
the base protocol (HTTP), but support of these extensions SHALL NOT be
required."

I am proposing to add this extra requirement to the architecture document 
provided that i do not get negative feedback(S).

Furtheremore, I think that the topic of general notification should be
delayed 
for a later stage. This will be mentioned in the draft also.

Please give feedback by the end of the day. The new -01 draft will be
comming out soon.

Abbie

---

From: "The Purple Streak (Hilarie Orman)" <[email-masked]>
Date: Mon, 10 Jun 2002 12:13:05 -0600

Fine with me.

Hilarie

Abbie Barbir wrote:

> All,
> 
> Following the thread on Content Provider Notification, it seems to me 
> that no
> However, it seems to me that if properly phrased, the following should 
> be added to
> The presence of an OPES processor in the data request/responce flow 
> SHALL NOT

---

From: John Morris <[email-masked]>
Date: Mon, 10 Jun 2002 15:25:23 -0400

At 12:44 PM -0400 6/10/02, Abbie Barbir wrote:
><snip>
>Furtheremore, I think that the topic of general notification should be delayed

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

---

From: "Oskar Batuner" <[email-masked]>
Date: Mon, 10 Jun 2002 18:32:28 -0400

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: [email-masked]
> [mailto:[email-masked]]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
>
>
>

---

From: "Oskar Batuner" <[email-masked]>
Date: Mon, 10 Jun 2002 19:51:34 -0400

What about some proposal from other threads that did not met
objections:

1. Introduction

>In some cases it may be impossible to offer the customization service
>at either the provider or the consumer applications. In this case,
>one or more additional application entities may participate in the
>data stream service.

This term - "impossible" - may leave an impression that this is the
only, or at least main justification to use OPES. This does not look
right. The only scenario (from existing draft-beck-opes-esfnep) where
OPES is the only way to implement the service is request filtering
for hand-held devices, in all other cases service can be implemented
either at the server side or at the client side, or both.
Still use of OPES may be beneficial, so I'd suggest ether to use
a different wording, like:

"In some cases in may be beneficial to provide a customization service
at network location instead of deploying it at either the provider or
the consumer host. For certain services performed on end-user behalf
this may be the only option of service deployment".

2. > 2.1 OPES Entities

Figure 1 should look like this:

                             +----------------+
                             | OPES service   |
                             | application    |
                             +----------------+
                             |data dispatcher |
                             +----------------+
                             |                |
                             |    HTTP        |
                             |                |
                             +----------------+
                             |   TCP/IP       |
                             +----------------+
                             |     ...        |
                             +----------------+

                    Figure 1: An OPES protocol stack

It also may have sense to point out explicitly that

"OPES application may be executed either on the same box (or
even in the same application environment) with the dispatcher
or on a different box through OCP."

I thing it has sense to emphasize this possibility and to provide a
figure like this:

        +--------------------------+
        | +----------+             |
        | |   OPES   |             |
        | |  service |             |      +----------------+
        | |   appl   |             |      | Callout Server |
        | +----------+             |      |                |
        |     ||                   |      | +--------+     |
        | +----------------------+ |      | | OPES   |     |
        | |     data dispatcher  | |      | | Service|     |
        | +----------------------+ |      | |  App2  |     |
        | |   HTTP     | OCP     | |      | +--------+     |
        | +------------|         |==========|  OCP   |     |
        | |            |---------+ |      | +--------+     |
        | |   TCP/IP   |           |      +----------------+
 =========|            |=============== OPES Data Flow ====
        | +------------+           |
        +--------------------------+

It illustrates positions and interaction of different components
of OPES architecture.

There were some other things mentioned, like use of PEP abbreviation,
but the most important are:

- Trust domains: delegation of authority (coloring) propagates
from the content producer start of authority or from the content
consumer start of authority, that may be different from the
the end points in the data flow.

- OPES processor MUST obey tracing/reporting/notification requirements
set by the center of authority in the trust domain to which OPES
processor belongs. As part of these requirements OPES processor MAY
be instructed to reject or ignore such requirements from the
the sources of a different "color".

Oskar

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Abbie Barbir
Sent: Monday, June 10, 2002 12:44 PM
To: OPES Group
Cc: The Purple Streak (Hilarie Orman); Markus Hofmann; Marshall Rose
Subject: Content Provider Notification: Summary: Please provide feedback
ASAP

All,

---

From: John Morris <[email-masked]>
Date: Tue, 11 Jun 2002 10:26:30 -0400

>filters, edge services, etc.)

You are correct that I am (perhaps too) focused on new services.  I 
appreciate the need/desire to use OPES to perform existing services 
better.

>server security flaws, etc.).

I am a little unsure of what you are saying.  If you are saying that 
"OPES will be no worse than bad stuff that is already  out there, so 
we do not need to worry about notice, authoritzation, etc." then I 
cannot agree.

But I don't think you are saying that.  If you are saying that so 
long as OPES is built with the proper architecture and consistent 
with the IAB requirements, it will not create new problems or 
perpetuate old ones, then I am fully supportive of that approach.

>are equally applicable to both OPES and non-OPES systems.

Agreed.

>intents I usually sympathize with the end-user.

Agreed.

John