attachment-0001

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <TITLE>Print MIB 09</TITLE> <META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD> <BODY> <DIV>Ira,</DIV> <DIV> </DIV> <DIV>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.</DIV> <DIV> </DIV> <DIV>    Ron</DIV> <DIV> </DIV> <DIV align=left class=OutlookMessageHeader dir=ltr>-----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 </DIV> 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 </BODY></HTML>