PMP Mail Archive: RE: PMP> FW: Print MIB 09

PMP Mail Archive: RE: PMP> FW: Print MIB 09

RE: PMP> FW: Print MIB 09

From: McDonald, Ira (IMcDonald@crt.xerox.com)
Date: Tue Nov 06 2001 - 14:27:20 EST

  • Next message: Bergman, Ron: "RE: PMP> FW: Print MIB 09"

    Hi Ron, Tuesday (6 November 2001)

    Below are my responses to Dave Harrington's comments preceded by 'ira:'.

    Separately, we should review and disposition all the errors and warnings
    in the extensive 'smilint' comments on Printer MIB v2 that I posted
    yesterday - this will take a little while.

    There's an Internet-Drafts blackout in two weeks, due to the IETF
    plenary in December, so we should be realistic about making that
    deadline or just proceeding as fast as we can with edits.

    Cheers,
    - Ira McDonald
      imcdonald@crt.xerox.com
      906-494-2434 (work until later this week)
      608-257-0466 (home/work in Madison, WI next week)

    ------------------------------------------------------------------------

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

    Our responses below are preceded by "WG.."

    <original message>...

    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.

    0) 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.

    ira: (We could ask Harry Lewis if IBM could bear to have most of the
    'private' TCs made back into simple objects? - it would in fact not hurt
    Xerox - because we already had private equivalent TCs for all of them)

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

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

    *** I cannot locate this !!! HELP???

    ira: (I can't find it either - in the '.txt' or in the 'mstrip'
    extracted '.mib' file - we need some more context or a quote to find
    Dave's reference)

    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 very explicit 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.

    ira: Agree - suggest changing your second line above to:

       object. Pages 116 and 117 define machine-parseable details

    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.

    ira: we should correct the weak wording in all six affected
         table index objects ...
            prtLocalizationIndex
            prtOutputIndex
            prtMarkerColorantIndex
            prtMediaPathIndex
            prtInterpreterIndex
            prtConsoleDisplayBufferIndex

         for example, current description of 'prtInterpreterIndex':
            "A unique value for each PDL or control language for which there
            exists an interpreter or emulator in the printer. The value is
            used to identify this interpreter. Although these values may
            change due to a major reconfiguration of the device (e.g. the
            addition of new interpreters to the printer), values are
            expected to remain stable across successive printer power
            cycles."

         should change the last lines to:
            addition of new interpreters to the printer), values SHOULD
            remain stable across successive printer power cycles."

       
    5) prtInterpreterFeedAddressability and other objects have no defined
    ranges.

    WG.. Do ranges make sense here?

    ira: All integer MIB objects must have ranges, per SMIv2 (RFC 2578).
         Regression loss - Gary Gocek discovered before with a MIB compiler.
         My apologies Ron - the following edits will take a while
         (I deskchecked the entire MIB - the following list is accurate).

         We revise ALL of the many deficient objects which currently say:
            SYNTAX Integer32 -- with no range specified

         change
            SYNTAX Integer32 (0..2147483647)
         for the following two objects:
            prtConsoleOnTime
            prtConsoleOffTime

         or
            SYNTAX Integer32 (2..2147483647)
         for the following one object:
            prtMarkerColorantTonality

         or
            SYNTAX Integer32 (-1..2147483647)
         for the following one object:
            prtAlertGroupIndex

         or
            SYNTAX Integer32 (-3..2147483647)
         for the following four objects:
            prtInputCurrentLevel
            prtInputNextIndex
            prtOutputRemainingCapacity
            prtMarkerSuppliesLevel

         or
            SYNTAX Integer32 (-1..65535)
         for the following two objects:
            prtInputDefaultIndex
            prtOutputDefaultIndex

         or
            SYNTAX Integer32 (0..65535)
         for the following two objects:
            prtChannelCurrentJobCntlLangIndex
            prtChannelDefaultPageDescLangIndex

         or change all other affected objects (most) to:
            SYNTAX Integer32 (-2..2147483647)

    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.. ?

    ira: I suggest that I work with Ron and Ray Casterline to write
         better DESCRIPTION clauses for some/all of 'xxxEntry' objects.
         This will take a while.

    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.

    ira: Out of our hands - we really cannot start adding more objects to
         Printer MIB v2 five years after the first implementations.

    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.

    ira: Out of our hands - 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.

    ira: (See point (0) above - how about collapsing all/most of the
         single-use TCs back into the objects themselves, unless they
         appear in the IMPORT section of Finisher MIB??)

    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.. ?

    ira: Agree - we should 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.

    ira: 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.

    ira: (Agree - this is Steve Waldbusser's work in RFC 1759).

    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.

    ira: (Ron - see section 10 'References' of SNMPv3 Arch (RFC 2571),
         which Dave Harrington wrote, for what he wants as 'normal')

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



    This archive was generated by hypermail 2b29 : Tue Nov 06 2001 - 14:27:34 EST