[AGENT++] Creating Rows in Shared MIB Tables

[Mark Ellison]

Hi Frank and Jen,

Thought I might add some comments inline...

Frank Fock wrote:

> Jens,
>
> A very good question! AgentX does not provide any mechanism
> for sharing tables with a RowStatus column (thus tables where
> rows can be created dynamically via SNMP requests).
> There are three possible solutions:
>
> 1. The subagents are using preallocated index ranges, but this
> requires that the managers know these ranges and the implicit mapping
> to subagents (although this could probably extracted from the
> AGENTX-MIB).

This approach works for well known mappings of indice sets to subagents 
for the shared table.  Each subagent simply registers its set of 
indices, even for rows that do not exist.  When a set-create is 
received, it will be directed to the appropriate subagent.  Doesn't 
scale well though.

>
> 2. Use contexts as you suggested in your posting. Each subagent uses
> its own context. But then you have no longer a shared table. 
> Nevertheless,
> there could be built a read-only shared table in the default context. 

non-default contexts are an alternate form of indexing, however manager 
needs to keep track of which context correlates to which subagent, 
instead of  which set of indices correlates to which subagent.  Its 
tempting to work through the idea of set/creating in a non-default 
context and see the composite table within the default context.  One 
would still need to be creative with mapping indice values between contexts.

>
> 3. Use an object outside the table to create rows in the table. 

(actually, a favorite hack :-).  Most tables that are shared and that 
provide set/create functionality should have companion objects that 
serve as an aid to managers.  For example, a "next available index" 
object.  There would need to be one subagent that registers at a subtree 
node that sits above both the companion object and the table and acts as 
an "orchestrator" for the shared table. 

Thus, a set-create request for a non-existent row would be dispatched to 
the orchestration subagent since shared-table subagents, in this 
paradigm, only register existing rows at the subtree node within the 
columns of the shared table including its set of indice values.  So, 
from the AgentX registration and SNMP master dispatch point of view, I 
don't see a hack....however, what the orchestration subagent does to 
actually instantiate the new row is on the road to hacksville.

Regards,

Mark