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