Subject: [Disman] Status of the Event MIB?

From: David Partain <[email-masked]>
Date: Wed, 9 Mar 2005 22:21:55 +0100

Hi all,

I'm curious what's going on with the Event MIB.  The
update from Aug 2004 (now expired) seems largely
to add StorageType objects to tables.  Is there more
work to be done other than editorial stuff like updating
references?  What are the current intentions
with respect to this document?

Thanks,

David

---

From: Benoit Claise <[email-masked]>
Date: Tue, 22 Mar 2005 23:08:15 +0100

David,

I will be traveling/on vacation for the next 20 days.
Then I will produce the next version of the draft.
Only editorial changes are needed.

PS: sorry about the delay in posting a new version of the draft.

Regards, Benoit.

---

From: Dave Shield <[email-masked]>
Date: Thu, 24 Mar 2005 11:11:19 +0000

On Tue, 2005-03-22 at 22:08, Benoit Claise wrote:
> David Partain wrote:
> > I'm curious what's going on with the Event MIB.
>

Is this MIB still open to anything other than editorial
changes, or is the behaviour now pretty much fixed?
Because I'm increasingly convinced that the handling of
the mteObjectTable is flawed.

Both the notification table, and the various trigger tables
contain 'mteXxxObjects' columns to specify which varbinds to
include in the notification payload.  The natural approach
would for mteEventNotificationObjects to list the objects
from the NOTIFICATION-TYPE definition, and the trigger
columns to specify any additional varbinds.

But given the order in which the notification payload is built
up, if mteEventNotificationObjects lists these objects, then
the trigger columns can't be used at all.  If they are to be
used, then *they* must cover the standard NOTIFICATION-TYPE
list as well (rather than mteEventNotificationObjects).

Is it too late to adjust the definition of mteObjectsEntry
so that the event-related objects are added first?

Dave

  [ I asked about this some three weeks ago, and got
    absolutely no response.   Nor to a couple of earlier 
    questions.   Is there still any interest in this MIB? ]

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 24 Mar 2005 08:41:55 -0800

Hi -

> From: "Dave Shield" <[email-masked]>
> To: "Benoit Claise" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, March 24, 2005 3:11 AM
> Subject: Re: [Disman] Status of the Event MIB?
>

> changes, or is the behaviour now pretty much fixed?

We hope the behaviour is fixed (in the sense of "no longer
broken").  If you mean "fixed" as "not to be changed", that's
another matter.

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

Randy
disman WG chair

---

From: Dave Shield <[email-masked]>
Date: Thu, 24 Mar 2005 17:26:19 +0000

On Thu, 2005-03-24 at 16:41, Randy Presuhn wrote:
> Dave Shield wrote:
> 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.

> 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

---

From: Dave Shield <[email-masked]>
Date: Wed, 30 Mar 2005 09:26:27 +0100

> Only editorial changes are needed.

Another question:
   In a couple of places in this draft (mteObjectEntryStatus,
mteEventEntryStatus, etc), the description refers to the term
"MAY not".  What does this actually mean?

RFC 2119 defines "MAY" as referring to optional features,
and makes no mention of "MAY not".  Is this intended to be
a prohibition on making any changes to an active row?

If so:
  a)  Shouldn't the text use  "MUST NOT" ?
  b)  What's the purpose of the mteEventEnabled column
        if the value can't be changed?
  c)  What is the reason for this prohibition?

Dave