Subject: List of edits applied to the Event MIB

From: Ram Kavasseri <[email-masked]>
Date: Tue, 21 Dec 1999 10:50:47 -0800 (PST)

Randy had mentioned that resolutions to Disman issues Event-01
through Event-14 discussed in August and September had not made it to
drafts-ietf-disman-event-mib-08.txt. Apologies for missing any
edit made prior to the last week in September.
:-(

Here's a list of all the edits I made to bring the
Event-MIB draft uptodate...
If I've left out any issue, please let me know soon so I can get
it worked into the draft. The following issues were not properly resolved
(or I was unclear about what to do for them)...Please let me know the
right thing to do (I've listed the event descriptions
in detail later in this email):
Event-02, Event-06, Event-07, Event-09 (this seems to be the biggest issue),

I'll post the MIB to the mailinglist without the above 4 issues.

The following edits were made to drafts-ietf-disman-event-mib-08.txt...

1. Added text to Section 1 (Abstract) as per disman issue Event-01.
******

2. Disman issue Event-02: Adding a "health warning":
 "It MAY not be possible to meaningfully monitor Counter64 objects
using an SMIv1 version of the MIB". 

Where should I add the above warning, and is the above text ok?
******

3. Fixed Disman issue Event-03:

This involves text about the Event MIB being a replacement for the RMON 
alarm and event groups.

In Section 4, replace "and its alarm and event groups and is intended as
a replacement for those groups." with "and provides a superset of the capabilities
of the RMON alarm and event groups.  Conceptually, the key extension is
the ability to allow alarms to be generated for MIB objects that are on
another network element."

Thus the resulting new text is:
	The Event MIB is based on extensive experience with the
	RMON MIB [RFC1757] and provides a superset of the capabilities
	of the RMON alarm and event groups.  Conceptually, the key
	extension is the ability to allow alarms to be generated for
	MIB objects that are on another network element.
******

4. Fixed Disman issue Event-04:

> The Management Target MIB is references a number of times (including in
> the security section) with no external reference this should be fixed.

Added references to [RFC2573]
******

5. The following text in Section 6 was modified(as per disman issue Event-05) from:
"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]."

to:
"Error handling is by notification.  These error notifications should
be enabled only for the diagnosis of problems indicated by error
counters.  If minimizing the probability of notification loss is a
concern they should be transmitted as Inform PDUs as described in the
[SNMP-TARGET-MIB] or directed to a log as described in the Notification
Log MIB [rfcNotificationLogMIB]."
******

6. I couldn't find a resolution for Disman issue Event-06. Is the consensus
to change the last sentence in the paragraph below?:

|       For 'existence', the specific test is as selected by
|       mteTriggerExistenceTest.  When an object appears or vanishes
|       the trigger fires.  The trigger will not fire again until the
|       object has changed states.

If so, how does the following change sound?:
Change "until the object has changed states"
to "until the object reverts back to the state before the trigger fired,
i.e. if the object's appearance caused the trigger firing, the object MUST
vanish before the trigger can be fired again for it, and vice versa".
******

7. The proposed resolution for Disman issue Event-07 was as follows:

> > 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.
> 
> Since this is a read-create object, the current DEFVAL tied to the
> maximum minimum (via the mteResourceSampleMinimum control object)
> seems reasonable.  A smaller DEFVAL would lead to paradoxes, so
> I think it makes sense to leave this value as it is.
> 
> There's another nit in this same object DESCRIPTION, where it says:
> "Systems that can support this should document those cases where it can
> be used.  In cases where it can not, setting this object to 0 simply
> returns a bad value error."  As long as "bad value" is not misinterpreted
> as "badValue", its ok, but we need to be clear that we're not requiring an
> SNMPv2c or SNMPv3 entity to generate the SNMPv1 error code in this case.
> (No change needed, unless "badValue" was intended.)

I'll leave the DEFVAL as is. For the "bad value" issue, how about changing
"setting this object to 0 simply returns a bad value error" to
"setting this object to 0 MUST fail"??
******

8. Added the following text as per disman issue Event-08 to
the description of mteTriggerDeltaDiscontinuityIDWildcard:
	"Note that the value of this object will be the same as that of the
	corresponding instance of mteTriggerValueIDWildcard when the
	corresponding mteTriggerSampleType is 'deltaValue'."
******

9. For Disman issue Event-09:

The following is an extract from the disman issue Event-09 discussion:

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

> Proposed resolution: add the suggested objects.
> 
> Objections?  Alternatives?

You would also need mteTriggerRisingDeltaInterval and mteTriggerFallingDeltaInterval,
since you need both the range and the time to calculate a rate-of-climb/fall.
Comments?
******

10. Changed text in the Abstract as per Disman issue Event-10:
	"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."
******

11. Changed the following text as per Event-11:
"With network sizes well beyond the ability of people to management them"
changed to
"With network sizes well beyond the ability of people to manage them"
                                                         ^^^^^^
******

12. Added a diagram that depicts the relationship between various
tables in the MIB (as per disman issue Event-12). Updated it
to account for the mteEventNotificationTable index changes - please
review this and let me know if the changes were ok.
******

13. Disman issue Event-13 - explaining what the abbreviation "mte"
stands for - the consensus was that it should be "management triggered
event". So I've added the following comment in the MIB:
******

************begin snippet*****************

dismanEventMIBObjects OBJECT IDENTIFIER ::= { dismanEventMIB 1 }

-- Management Triggered Event (MTE) objects

mteResource		OBJECT IDENTIFIER ::= { dismanEventMIBObjects 1 }
mteTrigger		OBJECT IDENTIFIER ::= { dismanEventMIBObjects 2 }

************end snippet*****************

Please let me know if the comment and its location are ok.
******

14. Disman issue Event-14:

> Spelling items:
> 
> Page 5 persistance to persistence
>        persistant to persistent

Done - found it in a couple of other places and fixed as well.
 
> Page 6 subidentifiers (is there a convention for this perhaps two words
> is better or hypen?)
>        subidentifier - ibid

Changed "subidentifier" to "sub-identifier".

> page 27 in ThresholdRising object afer should be after
>                                   bcomes should be becomes

Done.

> page 39 mteHotOID inluding should be including
>                   informaation should be information

Done.

> Page 42 preconfigured should probably be with a hypen

Done.

> Page 48 Acknowledgements should be Acknowledgments

I think it should be "Acknowledgements" - checked rfc2571 and rfc2575
to confirm this. So I haven't made this change.
******

15. The object mteTriggerThresholdValue has been removed.
******

16. Corrected the typo "[email-masked]" to "[email-masked]".
******

17. Changed the DESCTIPTIONs and indices of mteEventNotificationEntry
and mteEventSetEntry to use "{mteOwner, IMPLIED mteEventName }".
******

18. All occurrences of rfc2119 words were capitalized.
******

Thanks,

Ram