I will reiterate my belief that I don't think its realistic for a simple
embedded device to maintain notification info for hundreds of clients. I
don't think its in the notification requirements document...maybe we
should talk about the number of notifications that an embedded device
should minimally support? And include the outcome of that discussion in
the requirements doc.
Also, I used my managed device examples (small hub to enterprise switch)
to illustrate low-cost to high-cost devices with very wide variances in
burden cost for manufacturing (memory, power, cpu, etc.).
Maybe what we are actually debating is semantics in how we define
"lightweight" and "heavyweight" Does lightweight mean simple to build
(overall)? Simple to code? Lightweight in terms of CPU cycles? Other? It
sometimes sounds like we are defining terms differently.
Sent: Sunday, March 22, 1998 4:37 PM
To: Joe_Filion@mc.xerox.com; email@example.com; firstname.lastname@example.org
Subject: IPP> Re: SNMPv3 unsuited for IPP/JMP
Copies To: email@example.com, firstname.lastname@example.org, Joe_Filion@mc.xerox.com
Hi Randy, Sunday (22
My replies are imbedded in your note below, preceded by 'IEM>'.
to answer each of your questions.
- Ira McDonald (High North)
>From: "Turner, Randy" <email@example.com>
>To: "'firstname.lastname@example.org'" <email@example.com>, "'firstname.lastname@example.org'"
>Subject: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP
>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
>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
secrets to EVERY managed system, but does NOT specify a Key
Protocol. Because the SNMPv3 Target and Notification MIBs have
inefficient string indices, placing a significant burden on ALL
systems. For ACTIVE management (not just passive monitoring) of
infrastructure (routers, switches, hubs, etc), SNMPv3 may turn
be quite successful in the marketplace, but deployment will
be sporadic and interworking problems will be common.
>Also, I think its VERY unrealistic that an embedded device will
>manage "several hundred" client notification requests. If every
>can specify a totally different object set to be sent along
>notification, then I don't think this is realistic for embedded
>If you have a defined trap/notification, with a specific list
>that are returned, then a notification originator only has to
>of transport domains and addresses, not every combination of
>that "possibly hundreds of notification clients" might want to
IEM> Xerox (like IBM, and various other printer vendors) builds
production printing systems (which may cost over a million
The SNMPv1 framework defines 6 different important traps; each
MIB (Ethernet, TokenRing, etc) defines several more traps; the
defines one trap; the PWG Job Monitoring MIB will (hopefully)
or several (job- vs document-level) traps; the XCMI (Xerox
Interface) suite of 14 MIBs defines 16 different traps. Xerox
do NOT register promiscuously for ALL traps - they pick and
according to their end-user preferences or roles (operators and
administrators have different interests and needs, for example).
lightweight trap registration is a necessity for the printer
>I don't think SNMPv3 is heavyweight. It's designed be
>everything from $300 managed 100Mbit hubs, all the way to
>switches. And I think whatever solution we come up with will
>have the capability to support a distributed event notification
>similar to the way SENSE and other distributed notification
>remove the burden from individual embedded printers from having
>up with the entire world of notifications.
IEM> But, your examples are all of infrastructure
not printers, scanners, and other end-systems. Managing a hub
has essentially nothing in common with managing end-systems,
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
track record of SNMPv2!
No vendor can tell their customers that they can't manage their
until they deploy (largely non-existant) new enterprise open
systems (CA Unicenter, Tivoli TME, HP OpenView, Sun Solstice,
have support for SNMPv3 (some of those that I just mentioned
support for SNMPv2, yet). Xerox research has found that many
HATE to be told that "this product just requires a few little
applications." Elegant distributed event notification schemes
SENSE are very unpopular with Xerox product planners and
(and customers). Perhaps your customers haven't been bitten by
NetWare NLMs or NT server applications?
[Jay, I personally think SENSE is good stuff - but technical
isn't the only or even major factor in the deployment of