Re: mteOwner in Event MIB Notifications

I have to agree that it is broken. I have also since learned that I  
can't put mteOwner in the VarBind list because it is a non-accessible  
index. However, I think I might be able to put some other attribute  
directly from the table to convey the entire instance information. I  
am going to try that tomorrow.

Carl

On Jul 26, 2005, at 9:20 PM, Randy Presuhn wrote:

> 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
>
>
>
>
>