|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: a different view of SNMP
[ On Monday, September 6, 1999 at 14:24:47 (+0400), Alex P. Rudnev wrote: ] > Subject: Re: a different view of SNMP > > It's just the BRIGHT example when usage SNMP did not allow to create > friendly configuration interface - all network admins here hate WellFleet > for their confih methods and was happy to return back to CLI when they > realised it' The first words they have saying when learned CISCO was > _ohh, at least no GUI and SNMP!_ -:) Yes, you're right, but of course there's nothing inherent about SNMP that requires a GUI. It does require a separate host platform on which to run the configuration tool(s) though, which is indeed a bit of the problem, at least until more recent times. Of course there's nothing about a CLI that precludes having a GUI either, or any other kind of screen based menu/forms interface. > The reason - WWW is _SELF-DEFINED and SELF-HELPED_ protocol (sorry for > the wrong english usage), SNMP with GUI are not at all... Yes, you're mostly right there. The interesting thing about a WWW interface is that it almost totally puts the user-interface parts in the right place -- i.e. on an *independent* terminal platform. The SNMP interface, GUI or not, will often have a lot of dependencies upon the exact version of whatever is running on the device to be configured, even though SNMP should allow these minor differences to be hidden. X11, the Bell Labs blit terminals, and other similar attempts to divorce the meaning of the interface from the interface itself and the device that implements it, all point in the right direction. The HTML and HTTP protocols provide a high enough level of abstraction that even novice programmers can create very sophisticated user interfaces that are platform independent. WWW interfaces in routers don't cost a whole lot in memory, code, or processing power, to implement and yet they give the device operator a most definite degree of not just version independence, but device independence. They are ideal for embedded systems because the complexity and and processing requirements are moved to the less resource-restricted browser environment. In theory any generic computer with a network interface and a generic WWW browser will allow an operator to get their job done no matter what kind of device they actually encounter in the field. Of course I'm not optimistic that things will continue to get better in this arena.... Inevitably the feature junkies will continue to create facets of the interface in a device that'll require specific tools to be used and which we the users won't be able to do without. Should we allow router vendors to require JavaScript support, or should we try to force them to always maintain total compliance with the lowest common denominator? However I am still optomistic (perhaps insanely so) that someday SNMP may still become purvasive enough that generic configuration tools will be powerful enough to use across device platforms (i.e. not just the toys we have today that can be used to prototype things with). After all we do now have tools that are generic enough to allow us to use SNMP to gather statistics and error reporting and other such stuff. Your own tools and your own paper are ample evidence of this! You see the real problem with CLI interfaces is that they require programming talent to use in any automated way -- they will always differ too much between platforms. While I'm one of the first to say more people should learn to program computers intelligently, I'm also a pessimist about this ever happening to the degree it is necessary to A similar, but even more insidious, problem occurs with WWW interfaces. They are also inevitably going to be different in many ways between platforms (or at least between manufactures). They assist in making human operators more portable but they are no better at offering standard programming interfaces than CLIs are. In fact they make it easy (and fun) enough for an operator to do boring and repetive tasks. In addition they make it even harder to write programs that interface with them. The result is that they require many more human robots to operate than should really be necessary. While I think these diversities in CLI and WWW user interfaces between platforms and manufacturers are still a good thing in this business, they are barriers to writing automated tools. If SNMP isn't the exact answer something like it must force a low-level commonality on the programming interface to these devices. SNMP *is* a very simple protocol, but it requires very sophisticated programmers to make it dance to the tune of a sophisticated network operator! One of the other complaints folks have about SNMP, and it shows up in your article too, is that SNMP isn't sophisticated enough to do the things that a very experienced CLI (or WWW) user can do. While this is indeed true for given instances of implementations, it is *not* the fault of SNMP itself. These complaints are usually due to the fact that the SNMP designers (particularly those building private MIBs) are either not experts in the inticracies of the products they are designing for, or are not experts in SNMP design. The result is that they try to take shortcuts that will make SNMP "easier" to use. Unfortunately this often also means that their MIBs are more limiting than necessary too. (This is one thing I don't think Wellfleet suffered from -- they very effectively forced themselves to design MIBs that were capable of doing all of the sophisticated things that their products were required to do!) I.e. the answer to your question of why hardware vendors did not realise SNMP in the proper way is that most of them were not forced to do so. They were often only implementing SNMP because they were required to do so to meet the perception of some requirement to have such support and they often took many short cuts in their designs because they thought they knew that the real experts would always want to use the CLI. One thing that vendors could do to help make SNMP more accessible would be to make their MIBs more widely available -- perhaps even storing them in the devices now that flash memory is almost affordable. Of course one thing that SNMP did not properly address is change mangement in itself -- i.e. MIBs are not easily changed, but rather are designed to be properly defined and frozen before they are ever used. I certainly do not disagree with your description of SNMP data representation as inside out and in-human! (But then I hate RPN calculators too! ;-) -- Greg A. Woods +1 416 218-0098 VE3TCP <[email protected]> <robohack!woods> Planix, Inc. <[email protected]>; Secrets of the Weird <[email protected]>
|