Subject: Re: New Notification Log MIB Draft

From: Randy Presuhn <[email-masked]>
Date: Fri, 16 Oct 1998 18:49:17 -0700 (PDT)

Hi  -

(writing as a contributor, not chair)

> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: New Notification Log MIB Draft
> References: <[email-masked]>
> Date: Tue, 13 Oct 1998 09:43:04 -0400
> From: Martin Bjorklund <[email-masked]>
...
> I have a few questions and minor comments:
> 
> > 3.1.2.  Security
> [...]
> > The Notification Log MIB has the notion of a "named log."  By using
> > hierarchically structured log names and view-based access control a
> > network administrator can provide different access for different users.
> 
> 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

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

> > nlmConfigDataLimitUnits OBJECT-TYPE
> 
> I have some problems with the global Units vs the global and local
> limits.  The problem is that I don't understand what's supposed to
> happen if a manager changes the value from say 'notifications' to
> 'bytes'.  Are all *limit objects automatically recalculated?  I know
> the description says that an implementation doesn't have to support
> write access (btw, shouldn't this be part of the MODULE-COMPLIANCE
> macro invocation?), but I think the description should state what an
> impl. that does support writes should do.
> 
> This makes me wonder why this object exists in the first place?  Is it
> for a *manager* or for an *implementation*?  If it is for the
> implementation, maybe it just could be made read-only.

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.

...
> > nlmConfigLogControlFilterName OBJECT-TYPE
> >     SYNTAX     SnmpAdminString (SIZE(0..32))
> >     MAX-ACCESS read-create
> >     STATUS     current
> >     DESCRIPTION
> >         "A value of snmpNotifyFilterProfileName from the SNMP
> 
> I've said this before: using snmpNotifyFilterProfileName implies an
> entry in the snmpNotifyFilterProfileTable, which implies an entry in
> snmpTargetParamsTable.  This means that log is tied to a specific
> target.  For example, when creating a log, one of the targets must be
> chosen for the filter value.  What happens to the log if the target is
> removed?  Ok, one way to achieve this could be to create a dummy row
> in snmpTargetParamsTable, if needed.  If this is the intention, maybe
> some text could be added that describes this?

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.

> Some of the objects have default values defined in the DESCRIPTION
> clasuse.  These should probably be moved to DEFAULT clauses.

yes.  (DEFVAL)

> This one is really less important, but maybe the name
> 'nlmConfigLogControlTable' could be made less confusing, e.g. just
> 'nlmLogControlTable' or 'nlmConfigLogTable'?
...

I'd prefer nlmLogControlTable.

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