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

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]
> Subject: snmpconf FW: MIBs for events and notification logging
...
> 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: "Sharon Chisholm" <[email-masked]>
Date: Wed, 31 Oct 2001 08:26:54 -0500

hi

Configuration notifications may need to be sent out, but
the question is do they need to be as persistent and available
as the notifications/faults the alarm MIB is targeted towards?
My gut feel is that they don't, which does make the alarm
MIB a bit of an overkill for the problem. But, if an entity supported
the MIB for fault purposes, then a manager that is particularly
interested in specific configuration change notifications could
model an alarm around it.

As you've indicated, guaranteeing delivery and short term storage 
of the notifications - either via the notification log MIB 
or informs - might be all that is necessary.

The notification log MIB takes a lot of abuse, but it does 
have some strengths:
	- The notification storage is non-lossy
	- The same MIB can be support on the entity and mid-level
	manager
	- It's predictable 
	- It provides statistics that allow for intelligent use
	of the MIB without having to read in the entire thing.
	
Sharon

-----Original Message-----
From: Jon Saperia [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 7:52 AM
To: Chisholm, Sharon [CAR:NM50:EXCH]
Cc: Randy Presuhn; [email-masked]
Subject: Re: snmpconf FW: MIBs for events and notification logging

Sharon,

SNMP INFORM PDUs are a great way to keep a management station 'in sync'
with configuration changes. One of the reasons for doing this is that it
is a fact of life that more than one access method will be used to
manage devices and not all configuration management systems synchronize
between themselves.  I am aware that some would argue that they do not
trust INFORMS to do the job well enough. In my experience now with
fielded products, this works more than well enough.

Whether one sends notification data as a result of a configuration
change, and how much of it to send should be a matter of local
configuration. I still do have concerns about another MIB Module (the
Alarm) to add to the list of MIB Modules to ask vendors to implement in
this case. In an ideal world, I would probably agree that managed
devices should implement the Alarm Module.

/jon

> hi
> 
> I don't really follow SNMPconf, but hopefully I can still help
> work some of the issues from those discussions.
> 
> I did find this:
> <in SNMPconf John>
> 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. 
> </in SNMPconf John>
> 
> Currently the mandatory parts of the alarm MIB are
> 	alarm models
> 	active alarms
> 	active alarm variables.
> In earlier versions the alarm models were not mandatory.
> Do you think keeping the mandatory bits to be just the
> active alarm tables would address your concerns? 
> 
> It's interesting that this conversion is coming from SNMPconf,
> since I often give configuration notifications as examples
> of notifications that you don't want to alarm on. Do you
> see a need to alarm on configuration changes?
> 
> Sharon
> 
> -----Original Message-----
> From: Jon Saperia [mailto:[email-masked]]
> Sent: Wednesday, October 24, 2001 8:41 AM
> To: Randy Presuhn
> Cc: [email-masked]; [email-masked]
> Subject: Re: snmpconf FW: MIBs for events and notification logging
> 
> 
> My view is that while DISMAN might be a great place to talk about some
> of this part of the problem pointed to is alarm persistence on a simple
> managed device. If we have decided that to support alarm persistence one
> has to implement the alarm MIB I am afraid this might be too big a
> hammer for some vendors and they will do their own thing.
> 
> /jon

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 31 Oct 2001 14:37:13 -0800 (PST)

Hi -

> Message-Id: <[email-masked]>
> To: "David T. Perkins" <[email-masked]>
> Cc: Jon Saperia <[email-masked]>,
>         Sharon Chisholm <[email-masked]>,
>         Randy Presuhn <[email-masked]>, [email-masked]
> From: Jon Saperia <[email-masked]>
> In-reply-to: Your message of Wed, 31 Oct 2001 08:32:01 -0800.
>              <[email-masked]> 
> Date: Wed, 31 Oct 2001 11:54:13 -0500
...
>                      I have created mib documents that included in the
> description of an object that when a value changed a notification
> defined in that module should be sent in preferably an inform. Can not
> force the inform, but can recommend it. 
...

Keeping RFC 2573 and the architecture it implies in mind,
this sounds like it really should be considered advice
to the administrator configuring snmpNotifyType in the
SNMP-NOTIFICATION-MIB, rather than to the instrumentation
implementor.

(This sounds like its going back to the BCP part of the
thread, and that really belongs back in snmpconf.)