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 Oct 30 2001 - 12:37:01 EST

  • Next message: McDonald, Ira: "PMP> FW: Linted MIB index, by date"

    Hi Ron,

    Groan - OK - I'll gladly look over your replies list.

    Thanks for all your patience and good work, shepherding this Printer MIB v2
    to publication as an RFC. With luck it will come out before we all retire.

    Cheers,
    - Ira McDonald, consulting architect at Xerox
      High North Inc

    -----Original Message-----
    From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
    Sent: Monday, October 29, 2001 6:57 PM
    To: Ira McDonald (E-mail)
    Cc: 'pmp@pwg.org'
    Subject: PMP> FW: Print MIB 09

    Ira,
     
    More comments (sigh) on the Printer MIB. Some of these look the same as
    previous. I will generate a response, as before, and send it to the list
    for comments before a reply to the ADs.
     
        Ron
     
    -----Original Message-----
    From: Harrington, David [mailto: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.
    My copy of -07- is truncated at prtChannelInformation, so I've reviewed
    everything beyond that point afresh.
    1) line 2644 "with" should be "which"
    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.
    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.
    4) prtInterpreterIndex - could this be tightened up so the values are
    guaranteed to be persistent across reboots?
    5) prtInterpreterFeedAddressability and other objects have no defined
    ranges.
    6) prtInterpreterDefaultCharSetIn and prtInterpreterDefaultCharSetOut -
    define 2 as the DEFVAL?
    7) prtConsoleLightTable has an empty description.
    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?
    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.
    10) prtAlertTable has an empty description
    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.
    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
    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.
    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!!!!
    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.
    16) prtAlertTime - Given the issues I raised with the alert table, making
    the AlertTime optional seems silly.
    17) printerV1Alert - Bert, you worked on the coexistence rules. Is this the
    way traps should be handled in mibs?
    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.
    my $.02
    dbh
    David Harrington
    Director, Network Management Architecture
    Enterasys Networks, Inc.
    dbh@enterasys.com



    This archive was generated by hypermail 2b29 : Tue Oct 30 2001 - 12:37:26 EST