Subject: Re: Ref: Event MIB

From: Randy Presuhn <[email-masked]>
Date: Fri, 17 Dec 1999 14:00:10 -0800 (PST)

Hi -

Let's try to wrap this up.  I'd like to hear from others.
If no one else speaks up, I feel like declaring this to be
at an impasse and taking it back to the working group or just
letting the work item die, taking the expression and log MIBs
with it.

The current draft says:

mteTriggerEntry
mteTriggerDeltaEntry
mteTriggerExistenceEntry
mteTriggerBooleanEntry
mteTriggerThresholdEntry
INDEX       { mteOwner, IMPLIED mteTriggerName }

mteObjectsEntry
INDEX       { mteOwner, mteObjectsName, mteObjectsIndex }

mteEventEntry
INDEX       { mteOwner, IMPLIED mteEventName }

mteEventNotificationEntry
mteEventSetEntry
INDEX       { mteOwner, IMPLIED mteTriggerName }

The question is whether the indexing for
mteEventNotificationEntry and mteEventSetEntry should be
   a) { mteOwner, IMPLIED mteTriggerName } (current draft)
   b) { mteOwner, IMPLIED mteEventName } proposed "fix"
   c) something else (let's not go there unless nothing else works)

As I see it, the strongest arguments for (a) are:

   1) The definition of mteEventNotificationEntry says:
      "Information about a single event's notification.  Entries
      automatically exist in this this table for each mteTriggerEntry
      that has 'notification' set in mteEventAction."
      This rather strongly suggests that the indexes would
      need to be the same as for mteTriggerEntry.

   2) The definition of mteEventSetEntry says:
      "Information about a single event's set option.  Entries
      automatically exist in this this table for each mteTriggerEntry
      that has 'set' set in mteEventAction."
      This rather strongly suggests that the indexes would
      need to be the same as for mteTriggerEntry.

As I see it, the strongest arguments for (b) are:

   1) The definitions of all the mteTrigger*Event objects
      refer to the mteEventName of the event to invoke upon
      firing of the trigger.

   2) The definitions of mteEventNotificationEntry and
      mteEventSetEntry are internally inconsistant; though
      they refer to mteTriggerEntry, they also refer to
      mteEventAction [sic]; mteEventActions is actually an
      element of mteEventEntry, which has the { mteOwner,
      IMPLIED mteEventName } index structure.

   3) This permits (but does not require) creation of many-to-one
      relationships between triggers and actions (of a
      particular type) to be taken.

For reasons of internal consistancy, I think we should go with
(b), cleaning up the DESCRIPTION clauses to read:

   mteEventNotificationEntry:
      "Information about a single event's notification.  Entries
      automatically exist in this this table for each mteEventEntry
      that has 'notification' set in mteEventActions."
   mteEventSetEntry:
      "Information about a single event's set option.  Entries
      automatically exist in this this table for each mteEventEntry
      that has 'set' set in mteEventActions."
 
If we were to go with (a), then we'd really need to explain
what was meant by an event's notification information being
associated with an entry in the mteTriggerTable (rather than
the mteEventTable), and, furthermore, which mteEventActions
(which comes from a the mteEventTable with different indexing)
was the one governing the behaviour of a given mteEventSetEntry
and mteEventNotificationEntry.

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]       http://www.bmc.com/
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141  2141 N. First Street
 Fax:   +1 408 965-0359  San Jose, California 95131  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's should be coincidental.
 ------------------------------------------------------------------------

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Sun, 19 Dec 1999 01:51:20 -0800

>and mteEventNotificationEntry.

I can go with option (b). The clincher for me is the part about
"which mteEventActions was the one governing the behaviour of
a given mteEventSetEntry or mteEventNotificationEntry..."

I didn't hear voices for option (a) other than mine, so
I'm assuming we've got consensus on this?
:-)

Ram

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Dec 1999 14:41:36 +0100

>>>>> Randy Presuhn writes:

Randy> The question is whether the indexing for
Randy> mteEventNotificationEntry and mteEventSetEntry should be a) {
Randy> mteOwner, IMPLIED mteTriggerName } (current draft) b) {
Randy> mteOwner, IMPLIED mteEventName } proposed "fix" c) something
Randy> else (let's not go there unless nothing else works)

[...]

Randy> For reasons of internal consistancy, I think we should go with
Randy> (b), cleaning up the DESCRIPTION clauses to read:

That would IMHO be a step into the right direction.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>