Thanks for moving the Job Monitoring MIB along. Some comments
for consideration:
> 1. The issue of an index to allow for multiple printer support was
> discussed in New Orleans. The use of hrDeviceIndex was agreed to
> be a bad decision for the Printer MIB and should not be propagated
> in the Job MIB. Tom has proposed jmMIBInstanceIndex for this
> purpose.
>
> While I agreed with the decision from the November meeting to not
> use hrDeviceIndex, my current opinion has changed. The Job MIB
> will, most likely, be used in conjunction with the Printer MIB.
> For the case where the SNMP Agent supports multiple printers, it
> seems that the use of a common index is essential to correlate the
> data between the two MIBs. If the use of hrDeviceIndex is really
> that serious, it should be changed in the Printer MIB.
>
> I guess it would be possible to include in the definition that the
> object jmMIBInstanceIndex and hrDeviceIndex were equivalent, but
> it would be less confusing to just use the same object.
I don't believe I was able to attend the part of the last JMP meeting
during which it was stated:
"The use of hrDeviceIndex was agreed to be a bad decision for the
Printer MIB and should not be propagated in the Job MIB."
As I have stated several times before, originally I was not a supporter
of the design approach in which the Printer MIB was "embedded" within
the Host Resources MIB. However, after many, many months of studying
the "big picture", it seems obvious that this must be done IF we need
to manage printers directly attached to a server machine (as is very
often the case with NetWare, Windows/NT and even some Unix server
environments).
If we are now saying that this approach is a mistake, then we must be
implying that only network-attached printers can "play" with the Printer
MIB. Is this clear to everyone? If the PWG wants to declare that only
network printers are the intended application environment for the Printer
MIB, then so be it...as long as the rest of the world has a clear
understanding of the decision and the rationale behind it.
Now things get even stickier when we start to say things like:
"The Job MIB will, most likely, be used in conjunction with the
Printer MIB."
Is this really true? It certainly is true if a (network) printer
wants to expose its own internal print queue(s).
But what about the Job MIB being used to generally monitor printing
systems (without regard for the associated printers)? Underscore's
interest in the Job MIB has revolved around exposing the state of
Unix printing systems (LPD, etc), and not just internal printer queues.
If the hrDeviceIndex is required for the Job MIB, will monitoring
native printing systems be precluded?
I certainly hope not!
Therefore, I would like to see the Job MIB and the Printer MIB decoupled
as much as possible. It certainly would be nice, however, to have a
nice, clean way to tie a print queue to a printer containing Printer MIB
support. Would it be possible to design a Job MIB object that provides
such a reference? Such an object could be used to provide the value of
the associated printer's hrDeviceIndex (if available), or the object would
contain a "non-applicable" or "unknown" value if no such association is
known or defined.
> 2. The object jmJobIndex (from my previous proposal as a name change
> for jmJobLocalId) should be used in place of jmCompletedIndex.
> This will allow a common identification of jobs between the Job
> Group and the Completed group. I cannot see any need for a new
> index for the Completed Group.
Sounds like a great idea, Ron. By definition, an entry can't be in
both tables at the same time.
> 3. The object jmJobSourceChannelInformation should be eliminated.
> The Printer MIB should be used to obtain all required information
> concerning the selected channel. This information should not be
> repeated in the Job Monitor MIB.
I completely agree...although I realize some may think that I am
contridicting myself here. The point is, I believe the current
Job MIB proposal (as published by Tom Hastings in December) is still
way too fat, filled with lots of stuff that few people (or applications)
are interested in.
If someone wants the "Channel Information", then leverage the Printer MIB
for that data. If there is no Printer MIB-compliant printer associated
with the target job entry, then you don't get that info. I realize this
sounds kind of "mean", but we have to cut the fat someplace.
And, speaking of fat, I'd like to propose that the *entire* "Resources"
section be removed from the Job MIB proposal. When you look at all the
many objects defined in that section, ask yourself "Who or what is going
to REALLY use (much less NEED) that information?"
...jay