Re: P work in new charter

[Geetha Manjunath <geetham@xxxxxxxxxxxx>]

Hi,
I think Alex has put the scoping of 'P' discussion in a nice way... I mostly
agree with his agruments..

In terms of  what 'P' would enable:
* Rule Specification : The filtering services themselves would be provided by
vendors (say, virus scanners) while the configuring conditions (rules) will
be  described/specified using the 'P' rule language.
* Writing simple filters/actions: While modifying a message to be able to
call several commoditized filters may be one of the examples (Alex), I would
see the need for writing actions more when the actions themselves are very
simple - may be to just put some additional authentication controls onto
services, where the OPES processor would just return a 40x response. It could
also be used to compose output of multiple filters (I remember a discussion
we had on this mailing list about how pipelining of filters should function
and so on. This now leaves the decision to the rule writer). There will be
many more use cases I am sure.
* Writing modules in 'P':  Since a set of rules themselves may need to be
reused many a times, we may want to create customized reusable modules in 'P'
.

While the above are under the category of  "#1. How deep does P reach? (P
scope)", I want to just add on additional option to "#2. How deep does our
charter reach? (WG work scope)" or an extension to 2c.
(d) defining mechanisms by which a user can communicate rulesets to the OPES
processor.

Comments Welcome.
(sorry for joining in late on this thread - I was on a business trip could
not see my emails earlier )

Thanks and regards
Geetha

Alex Rousskov wrote:

> On Tue, 29 Jun 2004, Markus Hofmann wrote:
>
> > It moves functionality I would expect from a service itself into the
> > rules language!
>
> I believe I understand your concerns.
>
> The outcome of this discussion will have a paramount effect on initial
> P specs and, with some luck, on P success. So let's proceed with care.
>
> We are trying to find the right scope for P. We all agree that P is
> used for selecting services based on messages. We all have an
> understanding of what a typical service does to a message (block,
> filter, or modify). We all realize that a lot of customizations (i.e.,
> using logic and data specific to a local service invocation
> environment and to the message itself) may be required to adapt the
> message correctly; some of those customizations might be quite
> complex. We may disagree on where some of those customizations should
> be taking place and how they should expressed.
>
> > Rather than building all these fine-grained capabilities into the
> > rules language itself, I would prefer a very simple rules langueage
> > that allows me to invoke services - all the logic and more
> > fine-grained rules are part of the service.
> >
> > The whole reason we want to have callout servers is to move services
> > out to a separate server. Are we now trying to move some of the
> > processing complexity back into the OPES processor in form of a
> > highly programmable, compelx rules language that allows
> > "programming" of actions?
>
> I believe you highlighted the core of our problems and also hinted at
> the solution!
>
> Here is a key question: Why do we have OPES service as a distinct
> entity? Why do we not simply talk about OPES processors that somehow
> adapt messages? Calling a piece of code a "service" does not make it
> more efficient. Placing a piece of code on a separate box is not
> always a good idea (or we would not have software libraries and
> integrated appliances).
>
> I believe the primary reason we logically isolate services from
> processors is that we expect and want many services to be standardized
> and commoditized (based on their functionality, separately from OPES
> processors). Folks will be able to plug in the "best" virus filtering
> service, the "best" translation service, the "best" mobile rendering
> service, etc., all selected among many standardized offerings.
>
> If services are not easily pluggable/interchangeable, if there are
> only a few vendors building a few services, then we are wasting our
> time here. IETF WG should not be concerned with technologies that
> support just a few vendor products.
>
> So what? Well, if our operating environment is a large set of
> standardized and commoditized services, then those services cannot be
> efficiently customized by service _manufacturers_!
>
> For example, most customers today cannot buy a customized version of a
> disk drive or motherboard for their PC. They can select from a variety
> of models that will all comply with a few standards for size, voltage,
> and functionality. Manufacturers of drives and boards cannot know
> exact user needs and have to ship with reasonable defaults.
>
> Now, if customizations are essential, but OPES services cannot be
> customized by their manufacturers, and the number of manufacturers is
> large, there are two sane customization options for OPES
> administrators:
>
>   - customize OPES processor using a common rule language:
>     if (message meets some condition) then
>         apply(some service to message)
>
>   - customize OPES service using a common service-customization language:
>     if (message meets some condition) then
>         apply(some service function to message)
>
> Note that an OPES administrator will end up writing pretty much the
> same kind of rules in either case. That is, regardless of what is
> customized (processor or service), the same rule language is needed!
>
> In summary, we cannot assume that commoditized services will be
> customized by their manufactures and, hence, we cannot "offload"
> customization complexities from P to manufacture-specific
> languages/solutions. Same for OPES processors. We have to support
> those customizations in P, which may be used to customize OPES
> processors and/or services.
>
> Do you agree with the above logic?
>
> If yes, here is the next logical step. Given a set of commoditized
> OPES processors, commoditized OPES services, and a single rule
> language to configure/customize them, what should the minimal scope of
> that language be? I believe the answer is that "the language should be
> good enough for expressing all common OPES customizations" simply
> because that language is the _only_ customization interface an OPES
> administrator will have.
>
> For our work to make sense in IETF setting, we must accommodate common
> customizations _natively_ in P. We must not rely on processors or
> services to provide OPES administrators with non-standard ways of
> doing some part of that customization. Commoditized processors and
> services will not have non-standard interfaces, and an IETF WG should
> not care about markets where there are just a few vendors and those
> vendors are using a few proprietary interfaces.
>
> Is there a flaw in the above logic?
>
> Please note that the above does not give us the answer for, say,
> whether P should support user-defined functions or full regular
> expressions. However, it may give us a framework to derive those
> answers:
>
>         - If user-defined functions are essential for
>           matching messages with services, then P must have them
>
>         - If full regular expressions are essential for
>           matching messages with services, then P must have them
>
> We just need to debate whether X is essential for a good matching
> interface. If it is essential, it must be supported natively in P.
>
> In the absence of such a framework, we now have to debate two things:
>         - whether X is essential for a good matching interface
>         - whether X has to be supported natively in P or as
>           a part of some custom service or processor knob
>
> Sorry for such a long message. I could not find a shorter way to
> express this idea. Hope it makes sense.
>
> Please comment.
>
> Thanks,
>
> Alex.