RE: Help/guidance on L2TPv3 MIB draft

["Natale, Robert C (Bob)" <bnatale@lucent.com>]

Ha!  That's what I love/hate about getting into discussions of
fundamental concepts on SNMP lists:  Before you know it, you're
into "criminal hacks".  Amazing.

Let me drop back to "thinking about MIBs 101":  The cases
in which a MIB *should* be designed from the perspective of
being instantiated by only a single agent entity on a managed
system (host:port) are a few special cases.  In the general
case, a MIB should *always* be designed from the perspective
of multiple instances being supported concurrently, by multiple
independent agent entities, on a managed system.  When you think
this through, you will come to the realization that it is
nearly axiomatic wrt design principles.  Extrapolating from
that axiom leads you to the realization that scalar objects
are as out-of-place in MIBs as non-normalized constructs are in
a relational database schema.  Avoiding the problem is trivial,
both in terms of identifying a logical approach and in terms
of implementation effort and runtime overhead.

The one thing Dave said below that I can agree with is that
this is not an AgentX issue (and hence I suggest that any
further follow up should go only to the mibs@ops.ietf.org list
...I've bcc'd the AgentX list to give everyone a chance to join
the mibs list).  AgentX provides the standardized extensible SNMP
agent framework that makes best use of multiply instantiable MIBs,
but readily supports the (degenerate) case of a MIB designed for
single instance use only (RFC2741, Sec. 4.2.1), as well as a range
of applications that span both models.

To sum it up, my basic assertion is:  MIBs designed to be
multiply instantiable are better designed MIBs in the general
case than MIBs that are designed to be singly instantiable.
That they also enable maximum benefit from AgentX is a freebie
by-product of their design.  However, there may be some special
cases where singly instantiable MIBs are not inappropriate.
Nonetheless, it is also axiomatic that a multiply instantiable
MIB can inherently support single instance configurations, while
the converse, in the general case, does not hold.

I can't wait to see what the level after "criminal hack" is! :-)

Cheers (sincerely...this is not a matter of life and death
for me),

BobN
- - - - -
> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: Monday, September 30, 2002 6:05 PM
> To: Mark Ellison; Andy Bierman
> Cc: Margaret Wasserman; Juergen Schoenwaelder; bnatale@lucent.com;
> mibs@ops.ietf.org; agentx@dorothy.bmc.com
> Subject: Re: Help/guidance on L2TPv3 MIB draft
> 
> 
> 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
>