Re: Improvements for the sample tech document

[Nevil Brownlee <nevil@auckland.ac.nz>]

Hi Thomas:

I think Maurzio summarised 'filtering rules' well.

> To summarize it:
> there are two options about how to describe a filter:
> 1) describe it  with a "high level" syntax (like the one you propose)
> probably easy to implement and to export, that can build on existing
> common practice and code, but with the risk that it is "incomplete" and
> has to be proprietarily extended to match each vendors' implemented
> filtering rules (thus risking low interoperability)
> 2) describe it  with a "low level" syntax, in which whatever high level
> syntax can be translated (thus 100% interoperable and complete), with
> the (limited??) drawback of bigger exporting overhead  and the (big??)
> drawback of needing to write, on each equipment, the code that converts
> the description of a propriatery high level filter into that one?
> 
> Just to explain the current situation: in the absence of a decision, I
> described in the sample tech draft the low level syntax only, but I'm
> not engaged to it...
> If we want to take the other approach fine,  but in this case the group
> should reach some agreement of what this syntax should look like. Thomas
> stated his proposal, but  it's necessary to have a more extensive
> discussion on it. In particular, other vendors should state what their
> common practice in filtering is (which fields do you filter on? can you
> define masks, intervals, etc.?.).
> 
> The group should also decide if 1) and 2) are mutually exclusive, and if
> not what is MUST, what SHOULD and MAY.....

As another example of current practice, you might have a look at 
RTFM's Simple Ruleset Language, RFC 2723.

SRL uses simple (equality under mask) tests of RTFM attribute values
from the packet.  Using the RTFM attributes to select fields from
the packet has the advantage that they're well defined, and RTFM's
IANA considerations (in RFC 2722) saying how new attributes can be
added.

It has the disadvantage that it was built on top of the RTFM packet
matching engine, which is very general, and hence difficult (but
certainly not impossible) to implement in a high-speed metering
system.

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                 Computer Science Department | ITSS
   Phone: +64 9 373 7599 x88941           The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>