If anyone is still interested in the Finisher MIB, here are some comments
received from the IESG. I will put together a response and then update the
document. Any volunteers to review my comments and updated draft before
they are returned to the IETF?
Ron
-----Original Message-----
From: Bergman, Ron
Sent: Monday, June 11, 2001 3:56 PM
To: 'David Harrington'; Wijnen, Bert; Bergman, Ron; harryl at us.ibm.com
Subject: RE: review of finisher mib
David,
Thank you for your comments. The working group will review these and
return a response ASAP.
Ron Bergman
Hitachi Koki Imaging Solutions
-----Original Message-----
From: David Harrington [mailto:dharrington at mediaone.net]
Sent: Monday, June 11, 2001 2:23 PM
To: Wijnen, Bert; rbergma at hitachi-hkis.com; harryl at us.ibm.com
Subject: review of finisher mib
Hi,
I have reviewed the Finisher MIB, based on
draft-ietf-printmib-finisher-10.txt, at Bert's request and had these
comments.
There ar eplaces where SHALL is not used according to the definitions of
RFC2119. I haven't checkes for all the may, should, etc. usages.
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 shoul dbe able
to just change "to which" to "which"
Comb Binding - I think you're missing an "of"
"The agent is free to materialize an attribute..." - the verb
materialize is not how most people would phrase this. Most would say
create.
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 woul dbe more
accurate to say that "SNMP requires that if an abject cannot be
accessed, then..." It is possible that the specfic 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.
I found it difficult to review this mib, and I expect implemnters will
find it difficult as well, because the textual conventions are defined
else where in the doccument. In some cases I think there was only one
use of the TC.
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.
The Copyright statement appears to have suffered a cut&paste error.
Now the MIB:
The LAST-UPDATED field apperas to be very out of date.
MODULE-IDENTITY has no REVISION clauses.
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.
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.
There is a typo where finDevice is defined. lines 1640-1647 are
duplicated.
finDeviceEntry is defined as "... an entry for ... each ... process"
Whay not call it finProcessTable rather than finDeviceTable?
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.
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.
In the development of SNMPv2, we discovered that using integer indexes
made it difficult for users to comprehend the information inherent in
those indexes.
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"?
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?
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?
If an agent cannot sense the value, the value is unknown. Must the agent
implement this as read-write?
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 chnaged to an unrestricted parameter
value, as compared to having simply been set to a value in the first
place?
MediaPaths and AssociatedOutputs - Here is a place where a TC is called
for and not used.
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?
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?
ColorName, MediaType - why not use an enumeration rather than using an
octet string with a description that enumerates the possible values?
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?
The GROUP description for finSupplyMediaInputGroup could be more
concise. "This group is mandatory if a finisher device ..."
Hope this helps,
dbh
---
David Harrington Nework Management Standards Architect
dbh at enterasys.com Office of the CTO
Enterasys Networks