Subject: PMP> MIB-2 reference in Printer MIB

From: "Harry Lewis <[email-masked]>" <[email-masked]>
Date: Tue, 11 Mar 97 17:36:20 MST

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.

---

From: [email-masked] (Bill Wagner)
Date: Tue, 11 Mar 1997 20:36:15 -0500

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 <[email-masked]>" <[email-masked]> at Internet
Date:    3/11/97 5:36 PM

2.2.9.  Interfaces