Re: the future of SNMP
Bob Natale <[email protected]> Thu, 27 Feb 2003 18:40:29 -0500
| Newsgroups | gmane.ietf.eos |
|---|---|
| Message-ID | <[email protected]> |
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