Subject: RE: AgentX Charter/Milestone Update

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 19 Apr 2001 06:16:40 +0200

Inline

> ----------
> From: 	Ayers, Mike[SMTP:[email-masked]]
> Sent: 	Thursday, April 19, 2001 12:32 AM
> To: 	[email-masked]
> Subject: 	RE: AgentX Charter/Milestone Update
> 
> 
.. snip ..

> 	There is also USM, which needs the set of security credentials in
> order to support the Own Key Change objects.
> 
I would think that these USM things belong in the MASTER agent
and so would not have any impact on agentx protocol

Bert

---

From: Frank Strauss <[email-masked]>
Date: 19 Apr 2001 15:00:43 +0200

Hi!

>> order to support the Own Key Change objects.
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.

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.

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. In cases where there is
no instrumented entity, there is no need to move the implementation
away from the master agent.

 -frank

---

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

>>>>> On 19 Apr 2001 15:00:43 +0200, Frank Strauss <[email-masked]> said:

Frank> In my opinion, the same is true for other MIB tables that model
Frank> general functions or characteristics of an agent or its
Frank> infrastructure, e.g., in the DISMAN-EVENT-MIB or the
Frank> SNMPCONF-PM-MIB mentioned by Wes.

Well, I agree to a large extent.  My examples were certainly the
extremes.

However, I've already spoken with people (Jeff Case being one example)
that would not want to put the SNMPCONF-PM-MIB in the master agent, so
the desire is there.  In a discussion that revolved around the
capabilities table, agentx was explicitly discussed and it was decided
that support for agentx simply wouldn't be possible without crippling
the functionality that was being proposed.

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

Which works as long as there isn't conflicts with multiple subagents
registering the same row with possibly different values.  Granted,
this is somewhat of an impossible problem to solve without the
external tables explicitly saying how to handle this case.

Frank> It is not the purpose of AgentX to be used for each and every
Frank> MIB.

True.

Frank> It is the purpose of AgentX to allow to put the management
Frank> instrumentation next to the instrumented entities in order to
Frank> achieve a cleanly separated design where appropriate. In cases
Frank> where there is no instrumented entity, there is no need to move
Frank> the implementation away from the master agent.

You could easily imagine an external application being responsible for
monitoring or for policy manipulation.  I'd even venture to say that I
doubt any management station implements their polling engine inside
the master snmp demon running on the manager server.
-- 
Wes Hardaker
NAI Labs
Network Associates