Re: Status of the Event MIB?

On Thu, 2005-03-24 at 16:41, Randy Presuhn wrote:
> Dave Shield wrote:
> > Is this MIB still open to anything other than editorial
> > changes, or is the behaviour now pretty much fixed?
> 
> We hope the behaviour is fixed (in the sense of "no longer
> broken").

I wouldn't go as far as saying it's actually "broken".
But unless I've completely misunderstood how this is meant to
work, then it's currently *much* less useful than it could be.

>   If you mean "fixed" as "not to be changed", that's
> another matter.

Yes - that's exactly what I'm asking.

> > Because I'm increasingly convinced that the handling of
> > the mteObjectTable is flawed.
> ...
> 
> This is a legitimate topic for discussion.
> The WG should discuss the severity of the perceived problem
> and weigh that against the impact of the proposed change.

It's been suggested that my original explanation of the problem
was not particularly understandable.  I offer the following as
being (hopefully) a little clearer:

  Assume a trap is defined (in the MIB) as taking one object V.
  Let the corresponding entry in the object table use the tag O.

  Assume there is another "extra" object W, with object tag P,
  that should also be added to the trap.

  What should the values of mteEventNotificationObjects and
  mteTriggerObjects be?   How does this then map into the trap
  that's generated ?


I suggest that the most natural configuration would be

    mteEventNotificationObjects = O   (to add V)
&   mteTriggerObjects           = P   (to add W)


However, this results in a trap with the wrong payload (W,V).
Tweaking the order in which these objects were processed 
(taking mteENO first) would correct this.

Dave