One more time.
Ron
-----Original Message-----
From: Harrington, David [mailto:dbh at enterasys.com]
Sent: Monday, October 29, 2001 5:47 PM
To: Bert Wijnen (E-mail); 'Ron.Bergman at Hitachi-hkis.com'
Subject: Print finisher mib
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 at enterasys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/fin/attachments/20011030/527478d9/attachment-0001.html