Subject: [ OPES architecture] Final Points of Discussion: Tracing

From: "Abbie Barbir"<[email-masked]>
Date: Wed, 22 May 2002 09:58:24 -0400

Graham and all,

I am providing a summary of the current position and feedback. 
This will be points that we try to get agreement on.

1. endpoint-user must be able to access OPES diagnostic 
   information using legacy s/w.
2. have no problem with protocol extensions being available to 
   facilitate access to the information. 
3. not opposed to using In-band information even if it means extensions
4. keeping a log could be quite sufficient
5. having out of band access from one endpoint or the other is a far better 
   outcome than having none
6. (From mark baker) No need to standardize on a callout protocol.

Here I propose that we start a new thread where each point is discussed and
get solved.

abbie

---

From: John Morris <[email-masked]>
Date: Thu, 23 May 2002 10:41:41 -0400

At 9:58 AM -0400 5/22/02, Abbie Barbir wrote:
>Here I propose that we start a new thread where each point is 
>discussed and get solved.
>
>abbie

Unless I've missed something (which is certainly possible), the draft 
may want to suggest how the OPES architecture will respond to the 
following IAB consideration:

    (3.1) Notification: The overall OPES framework needs to assist
    content providers in detecting and responding to client-centric
    actions by OPES intermediaries that are deemed inappropriate by the
    content provider.

The response may be that this consideration will be addressed in a 
requirements document -- for example by requiring the initial request 
from a client to a content provider to deliver a header flagging the 
client-centric OPES action to be performed.  Although such a header 
may not have major "architectural" implications, in explaining and 
understanding an OPES flow it seems appropriate to state that there 
should be notice to the "other" primary party (i.e., the party not 
initially requesting the OPES transformation) of the planned OPES 
transformation or callout PRIOR to the transformation or callout 
actually happening.

A small and unrelated point about 3.4 of the draft:

>3.4 Privacy
>
>    Some data from data consumers is considered "private" or "sensitive",
>    and OPES processors must both advise the primary parties of the their
>    privacy policy and respect the policies of the primary parties.  The
>    privacy information must be conveyed on a per-flow basis.

Especially as peer-to-peer technologies become more widely used, 
there will likely be times that data providers also have private or 
sensitive data. I suggest changing "data consumers is" to "data 
consumers or providers may be."

John

----------------------------------------
John B. Morris, Jr.
Director, Internet Standards, Technology
    & Policy Project
Center for Democracy and Technology
1634 I Street NW, Suite 1100
Washington, DC 20006
(202) 637-9800
(202) 637-0968 fax
[email-masked]
http://www.cdt.org
----------------------------------------

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 23 May 2002 12:09:02 -0400

>    actions by OPES intermediaries that are deemed inappropriate by the

Section 2.6 of the draft should extend to include some form of 
notification of the OPES action to the originating party *when 
requested* by the originating party. Implicit notification mechanisms 
would not scale, but a content provider should be able to explicitly 
request notification in some form.

> Especially as peer-to-peer technologies become more widely used, there 
> will likely be times that data providers also have private or sensitive 
> data. I suggest changing "data consumers is" to "data consumers or 
> providers may be."

I would agree with that change.

-Markus

---

From: "The Purple Streak (Hilarie Orman)" <[email-masked]>
Date: Thu, 23 May 2002 11:40:37 -0600

I can see this as being an option for debugging, but making it
mandantory for use in forensic analysis of "inappropriateness"
by end users is simply outside the scope of protocol development.

Hilarie

---

From: John Morris <[email-masked]>
Date: Thu, 23 May 2002 14:31:44 -0400

At least some content providers are going to want this capability for 
reasons other than an after-the-fact forensic analysis. 
Hypothetically, a big content site that offers both (a) free web 
based content, AND (b) a fee-based option to get the same content in 
a low-bandwidth wireless-friendly format, might want to block an end 
user from getting a third party OPES wireless-reformatter to make the 
conversion.

Even though I personally am not thrilled about that hypothetical 
situation, I think it is very plausible, and one that should concern 
OPES intermediaries.  A site could easily, in its terms of service or 
other clipwrap agreement, limit a user's license to view content to 
only a single format.  At least arguably, if an OPES intermediary 
then transforms the content into a different format, the site might 
have a claim against the intermediary.

Stated more generally, I can easily see situations in which an OPES 
intermediary would want to (or would be required to) have the 
abililty to allow either primary party to veto a planned OPES 
transformation.  In many (but not all) cases, the end user might be 
able to exercise this veto simply by discarding the OPESized content. 
The approach that Markus suggests could give the content provider a 
similar veto (assuming the OPES intermediary honored the primary 
party's veto).

To be clear, there are lots of arguments why a content provider 
should not be able to control how the user transforms the delivered 
content.  But content owners are certainly going to want that 
capability, and the IAB discussed some reasons why that capability 
might in some cases be appropriate.

One alternative would be for OPES dispatchers to recognize a blanket 
"DO NOT OPES" flag on content received from content providers.  But 
if that is the only option a content provider has, we could see an 
unnecessarily high number of such flags on content (thereby 
marginalizing the client-centric OPES service market).

John

At 11:40 AM -0600 5/23/02, The Purple Streak (Hilarie Orman) wrote:
>>>Unless I've missed something (which is certainly possible), the 
>>>draft may want to suggest how the OPES architecture will respond 
>>>to the following IAB consideration:
>>>
>>requested* by the originating party. Implicit notification 
>>mechanisms would not scale, but a content provider should be able 
>>to explicitly request notification in some form.

---

From: "Oskar Batuner" <[email-masked]>
Date: Thu, 23 May 2002 14:51:38 -0400

1. Referring to the "coloring schema" proposed in part 3.1 
I'd suggest to limit notification requests by the area 
of the requesting party color. If the company or school 
administrator stops sport news and banner ads he/she has 
full right to do so - and has no obligation to report 
internal network settings nor to news media nor to 
advertisers.

Attempt to mandate otherwise will just result in 
limiting OPES applicability area or in proprietary 
modifications that may be more dangerous to security 
and privacy than controlled standardized provisions.

2. "Coloring schema": I see a problem in starting 
authority propagation from the data consumer or initial 
data provider. 

In company/school/library case final data consumer has 
no authority, in CDN case authority is delegated to 
the CDN distribution points.

I'd suggest to have a separate "start of authority" 
points for the color propagation.

Oskar

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Markus Hofmann
> Sent: Thursday, May 23, 2002 12:09 PM
> To: John Morris
> Cc: OPES Group
> Subject: Re: [ OPES architecture] Final Points of Discussion: Tracing
> 
> 
> 
> John Morris wrote:
> 
......................