Subject: Re: making AlarmModel more explicit

From: Randy Presuhn <[email-masked]>
Date: Tue, 23 Apr 2002 15:19:56 -0700 (PDT)

Hi -

> Message-Id: <[email-masked]>
> Date: Tue, 23 Apr 2002 15:04:52 -0700
> To: [email-masked]
> From: "David T. Perkins" <[email-masked]>
> Subject: Re: making AlarmModel more explicit
> In-Reply-To: <[email-masked]>
...
> 1) this, like the previous one seems to want to use the existing
>    notification mechanisms. However, there are problems, because
>    some notification definitions require that the code that
>    internally generates calls to the API to the SNMP engine to
>    distribute the notification MUST rate-limit the calls to the
>    API. If so, you may not see all alarms (you don't see the
>    raise), and more importantly you don't see the clear.
...

To some extent, the condition MIB would have provided a little
help here.  However, I agree that the way rate-limiting has
been formulated at the notification-type definition level is a
problem for us, and I don't see any good way around it without
pushing active alarm objects closer to the instrumentation
implementation, which would bring with it a whole different
set of really ugly problems.  I suspect this is just a problem
we'll have to live with.  I wonder about just how significant
a problem it would be in operation.

Occasionally the question of a general solution to the rate-
limiting problem resurfaces.  I think it'd be interesting
to speculate on how things would behave if we had done it
at the same point in the processing flow as the RFC 2573
notification mib.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 23 Apr 2002 15:22:37 -0700 (PDT)

Hi -

...
> 2) the picture below (I believe) incorrect in describing the flow
>    from the engine API. The notification table from the
>    notification MIB module is first consulted, not the targets
>    table from the target MIB module. Not sure that the notification
>    log MIB module fits where you have placed it. So, not sure
>    that all of the plumbing results in water with pressure where
>    you want it instead of water on the floor.
...

My error.  Swap the Notification and Target MIB labels in
the ASCII art and it should suddenly make *much* more sense.

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 23 Apr 2002 15:27:12 -0700 (PDT)

Hi -

...
> 3) It sort of seemed to me that if this system was to use the
>    existing notification stream, that the system would convert
>    existing notifications to new notifications that were 
>    "alarm reports". And if one was to follow the ITU module,
>    then the 10s of IETF notifications and 100s of vendor
>    notifications would be converted to one the four ITU
>    alarm reports (ignoring the security ones for now).
>    (For example, a potential linkDown would be converted
>    into a "communicationsAlarm notification" and it sent
>    out, and not the linkDown notification. If so, how is
>    this done? Otherwise, on alarms a manager would receive
>    the original notification and the alarm notification
>    (if these were not filtered by the notification
>     filters specified in RFC 2573.)
...

This is a question of goals.  I believe the goal is to provide
objects corresponding to the current set of "active alarms"
in a system, rather than mapping notifications into a stream
that would look more like X.733.

My recollection from one of our many meetings in Minneapolis
was that we hoped that such "generic alarm notification types"
suitable for massive re-use would end up in the ARC document.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Apr 2002 01:59:47 +0300

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Wednesday, April 24, 2002 1:23 AM

Thanks Randy, for making this clear. This swap needs to be done in the ASCII art in Section 3.3 of the draft.

Regards,

Dan