Subject: Re: AgentX Charter/Milestone Update

From: Randy Presuhn <[email-masked]>
Date: Thu, 19 Apr 2001 10:35:17 -0700 (PDT)

Hi -

> From: Frank Strauss <[email-masked]>
> To: [email-masked]
> Subject: Re: AgentX Charter/Milestone Update
> References: <[email-masked]>
> Date: 19 Apr 2001 15:00:43 +0200
> In-Reply-To: <[email-masked]>
> Message-ID: <[email-masked]>
...
> Bert> I would think that these USM things belong in the MASTER agent
> Bert> and so would not have any impact on agentx protocol
> 
> In my opinion, the same is true for other MIB tables that model
> general functions or characteristics of an agent or its infrastructure, 
> e.g., in the DISMAN-EVENT-MIB or the SNMPCONF-PM-MIB mentioned by Wes.

I think it would be very nice to be able to put the disman event,
schedule, script, and expression mibs into subagents.  The only
thing that currently makes that difficult is the need to remember
credentials and to consult the (abstract) isAccessAllowed service.

Building all these MIBs into the master agent implementation
would be a configuration management (in the software sense)
nightmare.

> However, if we look at some tables more detailed on a per-row basis,
> it might be reasonable to let a sub-agent register single rows with
> the master, e.g. in case of the capabilities table.

One can already perform such registrations with AgentX.

> It is not the purpose of AgentX to be used for each and every MIB.
> It is the purpose of AgentX to allow to put the management
> instrumentation next to the instrumented entities in order to achieve
> a cleanly separated design where appropriate. 

Agreed.

>                                               In cases where there is
> no instrumented entity, there is no need to move the implementation
> away from the master agent.
...

In cases where there is no instrumented entity, a MIB would
be pointless.

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

---

From: Frank Strauss <[email-masked]>
Date: 19 Apr 2001 21:21:04 +0200

Hi!

>> e.g., in the DISMAN-EVENT-MIB or the SNMPCONF-PM-MIB mentioned by Wes.

Randy> I think it would be very nice to be able to put the disman event,
Randy> schedule, script, and expression mibs into subagents.  

Why? -- In general, I feel more comfortable if all aspects of a
service are covered by one process, just for clarity and resource
consumption. 

In some other areas, criteria like robustness of the whole system if
one subsystem is buggy, or performance if threading is not available,
are mentioned. I'm not convinced that these are real arguments for
sub-agents.

Randy> The only thing that currently makes that difficult is the need
Randy> to remember credentials and to consult the (abstract)
Randy> isAccessAllowed service.

I agree that these two aspects should be carefully considered for
being conveyed by the AgentX protocol, although they would probably
drop a general concept of AgentX: The subagent could not remain "SNMP
ignorant", I assume.

Randy> Building all these MIBs into the master agent implementation
Randy> would be a configuration management (in the software sense)
Randy> nightmare.

Why? -- In general, I prefer to see all aspects of an agent
configuration covered by one scheme.

>> the master, e.g. in case of the capabilities table.

Randy> One can already perform such registrations with AgentX.

Yes, that's what I mean. :-)

If each sub-agent (no matter whether internal or via AgentX) registers
its "capabilities rows", there is no need for a sub-agent that serves
the whole capabilities table and a new protocol extension that allows
other sub-agents to register their capabilities with this capabilities
sub-agent.

>> a cleanly separated design where appropriate. 

Randy> Agreed.

>> In cases where there is no instrumented entity, there is no need to
>> move the implementation away from the master agent.

Randy> In cases where there is no instrumented entity, a MIB would
Randy> be pointless.

Sorry, I've probably used the wrong words. By "cases where there is no
instrumented entity" I mean those MIB objects that are not related to
a piece of source code that already exists.

Examples: If you want to implement the WWW-MIB or the MTA-MIB, then
you usually do this for a specific service application. This
application has data structures from which you can more or less easily
derive your MIB object implementation. Here, AgentX would be my
favorite choice.  On the other hand, if you implement something like
the DISMAN-SCRIPT-MIB or the any of the SNMP-???-MIBs there is no code
that already exists going to be instrumented. Everything has to be
done from scratch. Here, I see no need to create a new program and run
a separate process for questionable reasons. For example, on the
NET-SNMP platform the capability of dynamically loadable modules is my
favorite choice.

 -frank

---

From: [email-masked] (Frank Fock)
Date: Thu, 19 Apr 2001 22:09:02 +0200

Hi Frank,

Agreed.

> are mentioned. I'm not convinced that these are real arguments for

Agreed too.

> drop a general concept of AgentX: The subagent could not remain "SNMP

In addition the inter process communication between the master and the
subagent will be quite complex too. Especially on the subagent side,
because it must be capable to accept responses to its own
"isAccessAllowed" requests while it is processing an AgentX request
from the master agent. IMHO the overall cost of such a protocol
operation is higher than its benefit.

> configuration covered by one scheme.

I would prefer implementing those MIBs into the master agent too.

Regards,
Frank

---

From: Wes Hardaker <[email-masked]>
Date: 20 Apr 2001 08:43:00 -0700

>>>>> On 19 Apr 2001 21:21:04 +0200, Frank Strauss <[email-masked]> said:

Frank> In some other areas, criteria like robustness of the whole
Frank> system if one subsystem is buggy, or performance if threading
Frank> is not available, are mentioned. I'm not convinced that these
Frank> are real arguments for sub-agents.

Using that argument, why wouldn't you just implement everything inside
a single process?  I mean, why put the MTA-MIB inside the sendmail
demon?  Wouldn't it be just as easy to put the sendmail demon inside
the snmp demon?  It'd greatly simplify the process table:

% ps ax
1 ... snmpd

-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Frank Strauss <[email-masked]>
Date: 20 Apr 2001 17:53:08 +0200

Hi!

Wes> Using that argument, why wouldn't you just implement everything inside
Wes> a single process?  I mean, why put the MTA-MIB inside the sendmail
Wes> demon?  Wouldn't it be just as easy to put the sendmail demon inside
Wes> the snmp demon?  It'd greatly simplify the process table:

Wes> % ps ax
Wes> 1 ... snmpd

;-)

Why a process at all? Let's put it into the kernel!

 -frank

---

From: Wes Hardaker <[email-masked]>
Date: 20 Apr 2001 09:22:03 -0700

>>>>> On 20 Apr 2001 17:53:08 +0200, Frank Strauss <[email-masked]> said:

Wes> % ps ax
Wes> 1 ... snmpd

Frank> ;-)

Frank> Why a process at all? Let's put it into the kernel!

Good idea!

Oh wait.  That's DOS.

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."

---

From: Bob Natale <[email-masked]>
Date: Fri, 20 Apr 2001 15:03:39 -0400

>Frank> Why a process at all? Let's put it into the kernel!

Excellent piece of word-smithing, both of you.
Nice way to conclude the point:

  - the case for sub-agents has been well-established
    by the marketplace
  - a standard sub-agent technology (AgentX) can
    adequately address many/most real-world cases
  - there are some perfectly valid real-world cases
    were the cost/benefit ratio does not favor a
    de jure standard approach
  - various requirement-sets, design choices, and/or
    implementation strategies can result in different
    allocations of real-world cases among those two
    solution sets.

Cordially,

BobN