David,
The response from the WG to your comments follows. Again, we appreciate
your efforts in reviewing this document.
We also did an smiLint check on this document and with the exception of
three names longer than 32 characters, it passed. We do not intend to
make any changes to reduce the length of the names.
For the PrintMIB Working Group
Ron Bergman
Hitachi Koki Imaging Solutions
Our responses below are preceded by "WG.."
<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 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.
WG.. The WG has reviewed section 5.2 and has decided that paragraph 2 be
removed. There is significant overlap and some conflicts with the
paragraph that was added immediately after.
Here is the text that we will remove:
"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."
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.
WG.. A configuration will also generate a change in the Printer Alert table.
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. This
mechanism works for the Finisher MIB and Printer 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.
my $.02
dbh
David Harrington
Director, Network Management Architecture
Enterasys Networks, Inc.
dbh@enterasys.com
This archive was generated by hypermail 2b29 : Fri Nov 09 2001 - 12:45:10 EST