Subject: Fwd: Comments on the Event MIB

From: Randy Presuhn <[email-masked]>
Date: Wed, 25 Aug 1999 13:37:30 -0700 (PDT)

Hi -

Here are our reviewer's comments on the Event MIB.

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com/
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's is probably coincidental.
 ------------------------------------------------------------------------

> From [email-masked] Wed Aug 25 12:42:33 PDT 1999
> To: [email-masked]
> cc: [email-masked], [email-masked], [email-masked], [email-masked],
>         [email-masked]
> Subject: Comments on the Event MIB
> Date: Wed, 25 Aug 1999 15:07:34 -0400
> From: "Jon Saperia" <[email-masked]>
> 
> Bert et. al.
> 
> This is the note I promised for today.  I did run the file through the
> book version of smicng and got a successful parsing.  If we need logs let
> me know and/or I could use mosy.
> 
> The following comments on the Event MIB are based on
> draft-ietf-disman-event-mib-07.txt.  My comments are in the following
> sections:
> 
>         1.  General Technical Comments and Checks
>         2.  Editorial Nits, Spelling Etc.
>         3.  MIB compilation notes
> 
> General Technical Comments and Checks:
> 
> Bottom line, I think this document is worth progressing to Proposed
> Standard status.  There will be a significant cost of implementation for
> the MIB in terms of memory and CPU depending on how it is used but
> implementation specific controls and the existence of the Resource
> Control Section of the MIB help address this concern.
> 
> I find that there is often confusion about the definition of TRAPS,
> NOTIFICATIONS, INFORMS, EVENTS.  In section 2, second Bullet reference
> is made to the standards which is helpful.  I suggest a word or two of
> definition on EVENTS, TRIGGERS, etc up front.  This will make reading
> the tables a bit easier.
> 
> I would put in a cautionary note about the conversion to SMIv1 that is
> pon page 2.  The objects in large systems are increasingly 64bit
> counters.  A 32 bit counter for much of the work that I do day to day
> and to which this MIB might be meaningfully applied would be of no value.
> 
> Section 4.  
> 
> > The Event MIB is based on extensive experience with the RMON MIB
> > [RFC1757] and its alarm and event groups and is intended as a
> > replacement for those groups.  The Event MIB calls "triggers" what the
> > RMON MIB called "alarms," but the concepts are the same.  Event MIB
> 
> This is not so much a comment for this document as it is for our ADs.
> Has the RMON group agreed to this?  When will it happen?  I see no work
> item on the RMON web page for this activity.  If we are going to include
> this section on Relationship to other MIBs (and I think we must) we must
> also really follow-through.
> 
> The Management Target MIB is references a number of times (including in
> the security section) with no external reference this should be fixed.
> 
> > Error handling is by notification, which at first thought violates the
> > principle that notifications may be lost or become a crippling burden,
> > but the intent is that such error notifications be enabled only for the
> > diagnosis of problems indicated by error counters and if the
> > notifications are being lost they be directed to the log as described in
> > the Notification Log MIB [rfcNotificationLogMIB].  Note that this does
> 
> Do we want to suggest use of INFORMS?
> 
> Page 14:
> 
> >         If only 'existence' is set in mteTriggerTest this object has
> >         no meaning."
> 
> Should this really be an error?
> 
> Page 17:
> 
> > DEFVAL { 600 }
> >     ::= { mteTriggerEntry 11 }
> 
> This comment exposes a bias I have which is that I imagine this mib in
> many cases being implemented on a system rather than an NMS.  As a
> result, I  think a defval of something smaller say 300 would be more
> helpful.
> 
> Page 19:
> 
> > mteTriggerDeltaDiscontinuityIDWildcard
> 
> Wouldnt this correspond to the value in the Trigger Table which if a
> wildcard would also be a wildcard here.  If so making this clear would
> be nice.
> 
> Page 26:
> 
> This is a general coment about the Trigger Threshold Table.  Rising and
> Falling and combination objects are specified.  What is absent is the
> rate of change which is often in values (not talking about delta
> discontinuity here).  For example an object such as
> mteTriggerThresholdRisingDelat could be added (would require mod of
> mteTriggerThresholdStartup) which rahter than an absolute value would be
> measured at each interval so that if the change exceeded the value the
> trigger threshold would be thought to have been exceeded.  If this was
> already discussed and dismissed, OK but I think from an operational
> perspective this is of value.
> 
> Editorial Nits, Spelling Etc.:
> 
> Section 1 - Abstract:
> 
> I would reword:
> 
> > This memo defines an experimental portion of the Management Information
> > Base (MIB) for use with network management protocols in the Internet
> > community.  In particular, it describes managed objects used for
> > managing monitoring of MIB objects and taking action through events.
> 
> to:
> 
> This memo defines an experimental portion of the Management Information
> Base (MIB) for use with network management protocols in the Internet
> community.  In particular, it describes managed objects that can be 
> used to manage and monitor MIB objects and take action through events.
> 
> Section 3 - Overview
> 
> Fix bad wording:
> 
> > With network sizes well beyond the ability of people to management them
>                                                             ^^^^^^
> manage them
> 
> is what I think is meant.
> 
> Section 4 - MIB Sections
> 
> I propose a simple graphic to show the relationship of the tables which
> is something like:
> 
> 
>              Triggers---> Events ----> etc.
> 
> More words are needed by the idea is to show the relationships.
> 
> I can not see where the abbreviation mte for the mib came from, I could
> see evt (for event) or something like that as being more meaningful.
> 
> Spelling items:
> 
> Page 5 persistance to persistence
>        persistant to persistent
> 
> Page 6 subidentifiers (is there a convention for this perhaps two words
> is better or hypen?)
>        subidentifier - ibid
> 
> page 27 in ThresholdRising object afer should be after
>                                   bcomes should be becomes
> page 39 mteHotOID inluding should be including
>                   informaation should be information
> Page 42 preconfigured should probably be with a hypen
> 
> Page 48 Acknowledgements should be Acknowledgments
> 
> 
>