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 finisher mib</TITLE> <META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD> <BODY> <DIV>One more time.</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 5:47 PM To: Bert Wijnen (E-mail); 'Ron.Bergman@Hitachi-hkis.com' Subject: Print finisher mib </DIV> Hi, comments on finisher mib 12 Issue 6: The second paragraph of 5.2 is still incorrect. For security reasons, not implementation reasons, it is possible that, **due to administrative configuration**, not all objetcs will be accessible. SNMP requires certain error codes or exception codes be returned. One cannot design the mib to avoid this. The behavior as described will be non-compliant to SNMP rules. Issue 4 still exists in section 5.2. The security section discusses making objects read-only to make them secure. This may or may not be adequate. This can prevent them from being modifed, but it doesn't prevent disclosure of the information to unauthorized personnel. Making the object read-only also makes them far less useful, since nobody can modify these objects using SNMP to modify the operational characteristics of the device. This really defeats the purpose. Issue 16: The prtGeneralConfigChanges identifies when the finDevice table changes? I don't really think so. The values of read-write entries can be modified, but the onl;y way an application can determine which rows have changed is to compare every entry in the table looking for changes. This is horrible for management applications. Issue 19: I think you missed the point here. You have two enums that are binary opposites - known and unknown. What is there that is other, that is is not known or unknown? my $.02 dbh David Harrington Director, Network Management Architecture Enterasys Networks, Inc. dbh@enterasys.com </BODY></HTML>