Subject: Re: open issues in agentX MIB

From: "Smitha Gudur" <[email-masked]>
Date: Mon, 03 Aug 1998 10:04:07 PDT

>From [email-masked] Fri Jul 31 15:04:49 1998
>Received: (from uucp@localhost)
>	by almond.bmc.com (8.8.8/8.8.8) id RAA26253
>	for <[email-masked]>; Fri, 31 Jul 1998 17:04:42 -0500 (CDT)
>Received: from firewall.bmc.com(192.245.162.250)
>	by almond.bmc.com via smap (V2.0)
>	id xma025969; Fri, 31 Jul 98 17:04:03 -0500
>Received: (from uucp@localhost)
>	by dresden.bmc.com (8.8.5/8.8.6) id RAA12852
>	for <[email-masked]>; Fri, 31 Jul 1998 17:03:19 -0500 (CDT)
>Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via 
smap (3.2)
>	id xma011550; Fri, 31 Jul 98 17:02:13 -0500
>Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65])
>	by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA15748;
>	Fri, 31 Jul 1998 17:02:20 -0500 (CDT)
>Received: from almond.bmc.com (almond.bmc.com [172.17.0.100])
>	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA16380
>	for <[email-masked]>; Fri, 31 Jul 1998 14:57:17 -0700 (PDT)
>Received: (from uucp@localhost)
>	by almond.bmc.com (8.8.8/8.8.8) id QAA25126
>	for <[email-masked]>; Fri, 31 Jul 1998 16:57:14 -0500 (CDT)
>Received: from oden.exmandato.se(192.71.33.1)
>	by almond.bmc.com via smap (V2.0)
>	id xma025120; Fri, 31 Jul 98 16:56:53 -0500
>Received: from localhost (martin@localhost)
>	by oden.exmandato.se (8.8.8/8.8.5) with SMTP id XAA00477;
>	Fri, 31 Jul 1998 23:56:59 +0200 (MET DST)
>Date: Fri, 31 Jul 1998 23:56:59 +0200 (CEST)
>From: Martin Jacobsson <[email-masked]>
>Reply-To: Martin Jacobsson <[email-masked]>
>To: Smitha Gudur <[email-masked]>
>cc: [email-masked]
>Subject: Re: open issues in agentX MIB
>In-Reply-To: <[email-masked]>
>Message-ID: 
<[email-masked]>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>
>On Fri, 31 Jul 1998, Smitha Gudur wrote:
>
>> If there are any other open items that need to be addressed in the 
MIB, 
>> I urge everyone on the mailing list to send them as early as 
possible. 
>
>Section 2, goal 4 says:
>
>- Provide statistics about the protocol operation such as the number of
>  packets to and from each subagent
>
>This information is not available through the mib as defined.
>One option is to add agentxSessionInPackets and agentxSessionOutPackets 
to
>the session table. And another is to add agentxConnInPackets,
>agentxConnOutPackets, agentxConnProtocolErrors and 
agentxConnParseErrors
>to the connection table. All as Counter32's.

As Bob said, the objective is to keep the MIB minimal. 
The statistics were defined in detail in the early version of the MIB 
and were subsequently removed as it was felt there were not adding any
usefulness except in debugging. 

>
>Then a port table would be nice, so that it is possible to see what 
ports
>the master agent accepts connections from and if it listens on any
>nondefault ports. A typical unix master agent will listen on both tcp 
port
>705 and unix-domain socket "/var/agentx/master".

agentxConnTransportAddress is the transport address and
the port. 

smitha

>
>/Martin Jacobsson
>
>---
>.signature: No such file or directory
>
>
>
>
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

---

From: David Harrington <[email-masked]>
Date: Mon, 03 Aug 1998 14:30:31 -0400

> usefulness except in debugging.

I have not followed agentX very closely, since it is agent-centric,
and I am very manager-centric, but I am concerned that information
that would be helpful to network operators and snmp applications
may be eliminated in the quest for a minimal MIB.

If I understand correctly the purposes of agentX, it is to make
it 1) easier for devlopers to provide their domain-centric piece,
and 2) to permit developers to write their code to a consistent
interface for attachment to potentially multiple master-agent
toolkits. 

I believe I have seen allusions to a future of dynamic linking and 
registration (or other dynamic associations between master and subagent 
pieces). 

If dynamic "attachment" is likely to be supported by implementations,
then debugging could well become a problem that network operators and
snmp applications must deal with. Under those conditions, having the
statistics regarding the number of packets, and the number of errors
could be very important for determining the cause of problems and/or
inconsistencies in the network management information gathered. This 
information could be especially valuable if one sub-agent's registration 
can supercede another's registration, which I believe is part of
the spec.

My point is that "debugging" may be necessary at run-time, not just
development time, so good information should be available at run-time.

my $.02

dbh
-- 
-----------------------------------------------------
#include <std.disclaimer> 
David Harrington  [email-masked] 
Spectrum Network Management Platform Core Group
Cabletron Systems Inc. 
-----------------------------------------------------