Subject: Re: AgentX MIB issue 7

From: Randy Presuhn <[email-masked]>
Date: Thu, 3 Sep 1998 22:38:49 -0700 (PDT)

Hi - 

> From: [email-masked] (T. Max Devlin)
> To: [email-masked]
> Subject: Re: AgentX MIB issue 7
> Date: Tue, 25 Aug 1998 05:27:38 GMT
...
> I believe the success of AgentX depends on it providing value as an
> interoperable, multi-vendor standard data transfer protocol, regardless of any
> limitations it might have.  I believe instrumentation must be provided in
> order to support an acceptably flexible mechanism for monitoring
> implementation-independant master/sub-agent interactions.  To exclude error
> counters from the basic development effort will preclude vendor
> inter-operability as a market function.
...

The agentx bakeoffs demonstrated pretty conclusively that one does not
need a MIB with error counters to achieve multi-vendor interoperability.
This has also been demonstrated with other subagent protocols.

When we add things to this MIB, they should be demonstrably useful and
in response to a real need.  I'd like to hear an implementor of agents,
subagents, or management applications give a requirement before we
go adding more instrumentation.

 -----------------------------------------------------------------------
 Randy Presuhn           Email: [email-masked]      http://www.bmc.com     
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 In accordance with the BMC Communications Systems Use and Security
 Policy, I explicitly state that although my affiliation with BMC may be
 apparent, implied, or provided, my opinions are not necessarily those
 of BMC Software and that all external representations on behalf of
 BMC must first be cleared with a member of "the top management team."
 -----------------------------------------------------------------------

---

From: Bob Natale <[email-masked]>
Date: Fri, 04 Sep 1998 10:55:49 -0400

>At 9/3/98 10:38 PM, Randy Presuhn wrote:

Hi Randy,

<...>
>need a MIB with error counters to achieve multi-vendor interoperability.

True...then again I'd say that the bakeoffs demonstrated conclusively
that one does need a MIB at all to achieve multi-vendor interoperability
at the protocol level!  (I will use that assertion to argue against
your point below, however!)

>This has also been demonstrated with other subagent protocols.

It could probably be demonstrated with most protocols, whether
they pertained to subagents or not.  That is, implementations
may achieve interoperability at the protocol level by acquiring
and keeping whatever necessary state/housekeeping info using
whatever implementation-specific methods/structures they want
to.

I don't think that proves much in terms of what *should* be in
the AgentX MIB.

In other words, I think the purposes originally outlined for
the AgentX MIB served other potential "consumers" than (just)
protocol implementors.  I am not sure where the concept that
it should only serve the purposes of AgentX interoperability
arose (but I'm pretty sure you'll give me a hard-to-refute
reference for it!).

>When we add things to this MIB, they should be demonstrably
>useful and in response to a real need.

That is indisputable.  However, the primary "real need" I
see the AgentX MIB serving is to provide the local (i.e.,
master agent node) system administrator(s)--and the apps
they use--to monitor, assess, and control their AgentX
environment.  Knowing what connections, sessions, registrations,
and error states exist represent the *kinds* of information
those sysAdmins will need for this purpose.

>I'd like to hear an implementor of agents, subagents, or
>management applications give a requirement before we go
>adding more instrumentation.

Speaking primarily from the perspective of "an implementor
of management applications", please see above.

Granted one could easily devise an enterprise tree MIB to
achieve the goal I am talking about...however, that seems like
a cop-out here, esp. in this era when we are collectively
trying to make progress on standardized approaches to configuring
the SNMP environment itself.

So, my position is that we need the traffic/error info in the
MIB because sysAdmins will need it.  I don't have a closed
mind about it, however...I just don't have your rationale
for the "needed for implementation interoperability" test
clear in my mind.

As a related aside, I would not object to coalescing the
connection [as suggested by Shawn] and "status" info into
the agentxSessionTable, since that info can be (readily)
modeled as fixed (wrt number of instances) and directly
dependent upon the h.SessionID anyway.

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