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

From: Randy Presuhn <[email-masked]>
Date: Wed, 5 Jan 2000 15:37:50 -0800 (PST)

Hi -

> From: Alan Luchuk <[email-masked]>
> Date: Wed, 5 Jan 2000 13:14:42 -0500 (EST)
> Message-Id: <[email-masked]>
> To: [email-masked]
> Subject: <draft-ietf-disman-event-mib-09.txt>
> Cc: [email-masked]
> List-Id: IETF disman Working Group mailing list <[email-masked]>
...
> I been very carefully reading and thinking about draft 9 of the
> DISMAN-EVENT-MIB.  (OW!  My head hurts!!  :-)   

That does seem to be a common reaction to these three documents.
It's rather ironic, considering that they were motivated by the
desire to avoid the perceived complexities of the script MIB.

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

The expectation is that this specification may need to cycle at proposed
if we ever get it out the door.  Keeping this in mind, I believe only
things that are truly broken (and not just ugly) should be fixed at
this time.

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

Personally, I think adding IMPLIED to the SMI was a mistake.
In this particular case, it doesn't add much value, but it
also doesn't break anything.  I suppose one could construct
scenarios making use of wildcarding and naming conventions
to take advantage of the current structure, but I'm skeptical.

These MIBs were in fact written by different people, with
different views of how MIBs should be written.  So though I
agree with your argument, it's not the kind of problem that
supports making a technical change at this point.

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

Definitely for further study, definitely not for the
current document.  Given the discussions leading up to
<draft-kzm-hcdata-types-02.txt>, it looks like we'd have a
fight on our hands if we wanted to do anything in the area.

We should discuss this and look at solutions, but not for
incorporation at this time in the document we're trying to
publish.

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

I don't see what problem or requirement this would address.
Let's leave this question for the future based on implementation
and deployment experience.

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

Changing the datatype from Integer32 to Unsigned32 would have
no effect on capability, but would change what shows up on the
wire.  It's not a change we need to make.

The range itself is a different story.  This issue arose at
the Minneapolis meeting.  In the minutes of 1999-03-19:

| The Event MIB has one week remaining for WG last call.
| One question was raised by the chair regarding the "strange
| limits" of object mteResourceSampleMinimum (-1 | 1..600).
| Bob Stewart agreed that since he was the one who created
| it that he would investigate and document why those
| particular limits.  If no good reason is found then the
| architectural constraints will be lifted.  If no other
| concerns are raised, it will complete WG last call.

Bob subsequently identified the -1 as a cut-and-paste
error.  The upper bound of 600 was never justified.
It looks like our agreement was to get rid of the upper
bound, i.e., make it 2147483647.  Comments?

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

The mteTriggerTargetTag is already capable of specifying
multiple ip hosts through the normal operation of the
target MIB.  The need for yet another layer of wildcarding
hasn't been established (yet).  Let's defer this.

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

This, too, is something to put on the wich list for the next
version.

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

Let's say we have samples S[n-2], S[n-1], S[n], S[n+1], and S[n+2]
This means the potential deltas computed would be:
    time n-1: Delta(S[n-1], S[n-2])
    time n:   Delta(S[n],   S[n-1])
    time n+1: Delta(S[n+1], S[n])
    time n+2: Delta(S[n+2], S[n-1])

Now, if a discontinuity is detected at time n, then the only
deltas which can be considered valid are:
    time n-1: Delta(S[n-1], S[n-2])
    time n+1: Delta(S[n+1], S[n])
    time n+2: Delta(S[n+2], S[n-1])

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

An example would be the RFC 2564 applOpenChannelOpenTime
object, where each row in that table has its own indicator.
This is useful where different rows might be implemented
by different processes or subagents in a system.  Note that
that MIB uses the old RFC 1902 clause 7.1.10 approach of a
TimeStamp for the indicator, rather than the current RFC 2578
clause 7.1.6 approach of a DateAndTime or TimeTicks.

> 
> 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 second interpretation is the one intended.
Ram, make it clear.

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

I think you're right that changed(2) doesn't make sense 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.

Such a change would also permit specification of two conditions
not supported by the current design: always (all bits one)
and never (all bits zero).  In the interest of not letting the
features creep, let's leave it along for now.

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

That change would permit specification of one more pattern not
defined currently.  I think it would mean "never", but in the
interest of not letteing features creep, let's leave it alone.

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

Agreed, but this is a future issue.

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

Presumably via RFC 2573, though an implementation might
provide other means.

If we were to try to build the controls into this MIB, then
coping with multiple managers would be a problem or we'd
end up replicating RFC 2573's functionality for target and
notification handling.

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

It's nice to know what object triggered the notification
as well as the values of potentially related objects.

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

That's up to your security administrator.  For example, the
head network administrator probably should have sufficient
rights to turn off any of the monitors his/her minions
have created.

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

The comments are greatly appreciated.  I just wish they had come
two years ago.

 ------------------------------------------------------------------------
 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 R. Kavasseri" <[email-masked]>
Date: Tue, 11 Jan 2000 11:54:52 -0800

Can't remember responding to this email - there
were two issues that required edits to the event mib - just 
posting that the changes have been made...

>I believe the second interpretation is the one intended.

Done.

>I think you're right that changed(2) doesn't make sense here.

Agreed. I've removed "changed" from mteTriggerExistenceStartup.

Thanks,

Ram