Subject: complexity of the event mib

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 May 1999 14:03:58 +0200

I made figure showing the table relationships of the event MIB
<draft-ietf-disman-event-mib-06.txt.gz>. You can get the figure at
<URL:http://www.ibr.cs.tu-bs.de/~schoenw/event-mib.ps>. It turns out
that the figure is quite complex and I started to ask myself why this
is necessary.

Some of the complexity is caused by the (*ObjectsOwner, *Objects)
variables that exist in the mteTriggerEntry, mteTriggerExistenceEntry,
mteTriggerBooleanEntry, mteTriggerThresholdEntry, and
mteEventNotificationEntry. These objects point to entries in the
mteObjectTable which define the set of variables to send in a
notification. (Note that the draft does not specify in which order
these objects are placed in a notification message.)

I believe that we can drastically simplify this without loosing
anything by simply removing the following objects:

  mteTriggerObjectsOwner
  mteTriggerObjects
  mteTriggerExistenceObjectsOwner
  mteTriggerExistenceObjects
  mteTriggerBooleanObjectsOwner
  mteTriggerBooleanObjects
  mteTriggerThresholdObjectsOwner
  mteTriggerThresholdObjects

This also leads to a clearer design. A trigger for an event should
only specify what is needed to trigger an event. The parameters that
go into a specific event action should be defined in the action not in
the trigger of the underlying event.

Further, looking at the diagram shows that the action is an entry in
either the mteEventSetTable or the mteEventNotificationTable. The
action to be taken is defined by mteEvetAction in the mteEventTable.
IMHO, things would be much cleaner if the mteEventTable would refer to
the mteEventSetTable and the mteEventNotificationTable. I would rename
mteEventSetTable to mteActionSetTable and mteEventNotificationTable to
mteActionNotificationTable and either have an explicit pointer from
the mteEventTable to the action tables or using mteEventName rather
than mteTriggerName as an index into the action tables.

The core motivation here is to make the trigger/event/action model (as
I understand it ;-) clearer and to associate parameters etc. with the
right abstraction (the trigger, event or action).
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

---

From: Bob Stewart <[email-masked]>
Date: Wed, 19 May 1999 17:11:30 -0400

>that the figure is quite complex and I started to ask myself why this

Some of that complexity is a result of MIB artifacts such as separate
tables for objects that would otherwise make a row sparse (which you
requested).  Some of it comes from flexibility in how people can design
their own notifications and event criteria.

>these objects are placed in a notification message.)

That's a flexibility feature.  I'd made an attempt to specify the order,
but may have failed.  I'll fix that.

>  mteTriggerThresholdObjects

"Drastic" is somewhat over dramatic and overstating.  Half the objects come
from the double indexing for ownership, to which I've objected all along.
It's not a clean, simple solution to security concerns.  It's a painful,
ugly one, forcing the use of two coordinated objects to point from one
table to another.

>the trigger of the underlying event.

This opinion seems to embody the concept that triggers and events are more
1-to-1 than I'd assumed.  If you want them 1-to-1, we wouldn't need two
separate concepts.  What I'm supplying in the MIB is leverage off that
separation.

Multiple triggers or multiple tests within the same trigger can supply
different lists of relevant objects but map to the same event.  That seems
to me to be a useful, powerful feature, supplied at relatively low cost.

>than mteTriggerName as an index into the action tables.

Bizarre.  You removed this approach in your first suggestion and installed
it in your second one.  That is, I have triggers and events separated
(relative to extra objects) and events and actions tightly tied together.
You swapped that.  I suspect both of us are operating from a conceptual
bias rather than well-understood differences.

I'd prefer to leave the extra object feature as it is.  I might be
convinced to separate and modularized notification and set actions as you
suggest so the same notification and set entries could be used by multiple
events.  Note of course that each such pointer requires two objects...

>right abstraction (the trigger, event or action.

I believe which association is right depends somewhat on the concepts of
the designer of the three.  So at the moment the change I'd make is to
modify the event table to point to potentially shared entries in separate
action tables, as you suggest, but to leave the flexibility for additional
objects as it is.

	Bob