Thank you for your inputs on our efforts to develop a Finisher MIB. It is
nice to see some outside of the core developers of this standard actually
look at the document.
My responses are embedded in your original text below.
Ron Bergman
Dataproducts Corp.
On Fri, 12 Jun 1998, Paul Moore wrote:
> Several questions come to mind.
>
> 1. Is this intended as read-only?
>
> The intro suggests that it is for controlling as well. (1.1 Scope). I dont
> see how this can work.
As with most MIBs, it is primarily read-only. However, as in the Printer
MIB, Finisher devices can be enabled or disabled. The MIB also allows
some parameters that the agent may not be able to detect, such as
capacities or media type, to be defined by an SNMP Manager. This is no
more or no less than the control capability in the Printer MIB.
>
> 2. Doesnt the generic 'attributes' section merely punt the standardization
> issue?
>
> SNMP already has methods for passing general attributes around (its called
> OIDs and MIBS). We are now inventing another method. The whole purpose of a
> MIB is to define the attribute set.
The attributes method was developed during our work on the Job MIB as a
means of providing a core set of mandatory objects and allow additional
information to be provided for those exception cases. Since optional
objects are considered *bad* in SNMP, this appeared to be a good
compromise. The attributes method was review quite extensively by SNMP
expert David Perkins with no negative comments. The Job MIB has also been
reviewed by several other ADs and, again, no negative comments.
>
> What this really shows is that MIBs are too chunky and cannot be extended
> easily enough - so the group has ending up defining a way of adding 'TBD'
This is, to a degree, true. But if you look at the positive side, we have
provided a useful enhancement to SNMP. We have significantly reduced the
number of objects typically required to define a configuration.
>
> 3. Why have standard names for punching styles?
>
> Why not just explicitly state the hole sizes, shapes and placement? Are
> these 'well-known' values - where is Latvian9punch and Morrocan21Hole? :-)
You can actually do either. We have tried to define the hole patterns for
the common punch configurations. This means that in most cases the size,
shapes and placements are defined using one enum. For "other" patterns,
the attributes can be used to provide the definitions.
>
> 4. I like the way that it slides gracefully into the printer MIB model.
> (section 3)
Thank you for this comment. The group spent several meetings refining the
model to achieve this result!
>
> 99. (personal peeve) The word 'insure' is used where you mean 'ensure'.
>
Glad you caught this! Little things like this seem to be hard to spot in
a document. This will be corrected ASAP.