Reference: In ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ see
<draft-ietf-ipp-not-over-snmp-01.txt> (1 December 1999)
Ira,
My comments are prefixed by '* (ron)'.
I have deleted items 3 and 7, since I believe they are resolved.
1. Job MIB Event Group, jmEventPrinterState: This object syntax is
defined as OCTET STRING, but it 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.
* (ron)
* There are advantages to maintaining commonality with IPP. (I also
* prefer enums over strings for SNMP.) We certainly also need to keep
* 'device-state' aligned with 'printer-state', if and when this
* attribute is created.
2. Job MIB Event Group: The value of the objects in this group can have
many values, unique to each notification and subscription. 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.
* (ron)
* My error! I forgot about the recent issue with the Printer MIB
* alert table index in the trap! So I sadly accept 'read-only',
* but a statement needs to be added such as:
* "These objects are provided for identification of values that
* are returned in a printer event or job event notification only.
* Indexing is not defined for these objects to properly define
* the context of the value outside of the applicable notification.
* It is not recommended that an SNMP Manager perform a Get to any
* of these objects. The value returned by an SNMP Agent, to a
* Set, is implementation dependent as to its validity."
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.
* (ron)
* Although this is certainly a noble goal, I would prefer a simpler
* notification rather than be 'all things to all people.'
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)
* (ron)
* Did your comment get lost?
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.
* (ron)
* This really a messy issue! I am not sure how an attribute
* could be uniquely defined in a trap (inform) without an OID
* assignment as proposed. Also, why does this method prevent
* additional var-binds from being appended to the trap?
*
* I agree that keyword strings are more flexible for the job
* state reasons. (I missed this one!) Remove the three OIDs
* that I added for job state reasons below. This leaves only
* seven new objects. Better yet!
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 }
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).
* (ron)
* I didn't research the status of the values above, so some of them
* can possibly be removed. I was just trying to present the concept.
*
* Your comment on informs catches me by surprise. First we had
* discussed the use of informs in early discussions. (snmpnotify
* was proposed in place of snmptrap as the scheme name to allow
* informs?) Second, I did read in the SNMPv2 document (not sure
* which) of their use as you state. However, in some early Job
* MIB meetings on adding traps, Randy Turner pointed out that the
* newer SNMP documents removed that restriction on informs. (I
* do not know which document he was referring to, nor have I
* personally seen any text to this regard.) Informs do provide
* additional delivery reliability in those exceptional situations
* where this is desired. So it seems good to be able to support.
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.
All for now. I expect you will ignore this until the IDs for
the Adelaide meeting are completed.
Ron
This archive was generated by hypermail 2b29 : Thu Mar 09 2000 - 12:04:08 EST