Hi Tom and Chris, Wednesday (6 August 1997)
I think the problem is that the Job Monitoring MIB presently only defines
the attribute 'jobSourceChannelIndex' (a value for 'prtChannelIndex' in
the Printer MIB's 'prtChannelTable' which is useless, without a Printer
MIB implementation, for network management and accounting purposes).
To cheaply avoid dependency on the Printer MIB for job source channel info,
I suggest that we add the following two Job Mon MIB attributes:
1) 'jobSourceChannelType' (using 'PrtChannelTypeTC' from the Printer
MIB, but NOT requiring implementation of the 'prtChannelTable');
2) 'jobSourceChannelIfIndex' (a value for 'ifIndex' in the MIB-II
'ifTable', in the Interface group of RFC 1213).
Cheers,
- Ira McDonald (outside consultant at Xerox)
High North Inc
PO Box 221
Grand Marais, MI 49839
906-494-2434
>---------------------- Tom's and Chris's notes -----------------------<
>Date: Wed, 6 Aug 1997 00:58:43 PDT
>To: jmp at pwg.org>From: Tom Hastings <hastings at cp10.es.xerox.com>
>Subject: JMP> ISSUE from Chris: Submitting via serial/paraller ports
>>I don't understand this issue. The Job Monitoring MIB requires (and has
>always required):
>>3.1.2.1 MIB II System Group objects
>>The Job Monitoring MIB agent SHALL implement all objects in the System Group
>of MIB-II[mib-II], whether the Printer MIB[print-mib] is implemented or not.
>>3.1.2.2 MIB II Interface Group objects
>>The Job Monitoring MIB agent SHALL implement all objects in the Interfaces
>Group of MIB-II[mib-II], whether the Printer MIB[print-mib] is implemented
>or not.
>>But we need to discuss it this week.
>>Tom
>>>Date: Mon, 4 Aug 1997 18:59:04 PDT
>>From: Chris Wellens <chrisw at iwl.com>
>>To: Tom Hastings <hastings at cp10.es.xerox.com>
>>Cc: Ron Bergman <rbergma at dpc.com>, Lloyd Young <lpyoung at lexmark.com>
>>Subject: Re: Schedule and Plans for Job MIB
>>>>>From a network engineer's point of view, you must keep track of
>>all the traffic into and out of the networked device. This is
>>just gospel. With the Printer MIB, it seemed to me that
>>numerous times, the working group just wanted to sweep this
>>under the table. The best example of this was the efforts to
>>remove MIB-II as a requirement, stemming from the desire to have
>>hardware implementations that located the SNMP implementation
>>geographically removed from the device itself.
>>>>So, yes it is a concern, and the concern comes from both
>>the Area Directors, and if we had different ADs, the new ones
>>would have the same concern.
>>>>However, it is the people in the printer industry who do usability
>>testing and understand how the customers are using these printers on
>>networks who are in the best position to say whether this is an
>>issue or not. When a printer is networked, do the users tend to
>>use it that way, and not print via the parallel or serial ports? My
>>guess is that yes, that would be the case. But I don't really know.
>>>>So, yes, I think this should be addressed because an IETF audience is
>>going to pounce on this, just because of how a network engineer views
>>the world. You could address it in the JOB MIB document, in the
>>introduction, or if it is going to be a long, complex discussion, then
>>we would send it in a separate email prior to requesting that the
>>document be published as a RFC.
>>>>>>On Mon, 4 Aug 1997, Tom Hastings wrote:
>>>>> At 12:53 08/01/97 PDT, Chris Wellens wrote:
>>> snip...
>>>>>> >They know that it is coming. The big concern is that from the
>>> >user's perspective, jobs can be submitted via serial, parallel,
>>> >or network connections, and the Job MIB is only going to know
>>> >about the network connections. I haven't studied the last
>>> >draft, so I don't know how you've addressed this.
>>>>>> We never heard of "this big concern". Where is it coming from?
>>>>>> Do we need to address it?
>>>>>> Thanks,
>>> Tom