Subject: RE: SMTP filtering use case

From: "Abbie Barbir" <[email-masked]>
Date: Tue, 18 Feb 2003 04:54:07 -0500

Hi,
see comments inline

abbie

> -----Original Message-----
> From: The Purple Streak, Hilarie Orman [mailto:[email-masked]] 
> Sent: Monday, February 17, 2003 5:55 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: SMTP filtering use case
> 
> 
> 
> On Mon, 17 Feb 2003 at 17:17:18 -0500 Oskar Batuner avowed, 
> in replying to Alex Rousskov:
> 
> >  > It looks like the big question here is about control 
> over user  > 
> > preferences. To me, it seems unreasonable to assume that 
> all user  > 
> > preferences are handled at the OPES processor. It is just 
> too rigid of  
> > > a model and often very inefficient since the processor 
> knows very  > 
> > little about filtering and the filter (OPES server) may 
> need to know a  
> > > lot. If we restrict user preference handling to OPES 
> processor, we 
> > end  > up passing a lot of preference information to the 
> OPES server 
> > just so  > that it can process a transaction.
> 
> >  I'm afraid we are going too deep with analysis of this specific 
> > scenario.
> >  If I understand correctly Martin used preferences just as 
> an example of 
> >  the reason why callout processor may produce multiple responses 
> >  for a single request. 
> 
> Discussions that reveal schisms in the meaning of the 
> architecture are very important, whether or not it was the 
> intention of the original message.  The lack of specifics to 
> date has been difficult for everyone, and I'm sure that there 
> are more surprises lurking as we discuss a real protocol for 
> real uses.
> 

---------- abbie
agree, this is why we said that the fun begins now.

> >  There may be any number of reasons for the callout processor to
> >  produce multi-message response, the protocol just SHOULD 
> (MUST?) support 
> >  multiple responses while preserving transactional integrity.
> 
> >  We should not (MUST NOT) impose any limitation on what
> >  information is available to the callout processor (including 
> >  preferences) and how OPES processor and callout processor assign 
> >  tasks between themselves while performing a collaborative 
> >  processing - this is application specifics and should be 
> >  out of scope for protocol design.
> 
> I think it's not as collaborative and loose and all that.  
> The OPES processor is the enforcement point for privacy.  
> It's designed to be a very fast and fine-grained, 
> policy-based, application-layer switch.  If it is not the 
> repository for user preferences, then all the policy 
> enforcement and authentication requirements get pushed to the 
> callout servers.  This leaves the OPES processor with almost 
> no function - it might as well be a dumb hardware switch 
> operating at layers 4 through 7.
> 
> Hilarie
> 

---------- abbie

Hilarie, good points (agree with u here). 

We can not assume that the callout server will be the PEP (or at least the
main one). Otherwise, we get in trobule if the callout server is in
different administration domain, etc... The way I look at it, the OPES
processor may use different callout servers based on different services, so
this means that the OPES processor must be the PEP, the callout server can
be a secondary PEP if chaining is used.

abbie

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 18 Feb 2003 09:14:23 -0700 (MST)

On Mon, 17 Feb 2003, The Purple Streak, Hilarie Orman wrote:

> I think it's not as collaborative and loose and all that.  The OPES
> processor is the enforcement point for privacy.  It's designed to be
> a very fast and fine-grained, policy-based, application-layer
> switch.  If it is not the repository for user preferences, then all
> the policy enforcement and authentication requirements get pushed to
> the callout servers.  This leaves the OPES processor with almost no
> function - it might as well be a dumb hardware switch operating at
> layers 4 through 7.

On Tue, 18 Feb 2003, Abbie Barbir wrote:

> We can not assume that the callout server will be the PEP (or at
> least the main one). Otherwise, we get in trobule if the callout
> server is in different administration domain, etc... The way I look
> at it, the OPES processor may use different callout servers based on
> different services, so this means that the OPES processor must be
> the PEP, the callout server can be a secondary PEP if chaining is
> used.

I would suggest looking at the privacy/policy enforcement from the
content producer and content consumer points of view instead of from
OPES point of view. OPES must satisfy producer and consumer
expectations and must address IAB concerns. This does not imply that
we have to place enforcement in one place: OPES processor or OPES
server. It simply means that the policies must be enforced. The more
flexible the protocol is, the better. Neither the producer nor the
consumer care where/how exactly their policies are enforced as long as
the policies are enforced.

In some deployments, the OPES processor may be a dumb hardware switch
operating at L7. Fine! Some scenarios will make OPES server nearly as
dumb and place policy enforcement on the OPES processor. Great. If we
can permit both scenarios while enforcing the policies and addressing
concerns from producer and consumer points of view, we should do that.
At this time, it is too early to tell whether we can so let's not
assume any restrictions on policy enforcer location until we have to
introduce them.

Thanks,

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Tue, 18 Feb 2003 12:01:01 -0700

It's very difficult to satisfy the IAB concerns by saying that callout
servers will handle all policy - we aren't specifying the callout
server applications.  

I think that scenarios which can be satisfied by a switch are just
fine, but if they can be deployed today without any new protocols,
then they aren't topics for discussion in this WG, except as negative
examples, i.e., "you don't need OPES for that".

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 18 Feb 2003 12:19:23 -0700 (MST)

On Tue, 18 Feb 2003, The Purple Streak, Hilarie Orman wrote:

> It's very difficult to satisfy the IAB concerns by saying that
> callout servers will handle all policy - we aren't specifying the
> callout server applications.

We are specifying the protocol the OPES server MUST implement to be
called an OPES server. Our protocol may specify requirements that can
only be satisfied if OPES processor and OPES server work together and
do not violate each-other assumptions. That approach can both satisfy
the IAB concerns and allow for different implementations/integrations
of processors and servers to exist.

In other words, ideally, we should only care about the visible
end-to-end effect (the black-box approach) of a compliant
processor+server combo, not about what a particular OPES processor or
server may end up doing to satisfy our MUSTs.

> then they aren't topics for discussion in this WG, except as
> negative examples, i.e., "you don't need OPES for that".

If they are deployed today without OPES, they will violate IAB
concerns/requirements. That is why we are chartered, in part, to
produce a new protocol that addresses IAB concerns.

Alex.