The teleconference brought up some interesting points. Of course, Jay
is correct in that the MIB II system and the printer need not be the
same. One can think up special cases from multi-printer server boxes
to workstation-attached printers where the node is not unique to the
printer. However, these seem to me to be unlikely candidates to be
supporting the printer MIB, and as the request implied, the main
target of the identification within the printer MIB is to circumvent
sloppy NIC implementations that don't reflect printer identification
in MIB 2.
Now, since we are in the mood to support purity and goodness, let me
again bring up the question of interfaces and MIB 2.
Interfaces are a major group in the printer model. According to
paragraph 2.2.9, the interface subunits of a`printer are represented
by the interfaces group if MIB -II. (RFC 1213.)
Now:
1. it would seem that, if we agree that the MIB-II node does not
necessarily represent the printer for purposes of identification, how
can it for purposes of interface?
2. further, if we take the case of the printserver box with four
printers attached (the reason why we need a separate Object ID in the
printer MIB) the MIB-II will undoubted refer to the network interface
of the printserver. What about the ...say IEEE 1284 ports ... by which
the printers are connected to the printserver box?
Well... even if we list them in, how do we determine which one belongs
to which printer? AH..we can associate channel with printer, and we
can associate channel with interface. Therefore, the printserver with
one ethernet port which services four printers over IEEE 1284 ports
should identify the four 1284 ports... of should identify 8, since it
has a four 1284 ports and the for printers each has a 1284 port?
3. Now, lets say that each of the printers also has a serial port
and a local talk port. These may each be connected, and the printer
has hot ports. So should we now also list 4 RS 232 interfaces and 4
localtalk interfaces?
4. But look, RFC1213 only applies to network interfaces. So lets
drop all those non-network interfaces.
5. Indeed, even for simple one printer configurations, I have not
yet seen a printer MIB implementation that reflects the non-network
interfaces on the printer.
6. But these interfaces are keyed to the channels...or should we
simply not key non-network interfaces to their channels. Or perhaps we
should drop non network channels... that would simplify channels
nicely.
One could maintain that, for network administration, we need not care
about non-network connections. But if that is the decision, I think it
should be more clearly identified in the rfc. On the other hand, if
all possible interfaces to the printer are to be identified, that also
should be made clear; and if that is the case, then the problem with
rfc1213 dealing only with network interface should be addressed.
If this is confusing, I think you have the picture.
Bill Wagner, DPI