Subject: FIN> Comments on FIN MIB draft

From: "Caruso, Angelo " <[email-masked]>
Date: Mon, 23 Feb 1998 07:53:55 PST

Since I won't be in Austin, here are my comments on the latest finisher
mib draft, dated 19 February 1998.

Pages 6-7:
It is not very clear how these attributes are to be used. For example,
stitchingType(3), an INTEGER, provides additional information regarding
the stitching operation. What sort of additional information is being
provided, and how exactly will it be encoded as an integer???

Pages 10-11:
In the textual conventions section, several of the textual conventions
have been repeated (i.e. FinStitchingTypeTC, FinBindingTypeTC, and
FinSlittingTypeTC). I assume this is a simple cut and paste error.

Pages 14-15:
The optional Extended Finisher Device Group should be defined as a NEW
table that AUGMENTS the Finisher Device Group table. The printer MIB is
the only MIB I know of that defines subsets of an ENTRY sequence as
optional. This is incorrect MIB design, and we should not repeat this
error this just because it was done in the printer MIB.

Page 15-16 & 18-19:
The indexing schema for finisher supplies is different than that used
for marker supplies in the printer MIB. This results in tables with 3
and 4 indices! In the printer MIB, the marker supplies and marker
colorant tables contained a reference index to the corresponding marker
subunit, and therefore, those tables only needed two indices. Do we
really want a table with four indices here???

And, for that matter, the Finisher Supply Media Input Group, from what I
can tell, is more or less an exact copy of the Printer Input Group. Why
can't we use the input group from the printer MIB for finishers too? A
simple cross reference table (AUGMENTing the Input table, for example)
could be used to associate rows in the printer input table with specific
finisher subunits. Another approach would be to state that finishers
must always use a different hrDeviceIndex than printers. Then, it would
be obvious which rows in the input table are associated with the
finisher based on hrDeviceIndex.

Pages 21-23:
Same comments as Pages14-15, there are two more optional groups defined
here. These should be defined as NEW tables that AUGMENT the Finisher
Supply Media Input Group table.

Thanks,
Angelo

---

From: Ron Bergman <[email-masked]>
Date: Tue, 24 Feb 1998 08:26:53 -0800 (Pacific Standard Time)

Angelo,

Thank you for reviewing the Finisher MIB draft.  Your comments will
certainly help to improve this document.  

I have attached some additional comments and explaination with your text.

	Ron Bergman
	Dataproducts Corp.

> provided, and how exactly will it be encoded as an integer???
The idea here is to provide attributes, instead of unique objects, for
information that is unique for a finisher device.  This is the method used
in the Job MIB to minimize the number of objects.

For your example, see FinStitchingTypeTC for the information provided.
Also, see the Attribute Table for the objects that are encoded with this
information.

The Attributes section still needs a significant amount of work.  Anyone
that wouls like to make a contribution here, please do!

> FinSlittingTypeTC). I assume this is a simple cut and paste error.
Thank you for catching this!  I was interrupted in this middle of revising  
this section and really botched this up.  Not only are the 3 TCs repeated,
but I did not add 4 TCs discussed in Maui.  The 4 are FinFoldingTypeTC,
FinWrappingTypeTC, FinPunchHoleTypeTC, and FinPunchPatternTypeTC.  I will
update this prior to the meeting next week.

> error this just because it was done in the printer MIB.
This was patterned after the Printer MIB, since it is intended that the
Finisher MIB be combined into the Printer MIB, someday.  I was not aware
that this is incorrect MIB design.  So, should we match the format of the
Printer MIB and, if the documents are eventually integrated, they are
uniform?  Or, do we follow your proposed structure?  What about SNMPv1
compatibility with Augmenting?

I will add this as an issue and request comments.

> really want a table with four indices here???
This is a good point.  I will include this change unless there is an
objection.

> finisher based on hrDeviceIndex.
This is another good item for discussion!  By making a unique table it is
obvious that these inputs are not used by the marking subunit.  

But I do not believe that hrDeviceIndex is a good differentiator.  Our
model describes the finisher subunits as a part of the printer and
thus the same hrDeviceIndex applies.

I will add this as an issue.  Does anyone have a good suggestion as how
this can be implemented?