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