I mentioned this at some point in Minneapolis but it seems appropriate to
bring it up again in this thread. The assertion that all policies for
intermediate processing can be broken down into the 4 processing points, I
think, is short-sighted. It seems reasonable to me that we define some of
these expected processing points but I'm certain that some implementations
will invent new points in the flow at which to insert rule engine
evaluations.
For example, an implementation may choose, for efficiency reasons, to have
only one processing point per direction to avoid multiple invocations of the
rule engine: classify the message once and run all of the actions that
apply. There may be implications that might need to be exposed to the rule
authors, in which case, they'll need to have a different processing point
defined. There may be a different implementation that introduces processing
points that are related to interface types. For example, one might have a
special set of rules for POTS links or for different wireless services. One
might argue that a set of rules that are related to available bandwidth
might be a condition rather than a processing point. All processing points
can be thought of as another condition, e.g., if "replying to user-agent"
could replace processing point 4, yes? (In fact, once we introduce
"environment variables" into the rules, it may be hard to tell the
difference.) So, if everything that's outbound on a given link needs
adaptation, why not make it a processing point.
In the policy framework, these meta-conditions are used to select the rules
appropriate for a given processing point; they're called PolicyRoles.
If we were to pick up on this notion, an implication of this generalization,
I think, is that at architecture design-time we cannot dictate what happens
when. We could, perhaps, define some default policy roles (i.e., 4 of them)
but the architecture would need to have the flexibility to permit
implementation and deployment decisions that we're currently not
anticipating.
Comments?
Lee M. Rafalow
Voice: 1-919-254-4455; Fax: 1-919-254-6243
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, BRQA/502
RTP, NC 27709 USA
Alternate email: rafalow(_at_)us(_dot_)ibm(_dot_)com
Home email: rafalow(_at_)mindspring(_dot_)com
----- Original Message -----
From: "Andre Beck" <abeck(_at_)bell-labs(_dot_)com>
To: "Rajnish Pandey" <Rajnish(_dot_)Pandey(_at_)sun(_dot_)com>
Cc: <Hofmann(_at_)bell-labs(_dot_)com>; <ietf-openproxy(_at_)imc(_dot_)org>
Sent: Friday, May 04, 2001 4:25 AM
Subject: Re: Processing Point
Rajnish,
Suggestion : We can put such rules at point 3. And rules at point 3
should
be always considered, irrespective of object coming from origin server
or cache.
This would help us in taking advantage of cache.
I think we have to differentiate between services that generate a
user-specific response and those that don't.
User-specific services usually modify Web objects depending on certain
user characteristics, for instance if the user's native language is
German, then all Web pages are translated to German or if the user's Web
access device is a Nokia cell phone, then all requested Web objects are
adapted to fit the screen of the user's Nokia cell phone.
The second category of services modify Web objects equally for all
users. For example, a virus scanning service removes the same viruses
for all users. Or a bandwidth-saving service may compress all Web pages
with gzip before they get sent to the users.
Rules that trigger services of the non-user-specific kind should be
processed at processing-point 3 because the service execution result may
automatically end up in cache if the caching proxy decides that the Web
object is cacheable. These cached objects would subsequently be served
to other users as well.
Rules that trigger user-specific services should be processed at
processing-point 4. The service execution results at point 4 could still
be cached. However, they would be cached by the service itself rather
than by the caching proxy. The same is true for the retrieval of such a
cached Web object. The caching proxy wouldn't know what object to serve
to the client because it doesn't know the user's characteristics like
preferred language etc. Therefore this would probably require a service
at point 1 which gets triggered for certain user requestss and would
then check for a cached Web object that matches the user's
characteristics.
Comments?
-Andre