Subject: RE: AgentX Log Table

From: "Heintz, Lauren" <[email-masked]>
Date: Wed, 3 Feb 1999 17:03:02 -0600

Hi Bob,

> -----Original Message-----
> From: Bob Stewart [mailto:[email-masked]]
> 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.

The intention for my proposal for a simpler log mechanism
(using human-readable strings) was for interoperability
between a real person and a machine.  In the case of AgentX
error reporting, I think automation is overkill.

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

My intention is really to make it easier for lazy debuggers to debug AgentX.
Why should I have to configure several MIBs just to figure out which AgentX
subagent is mis-behaving if there's an easier way?  Easier implementation is
just icing on the cake.

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

You must have me confused with someone else.
I do like garlic, after all!  :)

> 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 also seems to be an SNMP (stress the letter, 'S") design principle to
make things more complex than they always have to be.  Sometimes simpler can
be better.  Everything (stress the word "everything") shouldn't HAVE to be
in binary, locked-down format.  Too constricting.  Instead, allow
implementations to choose which style of logging they want to use (binary or
readable) for a given purpose, and let customers decide which product is
better suited for their purposes.  BTW, I'm not suggesting we change or
replace the current disman LOG MIB -- rather, just add a new tool to the
disman toolbox.

In any case, the issue I am trying to solve is whether or not the AgentX MIB
must include an integral means of error logging, or whether it will rely on
a more generic mechanism.

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: Bob Natale <[email-masked]>
Date: Thu, 04 Feb 1999 09:34:10 -0500

>At 2/4/99:09:08 AM, Bob Stewart wrote:

Hi BobS,

<...>
>Recall that there was originally considerable debate as to whether
>AgentX was appropriate work for the SNMP community in the IETF at all.

True...but this "debate" was certainly not due to any question
of the importance and relevance of an agent extensibility protocol
to SNMP!  (As you well know, I'm sure.)

> It's an API for software development.

Dead wrong.

>That's really stretching the coverage of SNMP.

AgentX is one of the *core* aspects of SNMP evolution, as
defined by the ADs.

Are you thinking of something else entirely here, or what?

Cordially,

BobN
------------ ISO 9001 Registered Quality Supplier -----------
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
------------- Free downloads at www.winsnmp.com -------------

---

From: Mike Daniele <[email-masked]>
Date: Thu, 04 Feb 1999 09:40:09 -0500

Bob Stewart wrote:

> At 05:03 PM 2/3/99 -0600, Heintz, Lauren wrote:
> If this is purely for debug messages for people to read it seems
> inappropriate to standardized that in relationship to SNMP.  The purpose of
> SNMP is management via the network, not debugging code.  SNMP wasn't
> designed for the sort of high-volume, deeply-specific, human-targetted
> information that goes with debugging.  That's typically a function of the
> operating system and debuggers for the particular environment.
>
> That's not a good reason to open Pandora's box in SNMP.  Such a tool
> wouldn't be limited to appropriate uses.  It would become another short cut
> that people would use to avoid doing the real work but still keep the SNMP
> stamp of approval.
>

I agree.  It seems to me it's up to implementations to make analyzing
their errors "easy",  using whatever mechanisms are appropriate to
the platform in question.

> Recall that there was originally considerable debate as to whether AgentX
> was appropriate work for the SNMP community in the IETF at all.  It's an
> API for software development.  That's really stretching the coverage of SNMP.
>

Bob, I realize you're speaking in generalities in order to make a point,
but of course the whole point of AgentX is that it's a protocol that can
be implemented underneath existing or new sw development APIs.

The bakeoff saw interoperability at the protocol level between 4 or 5
different APIs.

> >be better.
> Gee, why didn't I think of that.  Guess I just like things too complicated.
>
> And my question is whether solving that problem is appropriate for SNMP at all.
>
>         Bob

I don't think the AgentX MIB should define error logging at all.

The MIB's registration table tells you essentially everything you need to know :
which session is authoratative for each region.  Just about anything else
can be relegated to syslog (or whatever the admins for the platform are used to
looking at.)

At any rate, I think it would be helpful to write down everything you are
concerned
about that could "go wrong", post it to AgentX (only :-), and let's discuss it.
I'm pretty sure that the last time we did this, the consensus was to leave things
as described in the paragraph above ...

Mike

---

From: Bob Stewart <[email-masked]>
Date: Thu, 04 Feb 1999 09:08:48 -0500

Bob

---

From: Bob Stewart <[email-masked]>
Date: Thu, 04 Feb 1999 10:57:28 -0500

>Are you thinking of something else entirely here, or what?

AgentX defines one way to implement agents, specifically those made up of
multiple pieces from different sources.  Since in some environments that's
a major concern, it is a valuable standard.

But we have to be careful about letting AgentX, or the implementation of
any other SNMP-related gadgetry, intrude too far or too specially on the
primary business of SNMP, which is managing the network and its components.

The question is how far should SNMP go in taking over the world.  Think of
emacs.  For some people emacs is the center of everything they do with
their computer, from developing code to managing files to reading and
writing email.  I question whether SNMP and the IETF working groups related
to it are appropriate as the place to define, for example, remote debugging
aids, whether that's for code in general or an agent implementation.

The problem is that "distributed management" can take on an extremely broad
definition, so broad that it risks becoming all of distributed systems, one
chunk at a time.

A cheap, local (or even remote) logging mechanism for debugging purposes
sounds like a handy gadget that might well be worthy of a standard.  I
don't believe it's SNMP's job to provide that in any way other than through
existing or already-planned mechanisms.  We're having enough trouble
finishing work that is clearly our own.

	Bob

---

From: Bob Natale <[email-masked]>
Date: Thu, 04 Feb 1999 11:44:06 -0500

>At 2/4/99:10:57 AM, Bob Stewart wrote:

Hi Bob,

>primary business of SNMP, which is managing the network and its components.

Yep.  We're in violent agreement on both point.

Cordially,

BobN
------------- Free downloads at www.winsnmp.com -------------