Harry,
You may recall that I did submit a much more involved description of
the way the MIB-2 and HR MIB groups interact with the printer MIB.
There was very little discussion about it (although it did not get
into the Internet draft). And I don't think I am suggesting sweeping
changes. I am merely reflecting that fact that the printer MIB does
not call out the inclusion of MIB-2 (the RFC does, not the MIB), that
the interoperability group did not think that implementation of MIB-2
objects was germane to the interoperability test, and that the values
become open to interpretation in any case other than the simple
printer with one network interface.
It seems that you were was the one who pushed (quite correctly) the
use of HR MIB objects in place of the MIB-2 systems group, and
campaigned for additional identification information in the printer
MIB general group. The effect was to disassociate the Systems group
from the printer.
And it also seems to me that you had several questions of how the
interfaces group was to be handled, in the particular case of multiple
NIC's. Indeed, I was very interested in how the interfaces table was
handled. Were local interfaces also listed? Were the full set of
rapidly varying objects for every interface available at every network
interface? Why? Did you synchronize sysUpTime between the multiple
interfaces? What if one interface were reset? These are just some of
the things that are not clear. What of the 'brick' case? Are the
interfaces of the brick or of the printers to which the 'brick'
interfaces are attached? Or are both listed? How does one associate
one of the many interfaces that could be listed with a given printer?
Through the channel table? It seems undefined and at best contorted.
From Jay's note, it was unclear that I was proposing that the
interface type (interface enum), identification (e.g., MAC or IP
address, depending on the level of the interface) and perhaps index be
included in the Channel Information field. If the definition of
ChannelIFIndex can be changed, it can go there. The advantage is that
the necessary information to connect to a channel is thereby provided
in the channel table. For all channels to the specific printer and
only to that printer. I suggest that this might even help clarify the
much abused channel group.
The change has no effect on the MIB except for changing the meaning of
the ChannelIFIndex and adding some information to the newly defined
ChannelInformation object.
Certainly, there would be nothing to prevent a full MIB-II from also
being implemented for the printer system.
______________________________ Reply Separator _________________________________
Subject: PMP> MIB-2 reference in Printer MIB
Author: "Harry Lewis <harryl at vnet.ibm.com>" <harryl at VNET.IBM.COM> at Internet
Date: 3/11/97 5:36 PM
Why do I have the feeling I will be the lonely voice in this discussion?
To me RFC1759 states quite clearly (inserting appropriate excerpts):
2.2.9. Interfaces
An interface is the communications port and associated protocols that
are responsible for the transport of data to the printer. A printer
has one or more interface sub-units. The interfaces are represented
by the Interfaces Group of MIB-II (RFC 1213).
3. Objects from other MIB Specifications
This section lists the objects from other IETF MIB specifications
that are mandatory for conformance to this Printer MIB specification.
3.1. System Group objects
All objects in the system group of MIB-II (RFC 1213) must be
implemented.
3.3. Interface Group objects
All objects in the Interfaces Group of MIB-II (RFC 1213) shall be
implemented.
I agree, the actual definition of the "system" is poorly articulated in
RFC1759. I will argue that the implication is that the Printer is the
system, however, I would probably have a difficult time substantiating
that (except the *name* of RFC1759 *is* the PRINTER MIB, not the NIC
MIB!). So System group of MIB-II stands a bit weak, but Interfaces
seems clearly defined, to me.
I guess my main concern in making the sweeping changes Bill suggests is
that an implementation that DOES treat the Printer as the system in terms
of both System and Interfaces groups of MIB-II would not end up looking
"broken" or non-compliant.
Harry Lewis - IBM Printing Systems.