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 at enterasys.com]
Sent: Monday, October 29, 2001 3:32 PM
To: Bert Wijnen (E-mail); 'Ron.Bergman at 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 at enterasys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/pmp/attachments/20011029/09417e59/attachment-0001.html