[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf Policy MIB: elements



At 06:22 PM 3/8/2001 -0800, Steve Waldbusser wrote:

>Robert Moore wrote:
> >
> >    The question is, why is *any* columnar OID allowed
> >    to identify an element type, leading to the
> >    clumsy-sounding rule that to detect duplicate
> >    element types, the last arcs of their OIDs must
> >    be ignored?  Is there any reason the OID for a
> >    (single-table) element type can't be defined to be
> >    the first accessible column in the table, similar
> >    to how the RowPointer TC is defined?
>
>Maybe it could be, I was just trying to be careful. It was hard to
>declare at the moment I was writing that text that: "the first
>accessible column in the table will *always* be appropriate". On the
>other hand, I really can't think of any reason why not.

For that matter, why does a columnar OID need to be specified at all? Why 
not just the table or tableEntry OID?  Doing a getnext on a tableEntry OID 
will return the first row of the first accessible column of the table, 
right?  Then there is no need to strip off the last arc of the OID.

There is one reason I can think of for requiring a columnar OID and 
allowing *any* column to be specified: holes.  Some columns may have holes 
in them. Using these columns's OIDs for element discovery would cause some 
elements to be missed. Ain't SNMP wonderful? :-(


>What I'm trying to say is the following code is also valid:
>
>     if (insubtree(elementName(), "ifEntry")
>         && getvar("ifOperStatus.$0") == 1
>         && getvar("dot3StatsDuplexStatus.$0") == 2)
>         return 1; // Match
>     else
>        return 0;
>
>Note that the element type is ifEntry, and we are using the address of
>ifEntry elements ($0), but we are using dot3StatsDuplexStatus as one of
>the "attributes" of this element. We don't need to create an elementType
>for dot3Entries.

This makes me wonder, do we want to run every policy filter over every 
discovered element?  Won't most policies be specific to certain element 
types?  Here's an idea (although it might be too late for it):

Add a column to the pmPolicyTable (e.g. pmPolicyElementPrefix) that acts as 
a "pre-filter" for a policy.  Only elements that match the specified 
prefix  will require running the filter. If the prefix is empty, then the 
filter would be run on all element types.  This would have three beneficial 
effects:

1. improved performance (because filters will not need to be run as often, 
especially if the agent is properly optimized).

2. Simpler filter code (drastically reduce need to call insubtree()),

3. (Addressing the confusion about multi-table element types), it would 
encourage the user to consider what really makes an element. In the above 
example, the pmPolicyElementPrefix value would probably contain the ifEntry 
OID. The user would hopefully realize that there is no need to also match 
dot3StatsEntry.  Even if he doesn't the policy action would still run only 
once per element because only ifEntry would actually trigger it.


- Pablo
---------------------------------------------------------------------
Pablo Halpern                                    phalpern@newview.org
http://www.halpernwightsoftware.com