Subject: Re: JMP> Calling all Job Monitoring MIB prototypers...

From: Harry Lewis <[email-masked]>
Date: Tue, 1 Apr 1997 19:00:25 -0500

Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems

Ira, I welcome your response.

>The Xerox community agrees with you that mapping between a CLIENT
>generated job submission ID and the managed devices LOCAL job ID
>is critical - thus the ClientIdMapTable in the Xerox Job Monitoring
>MIB (which Tom Hastings posted to the PWG server over a year ago).

>We also agree that it is desirable to register one (or probably
>several) 'well-known' forms of client job ID.  We have a form
>(really a family of forms) which has worked well and has been
>in product for over two years.  If the JMP folks are interested,
>we'll be glad to show them.

>Although Xerox (like most of the JMP members) is cautious about
>announcing future product plans, I can say for certain that
>truly open, standards-based, network management of network
>connected products is the end objective of the Xerox community.

>Thanks for your efforts prototyping the IETF Job Mon MIB.  I
>reviewed your very interesting slides last week.  Good work!

I respect Xerox's (and all PWG members) privacy and want to take this
opportunity to clarify that IBM has similar policies regarding un-announced
products. I think there's been a bit of a misunderstanding regarding Jay's
"call for a show of hands". My interpretation of this query related strictly to
PROTOTYPING THE JMP JOB MIB. If I'm not mistaken, the IETF process recommends
prototyping prior to and in parallel with draft submission. So the design I'm
sharing with the PWG is the result of this prototype activity and should not be
misconstrued as a product announcement. I think this (lengthy) clarification
probably goes equally for all respondents... at least that's how I've perceived
it. Of course, none of us would
be in this game if it weren't for products so I understand how the treading can
become very light in this area.;-)

Then... I have to admit I have lost track of the ClientIDMapTable that you
refer to. I plan to share the clientJobID formats that we consider useful and I
think it would be helpful if Xerox chose to share your formats also. Of course,
this is strictly up to Xerox. I think the notion of registered formats for
clientJobIDs could go a long way to facilitating standard print job monitoring.

Again, thanks for your review and I welcome any further comments.

Harry Lewis - IBM Printing Systems

---

From: Tom Hastings <[email-masked]>
Date: Wed, 2 Apr 1997 10:55:00 PST

Jay,

I'm not sure why we are having this Email exchange.  My entire purpose
of working on any standards is for their implementation in products
and as fast as possible.  TTM is a real concern of mine, as well as yours.
I've been working as fast and as hard as I can to get closure on the
Job Monitoring MIB, starting a year and a half ago when I submitten
a complete, compilable MIB and continuing.  I agree that one of the best 
ways to get closure and short TTM is to go for simplicity and add after
the first ship.

Furthermore, I am most interested in writing a standard that monitoring
applications from one implementor or vendor can interwork with multiple
agents from other vendors.  I'm not very interested in just writing a
MIB that works only for a vendor that writes both the client and agent.
In other words, I'm not interested in writing a standard that just becomes
a checkoff item for procurement specifications.  I would think that
my objective would align with Underscore's as well here.  So we need
to make sure that all implementors have the same understanding about
the specification.

Sorry you won't be in Austin to discuss this face to face.

We will definitely discuss Harry's good specific proposal for 
simplification.  It looks real good.  Making specific proposals
for simplification, such as Harry's, is the best way to make progress
towards simplification.  It doesn't help to say we need to simplify
without making a specific proposal for simplification.  So please make
some specific simplification proposals yourself.  

Its easier to engineer complication.  The hardest and best engineering 
is making things simple (and still useful).

Thanks,
Tom

At 09:35 03/29/97 PST, JK Martin wrote:
>Tom,
>
>> You ask some good questions here.  We need to discuss what is needed to
>> make the Job Monitoring spec be the thing that is being prototyped.
>> Lets put this discussion on the JMP agenda for next week?
>
>Regretably, I will not be able to make the Austin meetings.  However,
>I have been in pretty close contact with Harry Lewis about most of
>these issues, and I believe Harry can accurately state my views in
>my absense.
>
>      --- NOTE TO AUSTIN-BOUND JOB MIB MEETING ATTENDEES ---
>
>  Please take a few moments before the Job MIB meeting to read this
>  message, then form your own opinions and (please!) publicly state
>  your opinions at the meeting.  The day of reckoning draws near...
>
>
>> Is it some of the remaining issues, such as how a client can find
>> a particular job that passes through a server to a Printer with the MIB?
>
>It could very well be.  Underscore has studied this problem over the
>last year or so, and it appears to be a very difficult nut to crack.
>So much so, that we now agree with Harry (and some others) in stating
>that the Job MIB should be constrained to a simple client-server
>model...with no intervening print server concept.  Just a "client"
>(server, mgmt app) talking to a "server" (printer, print server).
>
>
>> Does it take proprietary solutions to solve this problem, so that that
>> is why implementors are doing something based on the spec, but not
>> actually implementing the spec.  Perhaps the proprietary solutions
>> can be separate MIBs that merely augments a conforming IETF Job Monitoring
>> MIB?  Or can we come up with an agreed means that doesn't require any
>> proprietary solutions?
>
>You can do anything with proprietary MIBs.  But that is not the point.
>We need to create standard MIBs here.
>
>A long time ago I passionately argued for a modular approach, whereby
>the initial Job MIB would be VERY VERY SIMPLE, and that we would then
>augment that simple MIB to support such things as accounting, etc.
>That way we could get the SIMPLE MIB out in the marketplace as quickly
>as possible so as to gain some real operational experience, particularly
>in order to know exactly what kinds of extensions are truly necessary
>(ie, "necessary" == "demanded by paying customers").
>
>
>> Another reason is that, as HP points out, we need to better understand
>> how each object is used with each job submission protocol and in each
>> of the configurations that we are trying to support.  How can we make
>> better progress on this part?  I'll be glad to document the understandings
>> in the spec, so that they can be tested during interoperability testing.
>
>This paragraph really scares me, Tom.  I thought the whole purpose of
>developing the table of "Existing Protocols Mapped to Job MIB Attributes"
>was supposed to address this topic.
>
>And, please recall (PLEASE), that last November in New Orleans, I pointed
>out that the Job MIB actually contained attributes for which NO EXISTING
>PRINT SUBMISSION PROTOCOL SUPPORTS.  That is, you had added attributes
>that do not map to any existing print submission protocol.
>
>During that meeting I suggested that we IMMEDIATELY remove those attributes.
>You did not agree, stating (as usual) that "someone in the future might
>find a need for those attributes" (or something to that effect).
>
>This is sheer lunacy.  And the paying marketplace suffers as a result,
>not to mention the vendors who wish to develop and deliver useful solutions
>to that marketplace.
>
>
>> Of course, another reason may be that the committee keeps evolving
>> the spec with each meeting, so that it is a moving target.  Is this
>> a problem?
>
>If this weren't so sad, I'd really have to laugh.  Tom, YOU are the one
>who keeps changing the spec!  Yes, the group then ends up making more
>changes...but almost always because your new changes don't map to any
>known reality in the market-driven world.
>
>
>> Except for the remaining issues, I think we are reaching
>> more stability.  We keep removing objects, so that now we are down to
>> only 21 mandatory objects (but we have 45 attributes, that are conditionally
>> manatory: you implement them if you got them).
>
>I think everyone should listen to what Harry Lewis is going to present.
>If the group doesn't buy Harry's approach, then I'd like to propose that
>Hewlett-Packard submit their Job MIB to the PWG as a new candidate for
>the official Job MIB (with all HP-proprietary stuff removed, of course).
>Similarly, any other vendor with a known working solution should be
>invited to propose their model.
>
>
>> Xerox has its own job monitoring MIB as well with its own solutions to
>> the above.  Xerox would like to implement the IETF spec when it is
>> stablized.
>
>Then why on earth didn't you just propose the solution as developed by
>Xerox, for heaven's sake??  Why did you constantly view the Job MIB
>effort as a "fundamental research activity", apparently ignoring any
>and all existing practice?
>
>
>Tom, you really have quite the ability to generate massive amounts of
>spec-oriented material.  You do that very well, and much of the content
>is quite interesting.  However, it is also clear that, unlike almost
>all other Job MIB participants, you do not actually develop product.
>More importantly, since you don't develop product, you have very little
>sensitivity to the concepts of "time to market" and plain, old fashioned
>bottom-line responsibility.
>
>The Job MIB effort has been going on for close to TWO YEARS now, and
>it's time to come to closure.  IMMEDIATELY.
>
>I apologize for the particularly intense flame-o-gram here, but enough
>is enough.  Standards developed by the PWG are intended as a vehicle
>to promote free enterprise within a level-playing-field environment.
>The PWG is NOT an altruistic body of interested people, but rather a
>group of cooperating competitors trying to raise the reference bar for
>new technologies in an evolutionary manner.
>
>Let's close this effort and get to the task of developing products for
>our customers.
>
>	...jay
>
>

---

From: JK Martin <[email-masked]>
Date: Wed, 2 Apr 1997 15:10:07 -0500 (EST)

Tom,

With all due respect, this will be my last mail message on this topic.

Hopefully by now you have also received the comments from Ron Bergman
(JMP Chairman) on this thread; I've attached it here in case you have
yet to read it.

> is making things simple (and still useful).

You should know by now that I couldn't agree more with this statement.
The fact that you are stating it, though, is a bit of a surprise.

Over the course of the last year, the JMP group has repeatedly asked
you to consider a more simplified model for the Job MIB.  And,
regrettably, you repeatedly appeared to have ignored every request of
that type.  (Note that simply removing objects out of the proposed MIB
is *not* necessarily simplifying the model.)

You also say:

> [Time to market] is a real concern of mine, as well as yours.
> a complete, compilable MIB and continuing.

IMHO, it should not have taken us this long to get to where we are now.
If the JMP group had gone the normal IETF working group route when the
Job MIB effort first started, we would either have a working Job MIB
by now...or the entire effort would have been shutdown by the IETF, due
to the IETF's strong rules on length-of-effort and maintaining the
associated schedule.

You and I are fundamentally different with regard to standards development,
that's for sure.  (And that's good, I believe.)  I prefer small, simple
efforts that can be quickly developed, while you prefer large, all-
encompassing efforts that attempt to solve all known problems in all
known environments (and even a few that don't fit this description! ;-).

Given that difference of position, it's likely that we'll have a
disagreement now and then.  That's ok, as long as it can be worked
out in an open forum.  (And it is, I believe.)

	...jay

----- Begin Included Message -----

>From [email-masked] Tue Apr  1 11:34 EST 1997
Date: Tue, 1 Apr 1997 08:28:54 -0800 (PST)
From: Ron Bergman <[email-masked]>
To: JK Martin <[email-masked]>
Subject: Re: JMP> Calling all Job Monitoring MIB prototypers...
X-X-Sender: [email-masked]

Jay,

Your message to Tom was very appropriate and expresses much of what I
have been thinking over the past months.  It seems like the more we
cut from the MIB, the larger the document becomes and the more issues
that are closed, the more new issues are added.

I have reviewed Harry Lewis' proposed changes and, except for some
points I don't fully understand, agree they are welcome improvements.
I am sure that the remaining members will also agree.

Keeping this project moving has been a difficult task due to many of
the reasons so well expressed in your message.  It is always nice to
see that someone else shares this view.

	Ron Bergman

----- End Included Message -----