Jay,
On 3 Jan 1997, Jay Martin wrote:
> Ron,
>> 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.
You are 100% correct! My point applies only to the network printer and
this index needs to be independent of hrDeviceIndex to be applicable to
the general case. I agree that an object needs to be added to define
the associated hrDeviceIndex value for the network printer case.
-----------------------------------------------------------------------
Ron Bergman
Dataproducts Corp
rbergma at dpc.com