FIN Mail Archive: RE: FIN> On reading the FIn draft

RE: FIN> On reading the FIn draft

Paul Moore (paulmo@microsoft.com)
Tue, 16 Jun 1998 09:45:53 -0700

> -----Original Message-----
> From: Ron Bergman [SMTP:rbergma@dpc.com]
> Sent: Tuesday, June 16, 1998 8:35 AM
> To: Paul Moore
> Cc: 'fin@pwg.org'
> Subject: Re: FIN> On reading the FIn draft
>
> 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.
>
>
> 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.
[Paul Moore] I am saying that you are defining an extension to
SNMP (a way of adding extra MIB entries without reving the MIB). This is
perfectly valid but should not be in a MIB, it should be in some SNMP v4 or
SNMP extensions document. The purpose of a MIB is to define the set of
attributes associated with an entity - you have defined a way of defining
the set of attributes associated with an entity. Specifically I cannot read
the FIN MIB document and see the set of supported attributes (cf RFC1759). I
will have to find another document. This is a significant change.
> >
> > 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.
[Paul Moore] You did not answer the question. Why is it useful to
use punch style names? Who is the benificary? What is the intent? There
seems to be a LOT in the MIB (implict attributes, many tables, ..) just to
support this. I dont see the point. If its valuable why dont we have named
sets of other things (paper trays for example). Paper types are different,
they are 'well-known' to end users

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