Subject: Re: New Notification Log MIB Draft

From: Randy Presuhn <[email-masked]>
Date: Wed, 4 Nov 1998 14:54:27 -0800 (PST)

Hi - 

> Date: Wed, 04 Nov 1998 17:23:11 -0500
> To: Randy Presuhn <[email-masked]>
> From: Bob Stewart <[email-masked]>
> Subject: Re: New Notification Log MIB Draft
> Cc: [email-masked]
...
> At 06:49 PM 10/16/98 -0700, Randy Presuhn wrote:
...
> >other log standards (ISO/ITU stuff) provide mechanisms for management
> >to place limits on the size of logs.  Usually it's done by having an
> >attribute in terms of the number of entries AND another attribute in
> >terms of the physical storage. I think think what's there now needs more
> >work, for the reasons you list.
> 
> As I said in my other reply, I'm inclined to go for a limit only on the
> number of entries unless someone has a compelling argument why we need the
> additional complexity.

My personal preferences, in order of preference:

   1) separate objects for space and number of entries; whichever is
      reached first is the limit

   2) number of entries only, with DESCRIPTION text noting that an
      implementation may have cut things off before that number is
      reached due to implementation or run-time limits, such as 
      available memory or disk space.

   3) space usage only, with DESCRIPTION text noting that the number
      of entries that will fit may depend both on the implementation
      as well as the content of the entries

> >I think it'd also help to define the objects so that the tables "work"
> >even if the configuration is inconsistant.  For example, what it means
> >for nlmConfigLogControlFilterName to have a value that is not in the
> >current set of snmpNotifyFilterProfileName values.
> 
> I'll make that clear.  It'll say if there's no filter with the specified
> name it's the same as having no name and no notifications are logged.

Thanks.

> >> Some of the objects have default values defined in the DESCRIPTION
> >> clasuse.  These should probably be moved to DEFAULT clauses.
> >
> >yes.  (DEFVAL)
> 
> Should I use DEFVAL even for scalars?  Heh heh.  I hear Keith grumbling.
...

This is surfacing in agentx land.  Wasn't there some discussion of this
issue at the Chicago SMI meeting?  This has been bouncing around for so
long I've forgotten what the resolution was.  

 -----------------------------------------------------------------------
 Randy Presuhn           Email: [email-masked] http://www.bmc.com     
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 In accordance with the BMC Communications Systems Use and Security
 Policy, I explicitly state that although my affiliation with BMC may be
 apparent, implied, or provided, my opinions are not necessarily those
 of BMC Software and that all external representations on behalf of
 BMC must first be cleared with a member of "the top management team."
 -----------------------------------------------------------------------

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 06 Nov 1998 09:38:57 -0500

>       as well as the content of the entries

I would actually prefer 3 over 2.  Given a set of logs, and a log
disk/memory space, how can a manager decide how many log entries
should be allocated to each log?  Since space normally is measured in
bytes, it makes more sense to allocate a certain number of bytes to
each log.  I think this would be more useful.

I also think that the extra functionality in 1 is not really worth the
added complexity.

/martin

---

From: Bob Stewart <[email-masked]>
Date: Fri, 06 Nov 1998 11:13:29 -0500

>each log.  I think this would be more useful.

I think Martin is the culprit responsible for me adding this in the first
place.  :-)}

Either measurement is going to be imprecise.  Since the number of bytes
taken by an entry can vary wildly depending on implementation techniques
with that metric you end up specifying a vague limit against vague usage.
The number of entries at least is comprehensible, and for someone walking
the line of space they could get a feel for it by knowing that the number
of entries wasn't exceeded but resources ran out anyway.

Doing it by entries also lets the manager think in terms of how many
notifications should be enough to keep instead of dealing with that
indirectly on how many bytes of space they take.

So I'm going to go for just entries.

>I also think that the extra functionality in 1 is not really worth the

Martin and I agree there.

	Bob

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 06 Nov 1998 12:10:10 -0500

> I think Martin is the culprit responsible for me adding this in the first

Whoops, that was not my intention!

> Either measurement is going to be imprecise.

Yes.

> Since the number of bytes

Why is that a problem for a manager?

> indirectly on how many bytes of space they take.

The problem I see is that the logs are not really isolated from each
other.

Suppose there are 2 logs in a system.  The manager sets each log to
keep 100 entries.  The first log fills up the available disk/memory
space after 50 entries.  Now, the second log is really important
(e.g. major alarms).  If there is a burst of 50 events for log1, all
logged major alarms will be lost, since we ran out of the log space.

Admittedly, there are practical problems with specifying the number of
bytes too.  For example, how does the manager know how much available
space there is?

One solution could be to just add an object that holds the available
space.  This should be a total of available space for all logs.  An
implementation could choose to partition the space for different log
types.

/martin