Re: Call for censensus on path forward

Mark Ellison wrote:
> 
> Hi Wes,
> 
> My (neutral) observation regarding complex filtering-
> 
> Why not start with the same expectations for logical operations as described in the
> definition of the expExpression object type in the disman expression mib?
> 

But the ASN.1 will have to define a means to represent the filter.

> Since simple is better when it comes to complex, I would also suggest two levels of
> compliance- the agent either does the complete specification for complex filtering, or
> does not do any filtering at all.  My concern is that many shadings in between would make
> it too difficult for management operations to accommodate variations in filtering rules.
> 
> Since I assume that complex filtering would be of interest to applications already using
> the disman expression mib, I surmise easier adaptation of complex filtering by such
> applications.
> 


Some of the drivers behind my proposal are:

-simple
-leverages existing get-bulk code
-leverage existing response

Carl

> Looking forward to the next draft!
> 
> Regards,
> 
> Mark
> 
> Wes Hardaker wrote:
> 
> > >>>>> On Mon, 23 Sep 2002 10:10:09 -0400, Dinakaran Joseph <[email protected]> said:
> >
> > [Sorry for the delay.]
> >
> > Dinakaran> A simple logical operations for filtering would be a very
> > Dinakaran> good thing.
> >
> > Ok, so you'd like to be able to use more complex expressions like:
> >
> > (column1 > 100) && ((column2 < 1 || column3 =~ /some.*thing/ ||
> >                     (column8 == 8 && column9 == 9)))
> >
> > Right?  Based on your statement, and the fact that Carl Kalbfleisch
> > and David Perkins submitted allowing similar expressions, I'm going to
> > take it that this feature is more desired than not.  I'm really
> > interested in hearing from anyone that opposes this level of
> > complexity being thrown into the protocol.  As I said at the bottom of
> > my last draft, I didn't throw this in because I didn't think people
> > would like it since it would impose even more requirements on the
> > agent side of things.  Any agent developers want to say something
> > negative about complex filtering, otherwise it'll go into my next
> > draft (in an easy to parse way [read: nested BER sequences]).
> >
> > More questions, assuming people want this:
> >
> > 1) should AND/ORing be MUSTs, SHOULDs or MAY?  (can it be optional to
> >    implement)
> >
> > 2) should there be a max depth or grouping level allowed to the
> >    expressions?  IE, can an agent say I won't support the above
> >    because it's greater than my max depth level of 2 (since the above
> >    has 3 levels of parens).
> >
> > --
> > Wes Hardaker
> > Network Associates Laboratories

-- 
Carl W. Kalbfleisch
NTT/VERIO
www.nttverio.com