Hi Ron, Thursday (8 November 2001)
Below are my responses to Dave Harrington's comments preceded by 'ira:'.
Separately, we should review and disposition all the errors and warnings
in the extensive 'smilint' comments on Finisher MIB that I posted
Monday - this will take a little while.
Cheers,
- Ira McDonald
imcdonald@crt.xerox.com
906-494-2434 (work until later this week)
608-257-0466 (home/work in Madison, WI next week)
------------------------------------------------------------------------
Subject: Response to Comments on the Finisher MIB
Date: Wed, 31 Oct 2001 17:23:14 -0800
From: "Bergman, Ron" <Ron.Bergman@Hitachi-hkis.com>
To: "Ira McDonald (E-mail)" <imcdonald@sharplabs.com>,"Ray Casterline
(E-mail)" <rcasterline@crt.xerox.com>
CC: "Don Wright (E-mail)" <don@lexmark.com>,"Harry Lewis
(E-mail)"<harryl@us.ibm.com>
There are some serious problems here (at least according to David) and
our answers need to careful crafted. This represents a rather anemic
start. Please review carefully!
Ron
<original message>...
From: Harrington, David [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
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 6 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.
** I propose that paragraph 2 in section 5.2 be removed. Due to the
** paragraph that was added immediately after, this paragraph is not
** extremely important.
** Here is the offending text:
SNMP requires that if an object cannot be accessed, then a compliant
agent SHALL return an SNMP error in SNMPv1 or an exception value in
SNMPv2. However, this MIB has been designed so that 'all' objects
can be implemented by an agent, and for read only operations neither
the SNMPv1 error nor the SNMPv2 exception value will be generated by
the agent. This MIB has also been designed so that when an agent
materializes an attribute, the agent will materialize a row
consisting of both the finDeviceAttributeValueAsInteger and
finDeviceAttributeValueAsOctets objects.
ira: Agree - let's delete the offending paragraph above.
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 only 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.
WG.. We agree. A much better way is for the manager to delete the
device configuration and reload. This is not that difficult of a task.
ira: I don't think I agree with your response, Ron. I think Dave is
complaining that relying on the 'prtGeneralConfigChanges' counter alone
forces a read of the entire configuration - particularly if the
management application is NOT the one responsible for setting the
printer configuration, but is inquiring about changes by some OTHER
management application. Dave's right in my opinion.
But the answer has always been in Printer MIB v1 and Printer MIB v2.
The device simply adds a row to the 'prtAlertTable' as follows:
prtAlertSeverityLevel = warning(3)
prtAlertTrainingLevel = noInterventionRequired(7)
prtAlertGroup = <table that changed>
prtAlertGroupIndex = <low-order index of changed row>
prtAlertLocation = <not applicable>
prtAlertCode = configurationChange(7)
prtAlertDescription = <description of change>
prtAlertTime = sysUpTime <time of event>
Then the 'printerV2Alert' trap avoids any brute force read. Right?
And this mechanism works just fine for the Finisher MIB tables as well.
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?
WG.. You are correct, our answer missed the point. The enum other(-1)
is used for objects that normally return a numeric value for those
situations where a numeric response is not applicable. For example, a
printer that uses roll paper would return other(-1) for the maximum
length paper it can handle in the feed direction. In most cases, for
most products, the other(-1) enum will not be used. It is available for
use only in those rare exceptions.
ira: Agree with Ron's response.
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 - 11:39:48 EST