Subject: Re: JMP> ISSUE from Chris: Submitting via serial/parallel...

From: [email-masked] (Ira Mcdonald x10962)
Date: Wed, 6 Aug 1997 11:20:09 PDT

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: [email-masked]
>From: Tom Hastings <[email-masked]>
>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 <[email-masked]>
>>To: Tom Hastings <[email-masked]>
>>Cc: Ron Bergman <[email-masked]>, Lloyd Young <[email-masked]>
>>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