More responses below.
Ron Bergman
Dataproducts Corp.
On Tue, 16 Jun 1998, Paul Moore wrote:
>
>
> > -----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.
Attributes are in reality enums. I would say "special purpose" enums, but
then all enums are "special purpose". SNMP is constantly using enums in
new ways to present the desired information. Many SNMP aware individuals
have examined the attributes as implemented in the Job MIB and no other
negative comments have been voiced.
I don't understand why you believe that a new version of SNMP would be
required to allow attributes. In what way does the use of attributes
break SNMP?
Regarding your comment that you "..cannot read the FIN MIB document and
see the set of supported attributes..", is this in reference to the
Textual Conventions that are imported? If so these are found in the
latest Printer MIB draft (update to RFC1759). Importing of TC's is common
SNMP practice and, I agree, does make it difficult to read the document.
You cannot do it without your entire SNMP library at hand.
> > >
> > > 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
>
Actually we have tried to define all finishing operations. Folding,
stapling, binding, slitting, and wrapping all have a set of enums to
define more detail regarding the possible configurations. It just so
happens that punching is significantly more complex to define. We could
have taken the simple approach and just said "punch-2-hole", but it was
agreed that the additional information would be useful.
> > >
> > > 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.
> >
>