headers
Dave Shield | 28 Feb 2005 18:26
Picon

Event-MIB - request for clarifications

I've recently been looking at the Event MIB, and whilst I've
mostly got a handle on how this works, there are a few things
that I'm not fully clear on.   I've had a look through the
mail archives without much luck, but if these issues have been
covered before, just point me to where they've been discussed.

  The points on which I'd appreciate some clarification are
the following:

a) Wildcard handling

  If mteTriggerValueID uses a "partial" wildcard, then
should the wildcard handling of corresponding mteObjectsID
and mteEventSetObject entry append the *full* instance of
the mteTriggerValueID value that matched, or just the OID
suffix added as part of the expansion?

For example, suppose I'm monitoring an interface-related
table that's indexed by ifName strings, and specify a
mteTriggerValueID of 'someObject."eth"'
(with mteTriggerValueIDWildcard set true).

Then a trigger fires, matching "eth1" (i.e. adding '1')

Should the corresponding mteObjectsID entries be specified
as 'someObject2."eth"' (and add the matching '1' suffix) or
just 'someObject2' (and add the full matching instance "eth1")

b) Updating configuration settings
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Shield | 3 Mar 2005 17:08
Picon

Event MIB object handling

I've got another question relating to the Event-MIB, in particular
the handling of the objects to be added to a notification payload.

Should the objects listed in the mteObjectsTable cover *all*
the varbinds for a particular notification, or just the "extra"
ones not included in the NOTIFICATION-TYPE definition (with those
being inserted automatically) ?

I've been assuming that this table should list everything
(since the agent might not have access to the MIB definition).
In which case I'm a little puzzled about the order in which
the three mte{Trigger,TriggerXxx,EventNotification}Objects
tags are applied.

Naively, I'd expect that the mandatory notification objects
would be closely linked with the notification itself, and hence
be specified via the mteEventNotificationObjects tag, with the
two trigger tags being used to add extra non-standard varbinds.
Which would imply that the mteENObjects tag would have to be
applied first.  And there's a note in the archives from Mike
Daniele (<3665A029.C3B03BD <at> zk3.dec.com> dated 02 Dec 1998)
commenting on draft #05 which seems to suggest the same thing.

  But draft #06 introduces text in the mteObjectsIndex
description which says:

   Groups are placed in the notification in the order of the
   selections for overall trigger, trigger test, and event.

and this seems to have remained the same through into RFC
(Continue reading)

Permalink | Reply | 5 comments |

Gmane