Subject: RE: FIN> On reading the FIN draft

From: Paul Moore <[email-masked]>
Date: Thu, 18 Jun 1998 11:45:18 -0700

I DO have the concern that we need to resolve the issues arounf SNMP vs IPP.

My main comment about attributes was saying that you have done a level shift
in the document. Most MIBS say - 'here is the set of attributes for object
set XXX'. FIN has said 'here are some of the attributes for finishers, plus
here is a way of adding other attributes that we havent thought about yet'.
You have defined a generic extensibiity mechanism - this is more properly
done in the core SNMP document set - not in an individual MIB. 

I expected to read in the FIN MIB the definition of ALL attributes for
finishers - they are not there (So where are they?). Compare this to 1759.

> -----Original Message-----
> From:	Harry Lewis [SMTP:[email-masked]]
> Sent:	Thursday, June 18, 1998 10:52 AM
> To:	[email-masked]
> Cc:	Paul Moore
> Subject:	RE: FIN> On reading the FIN draft
> 
> Ron - I got a bit behind... sorry I haven't jumped in... but your
> responses to
> Paul's concerns are excellent. Thanks. I too am glad that Paul has taken
> time
> to review our work.
> 
> Paul has been a big advocate of SDP so he may be wishing we could hold up
> FIN
> until the PWG gets a more serious bead on SDP. We, of course, feel we have
> run
> the gamut and are wanting to close down and call the FIN MIB complete.
> 
> I am also starting to see the great benefit a (modern) standard SDP would
> have
> so I share BOTH goals. I think we've had quite a bit of finisher expertise
> (especially Carlos from HP) helping define the FIN MIB and I'm comfortable
> that
> what we have is good. I sympathize with the discomfort someone feels when
> they
> first see the "attribute" based approach, but I can assure Paul, our Job
> MIB
> implementation is working flawlessly (well... we all like to exaggerate
> ;-) and
> developers had no problem with it. I guess Paul's point may be more of...
> "this
> ain't your grandfather's SNMP". Well, maybe not, but I don't think it is
> toxic
> or anything... If the comment is intended to help point out the benefit of
> focusing on a bona-fide SDP rather than "tricks with SNMP"... like I
> said...
> I'm beginning to convert.
> 
> I don't think there is any reason to deter our efforts to complete the FIN
> MIB,
> however. Actually, the FIN MIB probably has a better chance of being
> widely
> adopted than does the Job MIB, at this point. I think the set of
> attributes we
> have should form the basis for a robust SDP Finisher section. SDP will
> want to
> consider all the attributes in IPP, Printer MIB and FIN MIB (I hope) as it
> develops.
> 
> Harry Lewis - IBM Printing Systems
> 
> 
> ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 06/18/98
> 09:45 AM
>  ---------------------------
> 
> 
> [email-masked] on 06/18/98 09:40:18 AM
> Please respond to [email-masked]
> To: [email-masked]
> cc: [email-masked]
> Subject: RE: FIN> On reading the FIN draft
> 
> 
> Paul,
> 
> More responses below.
> 
> 
>  Ron Bergman
>  Dataproducts Corp.
> 
> 
> On Tue, 16 Jun 1998, Paul Moore wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: Ron Bergman [SMTP:[email-masked]]
> > > Sent: Tuesday, June 16, 1998 8:35 AM
> > > To: Paul Moore
> > > Cc: [email-masked]'
> > > 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.
> > >
> >
> 
> 
> 
>

---

From: Harry Lewis <[email-masked]>
Date: Thu, 18 Jun 1998 16:48:37 -0400

Jay - I'm not quite sure what we're talking about here. Generally, I agree
wholeheartedly with what you are saying. For Notifications, it is clear that
the PWG has shown a desire to investigate existing or emerging standards as the
basis for a solution. Originally, Paul Moore had commented on the robust use of
attributes in the FIN MIB... a scheme we adopted in development of the JOB MIB
to reduce the number of OIDs and avoid an approach which had proven less than
useful with the Printer MIB (Mandatory/Optional). No-one core to the Job MIB
team and no-one having prototyped and/or implemented the Job MIB seems to have
any issues. Admittedly, someone reviewing this for the first time (as Paul was
in the FIN MIB) may wonder. I was only trying to help Paul at least understand
the CONTEXT... even if he decides to persist in his disagreement with the
method.

[email-masked] on 06/18/98 02:42:15 PM
Please respond to [email-masked]
To: [email-masked], [email-masked], Harry Lewis/Boulder/IBM@ibmus
cc:
Subject: Re: FIN> On reading the FIN draft

Harry,

> With regard to trap registration... I agree. I think, if you've been following
> the Notifications discussions in the PWG (which I'm sure YOU have ;-), you'll
> find proposals to define PWG specific registration schemes "rejected" on the
> basis that SNMPv3 supplies most of what we need. As for "things we did with
the
> Job MIB"... remember, it was the IETF who turned their backs on us... this is
> strictly a PWG standard.

With all due respect, the fact that the Job MIB is not under
the domain of the IETF has nothing to do with the concept of
developing standard techniques in an open arena.

I personally struggled with this concept while developing
the SENSE technology.  I knew all along that a system
of inexpensive, light-weight, scalable event notification
was of emminent utility around the world, across almost
every type of distributed application.

Hence, I was (and remain) quite shy about having the PWG
declare its own notification system without regard for
the needs of others.  This is but one reason I put the
brakes on the SENSE project--to wait and see if other
proposals would emerge in a reasonable time frame.
(I am now monitoring the WebDAV's ENP effort quite closely.)

Just because the IETF declined to embrace the Job MIB
shouldn't mean we have license to institute any kind
of related technology we find interesting or useful.

Give unto Caesar what is Caesar's, and all that rot...  ;-)

Please do understand, though, that I wholeheartedly
encourage members of the PWG to band together and
form a new IETF WG to address any IETF-related technology
opportunity as a separate group.

 ...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------