David,
Here is the response from the Working Group to your comments on
the Finisher MIB.
I would like to thank you for your review of this document. The
majority of your comments did result in a change and the WG agrees
these changes are valuable improvements.
The responses follow the comments and are preceded by "**". I also
added issue numbers for easier reference. The revised MIB is now
available at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-printmib-finishing-11.txt
Ron Bergman
------------------------------------------------------------------------
I have reviewed the Finisher MIB, based on
draft-ietf-printmib-finisher-10.txt, at Bert's request and had these
comments.
ISSUE 1:
There are places where SHALL is not used according to the definitions of
RFC2119. I haven't checked for all the may, should, etc. usages.
************
** The document has been reviewed and in several instances the case has
** been changed to lower. In all remaining, the meaning is per RFC2119.
ISSUE 2:
This sentence has too many 'to's
"Defined by DPA as the axis to which some finishing processes are
applied to or referenced from by the Head Mechanism." You should be able
to just change "to which" to "which"
************
** The text has been revised as suggested.
ISSUE 3:
Comb Binding - I think you're missing an "of"
************
** Yes, it is changed to ".. along the binding edge of the sheets."
ISSUE 4:
"The agent is free to materialize an attribute..." - the verb
materialize is not how most people would phrase this. Most would say
create.
************
** This has been changed as suggested.
ISSUE 5:
Section 5.2 is non-standard SNMP. "SNMP requires that if an object
cannot be implemented because its values cannot be accessed, then a
compliant agent SHALL return an SNMP error in SNMPv1 or an exception
value in SNMPv2." I believe this is not quite accurate. It would be more
accurate to say that "SNMP requires that if an object cannot be
accessed, then..."
************
** The text has been deleted as suggested.
ISSUE 6:
. . . It is possible that the specific objects are not
accessible in the administratively assigned view for a user for security
reasons. So, there are times when one of the "not accessible" error
codes/exceptions would be appropriate, despite your attempt to design
the mib to not have those circumstances.
************
** Text has been added to explain this situation. The second paragraph
** of section 5.2 was modified and a new paragraph follows.
ISSUE 7:
I found it difficult to review this mib, and I expect implementers will
find it difficult as well, because the textual conventions are defined
else where in the document. In some cases I think there was only one
use of the TC.
************
** (no change) The PrintMIB Working Group has found, through experience
** with the Printer MIB, that TC's are very useful. Most printer
** vendors have developed Private MIBs and the use of the TCs allows
** the Private MIBs to import enumerations from the standard MIBs.
** It may appear that we have gone "overboard" here, but the usage
** of TCs was carefully analyzed during the MIB development.
ISSUE 8:
In the security Considerations, it says "...that vendors are free to
implement these objects as READ-ONLY." I suggest changing "these" to
"certain" to reduce ambiguity.
************
** Yes, we made this change and the added explanation for issue #6
** will also help.
ISSUE 9:
The Copyright statement appears to have suffered a cut&paste error.
************
** The year has been changed to 2001 (guess I am still living in the
** past;-)
ISSUE 10:
Now the MIB:
The LAST-UPDATED field appears to be very out of date.
************
** Has been corrected.
ISSUE 11:
MODULE-IDENTITY has no REVISION clauses.
************
** This clause has been added.
ISSUE 12:
The RFC editor apparently missed your note about the OID assignment. I
believe the correct approach if that you should contact the RFC editor,
get the assignment, and do the update yourself.
************
** This has been corrected. The value is "{ experimental 115 }".
ISSUE 13:
mib-2 is imported but not used.
A number of TCs are defined but not used: FinEdgeTC, FinStitchingTypeTC,
StitchingDirTypeTC, StitchingAngleTypeTC, FinFoldingTypeTC,
FinBindingTypeTC, FinPunchHoleTypeTC, FinPunchPatternTypeTC,
FinSlittingTypeTC, FinWrappingTypeTC, FinStackOutputTypeTC.
************
** The reference to MIB-2 will be removed. The remaining TCs are used
** in the attributes section. These TCs are required to create clients
** and develop agents that support finisher devices. Several of the
** working group members are building device specific SNMP based
** utilities that make use of these TCs.
ISSUE 14:
There is a typo where finDevice is defined. lines 1640-1647 are
duplicated.
************
** Strange, this does not appear in my original? Don't know what
** happened. Could be an email problem?
ISSUE 15:
finDeviceEntry is defined as "... an entry for ... each ... process"
Whay not call it finProcessTable rather than finDeviceTable?
************
** We are equating each "device" with a "process". Thus the table
** defines both the device and the function (process) performed.
** A sentence has been added to the description to clarify.
ISSUE 16:
finDeviceIndex, and other indexes, are meant to be persistent across
reboots ... usually. Is there any object that an NMS can query to
determine that the data was not persist on the last reboot? That would
be much easier than having to compare all the data in the tables over
and over looking for a possible discontinuity. Can the agent help with
some sort of discontinuity marker, such as a simple object that provides
a persistent count of the objects in a table based on the previous
reboot.
************
** There is a parameter in the Printer MIB (prtGeneralConfigChanges)
** which provides this information. In general, these changes seldom
** occur. We agree that it is not very efficient for a manager to
** have to compare all the data.
ISSUE 17:
You have tables that can be created by manager applications. You do not
use any of the normal best current practices for this, such as RowStatus
or TestAndIncrement from rfc2579.
************
** There was no intention by the working group to allow table entries
** to be created by a management app. The Attribute table is the
** only table that could be dynamic on a given device, but it can
** be changed only by the agent. (It is not anticipated that there
** will be many products where this table will even be dynamic.)
ISSUE 18:
In the development of SNMPv2, we discovered that using integer indexes
made it difficult for users to comprehend the information inherent in
those indexes.
************
** We can certainly understand your point and can imagine situations
** where non-integer indexes are useful. However, our experience with
** integer values in the Printer MIB and Finisher MIB have been positive.
ISSUE 19:
A number of objects use the <value=known><-2=unknown><-1=other>.
First, known/unknown is a binary state indicator; under what
circumstances does "other" make sense? "I don't know if I don't know"?
"I know but I'm not telling"?
************
** Other was included to be used if the state/condition is known but
** doesn't fall into any of the defined enums. This is allows
** implementers to have a value to use until a standard enum can be
** assigned. This is standard practice in the Printer MIB.
ISSUE 20:
Some objects are read-only if they know the answer; read-write if they
don't. How does an NMS know which it is? Try to change it?
************
** This depends upon the object. For example, finSupplyCurrentLevel
** will indicate unknown (-2) if the device is unable to sense the
** presence of the supply. For a NMS to set this value would require
** a way to monitor the level of this supply. Since the device is
** unable to perform this function it very unlikely that an automated
** way would be implemented to provide this information.
** But for the object finSupplyMaxCapacity this is a static value
** and does not require monitoring. The device may not know the
** value if there are optional configurations that cannot be detected
** by the device. In this case, the value can be set using the NMS
** during installation of the device.
ISSUE 21:
If a value is non-negative, that implies the agent can sense the value.
What if a manager reads <unknown> and then sets a value. What does a
second application conclude?
************
** The second application must assume the value returned is valid. This
** is definitely a security issue and implementers must be cognizant of
** this fact.
ISSUE 22:
If an agent cannot sense the value, the value is unknown. Must the agent
implement this as read-write?
************
** No. A read-write implementation is optional.
ISSUE 23:
xxxCurrentCapacity et al - "(-1) means other and specifically indicates
that the device places no restrictions on this parameter" What is an NMS
supposed to do with this? The parameter has a value of (-1); isn't that
a restriction on that parameter? Can I change this parameter to a value,
with no restrictions on the value I choose? How does an NMS know that is
used to be a (-1) but now it's been changed to an unrestricted parameter
value, as compared to having simply been set to a value in the first
place?
************
** Good question. This value is seldom used, but is available if the
** device believes it is appropriate. As an example a chad box for a
** punch unit may not have a full sensor. It is expected to be emptied
** at regular maintenance intervals but if this procedure is skipped,
** the chads simply fall onto the floor. To the device there is no
** limit to the capacity of this container.
ISSUE 24:
MediaPaths and AssociatedOutputs - Here is a place where a TC is called
for and not used.
************
** When this MIB was developed, this is how this syntax was handled in
** the HR MIB for hrPrinterDetectedErrorState.
ISSUE 25:
There are a number of places where an OCTET STRING is used, with the
"localization specified by XXX" - UTF8 is the preferred mechanism for
localization of strings in mibs, usually using an SnmpAdminString.. Is
there a reason why these objects don't use these?
************
** The WG has agreed to make a change identical to the latest draft of
** the Printer MIB. We are importing LocalizedDescriptionStringTC from
** the Printer MIB and it is now the syntax for finDeviceDescription,
** finSupplyDescription, and finSupplyMediaInputDescription.
ISSUE 26:
xxxCurrentLevel - (-3) means there is some supply or remaining space.
What is an NMS supposed to do with this? It assume the reason why this
object exists is becuase an application shouldn't send a job that it
knows would consume 10 units if there are less than 10 units available.
There is a way to specify <unknown>, so why do we need another value
that says "there's some, but I don't know how much"? Why not just use
<unknown>? How is (-3) useful?
************
** This is conformant with the Printer MIB. It indicates the device
** can detect a full or empty condition but cannot determine any
** intermediate levels. Unknown indicates that an error will never
** be reported. A small difference which can be useful.
ISSUE 27:
ColorName, MediaType - why not use an enumeration rather than using an
octet string with a description that enumerates the possible values?
************
** These objects use an identical syntax and values to very similar
** objects in the Printer MIB, IPP (RFC 2910 and 2911), and ISO DPA
** (ISO 10175). Especially since this is an extension of the Printer
** MIB, the WG believes it is best to maintain compatibility with
** these standards.
ISSUE 28:
InstanceIndex describes the value if only one is present, but it doesn't
describe subsequent values for this object. Must the numbers be assigned
sequentially? Is it expected that the InstanceIndexes be contiguous? or
can they be assigned randomly? Attributes can be created dynamically;
Can they also be deleted dynamically? If so, how will that impact the
contiguity of the InstanceIndexes?
************
** These values are expected to be contiguous and the description
** has been revised to include this requirement.
ISSUE 29:
The GROUP description for finSupplyMediaInputGroup could be more
concise. "This group is mandatory if a finisher device ..."
************
** We have revised this description.
Hope this helps,
dbh
---
David Harrington Nework Management Standards Architect
dbh at enterasys.com Office of the CTO
Enterasys Networks