Re: mteOwner in Event MIB Notifications

Hi -

> From: "Carl W. Kalbfleisch" <[email protected]>
> To: <[email protected]>
> Sent: Friday, July 22, 2005 10:16 PM
> Subject: [Disman] mteOwner in Event MIB Notifications
>
> I am working with an implementation of the DISMAN Event MIB.
>
> I get a mteTriggerRising notification with the following attributes:
>
> SysUpTime = 0 hours, 37 minutes, 0 seconds.
> Trap OID = .1.3.6.1.2.1.88.2.0.2
> .1.3.6.1.2.1.88.2.1.1 = processorLoad
> .1.3.6.1.2.1.88.2.1.4 = .1.3.6.1.2.1.25.3.3.1.2.1
> .1.3.6.1.2.1.88.2.1.5 = 32
>
> However, there is no instance information provided by the agent
> because the attributes in the VarBind list are scalars rather than
> the tabular data they actually represent.
>
> The question is, how can the manager know the mteOwner for the
> corresponding notifications. It seems like mteTriggerName (which is
> encoded as the mteHotTrigger in the notificatin) only has to be
> locally unique within a specific value of mteOwner. Therefore it is
> possible that I could have foo.x and bar.x as indexes into the
> mteTriggerTable, but when either goes off, the corresponding
> mteHotTrigger would be x with no indication of foo and bar.
>
> So how does the management application know which one it was? Is
> there a reason why the MIB is defined this way to exclude the
> instance information and the mteOwner.
>
> Could I define an entry in the mteObjectsTable t "add" mteOwner as a
> VarBind to the notification? Or is there also some reason I should
> not take this approach.
...

Yes, that's probably the simplest solution.

To me this suggests that the definitions of the NOTIFICATION-TYPEs
mteTriggerFired, mteTriggerRising, mteTriggerFailure, and
mteEventSetFailure are all arguably broken, in that all of them
have this same problem.  Fixing this would require deprecating
the existing notifications and adding new ones that had the right varbinds.
Not terribly appealing, and it would send us around again at "proposed",
but it seems that what's there is broken.  Please convince me otherwise.  :-)

Randy