Subject: FW: Issues raised in opes-enforcement and opes-threat conference call

From: <[email-masked]>
Date: Mon, 12 Aug 2002 08:22:28 -0400

>  -----Original Message-----
> From: 	Chan Tat (NRC/Boston)  
> Sent:	August 09, 2002 02:22 PM
> To:	[email-masked]'; 
> [email-masked]'
> Subject:	Issues raised in opes-enforcement and 
> opes-threat conference call
> 
> Hi all,
> 
> This is my attempt to summarize some of the issues raised 
> during the opes-enforcement and opes-threat conference call 
> this morning, with the hope to get a discussion going in the 
> mailing lists. So, please provide your comments.
> 
> Basically, the team agreed to go for the enforcement draft 
> first. In the meeting, there are at least these four issues 
> discussed, which should all be included in the enforcement draft. 
> 
> 1. There is a proposal that we have encryption at all points 
> in the OPES architecture. The supporting view is that for 
> environment such as in a VPN, they already have network layer 
> security, for instance, using IPSec. But there is also fear 
> that making this a requirement would scare implementors away. 
> Then again, there is also a view saying that IPSec is kind of 
> gaining momentum. 
> 
> 2. Regarding authorization of OPES devices, do we need to 
> define a separate protocol, or do we just specify the 
> requirements and let the implementors decide on what they want to use.
> 
> 3. Granularity of authorization. How fine-grained should the 
> authorization be? On one end of the spectrum, we can 
> authorize individual OPES devices. Once authorized, the OPES 
> device can perform any kind of transformation. On the other 
> end, we can have service by service authorization, or even 
> per-request authorization. 
> 
> 4. Should end-user only authorization be supported? For 
> instance, if a data consumer wants to perform language 
> translation to the web page he/she requests, should he/she be 
> the one who would authorize the OPES device which performs 
> the transformation. Should the content provider be notified 
> that the content they provide is being modified? There are 
> some copyright issues in there, since the transformation may 
> have already infringed the copyright of the content owner. 
> 
> If I left out anything, I hope the team would add to it. 
> Again, we would like to get a discussion going regarding 
> these issues, so please don't hestitate to provide your 
> valuable comments. 
> 
> Best Regards,
> 
> Tat Chan
> Senior Reserach Engineer
> Nokia Research Center
> NOKIA INC
> 5 Wayside Road, Burlington, MA 01803
> Phone (781) 993-5776, Fax (781) 993-1907
> [email-masked]
>

---

From: Arumugam K <[email-masked]>
Date: Tue, 13 Aug 2002 09:44:50 +0530

Hi Chan Tat,

> > opes-threat conference call

<snip>

> > have already infringed the copyright of the content owner.

There is an advantage in notifying the content provider when the data is
modified by opes device. The provider will come to know which lang. the
content 
is transformed the most. So that the provider could keep a copy of the
content
in the same language. Thus he could contribute on avoiding that many
opes 
transformations.

Thanks
Arumugham

-- 
Want to know CDN?
http://cdn.hcltech.com

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 13 Aug 2002 11:11:49 -0400

Arumugam,

 > There is an advantage in notifying the content provider when the
 > data is modified by opes device. The provider will come to know
 > which lang. the content is transformed the most. So that the
 > provider could keep a copy of the content in the same language.
 > Thus he could contribute on avoiding that many opes
 > transformations.

While there are clearly advantages in notifying the content provider
about certain services being performed, there are also services the
content provider does not really need to be notified about. 
Furthermore, default notification to content providers raises privacy 
issues - I might not want to let every content provider know what 
exact services I requested...

Notification is one thing, authorization another. Just as with
notification, there are services for which it would make sense to
require authorization from both endpoints (i.e. consumer and 
provider), but there are also services for which we cannot require
authorization from the provider. A stupid simple example is logging, 
or a charging service - why would a consumer need the consesus of a 
content provider to use a logging service? On the other hand, of 
course, legal issues might require provider authorization for certain 
services (e.g. content transformation). But maybe such authorization 
will happen in form of SLAs?

In general... In Section 2.2.2 of the scenarios draft, we talk about
"Services *not* intending to modify responses". Are these the services
that do *not* require authorization from content providers, while
"Services intending to modify responses" (as described in Section 
2.2.1) would require such authorization? And what about the services 
operating on requests?

-Markus

---

From: Arumugam K <[email-masked]>
Date: Wed, 14 Aug 2002 15:50:25 +0530

Hi,

see inline

> exact services I requested...

Yes. Default notification to content provider could be avoided
considering the
privacy issues. Instead of sending notification to content provider on
every
transformation, the cumulative report of the transformations may be send
to the
content provider. Especially in language translation service ,this will
help on
getting the advantage mentioned in my previous mail.

> will happen in form of SLAs?

When the content provider wants to have authorization for few services,
that has to be honoured. The SLAs could be used for this purpose.
I would like to mention one of the service given in the ICAP draft.
The ICAP protocol supports the advertisement insertion service. This 
service replaces the original ad with local ad. Definitely , without 
the approval of the content provider, this service could not be offered. 
SLAs could be used for this purpose.

> 2.2.1) would require such authorization? And what about the services

Sometimes it would make sense to provide a service to requests also.
An example could be given from the ICAP protocol.

Using ICAP ,we can provide a decompression service. The OS would keep
the content
in the compressed format. When the user makes a request to the original
data,
the ICAP server will convert this request to a request for compressed
data.
On receiving the compressed data, the ICAP server will decompress it and
sends 
the data in the original format to the end-user thro' the ICAP client.
This service helps on saving the network bandwidth.

In this service both request and response undergoes some modification.
This may be considered as a service where request also needs
modification

PS:  I would like to know the view of the ICAP team on adding the
decompression
     service to the current ICAP draft 

Thanks
Arumugam

-- 
Want to know CDN?
http://cdn.hcltech.com