RE: [Pcs] Re: some questions and comments on draft-barbir-opes-sp cs-01


hi all,

for dynamic rules we need to be carefull. In some cases we will need to
generate the rules and then delte it after the session is terminated. This
will be needed for privacy/security reasons. Thus, this may require that the
box be aware about the concept of a session.


abbie

-----Original Message-----
From: The Purple Streak (Hilarie Orman) 
[mailto:ho(_at_)alum(_dot_)mit(_dot_)edu]
Sent: Monday, April 01, 2002 2:29 PM
To: Yang, Lily L
Cc: ietf-openproxy(_at_)imc(_dot_)org; 'pcs(_at_)eng(_dot_)registro(_dot_)br'
Subject: Re: [Pcs] Re: some questions and comments on
draft-barbir-opes-sp cs-01.txt

It looks more like terminology if the rule compiler isn't tied to the
admin server, but instead has the freedom to reside in the OPES box,
optionally.  Then the OPES engine only has to notice that new rules
have arrived, get them approved, compiled, and loaded.  Whether this
is done locally or by being shipped to the admin-svr/rule-compiler and
returned in internal form isn't critical.  Some sites will not
accept dynamic rules as a matter of policy, I'm sure.

Hilarie

Yang, Lily L wrote:

Hilarie -- Maybe you are right to call it a matter of

terminology than

architecture. But I am a bit confused now about the role of

Admin server and

the callout server and how much now they overlap with each

other. I am also

concerned about the performance implication of dynamically

loading rules to

the OPES engine by callout server in the content path in

real time. In a

separate thread, you mentioned the slow XML parsing

performance. Whether or

not that is indeed true remains an ipen issue. But having

the callout server

dynamically loading the rules onto the OPES engine requires

that the rules

being transported over the wire is in standard formats

(IRML?) instead of

the internal format between the Admin Server and the OPES

engine. That

imposes some extra (XML?) parsing overhead in the content path. 
All these have implications that I think deserve some

careful consideration

in the requirement gathering phase.
Lily

-----Original Message-----
From: The Purple Streak (Hilarie Orman) 
[mailto:ho(_at_)alum(_dot_)mit(_dot_)edu]
Sent: Thursday, March 28, 2002 2:38 PM
To: ietf-openproxy(_at_)imc(_dot_)org
Cc: 'paknight(_at_)nortelnetworks(_dot_)com'; 
'pcs(_at_)eng(_dot_)registro(_dot_)br'
Subject: [Pcs] Re: some questions and comments on
draft-barbir-opes-spcs-01.txt

This seems like a matter of terminology more than architecture.
The OPES intermediary can trigger on the event "begin user
session" and have the action "notify personalization server" or
"notify user services admin server" as basic policy rules.  The
communication can use the OPES callout protocol, and the returned
items can be rules.  OPES policy can state that rules are 
only accepted
from a trusted callout server list, and they can implement

the policy

that the returned rules can apply only to the user session for which
the callout server was invoked.  This doesn't seem particularly
dangerous.  It does put more requirements on the OPES engine 
to enforce
local policy, but I thought it was going to be a policy enforcement
engine, anyway.

Hilarie

Yang, Lily L wrote:

Hi, Paul -- 

Just went through draft-barbir-opes-spcs-01.txt. Sorry that

I couldn't do

that earlier -- Looks like I got a lot to catch up.

First of all, I am not sure that I fully understand the

exact role of the

OPES Service Personalization Callout Server (SPCS) and how

it should be

treated in the OPES framework. My understanding of the

draft is that, to

achieve service personalizaiton, we actually need to deploy

two kinds of

callout servers within the OPES framework. One is the SPCS,

its role is to

generate dynamic rule modules to upload onto the OPES

intermediary based

upon subscriber profile and content profile. But the actual

rules (which are

dynamically generated by SPCS) will possibly invoke some

content adaptation

service that is to be carried out by the Callout Server

(per the diagram

depicted in Figure 1 on page 12). These Callout Servers are

the second kind

of callout servers. At the surface, both are callout

servers and should be

treated as such by the OPES framework. However, they are

VERY different in

what they actually do. 

In my mind, callout servers only do adaptation service for

the content, they

don't control/alter the behavior of OPES intermediary (the

engine). So only

the second kinds are the real callout servers in that

sense. The first kind

(SPCS) is not, at least not according to my understanding

of the callout

server definition. Allowing a callout server to dynamically

upload or delte

rules from the OPES engine sounds like asking trouble to

me. Allowing them

to adapt the content is already a riksy business! This is

10 times worse

than that. To me, SPCS sounds much more like one instance

of the OPES admin

server. Admin Server is the entity that can control/alter

the behavior of

OPES engine and it requires a much tighter security/trust

model between the

Admin Server and the OPES engine. . 

The description of the SPCS's functions are very much the

same as the Admin

Server, but with some important exceptions -- the purpose

of SPCS is much

narrower of the Admin Server; and there is the "real-time,

in the content

path" aspect of SPCS that is not required (in general) by

the Admin Server.

My understanding is that SPCS needs to generate and upload

the dynamic rules

in real time at the beginning of the "SP-session", and then

SPCS is not

involved for the rest of the session before its

termination, is it correct?

At the middle of the session, the rules that is just

uploaded would govern

the actual content adaption (for personalization). It seems

that somewhere

the text also suggests the profile might change mid-session

and does that

mean the rules will be generated again mid-session?

Maybe I misunderstand the whole concept -- otherwise, I

have some serious

concern about some of these issues. 

Lily


_______________________________________________
Pcs mailing list
Pcs(_at_)eng(_dot_)registro(_dot_)br
http://eng.registro.br/mailman/listinfo/pcs



_______________________________________________
Pcs mailing list
Pcs(_at_)eng(_dot_)registro(_dot_)br
http://eng.registro.br/mailman/listinfo/pcs

RE: [Pcs] Re: some questions and comments on draft-barbir-opes-sp cs-01.txt