IPP Mail Archive: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations

IPP Mail Archive: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations

RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations

Turner, Randy (rturner@sharplabs.com)
Sun, 22 Mar 1998 14:56:06 -0800

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.

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

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.


-----Original Message-----
From: imcdonal@eso.mc.xerox.com
Sent: Sunday, March 22, 1998 9:37 AM
To: Joe_Filion@mc.xerox.com; ipp@pwg.org; jmp@pwg.org
Subject: IPP> Re: SNMPv3 unsuited for IPP/JMP

Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com

Hi Randy, Sunday (22
March 1998)

I think you misunderstood several of my comments. My replies
are in
your note below, preceded by 'IEM>'.

- Ira McDonald (High North)

>From: "Turner, Randy" <rturner@sharplabs.com>
>To: "'imcdonal@eso.mc.xerox.com'" <imcdonal@eso.mc.xerox.com>,
> Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org
>Subject: RE: IPP> SNMPv3 unsuited for IPP/JMP Notifications
>Date: Tue, 17 Mar 1998 10:23:01 PST
>I am not sure what the dissenting opinion is, whether SNMPv3 is
not the
>correct solution? Or, is the proposed notification MIB not the
>If SNMP is the wrong solution, then any SNMP-accessed MIB would
be the
>wrong solution, including the JAM MIB.

IEM> The entire SNMPv3 MIB suite is unsuited to supporting very
end-user clients registered for notifications. But, the SNMPv1
is QUITE appropriate (and ubiquitously deployed) for basic
(and sometimes active management) of networked systems and

>I will try and address the concerns outlined below, with
>1) Scopes of interest are still supported by OID subtree
>specifications; it's the intended notification recipients that
>identified and matched by the UTF-8 tag.

IEM> No, OID subtrees are NOT in the SNMPv3 Notification or
Target MIBs.
Only local-scope tags (non-standardized names for groups of
are specified in the Notification MIB. OID subtrees are in the
View-based Access Control Model MIB (RFC 2275), but ONLY with
support of the user ('principal') security identifications
via the User-based Security Model MIB (RFC 2274). That is, it
takes the
whole ball-of-wax of SNMPv3 MIBs to get to OID subtree views and
STILL aren't designed for fine-grained control (like individual
which are ONLY intended to be controlled via the Notification

>2) Registration lifetimes would be a good idea. It's quite
>for an IPP MIB to augment the notification table with objects
>represent registration lifetimes. No need to throw the baby out
with the
>bath water on this one. Since it is an explicit augmentation,
>indices would be the same.

IEM> Augmenting an inappropriate scheme (SNMPv3) won't help.

>3) Indices that appear as SnmpAdminString types are labeled as
>NOT-ACCESSIBLE, so they should not appear in the response
packet of a

IEM> There is much confusion about 'not-accessible' indices. In
versions of SNMP (and OSI CMIP), the so-called 'variable
are lists of full MIB object OIDs with SUFFIXED 'instance
which are the VALUES of all the indices (so non-integer indices
reduce the efficiency of SNMP protocol exchanges).

>4) I'm not sure if a brute force search would be required or
>(yet). It appears from reading the RFC that this might be the
case and I
>understand how this conclusion could be made. However, I'm not
sure that
>duplicate registrations could be identified solely on the basis
>"transport" and "transport-address" matching. This particular
>would require more study.

IEM> In ALL versions of SNMP trap registration, duplicate
are determined solely on the basis of 'transport domain' and
address' matching (all the way back to the Historic SNMPv1 Party
RFC 1353). Because SNMPv3 is too heavyweight for a given
device to have many registered 'notification targets', the brute
search doesn't matter much, but for the printer industry
scenarios of
(potentially) hundreds of registered trap clients, the results
be catastrophic.

>5) This rationale does not exist for SNMPv3. This held true
>for V2 (and derivatives). All the text about "dual-role
entities" from
>V2 has been removed from the V3 doc set. The V3 specs now
>identify "notification senders" and "notification recipients".
The idea
>of specific functionality being reserved for a "mid-level"
>entity no longer exists. Implementors are free to instrument
>feature they need, depending upon the type of management (or
>entity is being constructed.

IEM> The SNMPv3 specs do NOT clarify appropriate use of
'Inform', as
David Perkins has repeatedly criticized. The use of 'Inform'
PDUs for
directly acknowledgemed notifications to/from a EACH printer
to (potentially) hundreds of registered clients would fail
to scale in an enterprise network environment.

>6) Again, this idea is a V2 idea, the restrictions on "how" a
>feature is used has been removed from the V3 specifications.
See #5
>above. Also, I have it on good authority from Jeff Case at SNMP
>Research, that the effort required to take the V1 trap code
base and
>move it to V3 trap/inform is no great task. A lot of code reuse
>possible. Also, V3 informs are as reliable as any other

IEM> See my comment below.

>7) Again, I have it on first hand communication from Bob
>Stewart(Cisco), Jeff Case and David Levi(SNMP Research) that
>"intent" was never to disallow the type of functionality I have
>proposed. Rather, it seems like a prudent reuse of all vendors'
>agent code base.

IEM> The new PDUs for SNMPv2 were first published five years ago
Nonetheless, almost ALL installed products speak SNMPv1 ONLY. A
minority support SNMPv1/SNMPv2 'hybrid agents'. Many of those
obsolete when the original SNMPv2 specifications (RFC 144x
series) were
abandoned and replaced with the (incompatible) current SNMPv2
(RFC 190x series) in January 1996. Many of the 'big names' in
management stations STILL only support SNMPv1 protocol. Quite a
STILL won't compile an SMIv2 dialect MIB (remember the SMI
dialect is
INDEPENDENT of the version of 'over-the-wire' SNMP protocol).
It is
inconceivable that customers will upgrade their open management
centers just to get at (newly incompatible) SNMPv3-based

>This reuse of technology (both in design and existing code) is
what I am
>trying to take advantage of. Given the speed at which SNMPv3 is
>adopted, I feel like a lot of vendors are going to want to
implement V3
>agents anyway. Also, after looking at Ira's proposal for the
>there are some ideas present in the JAM MIB that were not
included in
>the standard notification/target MIBs specified in RFC 2273. I
think we
>should include these ideas in whatever we come up with. I don't
think we
>should completely reinvent the wheel here, rather, I think we
>come up with a suitable set of additional (non-overlapping)
>features and AUGMENT the standard set. This is because, for a
lot of
>reasons, I think vendors will eventually have to support them
anyway to
>be "V3 compliant" at some point in the future.
>By the way, I have no SNMP religious affiliation, just a desire
to reuse
>technology. If we find out that our requirements exceed the
>of what SNMPv3 and related technology can deliver, then I would
be just
>as happy to pursue another path. But I think we need to study
this stuff
>a little more before taking any radical direction change.