Subject: Re: New Notification Log MIB Draft

From: Bob Stewart <[email-masked]>
Date: Wed, 04 Nov 1998 17:23:11 -0500

At 06:49 PM 10/16/98 -0700, Randy Presuhn wrote:
>> What do you mean by "hierarchically structured log names"?
>
>I think Bob is referring to names like
>
>   accounting
>   accounting-receivables
>   accounting-payables
>   accounting-inventory
>   accounting-inventory-capital_equipment
>   accounting-inventory-components

Correct.

>This would require careful naming as well as use of wildcards
>in vacm.  I'm not sure we should standardize it as a practice.

I'm not sure we should standardize on a whole extra column for owner.  I'd
like to see some experience with both approaches and see which works out best.

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

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

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

	Bob

---

From: Bob Natale <[email-masked]>
Date: Thu, 05 Nov 1998 01:15:06 -0500

>At 11/4/98 05:23 PM, Bob Stewart wrote:

Hi BobS,

<...>
>Should I use DEFVAL even for scalars?

I wish we (collectively) would.  Granted, the role DEFVAL
plays in the case of creatable columnar objects that are
omitted from a Set that instantiates a row is clear and
does not literally apply to scalars.  However, using DEFVAL
clauses as a somewhat structured way of identifying default
values the agent might apply to any object seems like a
sensible and handy form of documentation that does nothing
to harm the role of DEFVAL for creatable columnars...IMHO.

Cordially,

BobN
----- ISO 9001 Registered Hardware and Software Divsions ----
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ----
------ NetPlus (r) "FCAPS" Telemanagement Applications ------