ietf-openproxy
[Top] [All Lists]

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

2002-04-01 11:36:33

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


<Prev in Thread] Current Thread [Next in Thread>