Subject: RE: FIN> On reading the FIN draft

From: Harry Lewis <[email-masked]>
Date: Thu, 18 Jun 1998 15:23:26 -0400

Paul, don't forget that the IETF showed no interest in the Job MIB, this
allowed us to develop technology more well suited to our industry. We took
advantage of this position, but maintained close contact and review with SNMP
standards experts. The FIN MIB continues this approach even though it actually
augments RFC1759.

Harry Lewis - IBM Printing Systems

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

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

---

From: Jay Martin <[email-masked]>
Date: Thu, 18 Jun 1998 15:33:32 -0400

Notwithstanding, Paul has made an excellent point,
one that should be addressed without concern for
the Job MIB's position in the IETF food chain.

I tend to agree with Paul.  I have similar concerns
regarding the PWG's attempt to define standard ways
of subscribing to Traps--this is a truly generic
requirement for a very, very large audience, and not
just the PWG's.  If the PWG wants a "standard" mechanism
that is genuinely usable by a large audience, then we
should play the IETF game and get a new WG formed that
draws from that audience.

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

---

From: Paul Gloger <[email-masked]>
Date: Thu, 18 Jun 1998 22:05:17 PDT

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