Re: mteOwner in Event MIB Notifications

I was able to successfully add mteTriggerComment to the VarBind list and when it comes accross, I get instance information. 

However, this requires configuring mteTriggerObjectsOwner and mteTriggerObjects for each entry in the mteTriggerEntry so that I can specify different attributes in mteObjectsEntry which includes the instance information for the mteTrigger attributes. This is quiet combersome.

It would be nice to add mteOwner to the notification. However, as Randy pointed out that would require recycle at proposed.

I am wondering if we could avoid this by changing the description of mteTriggerName by dropping "for the trigger within the scope of mteOwner". IE, make mteTriggerName unique. This would prevent having instances foo.x and bar.x, but would allow the manager to scan the table for x. Just throwing out some options.

Thoughts?

Carl



-------------- Original message -------------- 

> 
> 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" 
> >> To: 
> >> 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 
> > 
> > 
> > 
> > 
> > 
> 
>