Subject: Heads Up - New Notification Log MIB Draft

From: Bob Stewart <[email-masked]>
Date: Wed, 16 Dec 1998 16:16:18 -0500

I'll shortly be sending a new version of the Notification Log MIB to be
posted as an Internet Draft with the name:

	 draft-ietf-disman-notif-log-mib-05.txt

In the interest of shorter review cycle, I'll CC this list when I send it
to Internet Drafts.

Here's what I did, based on the last round of comments and the IETF meeting
in Orlando:

Fixed all reported typos and tried to accomodate all requested clarifications.

Added an example.

Added new objects for the status of a log definition and for aging out old
log entries.

Changed resource control to be on the basis of entry count only.

And what I didn't do, with explanations.

I didn't change the name to have DISMAN in front.  I'll do that on the
Event and Expression MIBs, as they are indeed distributed management
gadgets, but the Notification Log MIB is really intended as part of the
infrastructure, along with the MIBs we got with SNMPv3, and I didn't want
to weaken the impact of that idea by making it look like it was only of
concern for distributed management.  If I'm going to add a prefix I'd
prefer that it be SNMP, like those MIBs.

I didn't change how I did security, that is, I didn't add an index object
for owner.  Partly this is because I don't believe we've really come to
terms with the problem and partly it's because the method I used was good
enough for the other SNMPv3 infrastructure MIBs and should thus be good
enough for this MIB, which I consider in the same class of MIBs.

I remain strongly resistant to changing the security in the Event and
Expression MIBs as well.  We should not be establishing pervasive kluges
that we imagine fix inadequacies in the SNMPv3 infrastructure.  That's not
good engineering and I strongly object to forcing it into all DisMan MIBs.

	Bob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Dec 1998 15:41:12 +0100

>>>>> Bob Stewart writes:

Bob> I didn't change the name to have DISMAN in front.  I'll do that
Bob> on the Event and Expression MIBs, as they are indeed distributed
Bob> management gadgets, but the Notification Log MIB is really
Bob> intended as part of the infrastructure, along with the MIBs we
Bob> got with SNMPv3, and I didn't want to weaken the impact of that
Bob> idea by making it look like it was only of concern for
Bob> distributed management.  If I'm going to add a prefix I'd prefer
Bob> that it be SNMP, like those MIBs.

The question here is basically whether we expect that the notification
logging MIB will become part of the typical SNMP agent or whether we
expect that only some selected SNMP agents will be used to provide
logging capabilities for a several agents in a management domain and
several managers. In the second case, this MIB would actually fit more
under the DISMAN umbrella, while in the first case, this looks really
more like SNMP infrastructure.

(My personal experience is that people building telecom devices are
usually interested to have notification logging capabilities in every
device rather than having remote logging facilities. This is probably
also a result of the perceived unreliability of SNMP notifications.
So I actually tend to view notification logging as a part of the SNMP
infrastructure.)

Bob> I didn't change how I did security, that is, I didn't add an
Bob> index object for owner.  Partly this is because I don't believe
Bob> we've really come to terms with the problem and partly it's
Bob> because the method I used was good enough for the other SNMPv3
Bob> infrastructure MIBs and should thus be good enough for this MIB,
Bob> which I consider in the same class of MIBs.

I think the "consensus" was pretty clear in Orlando. 

Despite that, I really think that it makes a difference whether a MIB
is designed to provide services for offloading management functions
for several management applications or not. The Script MIB is clearly
designed to allow several management applications to install
management functions and it is necessary to make sure that we have
proper ways to separate things so that access control can ensure that
no information leaks through. I think the same is true for the event
and the expression MIBs. They are less flexible than the Script MIB
with regard to the functionality they provide, but they are still used
by other management applications to offload some of their processing
and we better make sure that these delegated functions can be
protected via access control.

If we make the assumption that the notification logging MIB is an SNMP
infrastructure MIB (that is it will be part of the average SNMP agent
rather than a remote logging service), then I might be persuaded that
a simple string indexing scheme is good enough.

Bob> I remain strongly resistant to changing the security in the Event
Bob> and Expression MIBs as well.  We should not be establishing
Bob> pervasive kluges that we imagine fix inadequacies in the SNMPv3
Bob> infrastructure.

Here we have a problem. The actual cost of using two strings rather
than a single string to index the tables is pretty small compared to
the nightmare of trying to change anything in SNMPv3. And since
expressions and event triggers have a higher need to be protected and
since the expression and the event MIBs are designed to support
offloading processing of multiple management applications, I would
argue that we better make the ownership obvious. RMON introduced the
concept of OwnerStrings and it has some value. All we are doing now in
DISMAN is to make sure the OwnerStrings can be used for view-based
access control (which means they have to be part of the index).

							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

---

From: Bob Stewart <[email-masked]>
Date: Thu, 17 Dec 1998 15:16:47 -0500

>I think the "consensus" was pretty clear in Orlando. 

That was one of those cases where I question whether a straw vote on a
technical matter is the right way to decide.  It seems to me we need a
compelling technical argument and principle that we can document and apply
on all new MIBs and consider for modifying existing MIBs.

>for several management applications or not.

The compelling part of this argument (for me) is that any MIB that could
operate under distributed responsibility based on site policy needs a
mechanism to enforce that split.  Offloading management may well be done in
an environment where distributed responsibility isn't necessary.

>a simple string indexing scheme is good enough.

Perhaps to the detriment of my own position I'll suggest that distributed
responsibility may well apply to any of the infrastructure MIBs.  In fact I
can imagine a situation where the distributed management applications
belong to one group but the infrastructure belongs to multiple.  In that
case the argument comes out the other way around.

So my conclusion is that the infrastructure, including what's in the SNMPv3
document set, needs to be able to divide up access control just as much as
the DisMan MIBs, and that this need may extend into pretty much any MIB.

>the nightmare of trying to change anything in SNMPv3.

I have two problems with that.

One, I can make a case for adding such a string to pretty much any MIB
table you'd care to mention, so the overhead becomes pervasive in a way
that indicates to me this is not the right solution.

Two, SNMPv3 was done as a cooperative effort and its own infrastructure
depends on the solution of naming entries and using substrings of those
names to satisfy the need for view-based access control to divide entries
among differeent parties.

Since no one has shown why the substring approach simply won't work and
since it was explicitly considered sufficient for the infrastructure I
can't in good conscience subvert that design with a kluge in the first MIBs
to follow the v3 completion.

This is not an issue where a few MIBs in one working group should pick
their own work-around to what some people in that group consider a lack in
SNMPv3.  That is not abiding by the spirit of the SNMPv3 work.

	Bob