IPP> RE: Comments on the SNMP Notifications Document

IPP> RE: Comments on the SNMP Notifications Document

McDonald, Ira imcdonald at sharplabs.com
Tue Mar 7 17:58:17 EST 2000


Hi Ron,

My replies are below, prefixed by '> (ira)'.

It would appear that I won't have the time after some
future concensus to put out a revised I-D before the
10 March deadline (especially if I have to add all your
proposed objects - see below).

[These comments all address my latest IPP Notifications
over SNMP - which defines two traps to add to the PWG
Job Monitoring MIB and a few objects for bindings].

In ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ see

<draft-ietf-ipp-not-over-snmp-01.txt> (1 December 1999)

Cheers,
- Ira


-----Original Message-----
From: Ron Bergman [mailto:rbergma at hitachi-hkis.com]
Sent: Wednesday, March 01, 2000 6:36 PM
To: Ira McDonald
Cc: ipp at pwg.org
Subject: Comments on the SNMP Notifications Document


Ira,

At last here are my comments.  I hope this starts a good discussion.

1. Job MIB Event Group, jmEventPrinterState:  This object syntax is
defined as OCTET STRING, but is should match the syntax of the IPP
attribute "printer-state", which is an enumeration.  The enums
values also should be aligned with "printer-state" (i.e. idle(3),
processing(4), stopped(5) ).

> (ira)
> I changed this to a string (keyword) in the most recent draft
> to decouple from IPP.  When we generalize 'printer-state' to
> 'device-state', the three IPP states may NOT be appropriate
> or complete.

2. Job MIB Event Group: The value of the objects in this group can have
many values, unique to each notification and subscdription.  In
order for these objects to be properly identified, this group should
be a table with multiple indexes.  Some of the indexes necessary
would be (more may be necessary):

- jmGeneralJobSetIndex
- jmJobIndex
- jmEventIndex (new, must be defined)
- jmEventSubscriptionID

However, I don't see any need for direct access to any these
objects.  The only need for this group is to define the OIDs for use
by the SNMP notification.  Within the context of the notification,
these is no need to provide a unique OID to each instance of an
object.
A better solution would be to change the MAX-ACCESS clause from
"read-only" to "not-accessible".  Since this would be a somewhat
unusual application of an SNMP object group, a short explanation
needs to be added.

> (ira)
> TRAPs may NOT include objects that are 'not-accessible', only
> 'read-only' or higher (or the incompatible 'accessible-for-notify'
> in RFC 2578, which obsoletes RFC 1902 - it's irrational to
> use 'accessible-for-notify' in a MIB definition - it can't
> be translated to SMIv1 or classic SMIv2).
>
> I had separate objects in the last draft for each binding (without
> indexing), but removed them as redundant with the existing MIB.
> TRAPs are permitted to have optional bindings in SNMPv1/v2/v3.
> Therefore, we don't need to enumerate the bindings in OBJECTS
> clause of NOTIFICATION-TYPE macro.
> 

3. Section 3.1: "jmEventEventPrinterState" should be
"jmEventPrinterState".

> (ira)
> Noted - thanks

4. The notification contains 5 objects to define printer status
(hrDeviceStatus, hrPrinterStatus, hrPrinterDetectedErrorState,
jmEventPrinterState, and jmEventPrinterStateReasons).  This seems
like a large number of objects just to indicate what is wrong with
the printer.  The 2 objects hrDeviceStatus and hrPrinterStatus add
very little value and I strongly recommend their removal.
hrPrinterDetectedErrorState could be considered of marginal value,
due to the presence of jmEventPrinterStateReasons, but would provide
easier machine processing capability.  Certainly jmEventPrinterState
and jmEventPrinterStateReasons are sufficient for human use.

> (ira)
> The idea was that the notification would kill two birds.
> 1) Deliver IPP notifications for printers.
> 2) Let existing Printer MIB implementations emit 'reports'
> and 'warnings' and non-critical 'errors' via traps.
> Therefore, the 'hrxxx' objects - I'm willing to remove them
> and remove the coupling with HR MIB their presence causes
> for the (presently decoupled) Job Mon MIB.

5. The mapping of printer-uri to prtChannelInformation does not seem
appropriate.  I also question the need for both the printer name and
the printer URI in the notification.  We sometimes go overboard and
I am surprised that the printer location, manufacturer, model,
serial number, and date of manufacture are not also included;-).

> (ira)

6. The representation of an attribute in a notification presents
another unique problem.  The OID of an attribute cannot be
determined without first processing the entire attribute table in
the Job Monitoring MIB within the device.  Even after this
processing, it cannot be guaranteed that the OIDs will be stable.
To resolve this issue it would be best to include additional entries
in the Job MIB Event group for each attribute that is needed in the
notification.  Thus, 10 new objects would need to be added.

> (ira)
> See my comments at your point (2) above.
> I was trying not to define redundant objects.  I'm happy to
> add these trap binding objects BACK into the MIB, but then
> I have to define several traps, because of the different
> (per IPP Notifications spec) bindings of various job events.
> - Messy - not very extensible.
>
> I also believe it's *critical* to have a keyword string
> state-reasons (like IPP) to allow vendor private extensions
> which are not possible with the current Job Mon MIB bit-wise
> encoding of state-reasons.  This is a major ask from
> my Sharp implementor community.

jmEventJobName for "jmAttributeValue...jobName.1"
jmEventJobStateReasons2 for ...
jmEventJobStateReasons3 for ...
jmEventJobStateReasons4 for ...
jmEventSheetsCompleted for ...
jmEventJobCollationType for ...
jmEventSheetCompletedCopyNumber for ...
jmEventSheetCompletedDocumentNumber for ...
jmEventImpressionsInterpreted for ...
jmEventImpressionsCompletedCurrentCopy for ...

   jmEventJobName OBJECT-TYPE
       SYNTAX    OCTET STRING (SIZE (0..255))
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The human readable string name of the job assigned by the
           submitting user to allow the user to distinguish this job
           among others submitted by the same user.  The name may be
           truncated, if necessary, to fit into the SNMP datagram.
           This value is equivalent to the Job MIB Attribute jobName
           that is associated with the job.

           See:    Section 7 'Notification Content' in [IPP-NOT]."
       ::= { jmEvent 8 }

   jmEventJobStateReasons2 OBJECT-TYPE
       SYNTAX    JmJobStateReasons2TC
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Provides addition information concerning the state of the
           job, in addition to or instead of the information presented
           in jmJobStateReasons1, jmEventJobStateReasons3 or
           jmEventJobStateReasons4.  The value of this object
           corresponds to the value of the Job MIB Attribute
           jobStateReasons2 that is associated with the job.

           See:    Section 7 'Notification Content' in [IPP-NOT]."
       ::= { jmEvent 9 }

   jmEventJobStateReasons3 OBJECT-TYPE
       SYNTAX    JmJobStateReasons3TC
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Provides addition information concerning the state of the
           job, in addition to or instead of the information presented
           in jmJobStateReasons1, jmEventJobStateReasons2 or
           jmEventJobStateReasons4.  The value of this object
           corresponds to the value of the Job MIB Attribute
           jobStateReasons3 that is associated with the job.

           See:    Section 7 'Notification Content' in [IPP-NOT]."
       ::= { jmEvent 10 }

   jmEventJobStateReasons4 OBJECT-TYPE
       SYNTAX    JmJobStateReasons4TC
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Provides addition information concerning the state of the
           job, in addition to or instead of the information presented
           in jmJobStateReasons1, jmEventJobStateReasons2 or
           jmEventJobStateReasons3.  The value of this object
           corresponds to the value of the Job MIB Attribute
           jobStateReasons4 that is associated with the job.

           See:    Section 7 'Notification Content' in [IPP-NOT]."
       ::= { jmEvent 11 }

   jmEventSheetsCompleted OBJECT-TYPE
       SYNTAX    Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Defines the total number of media sheets that have
           completed marking and stacking for this job.  This value is
           equivalent to the Job MIB Attribute sheetsCompleted that
           is associated with the job.

           See:    Section 7 'Notification Content' in [IPP-NOT]."
       ::= { jmEvent 12 }

   jmEventJobCollationType OBJECT-TYPE
       SYNTAX    JmJobCollationTypeTC
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Specifies the type of collation used for this job.  This
           value is equivalent to the Job MIB Attribute
           jobCollationType that is associated with the job.

           See:    Section 7 'Notification Content' in [IPP-NOT]."
       ::= { jmEvent 13 }

   jmEventSheetCompletedCopyNumber OBJECT-TYPE
       SYNTAX    Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of the copy being stacked for the current copy
           document in this job.  This value is equivalent to the Job
           MIB Attribute sheetCompletedCopyNumber that is associated
           with the job.

           See:    Section 7 'Notification Content' in [IPP-NOT]."
       ::= { jmEvent 14 }

   jmEventSheetCompletedDocumentNumber OBJECT-TYPE
       SYNTAX    Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Defines the ordinal number of the document in the job that
           is currently being stacked.  This value is equivalent to the
           Job MIB Attribute sheetCompletedDocumentNumber that is
           associated with the job.

           See:    Section 7 'Notification Content' in [IPP-NOT]."
       ::= { jmEvent 15 }

   jmEventImpressionsInterpreted OBJECT-TYPE
       SYNTAX    Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Defines the current number of impressions completed for the
           job .  This value is equivalent to the Job MIB Attribute
           impressionsInterpreted that is associated with the job.

           See:    Section 7 'Notification Content' in [IPP-NOT]."
       ::= { jmEvent 16 }

   jmEventImpressionsCompletedCurrentCopy OBJECT-TYPE
       SYNTAX    Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Defines the current number of impressions completed for the
           current copy of the current document .  This value is
           equivalent to the Job MIB Attribute
           impressionsCompletedCurrentCopy that is associated with the
           job.

           See:    Section 7 'Notification Content' in [IPP-NOT]."
       ::= { jmEvent 17 }

7. Scheme Name: I was going to propose "snmpnotify", but if "snmp" can
be used, it is better yet!

> (ira)
> Lost my mind - 'snmp:' would indicate an SNMP Agent (command
> receiver) entity.
> We need to define 'snmpnotify:' (notification receiver) for
> the SNMP Manager entity that gets notified.

8. You had proposed including three optional parameters in the scheme
URL.  (version, pdu-type, and community-name)  We also need an IPP
attribute so that the printer can be queried to determine which
scheme parameters are supported.  (if we are not careful here we
will have another "3 musketeers" situation)  For discussion
purposes, I propose the following:

   attribute name:  snmp-notifications-supported

   attribute values:  snmpV1Trap, snmpV2cTrap, snmpV2cInform,
snmpV2uTrap, snmpV2uInform, snmpV3cTrap, snmpV3cInform, snmpV3uTrap,
and snmpV3uInform.

> (ira)
> I'm worried about the possible number of optional URL parameters.
> This needs more thought.
> I'd also like to observe that some of your SNMP flavors (above
> and below) are marked Historic or Obsolete by the IETF.  In particular,
> SNMPv3c (community) doesn't exist according to the IETF.
> And I don't much like encouraging people to use Inform (acknowledged
> event) because end-nodes (printers) are NEVER supposed to generate
> an Inform (it's reserved for the use of middle-tier management
> stations 'rolling up' event summaries to their superiors).

   There is a potential problem with SNMPv3, in that the PDU can be
encoded by any one of multiple methods, and I totally ignored
SNMPv2u security in a v3 packet.  But having each variant
combination a separate value prevents illegal combinations.

I hate to ask, but any comments?


    Ron Bergman
    Hitachi Koki Imaging Solutions, Inc.






More information about the Ipp mailing list