Subject: New Notification Log MIB Draft

From: Bob Stewart <[email-masked]>
Date: Mon, 12 Oct 1998 12:29:34 -0400

The new draft of the Notification Log MIB took me longer than anticipated
as I had to struggle a bit with security and multiple logs.

I ended up supporting multiple, named logs, with the log name now available
for different access control for different users.  A minimal system can
support only one log with a zero-length (null) name.

For object-level security I decided to apply it only to named logs (not the
null-named one), and only for locally-generated Notifications, based on the
credentials of whomever set the log creation entry to 'active'.  This bows
to the reality of where you can do access control on objects and to the
cost of dynamically filtering the log based on who's reading it, which is
too costly to contemplate.

So security of remotely-generated Notifications and those logged on a
system without named logs falls back onto overall access to the log entry.

Because of the amount of change I CCed DisMan on the message I sent to
Internet  Drafts, so you'll be getting a copy of this update in your mailbox.

	Bob

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Oct 1998 09:43:04 -0400

Bob Stewart <[email-masked]> wrote:
> for different access control for different users.

Great ;-)

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

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

> nlmConfigGlobalDataLimit OBJECT-TYPE

The DESCRIPTION clause still talks about "the log", which I guess is
just some old text from the old draft.

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

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

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

/martin