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@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) ).
> (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.
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 18:06:37 EST