Thanks so much for your review and comments regarding the
applicability (or not) of the new SNMPv3 async notification
facilities. I particularly liked your summary paragraph:
> As I hope most of you know, I'm dedicated to the use of standards where
> available and applicable. But the SNMPv3 MIBs were never intended to be
> used by many clients. They simply aren't appropriate to the problem of
> trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps.
This comes as no surprise to those of us developing SENSE over
the last two years or so. SNMP was primarily designed for
management network elements, and has never demonstrated the
power required in larger, non-management applications, such
as generic client-side features of network printing.
That is precisely why we went off and did SENSE, to create
a more scalable, more generic system for async notifications.
Simply hacking onto existing (or future) SNMP facilities
never seemed to make the grade. And now your analysis seems
to verify that original assumption.
Perhaps someday the PWG will come to understand the need
for SENSE...or something just like it, anyway.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
Ira Mcdonald x10962 wrote:
>
> Copies To: ipp@pwg.org
> jmp_pwg.org
>
> Hi folks, Sunday (15 March 1998)
>
> Extracted below (with line numbers) is summary information from the five
> SNMPv3 documents (RFC 2271 to RFC 2275, January 1998).
>
> As Randy Turner has argued, it IS possible to use a small subset (Target
> and Notification MIBs in RFC 2273) of the SNMPv3 MIB modules (there are
> a total of 7 SNMPv3 MIB modules) to achieve a simple (security-free)
> SNMP trap registration mechanism (see the 'snmpNotifyBasicCompliance'
> declaration at line 2773 of RFC 2273).
>
> But, the functionality provided is INFERIOR in important ways to that
> provided by the JAM (Job Async Monitor) MIB that Joe Filion and I posted
> on Wednesday (4 March 1998) or to my informal understanding of the IBM
> method presented by Harry Lewis during last week's PWG monthly meeting
> in Austin, TX.
>
> 1) The JAM MIB and Historic SNMP Party MIB (RFC 1447) support scope
> (traps of 'interest') specified as object identifier subtrees.
> The SNMPv3 Target/Notification MIBs support scope only by short (32
> character) UTF-8 tags, which are NOT standardized by SNMPv3 and (due
> to their length) are NOT amenable to standardization.
>
> 2) The JAM MIB supports automatic trap deregistration specified as
> 'DateAndTime'.
> The SNMPv3 Target/Notification MIBs do NOT support automatic trap
> deregistration at all!
>
> 3) The JAM MIB supports simple integer indices for all 'read-create'
> object groups (written by a remote client).
> The SNMPv3 Target/Notification MIBs support indices ONLY as (32
> character) UTF-8 'SnmpAdminString' values, seriously restricting the
> number of SNMP objects which can be transferred in a single packet.
> Since SNMP runs over UDP (in the Internet suite) and there is no
> 'chunking' for SNMP requests, this limitation is significant!
>
> 4) The JAM MIB supports a 'read-only' lookup table (maintained by the
> SNMP agent on the device) which provides direct lookup from SNMP
> transport domain and transport address to a client (target) trap
> registration entry (to avoid duplicate registrations).
> But, the SNMPv3 Target/Notification MIBs support only brute force
> (ie, read the entire Target table) for this important functionality!
>
> 5) The JAM MIB scales well to a very large number of (end-user) trap
> client (target) registrations.
> But, the SNMPv3 Target/Notification MIBs do not scale well. They
> are intended ONLY for use by network management stations!
>
> 6) Randy has suggested that SNMPv2/SNMPv3 'Inform' requests/responses
> could be used for (questionably) 'reliable' event notification.
> But, 'Inform' is intended by the SNMPv3 developers to be used ONLY
> for reporting up a hierarchy of network management stations!
> Also, 'Inform' is not defined in SNMPv1, so the huge installed base
> of SNMP agents which (almost exclusively) speak SNMPv1 cannot use
> 'Inform'.
>
> 7) Lastly, as SNMP agent toolkits become available from software tool
> vendors, any 'local' use of SNMPv3 Target/Notification MIBs by the
> printer industry vendors will inevitably conflict with the very
> different intent of the SNMPv3 developers. Recall why the Job Mon
> MIB is a PWG standard and NOT an IETF standard!
>
> As I hope most of you know, I'm dedicated to the use of standards where
> available and applicable. But the SNMPv3 MIBs were never intended to be
> used by many clients. They simply aren't appropriate to the problem of
> trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps.
>
> Cheers,
> - Ira McDonald (High North, outside consultant at Xerox)
>
> ------------------------------------------------------------------------
> **** SNMPv3 Documents ****
>
> rfc2271.txt: Architecture for Describing SNMP Management Frameworks
> - 38-44:
> This document describes an architecture for describing SNMP
> Management Frameworks. The architecture is designed to be modular to
> allow the evolution of the SNMP protocol standards over time. The
> major portions of the architecture are an SNMP engine containing a
> Message Processing Subsystem, a Security Subsystem and an Access
> Control Subsystem, and possibly multiple SNMP applications which
> provide specific functional processing of management data.
> - 1913:
> SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN
> - 2420:
> snmpFrameworkMIBCompliance MODULE-COMPLIANCE
>
> rfc2272.txt: Message Processing and Dispatching for SNMP
> - 41-46:
> This document describes the Message Processing and Dispatching for
> SNMP messages within the SNMP architecture [RFC2271]. It defines the
> procedures for dispatching potentially multiple versions of SNMP
> messages to the proper SNMP Message Processing Models, and for
> dispatching PDUs to SNMP applications. This document also describes
> one Message Processing Model - the SNMPv3 Message Processing Model.
> - 810:
> SNMP-MPD-MIB DEFINITIONS ::= BEGIN
> - 936:
> snmpMPDCompliance MODULE-COMPLIANCE
> - 976:
> SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN
>
> rfc2273.txt: SNMPv3 Applications
> - 37-44:
> This memo describes five types of SNMP applications which make use of
> an SNMP engine as described in [RFC2271]. The types of application
> described are Command Generators, Command Responders, Notification
> Originators, Notification Receivers, and Proxy Forwarders.
>
> This memo also defines MIB modules for specifying targets of
> management operations, for notification filtering, and for proxy
> forwarding.
> - 1561:
> SNMP-TARGET-MIB DEFINITIONS ::= BEGIN
> - 2209:
> snmpTargetCommandResponderCompliance MODULE-COMPLIANCE
> - 2305:
> SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN
> - 2773:
> snmpNotifyBasicCompliance MODULE-COMPLIANCE
> - 2881:
> snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE
> - 2894:
> snmpNotifyFullCompliance MODULE-COMPLIANCE
> - 2960:
> SNMP-PROXY-MIB DEFINITIONS ::= BEGIN
> - 3242:
> snmpProxyCompliance MODULE-COMPLIANCE
>
> rfc2274.txt: User-based Security Model (USM) for SNMPv3
> - 37-41:
> This document describes the User-based Security Model (USM) for SNMP
> version 3 for use in the SNMP architecture [RFC2271]. It defines the
> Elements of Procedure for providing SNMP message level security.
> This document also includes a MIB for remotely monitoring/managing
> the configuration parameters for this Security Model.
> - 861:
> USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN
> - 1701:
> SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN
> - 2439:
> usmMIBCompliance MODULE-COMPLIANCE
>
> rfc2275.txt: View-based Access Control Model (VACM) for SNMPv3
> - 38-42:
> This document describes the View-based Access Control Model for use
> in the SNMP architecture [RFC2271]. It defines the Elements of
> Procedure for controlling access to management information. This
> document also includes a MIB for remotely managing the configuration
> parameters for the View-based Access Control Model.
> - 541:
> SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN
> - 1356:
> vacmMIBCompliance MODULE-COMPLIANCE
> ------------------------------------------------------------------------