Tom,
> >Whoa, here. Replication of MIB values is an explicit non-goal of
> >traditional MIB design, right? At least this is what Steve Waldbusser
> >has repeatedly stated (and for good reason).
> >
> >If you're replicating values to somehow make it easier for a mgmt app,
> >then I'd suggest the MIB is too complicated.
>> I agree completely that the same information should not have two ways to
> be accessed. That is why I have been suggesting getting rid of
> the Job State table altogether.
This is what Harry explicitly does NOT want to do, right? (I'm asking
just to make sure I've got these threads straight.)
Tom, does removing the Job State Table result in the following:
* Does not decrease the functionality needed to monitor job state,
the number ONE reason for having the Job MIB in the first place
* Makes the Job MIB less COMPLEX, and therefore easier to use by
management apps and agents alike
Pending Harry's comments, I could get behind your position if your proposed
changes are in line with the above statements.
We all know that Harry and the others at IBM are busy working on a full
working version of the Job MIB for their products. How about you folks
at Xerox? We know that Xerox has a job MIB (or two) of their own, but
what can you tell us about Xerox's experience in prototyping this version
of the standard Job Monitoring MIB?
If you're not prototyping the Job MIB, I would imagine it is difficult
to understand some of the problems raised by Harry and his group.
...jay