Subject: Re: AgentX MIB issue 7

From: David Battle <[email-masked]>
Date: Fri, 4 Sep 1998 12:52:49 -0400 (EDT)

> When we add things to this MIB, they should be demonstrably useful and

Frankly it's not clear to me that we need a mib at all.  EMANATE has been
very successful to-date without a mib at all, and like you said it isn't
needed for multi-vendor interoperability.

Thanks,
-David

---

From: Lauren Heintz <[email-masked]>
Date: Fri, 04 Sep 1998 11:45:43 -0700

I believe everyone I've tested with had varying versions
of the AgentX MIB -- and few (if not none) had significant
error instrumentation.  Still, we all managed to interoperate
successfully and I don't remember anyone ever crying out, "Oh, if
we only had some error counters in this darn MIB!"

Translation: nix the error counters and keep the MIB simple.

Tks,
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: Fri, 04 Sep 1998 16:07:21 -0400

>At 9/4/98 11:45 AM, Lauren Heintz wrote:

Hi Lauren,

>successfully and I don't remember anyone ever crying out,
>"Oh, if we only had some error counters in this darn MIB!"

I can only try to restate what I said (evidently unclearly)
in my response to Randy's message on this thread:  I don't
think it proves much (or counts for all that much) that
multiple implementations of the protocol are able to inter-
operate w/o a MIB.

What is the basis for the assertion that the purpose of the
MIB is implementation interoperability?  I don't believe that
is the primary purpose of the MIB--indeed, as your comments
(and the similar ones from Randy and David) indicate, the
MIB may serve no (essential) purpose wrt implementation
interoperability at all.  So what?

The primary purpose of the AgentX MIB--as with most (all?)
MIBs--is to enable the relevant user group(s)--primarily
sysAdmins in this case--to manage their environment.  At
least, that's how I read the situation and, since that
group (as usual/always) is vastly under-represnted in such
a WG, I must (as WG chair) ensure that their interests
are fairly represented (which does not mandate a certain
outcome, however) and I am also expressing my technical
opinion on the matter (which may well be proved wrong).

>Translation: nix the error counters and keep the MIB simple.

Re-translation:  Let's take a closer look at who *should*
benefit from an AgentX MIB and what *their* needs may be.

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: Wed, 09 Sep 98 17:21:04 -0400

Hi Bob,

>interoperability at all.  So what?

I think what happened was something like this:

1) T. Max Devlin posted something that said, *roughly*, you won't
   be able to have interoperability without a MIB with good error counters.

2) Lauren pointed out that this is not the case, using the bakeoff
   as an example.

As such, I think you and Lauren agree :-)

>sysAdmins in this case--to manage their environment.

I think there is wide agreement with that statement.

>benefit from an AgentX MIB and what *their* needs may be.

Makes sense.

To me, the sysadmin needs 

1) to be able to control which subagents start, and perhaps how
   they register (what priority)
2) to be able to view the state of the registry
3) to be able to alter the registry by one or more of
   a) stopping subagents
   b) closing sessions
   c) forcing unregistrations 

I don't believe 1) is possible via this MIB.  
It's a question of what applications are started with what specific
configuration parameters.

2) is fulfilled by the session and registration tables

3) b) is fulfilled by agentxSessionAdminStatus
   a) seems like too big a hammer
   c) may be too fine granularity

   I think what we have currently is a reasonable balance.

The only error counter that seems to help here is agentxRegisterDuplicate.
It would be more helpful it if were part of session table.
(It might be even more helpful as part of the registration table, not sure.)

My 2 cents,
Mike