Subject: <draft-ietf-disman-event-mib-09.txt>

From: Alan Luchuk <[email-masked]>
Date: Wed, 5 Jan 2000 13:14:42 -0500 (EST)

Hello all,

I been very carefully reading and thinking about draft 9 of the
DISMAN-EVENT-MIB.  (OW!  My head hurts!!  :-)   I realize it is
"after midnight" to submit these questions and comments about the 
DISMAN-EVENT-MIB.  If any of these bring up issues that really
need attention and are not due simply to my ignorance, perhaps 
the issues could be considered in the next doc cycle.  

Specifying IMPLIED for the second octet string index for each of the
tables is inconsistent with the DISMAN-SCHEDULE-MIB and DISMAN-SCRIPT-MIB.
Consistency in the MIBs produced by a single IETF WG reflects better
upon the IETF WG that produced the MIBs.  That is, if the MIBs produced
by an IETF WG are consistent among each other, the MIBs then look
like the same people wrote them.  I suggest dropping the IMPLIED
from each of the tables in the DISMAN-EVENT-MIB.

Based upon the text in the first paragraph of the DESCRIPTION clause
for the mteTriggerTest object, the DISMAN-EVENT-MIB supports sampling
of data types that are BER encoded as integer types.  Not supporting
the sampling of unsigned or counter64 types restricts the stand-alone
(i.e., without the DISMAN-EXPRESSION-MIB) utility of the DISMAN-EVENT-MIB.
I would suggest extending the DISMAN-EVENT-MIB to sample unsigned and
counter64 types.

Perhaps add a "MIN-ACCESS read-only" clause in the compliance statement
for the mteResourceSampleMinimum and mteResourceSampleInstanceMaximum
MIB objects.

In real-world implementations, the mteResourceSampleMinimum will
always have seconds values that are zero or positive.  I suggest
that changing its syntax to "Unsigned32" better reflects the real-
world values it can take on.  Also, what is the rationale for the
upper bound of 600 on mteResourceSampleMinimum?

Should the DISMAN-EVENT-MIB have the capability to wildcard the
mteTriggerTargetTag?   I can envision that DISMAN-EVENT-MIB users
would want to monitor the same MIB objects on different IP hosts.

I suggest that renaming the MIB objects:

   mteTriggerEnabled  ----->  mteTriggerAdminStatus
   mteEventEnabled    ----->  mteEventAdminStatus

would clarify the function of these MIB objects.  It might also
change the syntax of these objects to be consistent with the
AdminStatus MIB objects in the DISMAN-SCHEDULE-MIB and DISMAN-
SCRIPT-MIB.  (Consistency comments above...)

Please pardon my ignorance, but I'm still pretty clueless about
what the "Trigger Delta Table" is for and how it works.  It appears
that the mteTriggerDeltaDiscontinuityID object is supposed to
specify a TimeTicks, TimeStamp, or DateAndType object on the
monitored system.  What happens if the clock on the monitored
system does have a time discontinuity?  Also, mteTriggerDelta-
DiscontinuityID object can be wildcarded.  Will someone please
explain a situation where this wildcarding capability would be
useful?  Better still, I suggest documenting it in the MIB itself.

The mteTriggerExistenceTest is defined as follows:

   mteTriggerExistenceTest OBJECT-TYPE
       SYNTAX      BITS { present(0), absent(1), changed(2) }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
        "The type of existence test to perform.  The trigger fires
        when the object at mteTriggerValueID is seen to go from
        present to absent, from absent to present, or to have it's
        value changed, depending on which tests are selected.

        Once the trigger has fired for either presence or absence it
        will not fire again for that state until the object has been
        to the other state."
       DEFVAL { { present, absent } }
       ::= { mteTriggerExistenceEntry 1 }

The exact function of each bit is somewhat ambiguous.  For example,
assuming the description ordering matches the bit ordering, here
are the bit functions:

  present(0) - the mteTriggerValueID object goes from present to absent
  absent(1)  - the mteTriggerValueID object goes from absent to present
  changed(2) - the mteTriggerValueID object value changes

But, based upon the final state of the mteTriggerValueID object, the
bit functions might be:

  present(0) - the mteTriggerValueID object goes from absent to present
  absent(1)  - the mteTriggerValueID object goes from present to absent
  changed(2) - the mteTriggerValueID object value changes

Other orderings are possible.  Changing the DESCRIPTION text to spell
this out would clarify this issue for me (and probably for other
implementors.)

I believe the 'changed(2)' bit value should be deleted from the
mteTriggerExistenceStartup MIB object.  Including this bit value
suggests (to me, at least) the DISMAN-EVENT-MIB knows the value
of the monitored object before mteTriggerExistenceTest is configured.
Am I missing something here?

Changing the mteTriggerBooleanComparison syntax from an INTEGER
to a BITS type, with the values less(0), equal(1), and greater(2),
might simplify this object a little.

Changing the mteTriggerThresholdStartup syntax from an INTEGER
to a BITS type, with the values rising(0) and falling(1),
might simplify this object a little.

The mteEventSetObject and mteEventSetValue support setting only
Integer32 objects.  This means the DISMAN-EVENT-MIB has the same
set-event limitations that the DISMAN-SCHEDULE-MIB has.  I suggest
that providing a facility for setting arbitrary MIB objects when
an event fires would increase the utility of the DISMAN-EVENT-MIB.

My first thought about how this might be resolved would be to expand
the mteObjectsTable to contain values.  MteEventSetEntrys could refer
to the mteObjectsTable to get the list of objects to set.

How are the error notifications (mteTriggerFailure, mteEventSetFailure)
enabled and disabled?

OK.  Now a question about the notification handling of the DISMAN-
EVENT-MIB.  Can someone give me examples about why I would want to
have trigger-specific, trigger-subclass-specific, and event-specific
MIB object lists in event notifications?  Why is it insufficient to
have only the mteEventNotificationObjectsOwner and mteEventNotif-
icationObjects and delete:

   mteTriggerObjectsOwner
   mteTriggerObjects
   mteTriggerExistenceObjectsOwner
   mteTriggerExistenceObjects
   mteTriggerBooleanObjectsOwner
   mteTriggerBooleanObjects
   mteTriggerThresholdObjectsOwner
   mteTriggerThresholdObjects

Can someone give me examples where I would want to allow one
user access to another user's entries in the mteObjectsTable
and the mteEventTable?

As always, I hope my comments and questions help produce the most
useful specification, and don't just waste net bandwidth.

Thanks to Ram for his continued work on the DISMAN-EVENT-MIB!

Regards,
--Alan

 -----------------------------------------------------------------------------
 Alan Luchuk       SNMP Research, Inc.                 Voice:  +1 865 573 1434
 Software Engineer 3001 Kimberlin Heights Road         FAX:    +1 865 573 9197
 [email-masked]   Knoxville, TN  37920-9716  U.S.A.   http://www.snmp.com/
 -----------------------------------------------------------------------------

   Please note that our telephone area code recently changed from 423 to 865. 
   Area 423 should countinue to work until it is phased out in April, 2000.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Jan 2000 11:33:45 +0100

>>>>> Alan Luchuk writes:

Alan> Specifying IMPLIED for the second octet string index for each of
Alan> the tables is inconsistent with the DISMAN-SCHEDULE-MIB and
Alan> DISMAN-SCRIPT-MIB.  Consistency in the MIBs produced by a single
Alan> IETF WG reflects better upon the IETF WG that produced the MIBs.
Alan> That is, if the MIBs produced by an IETF WG are consistent among
Alan> each other, the MIBs then look like the same people wrote them.
Alan> I suggest dropping the IMPLIED from each of the tables in the
Alan> DISMAN-EVENT-MIB.

My personal opinion is that you SHOULD NOT use IMPLIED unless you have
a very very good reason to do so. I do not see a good reason why
IMPLIED in this MIB has a big advantage and so I agree.

With regard to the consistency problem: Bob and I obviously had very
different views on MIB design and this is reflected in the document
produced by this WG. It basically shows that the WG failed to define
what the WG's preferred MIB design looks like. Hence, the editor's did
what they think is the right thing to do.

But I generally agree that consistency will (a) make it easier to read
and understand these document, (b) make it easier to for users to use
them in interesting combinations and (c) will save development time
and costs for potential implementors. So even if it is very very very
late in the process, we should try to align things, especially in
areas that are hard to change after publication. (Changes in the
indexing structure requires to deprecate whole tables - very annoying.)

Alan> I suggest that renaming the MIB objects:

Alan> mteTriggerEnabled -----> mteTriggerAdminStatus
Alan> mteEventEnabled -----> mteEventAdminStatus

Alan> would clarify the function of these MIB objects.  It might also
Alan> change the syntax of these objects to be consistent with the
Alan> AdminStatus MIB objects in the DISMAN-SCHEDULE-MIB and DISMAN-
Alan> SCRIPT-MIB.  (Consistency comments above...)

I would have no problem with such a change. ;-)

Alan> The mteEventSetObject and mteEventSetValue support setting only
Alan> Integer32 objects.  This means the DISMAN-EVENT-MIB has the same
Alan> set-event limitations that the DISMAN-SCHEDULE-MIB has.  I
Alan> suggest that providing a facility for setting arbitrary MIB
Alan> objects when an event fires would increase the utility of the
Alan> DISMAN-EVENT-MIB.

Its possible to address this "limitation" for all these MIBs by
defining something like a DISMAN-SET-MIB. I would rather go this
direction instead of adding a facility for setting arbitrary MIB
objects to the DISMAN-SCHEDULE-MIB or the DISMAN-EVENT-MIB or both.

Alan> OK.  Now a question about the notification handling of the
Alan> DISMAN- EVENT-MIB.  Can someone give me examples about why I
Alan> would want to have trigger-specific, trigger-subclass-specific,
Alan> and event-specific MIB object lists in event notifications?  Why
Alan> is it insufficient to have only the
Alan> mteEventNotificationObjectsOwner and mteEventNotif-
Alan> icationObjects and delete:

Alan>    mteTriggerObjectsOwner mteTriggerObjects
Alan> mteTriggerExistenceObjectsOwner mteTriggerExistenceObjects
Alan> mteTriggerBooleanObjectsOwner mteTriggerBooleanObjects
Alan> mteTriggerThresholdObjectsOwner mteTriggerThresholdObjects

I proposed this simplification several months (years?) ago. The
question here is whether the additional (*ObjectsOwner, *Objects)
pairs reduce the complexity of the configured rows substantially and
whether the price in terms of additional complexity (both on the
managers and agents side) is justified. I would start with a simple
solution and add additional complexity once we know it is needed.

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