IPP Mail Archive: RE: IPP> Re: Comments on the SNMP Notifica

IPP Mail Archive: RE: IPP> Re: Comments on the SNMP Notifica

RE: IPP> Re: Comments on the SNMP Notifications Document

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Thu Mar 09 2000 - 16:03:46 EST

  • Next message: Ron Bergman: "Re: IPP> Revised I-D for SLP 'printer:' template"

    Hi Ron,

    I just read through all of this. Good comments.
    I'm kind of burned out at the moment (from flu
    and too many hours editing) so it may be next
    week before I reply.

    Many thanks for your careful reading.

    Cheers,
    - Ira

    -----Original Message-----
    From: Ron Bergman [mailto:rbergma@hitachi-hkis.com]
    Sent: Thursday, March 09, 2000 9:06 AM
    To: McDonald, Ira
    Cc: ipp@pwg.org; 'jmp@pwg.org'
    Subject: IPP> Re: Comments on the SNMP Notifications Document

    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 - 16:11:45 EST