Subject: Re: FIN> On reading the FIN draft

From: Harry Lewis <[email-masked]>
Date: Fri, 19 Jun 1998 11:27:07 -0400

Criticism can be healthy... and your points of view are valid, although I must
say I wish they had been more timely. There ARE other points of view which were
obviously factored into the design.

>However, it is inappropriate behavior on the part of a standards body
>to choose such a course, to go charging off into wild new territory,
>without first at least clearly recognizing the problems that it entails
>and clearly considering the alternatives. I don't think I ever saw that
>done here.

I'll spare the counter-criticism... rather, I'd like to seek a show of hands
how many people are aware of customers using generic web browsers to
effectively manage print, printers or printer extensions (finishers). Please
take a look (ESPECIALLY with the Job MIB) at the types of objects we are
managing!

>I lacked the time and energy to raise the issue myself here.

Welcome to the club. Precisely why rehashing seems like a tiresome setback.
Let's see... haven't we gone through this with IPP recently?

>Of course it is rather late to be raising this issue in connection with the
>FIN or the JOB MIBs.  This issue was timely for those a year and two ago.

Thank You!

>But the point is still well taken.

OK. So what are you suggesting? What is the real issue NOW? I would like to see
this discussion move to a more productive stage as opposed to a
critical/defensive one. I'm hearing "We're gone too far with "SNMP"... So
what's the antidote? Do we back up to a flat FIN MIB with sets of mandatory and
optional attributes (this was ugly when we tried it!). Are we saying that some
of our problems are just to complex to address with SNMP and the solution space
should move to the SDP arena?  Do we just need a FIN MIB FAQ to help with the
understanding? I'm open to suggestions and eager to find a direction with more
consensus.

Please remember that there are significant numbers of PWG members who think the
FIN MIB is fine... and worked quite hard to get it there. Please don't
underestimate the effort and dedication even though the working group received
less fame than (say) IPP.  Also note that any solution... SDP or whatever... is
VERY likely to result in SIMILAR complexity... after all the problems will be
the same... we just won't be able to look back and say... "well, THAT's not
SNMP!"

Harry Lewis - IBM Printing Systems

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

I would like to echo Jay's statement, that Paul Moore has made an excellent
point, and respond to Ron's question, "In what way does the use of
attributes break SNMP?"

The complaint is not that "the use of attributes breaks SNMP."  The
complaint is that the use of attributes like this is really not SNMP.  As
Paul M. says, SNMP has a clear, central model for representing
objects/attributes and values thereof, and this attributes table approach
does not follow the SNMP model.  Instead, it uses SNMP as a mere framework
or platform on top of which to build a significantly different attributes
and values representational model.  And it does this without benefit of
appropriate documentation or standards or infrastructure or technical
support or tooling or diagnostics or any of the zillion things that are
normally expected when a new standard data representational model is
established.  (Does anybody have a MIB browser that will do a useful job of
browsing attributes tables?  I'd be very surprised - albeit pleasantly so.)

It is conceivable that this attributes-table poor solution (poor because
unsupported, as above) is the best available under the circumstances, that
all the other available choices are worse.  However, it is inappropriate
behavior on the part of a standards body to choose such a course, to go
charging off into wild new territory, without first at least clearly
recognizing the problems that it entails and clearly considering the
alternatives.  I don't think I ever saw that done here.  I lacked the time
and energy to raise the issue myself here.  Paul M. is now raising it.

Of course it is rather late to be raising this issue in connection with the
FIN or the JOB MIBs.  This issue was timely for those a year and two ago.
But the point is still well taken.

/Paul Gloger

---

From: Jay Martin <[email-masked]>
Date: Fri, 19 Jun 1998 12:37:26 -0400

Harry,

If nothing else, this thread serves as useful information
to be used as a rough design guideline for future efforts,
that's all.

I don't think anyone is jumping up and down to get the
FIN MIB substantially changed at this point.  (Although
Paul Moore might be... ;)

One other thing.  Please don't say that concerns weren't
raised about this generic topic before, because they were.
The designers of the Job MIB simply decided to ignore it,
that's all.

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