One comment Ira wrote to Randy is particularly notable:
> >I don't think SNMPv3 is heavyweight. It's designed be implemented in
> >everything from $300 managed 100Mbit hubs, all the way to enterprise ATM
> >switches. And I think whatever solution we come up with will have to
> >have the capability to support a distributed event notification system,
> >similar to the way SENSE and other distributed notification mechanisms
> >remove the burden from individual embedded printers from having to keep
> >up with the entire world of notifications.
>
> IEM> But, your examples are all of infrastructure (intermediate-systems),
> not printers, scanners, and other end-systems. Managing a hub or router
> has essentially nothing in common with managing end-systems, except that
> they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to be
> widely deployed for at least the next three years - look at the deployment
> track record of SNMPv2!
In essence, all things are *not* necessarily equal under SNMP in
terms of scale and functionality. I have been trying to get people
in the PWG to understand this essential fact for years now.
SNMP was designed for "network elements" (what Ira calls "infrastructure
elements", another good name). That was the sole problem domain for
which SNMP was designed.
Can SNMP be used for other applications? Of course.
Must we necessarily constrain our product designs around the
limitations of SNMP? (That is, if SNMP can't do it, then
either can/should we.) That's silly.
Just because you can, doesn't mean you should...
> No vendor can tell their customers that they can't manage their printers
> until they deploy (largely non-existant) new enterprise open management
> systems (CA Unicenter, Tivoli TME, HP OpenView, Sun Solstice, etc) that
> have support for SNMPv3 (some of those that I just mentioned don't have
> support for SNMPv2, yet). Xerox research has found that many customers
> HATE to be told that "this product just requires a few little server
> applications." Elegant distributed event notification schemes like
> SENSE are very unpopular with Xerox product planners and marketers
> (and customers). Perhaps your customers haven't been bitten by unstable
> NetWare NLMs or NT server applications?
Amen, brother. We at Underscore constantly wrestle with the plain
fact that customers ABHORE the need to install/maintain/operate
additional components required to make your product work.
That cold, hard fact became painfully obvious with our work on
designing a product-oriented implementation of SENSE.
For example, we needed a very, very lightweight directory service.
No problem. How about LDAP? What about SLP? Hey, even NDS may
be possible.
And yet the continual problem we faced was: Which lightweight
directory is ubiquitously available across all major server
platforms today?
The answer, of course, is: None.
So we had to (quickly) design/implement the very, very lightweight
directory service directly inside SENSE. It was no big deal,
and we do not have any external dependencies that customers abhore.
> [Jay, I personally think SENSE is good stuff - but technical excellence
> isn't the only or even major factor in the deployment of technology.]
Again, amen. I would never consider the current SENSE design as
"technically excellent". That was NEVER the goal.
The goals? Simple. Very lightweight. Eminently portable. Easy
to use. Easy to understand. Easy to extend. Low resource requirements.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------