Subject: JMP> Re: SNMPv3 unsuited for IPP/JMP Notifications

From: [email-masked] (Ira Mcdonald x10962)
Date: Sun, 22 Mar 1998 16:37:08 PST

Copies To:  [email-masked], [email-masked], [email-masked]

Hi Randy,                                         Sunday (22 March 1998)

My replies are imbedded in your note below, preceded by 'IEM>'.  I tried
to answer each of your questions.

Cheers,
- Ira McDonald (High North)
>----------------------------------------------------------------------<
>From: "Turner, Randy" <[email-masked]>
>To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
>Subject: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations
>Date: Sun, 22 Mar 1998 14:56:06 PST
>
>There two questions that have yet to be answered.
>
>You've repeatedly stated that SNMPv3 is not intended for "very many
>notification clients". I would like to hear a technical analysis of why
>you think this is the case.

IEM> Because the SNMPv3 security depends on the distribution of shared
secrets to EVERY managed system, but does NOT specify a Key Management
Protocol.  Because the SNMPv3 Target and Notification MIBs have highly
inefficient string indices, placing a significant burden on ALL managed
systems.  For ACTIVE management (not just passive monitoring) of key
infrastructure (routers, switches, hubs, etc), SNMPv3 may turn out to
be quite successful in the marketplace, but deployment will undoubtedly
be sporadic and interworking problems will be common.

>Also, I think its VERY unrealistic that an embedded device will have to
>manage "several hundred" client notification requests. If every client
>can specify a totally different object set to be sent along with each
>notification, then I don't think this is realistic for embedded devices.
>If you have a defined trap/notification, with a specific list of objects
>that are returned, then a notification originator only has to keep track
>of transport domains and addresses, not every combination of object sets
>that "possibly hundreds of notification clients" might want to know
>about.

IEM> Xerox (like IBM, and various other printer vendors) builds VERY big
production printing systems (which may cost over a million dollars each).
The SNMPv1 framework defines 6 different important traps; each interface
MIB (Ethernet, TokenRing, etc) defines several more traps; the Printer MIB
defines one trap; the PWG Job Monitoring MIB will (hopefully) define one
or several (job- vs document-level) traps; the XCMI (Xerox Common Mgmt
Interface) suite of 14 MIBs defines 16 different traps.  Xerox clients
do NOT register promiscuously for ALL traps - they pick and choose,
according to their end-user preferences or roles (operators and system
administrators have different interests and needs, for example).  VERY
lightweight trap registration is a necessity for the printer industry!

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

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?

[Jay, I personally think SENSE is good stuff - but technical excellence
isn't the only or even major factor in the deployment of technology.]
>----------------------------------------------------------------------<

---

From: Jay Martin <[email-masked]>
Date: Mon, 23 Mar 1998 10:22:51 -0500

This is a *great* thread.  Hopefully everyone is reading the
exchanges between Randy and Ira so as to quickly come up to
speed on the applicability (or not) of SNMPv3 to the network
printer universe.

> widely deployed for at least the next three years - look at the deployment

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...

> 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.

> 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:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------