Hi Ron,
This will take some time to digest...
I'm about to be buried in four different telecons
for the rest of today, but hopefully tomorrow.
We have guests this weekend, so otherwise next
week.
One quick. In previous drafts I had separate
objects for each of those attributes from the
jmAttributeTable that you proposed below. Harry
Lewis and others pointed out that was dumb, because
they are already defined in the MIB.
Of course, the difficulty (I begin to see why
the IESG doesn't like the Job Mon MIB) is that
ASN.1 doesn't let you name an INSTANCE of an
object (base OID plus index values called
'instance qualifiers'). That's why all the
attributes from Job Mon MIB as included in the
trap definition only by comments in the DESCRIPTION
clause of the NOTIFICATION-TYPE macro.
You know, I lost my mind yesterday. You're right
that the scheme should be 'snmpnotify' or some
such, because 'snmp' would name an Agent (managed
device) and not a Manager (client system).
Cheers,
- Ira
-----Original Message-----
From: Ron Bergman [mailto:rbergma@hitachi-hkis.com]
Sent: Wednesday, March 01, 2000 6:36 PM
To: Ira McDonald
Cc: ipp@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) ).
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.
3. Section 3.1: "jmEventEventPrinterState" should be
"jmEventPrinterState".
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.
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;-).
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.
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!
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.
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.
This archive was generated by hypermail 2b29 : Thu Mar 02 2000 - 12:43:46 EST