Subject: RE: ASCII art

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Wed, 28 Mar 2001 12:22:20 -0500

Tammy:

Severity-based suppression is a simple mechanism to
suppress the reporting the change of condition  (raised/cleared) 
based on its assigned level of severity.
It is proposed for a simpler device that won't implement ARC.
The last page of my presentation show the behavior.

Anni

> ----------
> From: 	Tammy Ferris[SMTP:[email-masked]]
> Sent: 	Wednesday, March 28, 2001 11:59 AM
> To: 	Randy Presuhn
> Cc: 	[email-masked]
> Subject: 	Re: ASCII art
> 
> 
> Randy,
> 
> You are really great at ASCII art.
> 
> Could somebody please tell me what is meant by:
> Severity-based Suppression (?)
> 
> Tammy
> 
> Randy Presuhn wrote:
> 
> > Hi -
> >
> > As WG chair, I think it's time for some ASCII art.  As a
> > technical contributor, I'm submitting the following, to
> > give folks something to clone / mangle, loosely based on
> > Anni's nifty slides.  I'm not committed to any of the labels
> > attached to any of the boxes, nor does the appearance of a
> > box here necessarily imply that I think that that box should
> > be realized as one or more MIB tables.  (e.g., some believe
> > that we don't need to standardize "condition severity profiles".)
> >
> > Top-level Block diagram with information flows:
> >
> > Anni, Kam, and Dave's document-to-be:
> >
> > +------------------------------------------------+
> > | Resource / Resource Manager / Whatever         |
> > |                                                |
> > |  +------------------------------------+        |
> > |  | Condition Detection (out of scope) |        |
> > |  | defined in various DESCRIPTIONs    |        |
> > |  +--------------+---------------------+        |
> > |                 |                              |
> > |  +--------------V----------------------------+ |
> > |  | Condition Management (optional)           | |
> > |  |                                           | |
> > |  |  +------------+                           | |
> > |  |  | Condition  | --> Transient conditions  | |
> > |  |  | Severity   | --> Current condition list| |
> > |  |  | Profiles   | --> Condition history list| |
> > |  |  +------------+                           | |
> > |  +------------------+------------------------+ |
> > |                     |                          |
> > |  +------------------V-----------------------+  |
> > |  | Condition Report Suppression/Deferral    |  |
> > |  |              (optional)                  |  |
> > |  |  +----------------------------+          |  |
> > |  |  | Alarm Report Control (ARC) |          |  |
> > |  |  +-----------+----------------+          |  |
> > |  |              |                           |  |
> > |  |  +-----------V--------------------+      |  |     Out of Scope:
> > |  |  | Severity-based Suppression (?) |      +------> Audio/visual
> > |  |  +--------------------------------+      |  |     Alarm Control
> > |  +------------------------------------------+  |     Signals
> > +------------------+-----------------------------+
> >                    |
> >                    V
> >
> > What flows out of this box are notifications in the sense of
> > the agentx-Notify-PDU.  We currently lack a good term for
> > these that distinguishes them from the definition using the
> > NOTIFICATION-TYPE macro and from what appears in SNMP protocol.
> > Neither RFC 3014 nor RFC 2741 nor RFC 2573 provides much help.
> > Calling them "potential notifications" or "potential event
> > reports" seems rather unwieldy, so let's call them "bulletins"
> > until someone comes up with something better.
> >
> > Continuing the flow...
> >
> >                    |
> > +------------------V-------------+   +----------------------------+
> > | Existing Specs.  |             |   | Sharon & Dan's Document    |
> > |                  |             |   |  +------------------+      |
> > |                  +----------------->--> Mapping Profiles |      |
> > |                  |             |   |  | (descriptions)   |      |
> > |                  |             |   |  +--------+---------+      |
> > |                  |             |   |           |                |
> > |                  |             |   |  +--------V------------+   |
> > |                  |             |   |  | Generic: Model-     |   |
> > |                  |             |   |  | Active : Specific   |   |
> > |                  |             |   |  | Alarms : Extensions |   |
> > |                  |             |   |  +---------------------+   |
> > |                  |             |   |           |                |
> > |                  |<----------------------------+                |
> > |                  |             |   |                            |
> > |                  |             |   +----------------------------+
> > |  +---------------V----------+  |
> > |  |         RFC 2573         |  |
> > |  |     SNMP-TARGET-MIB      |  |
> > |  +--------+---------------+-+  |
> > |           |               |    |
> > |  +--------V-------------+ |    |
> > |  |       RFC 3014       | |    |
> > |  | NOTIFICATION-LOG-MIB | |    |
> > |  +----------------------+ |    |
> > |                           |    |
> > |  +------------------------V-+  |
> > |  |         RFC 2573         |  |
> > |  | SNMP-NOTIFICATION-MIB    |  |
> > |  +----------+---------------+  |
> > |             |                  |
> > +-------------|------------------
> >               |
> >               V
> >       Informs & Traps
> >
> >  -------------------------------------------------------
> >  Randy Presuhn           [email-masked]
> >  Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
> >  Fax:   +1 408 965-0359  2141 North First Street
> >  http://www.bmc.com/     San José, California 95131  USA
> >  -------------------------------------------------------
> >  My opinions and BMC's are independent variables.
> >  -------------------------------------------------------
> 
>