Re: issues on IRML & rule processing for OPES

["Micah Beck" <mbeck@xxxxxxxxxx>]

Unfortunately, I cannot make it to the workshop, but I will offer my
opinions for the record:

----- Original Message -----
From: "Yang, Lily L" <lily.l.yang@xxxxxxxxx>
To: <ietf-openproxy@xxxxxxx>; "Yang, Lily L" <lily.l.yang@xxxxxxxxx>
Cc: "Andre Beck (E-mail)" <abeck@xxxxxxxxxxxxxxxxxx>;
<hofmann@xxxxxxxxxxxxx>
Sent: Tuesday, June 05, 2001 8:18 PM
Subject: RE: issues on IRML & rule processing for OPES


> Here is a list of open issues concerning IRML and rule processing:
>
> 1) In what order should the rule engine process rule modules by client,
> content provider and access provider?
>  The current IRML draft proposes the order following the content flow,
i.e.,
> the requests from the client to server (at point 1 & 2) should be
processed
> in the order of client, access provider to content provider, while the
> responses (at point 3 and 4) should be in the order of content provider,
> access provider to client. This order may not always make business sense
to
> the OPES box owner. One can argue that the exact order should be left
> outside of the rule engine and other external factors such as business
> arrangement or administration policy could dictate the order in any way.
> Following this argument, the ordering infomation can be completely left
> outside of the IRML and be part of the configuration or policy info on the
> OPES device. Thus the question becomes how and in what form, what
> granularity such order infomation should be passed to the OPES device?

I strongly urge OPES to define an interface that allows the fully integrated
set of rules to be specified with no possibility of introducing additional
rules.  This interface could be used by a mechanism that integrated
multiple, interdependent sets of rules from different sources to create a
single, well-defined rule set with a known order of rule applications.

If the OPES group really wants to try and specify a mechanism for rule set
merging, then that can be a seperate effort, using a metadata language that
specifies dependences and other complications.  However, the basic rule
application mechanism is useful even if this rule set merging mechanism
cannot be standardized.  There are business approaches to using OPES that
have no need for rule set merging procedures.

> 2) How many and what kind of processing points should we define for OPES
> devices?
> Currently there are 4 clearly-defined processing points in the OPES
> framework and these points are very much cache-oriented. Are there any
> additional points that people see useful for other intermediary devices or
> applications? Should these points be defined statically at the
configuration
> time or dynamically on the fly? (Actually I don't see how it can work
> dynamically since the rules are written for a specific processing point in
> IRML, hence the processing points need to be well-defined to be
> interoperable.)

Perhaps there should be a hierarchical system for naming processing points?
A servelet sees only one processing point: the client request/response.  A
cachelet sees four: the client request in, the server request out, the
server response in and the client response out.  Apparently, some people see
a value in further decomposing some of those points.

> 3) What kind of environmental variables need to be supported in IRML?
> Currently we have time and day. Anything else? How do we support condition
> like "when the server load is low..." ?
>
> 4) Currently IRML supports only regular expression for condition matching.
> Do we see a need for other kind of conditions, like arithmetic support?
This
> is related to question 3). Regular expression isn't so handy for
conditions
> like "for every 5 minutes", or "if the load is below 25%" etc.

This is moving IRML towards being a scripting language for proxies (equally
applicable to servers, by the way).  Defining such a language is an
interesting idea, but perhaps a bit ambitious for OPES at the moment.

> 5) Currently IRML supports only static and exact action binding in the
> <action> element. It is proposed that late and flexible (or not-exact)
> action binding might also be desirable. How can IRML facilitate both? In
> another word, how can we allow people to say "do exactly this translation
> service by this vendor at this location", or "just do whatever virus scan
> you have".

This is no longer a rule-based service, it is end-user programming.

> 6) Do we allow multiple rule modules from the same content provider (for
> different level of domains)? One example is to have one general rule
module
> for intel.com and another more specific rule module only for
www.intel.com.
> Since the ID attribute in the <owner> element really identifies the domain
> boundary that the rule module is applicable to, it seems legal to have
both
> rule modules in place and it also seems logical to apply both rule modules
> for content inside www.intel.com domain. Does it make sense? What about
the
> order then? Should it be the general module (intel.com) first followed by
> the more specific one (www.intel.com)?

See comment on (1) above.

> 7) what kind of rules make sense for streaming media instead of web
content?
>
>
> Feel free to add to it.
>
> Lily

Hope this is useful input.
/micah