Subject: Re: duplicateRegistration error handling

From: "Heintz, Lauren" <[email-masked]>
Date: Tue, 9 Mar 1999 16:50:31 -0600

Hi all,

I'd suggest that unless we can reasonably show that error counters are
useful in helping to detect spontaneous AgentX-related network problems,
that the counters are not justified being in the MIB.

Seems to me that the only thing we've been talking about so far (as
justification for adding the duplicate counter) is the single,
non-spontaneous issue of easing subagent installation.

Is it really wise to complicate the MIB (even if ever so slightly) just to
ease subagent installation?

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: "Heintz, Lauren" <[email-masked]>
Date: Mon, 15 Mar 1999 15:45:17 -0600

This relevant message (below) didn't make it on the AgentX list since it
originated from a non-subscriber.

Lauren

-----Original Message-----
From: Mark Ellison [mailto:[email-masked]] 
Sent: Saturday, March 13, 1999 6:40 AM
To: Heintz, Lauren
Cc: [email-masked]; Mark Ellison
Subject: Re: duplicateRegistration error handling

...sorry if I kicked up some dust on the agentXRegisterDuplicate attribute-

My original thought was that a global counter of duplicate registrations in
the AgentX MIB is not very useful in helping figure out a root cause.

I thought a duplicate registration counter within the
AgentXRegistrationEntry
would go alot farther in helping to determine a root cause.

I don't think it matters which AgentXRegistrationEntry gets the
register-duplicate counter incremented when a registration request is a
duplicate of more than one registration.  Also, I don't think it matters if
an
AgentXRegistrationEntry with a non-zero duplicate registration counter goes
away when a subagent unregisters the region, or terminates processing.

When the only subagents loaded on a system are provided by the system vendor
(e.g. an embedded device, like a Cisco or Cabletron box; or, a general
computing platform, like Compaq Tru64 UNIX, or IBM AIX), I don't think a
counter of duplicate registrations is necessary at all- those sort of
installation/configuration problems would presumably be caught and resolved
prior to product release.

With general computing platforms, application and layered software can be
added to the platform's process mix.  Along with this software often comes
managability via SNMP- i.e. an AgentX subagent.

Should this software be misconfigured, or installed improperly, one of the
symptoms might likely show up as a duplicate registration when its subagent
starts up.

For example, an Oracle database server might kick off several processes,
each
responsible for a portion of some table, organized by indices.  If these
processes are mis-configured, a support desk might receive calls due to user
perceived problems of database performance...but this same issue might also
be

seen as a duplicate registration...and, if the registration duplicates are
counted within the AgentXRegistrationEntry, then diagnosis of such a problem
would be simplified.

While it is clear  this is an installation/configuration problem, it is a
problem of an essentially different nature than an
installation/configuration
problem when all subagents come as part of a base product from a single
vendor.

In summary, I feel the agentxRegisterDuplicate attribute, to be of any real
use should be in the AgentXRegistrationEntry.  However, I'm not going to
lose
any sleep if it doesn't show up there in the final version of the AgentX
MIB-
that's up to the WG at large.  Also, I won't worry if the
agentxRegisterDuplicate attribute remains as a global either, or, is removed
entirely from the MIB.  I can implement this in either manner, or not.

Anyway, that's what my current thoughts are on this topic.  Hope this helps.

Regards,

Mark