Two points of clarification:
1. I know of no attempt remove MIB 2 as a necessary adjunct to the
Printer MIB. There was the observation that, by specifcally calling
out the System and Interface groups, some implementors felt that the
other germain groups of MIB-2 were not needed. It was my suggestion
that, insofar as MIB-2 is required for any network node, specifically
calling out two groups of the MIB led to a lesser and more
inconsistent implementation than if the printer MIB remained silent in
this regard.
2. Indeed, because of various reasons, the information in the MIB-2
systems group, other than perhaps sysUpTime, must be considered
applicable only to the network node (NIC or host), and not the
printer. By revised convention, the systems information for the
printer is within the HR MIB and some of the new objects in the
Printer MIB.
3. The non-handling of local ports in the Interfaces group (I am not
aware of any implementation that does include the local ports) was a
result of the wording of MIB-2, the confusion over the "Evolution of
the Interfaces group" MIB, and the very inappropriate way that the
"Evolution" seems to handle local ports. Considering the time that was
spent considering how to handle local ports, I regard the comment
about "the working group just wanted to sweep this under the table."
as highly inappropriate. However, I believe that, although the
accepted notion that the MIB just dealt with network access was sort
of accepted for the printer MIB itself, it does not work for the Job
MIB.
I agree that this should be discussed.
Bill Wagner, Osicom/DPI
______________________________ Reply Separator _________________________________
Subject: JMP> ISSUE from Chris: Submitting via serial/paraller ports
Author: Tom Hastings <hastings at cp10.es.xerox.com> at Internet
Date: 8/6/97 12:58 AM
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
>Return-Path: <chrisw at iwl.com>
>Date: Mon, 4 Aug 1997 18:59:04 PDT
>From: Chris Wellens <chrisw at iwl.com>
>Reply-To: 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
>>>>>>>>