[ 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! 
