PMP Mail Archive: PMP> RE: Print MIB 09

PMP Mail Archive: PMP> RE: Print MIB 09

PMP> RE: Print MIB 09

From: Bergman, Ron (Ron.Bergman@Hitachi-hkis.com)
Date: Thu Nov 08 2001 - 17:41:25 EST

  • Next message: Harry Lewis: "PMP> Re: Print MIB 09"

    David,

    The Working Group has carefully reviewed your comments and is sending
    the following response. Unfortunately, some of your comments are
    issues relating to the original Printer MIB (RFC 1759) and changes
    cannot be made that affect interoperability.

    In addition, we located Bill Fenner's smiLint index and found some
    additional items that we plan to correct in the next draft. smiLint
    found four issues:
    1) Empty description clauses (which you already pointed out)
    2) Use of INTEGER instead of Integer32 in PrtSubUnitStatusTC
    3) Object, type, and enumeration strings longer than 32 characters
    4) Notification object error (prtAlertIndex is not-accessible)

    The first two we will correct. The third issue, since it is legal
    with all modern compilers and many printer vendors have been shipping
    the MIB for several years, will not be changed.

    The fourth issue is more complicated but we have decided to change
    this object to read-only so that users do not have to edit the MIB
    to obtain an error-free compile. This issue was also noted by
    Juergen Schoenwaelder in his review dated June 7, 2001. At that
    time the WG felt that we should maintain compatibility with RFC 1759.
    The group now believes that it would be better to have an error
    free compile. Your comments on this subject would be appreciated.

    I hope you can review these comments quickly so that we only need
    to do one more revision of the document. This MIB has been in the
    queue for about five years (most of this time was due to the HR MIB
    update) and the WG is becoming very impatient. Many vendors have
    been shipping the MIB for several years and would like to be able
    to reference a "standards" document.

    We do appreciate the time and effort that you have expended in
    the review of this document.

            For the PrintMIB Working Group,
            Ron Bergman
            Hitachi Koki Imaging Solutions

    Our responses below are preceded by "WG.."

    <original message>...

    From: Harrington, David [dbh@enterasys.com]
    Sent: Monday, October 29, 2001 3:32 PM
    To: Bert Wijnen (E-mail); 'Ron.Bergman@Hitachi-hkis.com'
    Subject: Print MIB 09

    Hi,

    comments on printmib 09

    I didn't run this through a compiler to check syntax.

    The overuse of TCs makes it way more difficult to work with this mib than it
    needs to be. The single-use TCs should be eliminated.

    WG.. The addition of the TCs was a decision by the Working Group
       to allow these values to be imported into other MIBs. The
       Finisher MIB presently uses some of these TCs and most others
       are used in private MIBs.

    My copy of -07- is truncated at prtChannelInformation, so I've reviewed
    everything beyond that point afresh.

    1) line 2644 "with" should be "which"

    WG.. Several members of the WG have attempted to locate this occurrence.
       Could you provide more details regarding its position in the document?

    2) prtChannelInformation concerns me. It is a constructed octet string. This
    type of constructed string is an invitation to vendors to use it to pass
    proprietary information, which somewhat defeats the goal of standardization.

    WG.. We have actually defined very specific formats for this
       object. Pages 116 and 117 provide machine-parseable details
       regarding the encoding rules for this object. Also, the
       PrtChannelTypeTC (pages 36 to 45) provides specific rules
       for this object far each channel type.

    3) prtInterpreterTable has an empty description clause. The description is
    contained in comments instead. I believe it is considered appropriate to put
    the description in the description clause. Some tools strip the comments
    away, and the mib becomes much less useful if the descriptions are in the
    comments. An example would be a management application that imports
    description clauses and generates help screens from them. Machine parsing
    won't recognize that the comments contain the description.

    WG.. This will be corrected in the next draft.

    4) prtInterpreterIndex - could this be tightened up so the values are
    guaranteed to be persistent across reboots?

    WG.. This description is identical to RFC 1759. The exact reason
       for this wording has been lost in time but it basically allows
       a major upgrade to the functionality of the printer, either
       through a firmware or a hardware upgrade, which essentially
       creates a new printer. In practice this seldom occurs. However,
       we have agreed to change the text to: "... values SHOULD remain
       stable across successive printer power cycles."
       This change will be made for prtLocalizationIndex, prtOutputIndex,
       prtMarkerColorantIndex, prtMediaPathIndex, prtInterpreterIndex,
       and prtConsoleDisplayBufferIndex.

    5) prtInterpreterFeedAddressability and other objects have no defined
    ranges.

    WG.. The Working Group agrees to add ranges to all objects with a
       SYNTAX of integer32.

    6) prtInterpreterDefaultCharSetIn and prtInterpreterDefaultCharSetOut -
    define 2 as the DEFVAL?

    WG.. The DEFVAL clause will be added and the text modified. The
       CodedCharSet (TC) will also be modified to add "unknown(2)".

    7) prtConsoleLightTable has an empty description.

    WG.. This will be corrected in the next draft.

    8) prtConsoleOnTime/OffTime - this may be a standard practice in printers.
    It seems to me that it might be simpler to have one object for on/off and
    another for blink rate, rather than requiring that both of these objects be
    retrieved to determine that the light is off or on. Couldn't this be done
    with an enumeration on/off/blinking plus a blink rate? Why are these
    read-write? Do you anticipate an external application adjusting the blink
    rate of a light, or turning the lights on/off? If an external application
    was to read the values, how would they be used? Are these values likely to
    change faster than network latency allows the values to be retrieved? Are
    blink rates likely to vary for a given light?

    WG.. This model is from RFC 1759 and must be maintained for
       compatabilty. We agree that the model is clumsy. The objects
       are read-write to allow a remote application to either enable
       or disable the lamps. In almost all implementations these are
       read-only objects. Some implementations may use blinking vs
       continuous on to indicate if the problem is critical or non-
       critical. In this case, the remote app could look for this
       state to determine the criticality of the condition. Although
       this information more likely obtained from the alert table. In
       all known implementations, the blinking rates do not vary.

    9) Comments that "Implementation of every object in this group is
    mandatory." may not be a good idea because the compliance clauses may change
    at some point, and it might be ambiguous which took precedence. Using the
    compliance clauses should eliminate the need to include such comments.

    WG.. All statements that define if the group is mandatory or
       optional will be removed in the next draft. The compliance
       clauses will provide the only definition.

    10) prtAlertTable has an empty description

    WG.. This will be corrected in the next draft.

    11) various table entry definitions do not describe the entry, but only that
    a row may exist for each device of type printer. It would generally be
    better to include meaningful information in the descriptions, such as row
    persistence or what a row represents. This can be helpful in the future as
    objects get added or deprecated to ensure that the meaning of the row isn't
    changed inadvertently.

    WG.. We will provide better DESCRIPTION clauses for some/all of 'xxxEntry'
       objects.

    12) I have concerns about the prtAlertTable. There are ways to help the
    application avoid re-reading the entire table after a change. RMON uses a
    timefilter; other tables use various mechanisms to record the number of
    deletes done, or the last time the table was changed, and so on. This table
    could benefit from some of these techniques

    WG.. The objects prtGeneralConfigurationChanges,
       prtAlertCriticalEvents, and prtAlertAllEvents provide a global
       view of the table. Also, hrDeviceStatus, hrPrinterStatus, and
       hrPrinterDetectedErrorState are used by a management app to
       determine if a problem exits that require examination of the
       table. This structure was defined during the development of
       RFC 1759 by Steve Walsbusser and our other advisors. These objects
       and the Alert Table are presently incorporated in thousands of
       printers installed throughout the world. The WG cannot consider
       any changes in this area.

    13) The reliability of information from the prtAlerttable concerns me. The
    resetting index could make it easy to overlook that a reset occurred, and to
    ignore the current #1 in favor of the #1 I already retreived before an
    undetected reset. It might be more appropriate to use a non-resetting
    (persistent across reboots) TestAndIncrement to generate the indexes here,
    or to use an RMON timefilter in the index.

    WG.. This is very implementation dependent. On low cost printers
       it can be very expensive to add non-volatile memory to support
       this requirement. Most high end printers do have the necessary
       memory and do not reset the index during a reboot. Note that
       the alert table architecture is from RFC 1759 and must be
       maintained to achieve interoperability. Again, we cannot start
       revising syntax or adding objects to the 'prtAlertTable' - it has
       been shipping in printers for six years.

    14) prtAlertTrainingLevel - There is still the style problem of over-using
    TCs. It makes it very difficult to really understand the syntax of an object
    when you have to go elsewhere to lookup a TC to see what the syntax is. Use
    of TCs is very appropriate when the same behavior is repeated for multiple
    objects, and you want to define the convention only once. But when only one
    object in the mib is defined using that convention, it is better to define
    the syntax in the object itself. Just to review the document, I kept two
    computers displaying the document, one to keep track of where I was in the
    review, and another to keep jumping around in the document looking up TCs.
    This was mentioned in the original reviews by both me and Bert. It is bad
    practice!!!!

    WG.. We agree. When the enums were moved to TCs this issue was
       considered. Only those enums were moved that were to be used
       in the Finisher MIB or were requested for Private MIBs.

    15) prtAlertGroupIndex - "An index of the row within the principle table in
    the
            group identified by prtAlertGroup that represents the sub-unit
            of the printer that caused this alert." - huh??? What's a principle
    table? Again the overuse of TCs also made this difficult because you
    couldn't see what the possible enumerations were for the values that would
    have made it clearer. When the pointers get complex, it is imperative that
    the text be clear and easy to read, not buried away in some distant TCs.

    WG.. Agreed - we will change the first lines of the DESCRIPTION to:
       "The low-order index of the row within the table identified
       by prtAlertGroup that represents the sub-unit of the
       printer that caused this alert, or (-1) if not applicable."

    16) prtAlertTime - Given the issues I raised with the alert table, making
    the AlertTime optional seems silly.

    WG.. This also is identical to RFC 1759 and must maintained for
       compatibility. Jurgen Schoenwaelder specifically requested that we
       correct this object to the original (RFC 1759) OPTIONAL, because
       to change it (as we had done earlier) was an illegal change to a
       published MODULE-COMPLIANCE macro with an assigned OID.

    17) printerV1Alert - Bert, you worked on the coexistence rules. Is this the
    way traps should be handled in mibs?

    WG.. This section was provided to the group by Steve Waldbusser.

    18) The references section is rather different than normal. I'd prefer to
    see it following the normal formats, and I'd like to see the "unused"
    entries removed.

    WG.. This section will be edited and the "unused" entries removed. We will
    also
       add the required references from the MIB boiler plate.

    my $.02
    dbh

    David Harrington
    Director, Network Management Architecture
    Enterasys Networks, Inc.
    dbh@enterasys.com



    This archive was generated by hypermail 2b29 : Thu Nov 08 2001 - 17:33:24 EST