Hi Ron,
Looks fine to me - ship it.
By the way, I did NOT see any reply from David to the Printer MIB
changes (but my old email address at Sharp proved to be in the
note).
Eek - I just noticed that in the Printer MIB v2 latest draft, my
email address is still at Sharp and not at Xerox - please correct
this in the next draft!
Cheers,
- Ira McDonald, consulting architect at Xerox
High North Inc
imcdonald at crt.xerox.com
-----Original Message-----
From: Bergman, Ron [mailto:Ron.Bergman at Hitachi-hkis.com]
Sent: Thursday, November 08, 2001 8:37 PM
To: 'McDonald, Ira'; Bergman, Ron; Casterline, Ray; 'harryl at us.ibm.com'
Cc: 'fin at pwg.org'
Subject: RE: FIN> FW: Print finisher mib
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