Subject: RE: snmpconf FW: MIBs for events and notification logging

From: "Harrington, David" <[email-masked]>
Date: Tue, 23 Oct 2001 10:39:18 -0400

Hi,

I think it would be important to discuss the use of local mid-level managers
as potential keepers of the notification logs so neither the agent nor a
centralized manager be burdened by the storage of the notification log. 

In addition, it might be nice to mention that using a specialized proxy
application at the MLM one could permit v1-only agents to send (unreliable)
traps to the MLM, which could then forward the trap to a centralized manager
using v3 informs to verify receipt of the trap, and to subsequently delete
the notification from the MLM log. This would eliminate log storage for
traps where delivery was known to be successful. Repetitive sending of traps
by the v1 agent (who doesn't know delivery was successful) could be filtered
by the MLM to reduce unnecessary trap resends.

dbh

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, October 23, 2001 7:34 AM
> To: [email-masked]
> Subject: snmpconf FW: MIBs for events and notification logging
> 
> 
> FYI and possible actions
> 
> Bert 
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Thursday, October 18, 2001 7:15 PM
> To: IESG
> Subject: MIBs for events and notification logging
> 
> 
> All, while discussing the frnetmib documnet, we talked about
> how to handle data (events) that should be persistent.
> 
> In general, managed devices do not keep such persistent
> information. Instead, they send notifications, that is
> traps or informed (if enabled by configuration), to one
> or more management stations. The management stations/apps
> would keep the data in a persistent database. Also, managers
> will poll devices to obtain status/usage info and save that
> in a persistent database.
> 
> Events/notifications may not be delivered to a manager
> if there are network problems. In that case, usage of the
> event mib (RFC2981) or the notification log mib (RFC3014)
> can keep such data at a managed device for a while.
> 
> Does this explain enough?
> 
> I will post to SNMPCONF WG to stimulate that they include
> something in the SNMP BCP that they are working on
> 
> Bert 
>

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 23 Oct 2001 16:39:42 -0700 (PDT)

Hi -

> Date: Tue, 23 Oct 2001 14:35:07 -0700
> From: [email-masked] (Mike MacFaden)
> Message-Id: <[email-masked]>
> To: [email-masked]
...
> One quip I heard from an circuit-head 
> is the only difference between datacom gear
> adhering to IETF standards vs telco
> gear adhering to TMN standards is
> that that the latter has a "show alarms"
> state and an Alarm Cutoff (ACO).
...

The disman WG is currently working on this.  Persistance of
alarms and the alarm management configuration is an area that
needs closer examination.   Please follow-up on the disman
WG mailing list.

 ------------------------------------------------------
 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: Jeff Case <[email-masked]>
Date: Wed, 24 Oct 2001 09:16:19 -0400 (EDT)

js>My view is that while DISMAN might be a great place to talk about some
js>of this part of the problem pointed to is alarm persistence on a simple
js>managed device. If we have decided that to support alarm persistence one
js>has to implement the alarm MIB I am afraid this might be too big a
js>hammer for some vendors and they will do their own thing.

i agree with several of the posters, including this note, at least in part

the disman alarm mib is merely A way, not to be confused with THE way
of doing this aspect of alarm management

we had vendors of simple managed devices implementing their own style of
alarm management via standards-track mib objects before there was a disman
alarm mib, and vendors continue to implement today, and will continue
to implement tomorrow -- no matter what happens in the disman working
group

i don't think anybody is trying to jam the disman alarm mib down any
particular throat, nor should anybody attempt to do so in the future,
because to do would be just plain wrong

the disman approach is A way, not THE way

the nice thing about standards is that ...

regards,
jdc

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 28 Oct 2001 14:54:08 +0100

Inline

> From: Jon Saperia [mailto:[email-masked]]
> Sent: Wednesday, October 24, 2001 2:56 PM
> To: [email-masked]
> Subject: Re: snmpconf FW: MIBs for events and notification logging 
> 
> 
> Bert, one follow up. Persistence of configuration data is dealt with a
> bit in the BCP. Persistence of alarm data is, a bit differenet in
> my view. I just posted to the DISMAN list that I thought the alarm MIB
> or even that in combination with an implementation of the LOG 
> MIB is too heavy weight for notifications sent from a device. 
> Perhaps the problem could be broken down into two parts. 
> Work on a conformance statement with some restructure might do the 
> trick for the Alarm MIB. 
> 
OK. I believe this discussion ahs now started in DISMAN. So let us
keep/take it there.

> With regard to the configuration aspect, I recall a discussion at
> an SNMPCONF WG meeting a couple of IETFs ago about configuration
> persistence. I do no know where that went, if anywhere. Was there
> something that should have happened that did not?
> 
Yep... there was. I believe that Juergen has published:
   draft-schoenw-storage-type-00.txt
and has asked for help with the document. It would make a lot of sense
to pick up that work somehow.

Bert