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

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 30 Oct 2001 20:29:48 -0500

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
> Hi -
> > Message-ID:
<[email-masked]>
> > From: "Wijnen, Bert (Bert)" <[email-masked]>
> > To: [email-masked]
> > Subject: RE: snmpconf FW: MIBs for events and notification logging
> > Date: Tue, 23 Oct 2001 21:47:22 +0200
> > Reply-To: [email-masked]
> > 
> > The idea of my email was more to stimulate the WG
> > to try and address the issue of persistence of
> > configuration data and event data.
> > 
> > If the MIB that is out of the DISMAN WG is no good,
> > then that topic should be discussed in the DISMAN WG.
> > 
> > Or so I think.
> ...
> 
> I would think so, too, but I'd be happy just to find out
> what these problems are.  There have been multiple requests,
> both on the disman list and in person, for folks to identify
> any specific problems.  So far, we know that there is one
> redundant object in the Log MIB.  There has been discussion
> about whether different index structures might provide better
> retrieval performance.
> 
> So, at the risk of sounding like a broken record: if you
> have technical issues with RFC 3014, please bring them
> to the disman WG mailing list.  Meaningful input and
> specific proposals are welcome.
> 
>  ------------------------------------------------------
>  Randy Presuhn          BMC Software, Inc.  1-3141
>  [email-masked]  2141 North First Street
>  Tel: +1 408 546-1006   San Josi, California 95131  USA
>  ------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  ------------------------------------------------------

Thanks,
/jon
--

Jon Saperia		     [email-masked]
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/

---

From: Jon Saperia <[email-masked]>
Date: Wed, 31 Oct 2001 07:51:32 -0500

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

Thanks,
/jon
--

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 31 Oct 2001 08:32:01 -0800 (PST)

HI,

Maybe I'm reading too much into Jon's response here...

But, the BCP draft that I previous reviewed had MANY problems
with respect to using INFORMs. The keys one are:

   1) it specified incorrectly that MIB designers could indicate
      that a notification MUST be sent using an INFORM operation.
      This is just plain incorrect.

   2) it incorrectly described INFORMs as "reliable". Again
      this is just plain incorrect.

The BCP had a section covering the issue of synchronization of
configuration, which had parts that were incorrect, incomplete,
and not too usable. I hope that these technical problems are
fixed in the next draft.

Regards,
/david t. perkins

---

From: Jon Saperia <[email-masked]>
Date: Wed, 31 Oct 2001 11:54:13 -0500

Whether one assigns the word 'reliable' to INFORM PDUs or not, they are
good enough for what I was talking about. From Sharon's response it was
clear that she understood what was intended. As for your fist point I
believe we disagree. 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. Again, I believe that Sharon
correctly understood my meaning.

/jon

Thanks,
/jon
--