Re: Help/guidance on L2TPv3 MIB draft

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

I suggest that this is really a system problem, and not an agentX
or SNMP problem.  Its a system problem because a well designed system
that supports management should not require an agentX hack to add
support for another interface. So if I was the first developer to
add support for a new interface and there was not an system interface
to add in the support for management, I would add one to an open
source OS, and for closed source OSs, then I would work with the
vendor. Only after ALL other available options were exhausted would
I add an agentX hack.

Why do I call it a hack? It is because ideally all management information
should be available via all management interfaces to a system. That is,
there should be system calls to present info on a CLI, present via
a WEB server, and SNMP agent. As soon as you do a "quick and dirty"
job to circumvent the OS, then you find you need to provide it for
other management interfaces. The result being extra cost and lower
integrity than if the wholistic approach is taken. Note that there
are some vendors (such as MicroSoft) that make things difficult. But
for all others it is criminal to go the hack approach.
 

At 04:24 PM 9/30/2002 -0400, Mark Ellison wrote:
>Hi Andy,
>
>Allowing for subagent to subagent queries would be predicated upon having
>sufficient security in place.  Support for the SNMPv3 security has been proposed
>as work items (see the "security credentials"  and "isAccessAllowed()" threads
>on the agentx-email list).
>
>Until there is an update to the AgentX protocol, this sort of orchestration must
>occur "out of scope" or "out of band" to a standards compliant snmp agent.
>
>I would suspect the subagent knowing about certain scalars would likely be part
>of the same daemon or process as that responsible for spawning instance daemons,
>so would probably already contain the instrumentation, or access to it the local
>instrumentation's of the scalar without additional demands on the snmp agent.  I
>think this true for both monolithic and run time extensible agents.
>
>If the eos and sming working groups create changes to the operations and the
>underlying PDU structure, then there is a definite need to make changes to
>AgentX to support these new features  (One option would be to convert everything
>per `on the wire' for compatibility with the current set of AgentX PDUs, but
>this would be extremely inefficient).  So I think there'll be ample time to
>discuss subagent to subagent requests as well.
>
>In the meantime, pointing out issues to MIB designers is still a very good tool.
>
>Regards,
>
>Mark
>
>
>Andy Bierman wrote:
>
>> [deletions]
>>
>> Here is one more design approach:
>>
>> (4) Allow for sub-agent to sub-agent queries.  E.g., the sub-agent that
>>     registers for ifNumber sends a request to every other sub-agent for
>>     the number of rows in ifEntry owned by that sub-agent.
>>
>> Either this or (2) below are acceptable because they don't force
>> MIB design changes.
>>
>> Andy
>>
>
>[deletions]
Regards,
/david t. perkins