Subject: JMP> Use of hrDeviceIndex in the Jobs MIB

From: [email-masked]
Date: Sat, 4 Jan 1997 10:17:35 -0800

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
	[email-masked]