Ira,
I have attached my response to David exactly as I intend to send. Looks
like no changes will be required. The only potential change is the
formating of the references section. This could be handled with the RFC
editor. But this section does not look as bad as in the Printer MIB.
Notice that he did reply very quickly and favorably to the Printer MIB
changes. Now we have to get a new draft out. I will try to get this
updated by early next week. I hope that you and Ray can then review. Would
like to get an I-D out by the week of Nov 19.
Ron
-----Original Message-----
From: McDonald, Ira [mailto:IMcDonald at crt.xerox.com]
Sent: Thursday, November 08, 2001 8:40 AM
To: 'Bergman, Ron'; McDonald, Ira; Casterline, Ray; 'harryl at us.ibm.com'
Cc: 'fin at pwg.org'
Subject: RE: FIN> FW: Print finisher mib
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 at 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 at Hitachi-hkis.com>
To: "Ira McDonald (E-mail)" <imcdonald at sharplabs.com>,"Ray Casterline
(E-mail)" <rcasterline at crt.xerox.com>
CC: "Don Wright (E-mail)" <don at lexmark.com>,"Harry Lewis
(E-mail)"<harryl at 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 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 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 at enterasys.com
-------------- next part --------------
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 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.
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 at enterasys.com