[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf Policy MIB: elements
Pablo Halpern wrote:
> 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.
You don't know which is the first accessible column so you have to
depend on getnext to tell you. Normally when we getnext through a column
we give as a constraint the column oid which is the root of the subtree
- this algorithm is different, you have to retrieve an OID which will
become the constraint OID. In this case you'd say, if I have OID with N
subids, do a getnext and save the N+1 subids of the response oid and
then walk the subtree constrained by these N+1 subids. So the answer was
"this is too complex to write without confusing many readers". Maybe I
could define it in policyScript code.
Of course there are benefits to not having the columnar OID. One is that
the de-duplication text could be removed (The paragraph beginning with
"Before registering ..."). The other is that I fear that with the
columnar subid included that it is too suggestive that a getnext walk is
the only way (or even the suggested way) to do discovery. It would also
be easier for the policy script to do a match on the element type.
Now that I think about it I have a better answer:
There's no reason I need to describe the discovery mechanism as a walk
of a subtree. If we just specify up to the "entry" part of the oid (e.g.
ifEntry), then it can just speak of "all instances of xxxEntry" without
getting caught up in any description of the algorithm to retrieve them
> 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? :-(
That's one of the things I was originally uncomfortable with which led
me to say *any* columnar OID. Another was what if that column isn't
implemented by a particular agent. I realize now that practically
speaking, the agent will be in a better position to choose the column
than the manager.
> >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
> 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.
Yes, this is one of the proposals I plan to make in Minneapolis. Those
of you in the New Hampshire meeting (a long time ago) will remember we
discussed this topic but didn't act on it. I now think this is really