Subject: IPP> 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: "Turner, Randy" <[email-masked]>
Date: Sun, 22 Mar 1998 17:04:26 -0800

Your scalability rationale essentially boils down to string indices,
since not all SNMPv3 implementations have to implement security via
shared secrets. I don't think this single rationale is enough to dismiss
on a scalability question. All along we've been talking about how to
scale things down enough to make things "simple, lightweight", including
talk about a much lighter weight protocol for host-to-device
communication, where a notification protocol might be used. For you to
bring up the fact that Xerox and other vendors have up to 1 million
dollar printers is an argument for many notifications, but doesn't make
much sense in the context of our heretofore previous discussions. You
even talk about "1 million dollar printers" and "VERY lightweight" in
the same paragraph ;) ;)

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.

Randy

	-----Original Message-----
	From:	[email-masked]
[SMTP:[email-masked]]
	Sent:	Sunday, March 22, 1998 4:37 PM
	To:	[email-masked]; [email-masked]; [email-masked]
	Subject:	IPP> Re: SNMPv3 unsuited for IPP/JMP
Notifications

	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,

	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.

	>that "possibly hundreds of notification clients" might want to
know

	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!

	>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: Harry Lewis <[email-masked]>
Date: Tue, 24 Mar 1998 11:34:05 -0500

Well, yes, it gets pretty confusing...

>Well, here we go again...
>
>Is it just me, or are we running into the embedded printer requirements
>versus the print server requirements.  If we are talking about IPP, the
>host to device protocol, then I agree that the device need only support
>a limited number of notification clients.  If we are talking about IPP,
>the print client to server protocol, then I believe that print server
>ought to be able to scale to 100's, even 1000's, of clients.
>
>...walker

Because we're talking less about IPP and more about a notification service
where, as a potential ubiquitous print submission protocol, IPP needs a
mechanism for registering clients for notifications, regardless of the
scalability of the notification server

I think we need to look at notification services both from the limitations of
an embedded device (where most notifications will originate), AND from the
point of view of a robust server implementation (like SENSE). The device is not
likely to accept the notion of give me e-mail on this message, pager from
noon-2pm and fog horn after dark. Oh, and I'd like specifically, and ONLY, the
following content with that notice. But, I'm hearing that we wish to consider
all this flexibility (and more) in our design.

If we break notification into "stages"... the "device originated notification"
and the "server based notification"... I think it is likely that typical
client-server-device breakpoints will result in several registered hosts at the
device. It is also possible to create a limited peer-to-peer printing system
with no notification server where print clients register directly with the
device. It is also possible to create a notification server that simply polls
the device, eliminating the need for a device notification protocol or
registration scheme.

Since, as Jim points out, we really are talking about (at least) two stages of
notification, we should be careful to indicate which part of the problem our
recommendation is addressing.

Harry Lewis - IBM Printing Systems