Subject: FIN> On reading the FIn draft

From: Paul Moore <[email-masked]>
Date: Fri, 12 Jun 1998 14:33:54 -0700

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.

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.

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'

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? :-)

4. I like the way that it slides gracefully into the printer MIB model.
(section 3)

99. (personal peeve) The word 'insure' is used where you mean 'ensure'.

---

From: Ron Bergman <[email-masked]>
Date: Tue, 16 Jun 1998 08:35:25 -0700 (Pacific Daylight Time)

Paul,

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.

> The intro suggests that it is for controlling as well. (1.1 Scope). I dont

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.

> 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.  

> 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.

> 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.

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.