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
about.
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.
Randy
-----Original Message-----
From: imcdonal@eso.mc.xerox.com
[SMTP: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
Notificiations
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>'.
Cheers,
- 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
right
>solution?
>
>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
many
end-user clients registered for notifications. But, the SNMPv1
suite
is QUITE appropriate (and ubiquitously deployed) for basic
monitoring
(and sometimes active management) of networked systems and
devices.
>I will try and address the concerns outlined below, with
matching
>numbers.
>
>1) Scopes of interest are still supported by OID subtree
>specifications; it's the intended notification recipients that
are
>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
attributes)
are specified in the Notification MIB. OID subtrees are in the
SNMPv3
View-based Access Control Model MIB (RFC 2275), but ONLY with
additional
support of the user ('principal') security identifications
accomplished
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
they
STILL aren't designed for fine-grained control (like individual
traps,
which are ONLY intended to be controlled via the Notification
MIB).
>2) Registration lifetimes would be a good idea. It's quite
possible
>for an IPP MIB to augment the notification table with objects
that
>represent registration lifetimes. No need to throw the baby out
with the
>bath water on this one. Since it is an explicit augmentation,
the
>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
>GET, or GET-BULK.
IEM> There is much confusion about 'not-accessible' indices. In
ALL
versions of SNMP (and OSI CMIP), the so-called 'variable
bindings'
are lists of full MIB object OIDs with SUFFIXED 'instance
qualifiers',
which are the VALUES of all the indices (so non-integer indices
greatly
reduce the efficiency of SNMP protocol exchanges).
>4) I'm not sure if a brute force search would be required or
not
>(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
of
>"transport" and "transport-address" matching. This particular
scenario
>would require more study.
IEM> In ALL versions of SNMP trap registration, duplicate
registrations
are determined solely on the basis of 'transport domain' and
'transport
address' matching (all the way back to the Historic SNMPv1 Party
MIB,
RFC 1353). Because SNMPv3 is too heavyweight for a given
low-level
device to have many registered 'notification targets', the brute
force
search doesn't matter much, but for the printer industry
scenarios of
(potentially) hundreds of registered trap clients, the results
would
be catastrophic.
>5) This rationale does not exist for SNMPv3. This held true
only
>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
generically
>identify "notification senders" and "notification recipients".
The idea
>of specific functionality being reserved for a "mid-level"
manager
>entity no longer exists. Implementors are free to instrument
whatever
>feature they need, depending upon the type of management (or
managed)
>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
device
to (potentially) hundreds of registered clients would fail
utterly
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
is
>possible. Also, V3 informs are as reliable as any other
notification
>mechanism.
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
their
>"intent" was never to disallow the type of functionality I have
>proposed. Rather, it seems like a prudent reuse of all vendors'
existing
>agent code base.
IEM> The new PDUs for SNMPv2 were first published five years ago
(1993).
Nonetheless, almost ALL installed products speak SNMPv1 ONLY. A
small
minority support SNMPv1/SNMPv2 'hybrid agents'. Many of those
became
obsolete when the original SNMPv2 specifications (RFC 144x
series) were
abandoned and replaced with the (incompatible) current SNMPv2
specs
(RFC 190x series) in January 1996. Many of the 'big names' in
open
management stations STILL only support SNMPv1 protocol. Quite a
few
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
control
centers just to get at (newly incompatible) SNMPv3-based
printers!
>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
being
>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
JAM MIB,
>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
should
>come up with a suitable set of additional (non-overlapping)
notification
>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
boundaries
>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.
>
>Randy
>----------------------------------------------------------------------<