Subject: List of Notif Log MIB issues

From: Ramanathan Kavasseri <[email-masked]>
Date: Wed, 12 Dec 2001 09:50:04 -0800

Here are the issues that people have raised with the Notification Log
MIB.
Apologies for the late submission of this list. If I've left anything
out, please let
me know...

Issues

1. Should clarifying text be added as to whether inform resends are
added to the notification Log.
2. Adding a number in the nlmLogTable that tells you how many variable
bindings are stored in the
    nlmLogVariableTable. This allows the log entry to be retrieved in
fewer queries.
3. Variable to indicate the current log index for each named log
4. Should text be added to indicate that view-based access checks should

not be done when the log is polled?
5. Accessing logged notifications is inefficient. Should this be
revisited?
6. Should we add a nlmLogConfigAgeout for each log?

Ram Kavasseri

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 28 Dec 2001 10:53:25 -0800 (PST)

Hi -

> Message-Id: <[email-masked]>
> Date: Fri, 28 Dec 2001 09:27:43 -0800
> To: Randy Presuhn <[email-masked]>, [email-masked]
> From: "David T. Perkins" <[email-masked]>
> Subject: Re:  List of Notif Log MIB issues
> In-Reply-To: <[email-masked]>
...
> Well, my plan is to go back to the notification distribution scheme found
> in RFC 2573 and work forward. From my review last year, it appeared that
> few understood it. (And I've yet to find a management app that could
> intelligently configure the objects that control it.
...

This sounds like a problem for the SNMPv3 WG, not disman.

> To do a thorough test, there needed to be a mechanism that could be
> used to cause "instrumentation" to "bubble up" specific notifications
> with specific instances of variables to test the notification
> distribution system in SNMP engine implementations. (And there is
> not one that I know of that has been implemented.)

I suspect vendors use ad-hoc subagents to generate such things.
That's what we do.  By their nature, such tools aren't allowed
out of the lab.

>                                                     Also, found in
> the review of the notification distribution system was a lack of
> counters that could be used to determine why a notification was
> filtered.

Including counters to count the number of things that management
isn't interested in seems pointless.

> With RFC 3014 (the notification log MIB), it set out to log notifications
> that were distributed by a SNMP engine and to log notifications
> received by a "mid-level manager" in one combined MIB module.
> In my review last year, I found many problems and would like to
> see the MIB module rewritten.

Based on the implementation report in Salt Lake City,
it seems that the "problems" haven't prevented implementation.

> The Alarm work from Dan and Sharron is built on a functioning
> notification log MIB. It concerns me that it is based on the
> unsure foundation of RFC 3014.

What is this "unsure foundation"?  RFC 2573 notification
filtering works.  RFC 3014 has been implemented.  If there
is a real problem, spell it out.  So far, the issues have been:
	- one superfluous object (the solution is obvious)
	- one case where the document didn't spell out the
	  obvious (no special tweaks needed for VACM)
	- some fine-tuning of the knobs and dials (under discussion)
	- improving bulk retrieval / synchronization performance.

Only the last of these would even come close to a "re-write",
and we need a specific counter-proposal (which DaveP and
Ram have volunteered to work on) in order to do the math of
whether a change makes sense.

> So, the updates below of RFC 3014, while needed, do not
> seem sufficient to me.

What would seem sufficient to you?

> At 09:44 PM 12/27/2001 -0800, Randy Presuhn wrote:
> >Hi -
> >
> >As a consensus check, I'm including the proposed resolutions
> >of these issues discussed in the WG meeting in Salt Lake City.
> >In some cases, folks have taken action items, and I'd love
> >to hear reports of rapid progress.
> >
> >> Message-ID: <[email-masked]>
> >> Date: Wed, 12 Dec 2001 09:50:04 -0800
> >> From: Ramanathan Kavasseri <[email-masked]>
> >> To: [email-masked]
> >> Subject: List of Notif Log MIB issues
> >...
> >Yes, text should be added that retransmissions (if detected
> >as such) are not added to logs.
> >
> >Sharon Chisholm took the action item to do the math to assess
> >what the actual improvement will be.  The numbers are... ?
> >
> >Sharon Chisholm took the action item to do the math to assess
> >what the actual improvement will be.  The numbers are... ?
> >
> >The text should be clarified that VACM (or whatever other
> >access control model is in place) does not need to do any
> >extraordinary processing to handle requests to access log
> >entries.
> >
> >Ram and Dave Perkins volunteered get together to prototype
> >an alternate MIB proposal for more efficient retrieval, and
> >test it.  Status?  Contributions by any other design teams
> >would be most welcome, as would more reports of operational
> >experience.
> >
> >...
> >The pros and cons of this proposal need to be discussed
> >on the mailing list.  Well?
...

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