Subject: IPP> SNMPv3 unsuited for IPP/JMP Notifications

From: [email-masked] (Ira Mcdonald x10962)
Date: Sun, 15 Mar 1998 16:35:07 PST

Copies To:  [email-masked]
            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
------------------------------------------------------------------------

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 17 Mar 1998 10:23:01 -0800

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.

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

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

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

	Copies To:  [email-masked]
	            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,

	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.

	  management operations, for notification filtering, and for
proxy

	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