Subject: RE: ASCII art

From: "Thomas, Steven C (Steve)" <[email-masked]>
Date: Thu, 29 Mar 2001 13:54:43 -0500

Hey,

The ASCII helped a lot.  But, I still have some points I'm confused or
uncertain about.

1) What is the "Mapping Profiles" box in Sharon & Dan's Document big box?
Is this something in the existing drafts or something coming?

2) It looks like severity will be associated with the conditions (at least
if one uses "Severity-based Suppression").  And severity would also be
associated with the Active or Model Specific Alarm.  Am I understanding that
correctly?

3) In the case with multiple managers, is it the intent that the "Alarm
Report Control (ARC)" and "Severity-based Suppression" would be a single
definition?  (I.e. if one manager set up "Condition Report Suppression"
would it affect what all the managers would see reported?)

4) Since there are "transient conditions" possible, should I assume that the
definition of alarms will also change to allow "transient alarms"?

Thanks for the clarifications,
Steve

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]]
Sent: Tuesday, March 27, 2001 8:58 PM
To: [email-masked]
Subject: ASCII art

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