Subject: AgentX Log Table

From: "Heintz, Lauren" <[email-masked]>
Date: Wed, 3 Feb 1999 12:24:35 -0600

I am x-posting this to disman and AgentX.

As co-editor of the AgentX MIB draft, one of the
issues I am dealing with is to come up with a specific
recommendation to instrument appropriate AgentX errors or
events.

Ideally, I think a generic (non-AgentX) log mechanism
would solve the problem, but I know of no such mechanisms
except perhaps the disman LOG MIB.

The disman LOG MIB allows applications to define notifications
that map to interesting events and which can then be logged once
the notification is transmitted, but this seems too complex for
the indended purpose (simple debugging of AgentX situations).

Instead, what I would like to propose is that in addition to
the existing LOG MIB, the disman WG create a more simplified
remote logging mechanism, implemented as a table and a single scalar
variable, something like:

	logSize - scalar could be set by a manager to control the
	maximum number of log entries.

	logTable would have the following two columns:

		logIndex (incrementing int type)
		logEntry (SnmpAdminString, application generated LOG entry)

logEntry would have max len of, say, 255.  Applications could then
generate human-readable log entries for any event it chooses.  Richness
of reporting could be implementation-specific or, in some cases, specified
in RFCs.  The AgentX MIB RFC, for example, could specify which kinds of
AgentX events SHOULD be reportable and could even recommend the format of
the
each logEntry so that it could be parsed by manager applications.  AgentX
MIB
could even provide one or two additional variables that enabel/disable
AgentX log
reporting or set a log severity level (kinds of AgentX events to be
reported).

Manager-side parsing of logEntry is not necesarrily intended, although
not precluded on a case-by-case basis.  Rather, the disman log MIB
should instead be considered for most events that REQUIRE parsing.

Lastly, this simpler logging mechanism is intended for applications
that require an easy-to-implement-and-use remote debug capability, and
it would preclude the need for AgentX to define its own specialized
table.

Thoughts?  Agreements?  Objections?  Suggestions?

Thanks,
Lauren

-------------------------------------------------------------------------
Lauren Heintz                 BMC Software, Inc. (Formerly PEER Networks) 
Voice: +1 408 616-3169        Silicon Valley Division 
Fax:   +1 408 616-3339        965 Stewart Drive 
Email: [email-masked]  Sunnyvale, California 94086 USA 
-------------------------------------------------------------------------

---

From: Mike Daniele <[email-masked]>
Date: Wed, 03 Feb 1999 15:26:48 -0500

> except perhaps the disman LOG MIB.

Hi Lauren,

Maybe I don't understand the requirement.  But what is wrong
with just defining appropriate counters/notifications in the AgentX MIB?

Mike

---

From: Bob Stewart <[email-masked]>
Date: Wed, 03 Feb 1999 16:05:45 -0500

>except perhaps the disman LOG MIB.

The Notification Log MIB is intended to be a generic mechanism for logging
notifications.  (Sounds repetitive doesn't it?)

>the indended purpose (simple debugging of AgentX situations).

The Notification Log MIB simply logs any standard SNMP notification.
Independent of that anything can have its own MIB that defines its own
notifications.

>variable, something like:

This is very different from the idea of the MIB.  It's for logging SNMP
notifications, not for general message logs.

>Applications could then
>generate human-readable log entries for any event it chooses.

I have a major problem with this.  I've recently been fighting off internal
company attempts to define notifications designed around DisplayStrings.
In the past we've gone out of our way to fight off DisplayStrings in MIBs
in general.  DisplayStrings are useful only for people to read.  They are
not the friend of interoperability or automation, both of which are primary
SNMP goals.

Undocumented strings of allegedly useful text are a scourge and an
abomination when you're trying to sort out a problem.  We should not
implement general mechanisms that allow programmers the freedom to be so lazy.

> and could even recommend the format of the
>each logEntry so that it could be parsed by manager applications.

Eeeeek.  Picture Von Helsing holding off Dracula with cross, holy water,
and garlic.

A basic principle of SNMP design is that we put information in binary form
that's easy for software, not in ASCII text that must then have a
specified, locked-down format so you can parse it.

>it would preclude the need for AgentX to define its own specialized

If AgentX finds it acceptable to grand implementors a standard SNMP
Notification that carries a text-based debugging comment, that's up to the
AgentX designers.  You might guess that I personally wouldn't be
particularly supportive of such a notification.

Given a standard SNMP notification, the Notification Log MIB would be
perfectly willing to store it and supply a copy to whomever has access.

At the last IETF I talked about the error reporting mechanism in the DisMan
Event MIB.  I used notifications and didn't include a history table.  I
explained that the idea was to provide debug information that you'd enable
through generic notification control mechanisms only when you needed it.
In most cases you'd have it sent where you wanted it and most of it would
most likely arrive.  If you wanted it more reliable, you could have an
implementation of the Notification Log MIB to store it locally for perusal
at your leisure.  I think this is a solid mechanism, using existing or
nearly completed components in a way that doesn't seriously violate SNMP
conventions.

	Bob