-----Original Message-----
From: Scott Brim [mailto:swb(_at_)employees(_dot_)org]
Sent: Sunday, March 31, 2002 10:58 AM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: The Purple Streak (Hilarie Orman); ietf-openproxy(_at_)imc(_dot_)org;
Knight,
Paul [BL60:1A00:EXCH]; 'pcs(_at_)eng(_dot_)registro(_dot_)br'
Subject: RE: [Pcs] Re: some questions and comments on
draft-barbir-opes-sp cs-01.txt
On 31 Mar 2002 at 09:58 -0800, Reinaldo Penno allegedly wrote:
Hello Lily,
having a callout change rules on OPES follow a similar
architecture adopted
by the MIDCOM WG, where a external server change
firewall/NAT rules on a
midllebox and also the policy framework in general. This is
nothing new to
the IETF and as Hilarie pointed out, the idea is/was that the OPES
intermediary would be a policy engine.
You can't draw a parallel with how a midcom agent is supposed
to talk to
a midcom intermediary, except when you get down to the level where all
such policy transaction protocols are the same. The midcom agent
initiates the interaction, and may not know which intermediary (or
intermediaries) is in-path when it first does so.
I know what you mean, but eventually it needs to know which
intermediary/middlebox is in-path (through manual configuration or a MB
discovery protocol).
Thinking about midcom, it seems that OOP midcom agents and OPES have greater
similarity.
The OPES call-out
server knows exactly what the state of a particular rule should be on
the particular in-path box it's talking to. The call-out
server is more
knowledgeable about policy. The midcom agent is more akin to an OPES
client. It knows what rules it wants but not what the policy might be
surrounding the intermediary.
...Scott
regards,
Reinaldo
-----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: Knight, Paul [BL60:1A00:EXCH]; '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