[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the future of SNMP



At 2/27/2003:03:07 PM, Andrew Smith wrote:

Hi,

>I don't see how tweaks to the MIBs are going to solve a lot of the
>issues. 

True.  But for my part, I am not talking about "tweaks to the MIBs"
at all.  I am talking about much more capable MIBs...that embody
higher-order functionality, both for monitoring and for control.
Such MIBs can be written today with SMIv2 (which is not to say
that the SMI might not need some "tweaks").  Of course, getting
those MIBs designed is a big hurdle; getting them implemented
(preferably via sub-agents to SNMPv3-capable AgentX master agents)
and utilized by secure SNMPv3-capable management applications
will also prove to be hurdles.  However, my bet is that this 
"Enhanced MIBs" approach will yield the biggest bang for the
buck in the shortest time frame and, above all, is the most
promising way to bring SNMP back to the forefront of network
management.

>IMHO, SNMPCONF effectively did all the MIB work needed to deal
>specifically with provisioning large numbers of similar sets of
>information (I'm talking about the "templating" mechanisms buried in
>draft-ietf-snmpconf-diffpolicy-05.txt, not the PM language from
>draft-ietf-snmpconf-pm-12.txt which is orthogonal): the work done so far
>needs to be generalised of course.

That is true.  The example you cite is just an example of the
*kinds* of things that can be done.

>But the protocol itself needs to grow up in some of the ways that
>Carl, Wes, Dinakaran and others have suggested over the last 10 years.

I don't really agree with the implicit MUST in that assertion.
However, I'd be less opposed to it *if* we were pursuing the
kinds of advancements possible within the current environment
first.  Filtering, selection, etc., can be done in the agent
via Set-able MIB objects; most of the schemes proposed for MIB-
based out-of-band bulkdata/file transfer would work just fine
a practical sense.  Above all, with the huge relaxation of the
original resource constraints on *most* agent environments that
initially dictated the nature of MIBs, we can now pack a lot
more capability into efficient high-order MIB object interfaces
for agents to implement and managers to use.

Lets do that, as a standards body and as an industry.

Cheers,

BobN