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