Subject: PMP> MIB-2 reference in Printer MIB

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

At the last PMP discussion, I suggested that the references to the 
     System and Interfaces group of MIB II be removed from the printer MIB 
     RFC. Indeed, since the current draft includes the reference in the 
     text but not in the MIB itself, the requirement for inclusion is 
     unclear.  It is preferable to remove this cumbersome and 
     inconsistently implemented reference than to leave it ill defined and 
     functionally useless. Indeed, the problems with using the MIB-2 
     referenced objects are reflected in the facts that:

        1. the MIB-2 groups referenced in the printer MIB were not 
     considered sufficiently significant to include in the 
     interoperability testing, and 
        2. the printer identification and configuration functions 
     originally intended to be addressed by MIB-2 objects are now to be 
     handled by HRMIB objects and additional objects in the main body of the 
     printer MIB, 

     The consideration of the cases of:
      
        1. the workstation or printserver box supporting multiple printers , and
        2. the printer sporting more than one network interface
     
     have rendered the MIB-2 groups unable to provide useful printer objects. 
     Although MIB-2 continues to be applicable to the network interfaces 
     themselves, the variables can not be guaranteed to be either unique (when 
     multiple printers share the interface) nor single valued (when a printer 
     has multiple network interfaces). The need for unique values has been 
     addressed by using more of the HR MIB objects, and by adding objects to the 
     systems section of the printer MIB. There has been little consistency in 
     the handling of the of the multiple NIC problem. (e.g., which sysUpTime 
     does one use for the printer alert time?).
     
     Consideration of compatible implementation of the interfaces group has been 
     avoided. There are no guidelines on whether the listed interfaces include 
     host workstation (or print server box) interfaces, just printer interfaces, 
     or just printer network interfaces. In the case of multiple printers, 
     discerning local interfaces to each printer could be a real puzzle. And 
     many of the objects in the interface table are of very little interest from 
     a printer maintenance viewpoint
     
     I therefore suggest that the Printer MIB remove a direct reference to 
     including the systems and interface groups of MIB -2. A comment to the 
     desirability to have each network interface support MIB-2 for itself is 
     recommended; but the intent of the MIB-2 objects as applied to the printer 
     is handled elsewhere in the HRMIB groups and the modified printer MIB.
     
     Note that I am not blithely suggesting the elimination of objects; I am 
     generally opposed to doing this. Nor am I suggesting that MIB-2 not be 
     used; I would suggest a strong encouragement that all network nodes 
     providing input to a printer be supported with MIB-2.  I am observing that 
     MIB-2 objects cannot consistently be used as printer specific objects, that 
     the need for MIB-2 objects in a printer context has largely been removed by 
     the use of HRMIB and Printer  MIB objects, and that the remaining 
     association between the referenced MIB-2 objects and the printer can be 
     better handled elsewhere. 
     
     The following list of System Group and Interfaces Group objects indicates 
     the disposition of the purpose for which this object may have been 
     originally intended in the Printer MIB. 
     
     sysDescr           hrDeviceDesc
     
     sysObjectID        hrDeviceID
     
     sysUpTime          * (see note 1)
     
     sysContact         prtGeneralServicePerson
     
     sysName            prtGeneralAdminName
     
     sysLocation        can be uncluded in prtGeneralAdminName
     
     sysServices         hrDeviceType

     -- the Interfaces group
     
     ifNumber   Implicit
     
     ifIndex            unnecessary if interfaces are defined in conjunction 
                                with channel table
     ifDescr            not applicable to printer
     ifType             include in channel table
     ifMtu              not necessary
     ifSpeed            not necessary
     ifPhysAddress      include in channel table where necessary
     ifAdminStatus      not necessary.. implicit in channel status
     ifOperStatus       not necessary.. implicit in channel status
     ifLastChange       not necessary
     ifInOctets         not necessary
     ifInUcastPkts      not necessary
     ifInNUcastPkts     not necessary
     ifInDiscards       not necessary
     ifInErrors         not necessary
     ifInUnknownProtos  not necessary
     ifOutOctets        not necessary
     ifOutUcastPkts     not necessary
     ifOutNUcastPkts    not necessary
     ifOutDiscards      not necessary
     ifOutErrors        not necessary
      ifOutQLen         not necessary
     ifSpecific         not necessary

     * Note 1. sysUpTime. In a printer context, this gives not only the time up, 
     but also allows the alert event times to be related to a time of day. It 
     may be desirable to provide this elsewhere. Although the function could 
     still be served by the sysUpTime in the associated network node MIB-2 (s), 
     the present question of which one to use, if there are more than one, 
     remains. 
     
      The Interface group relates primarily to the channel group of the printer 
     MIB. 
     
     1. prtChannelIfIndex would no longer be applicable and would be either  
     deprecated or redefined to refer to a printer interface index inherently 
     defined by the channel table.
     
     2. prtChannelInformation: The description states "information to allow a 
     printing application to use the channel for data submission to the printer" 
     I suggest that this be made self sufficient by also identifying the 
     applicable information about the interface used by that channel. This would 
     include the interface type enum (perhaps copping the enums from the 
     "evolution of the interface group MIB) and, as applicable, an identifying 
     address. MAC address might be good for ethernet and token ring interfaces 
     and is applicable to many non-IP print services listed under channels. IP 
     address is an alternate  address appropriate to any internet interface. 
     Perhaps URL might be an appropriate address in the future.

     I would appreciate comment on this proposal. If there is agreement, I would 
     volunteer to edit text sections of the  RFC that would be affected.
     
     Bill Wagner, Osicom/DPI

---

From: "Eugene Chen" <[email-masked]>
Date: Tue, 11 Mar 1997 12:37:59 -0800

Bill:

I definitely agree with you that the purpose of including Interface into
printer MIB is very confusing.

In our (EFI) network implementation, we have a very clear line between physical
interface and logical interface. Physical interfaces are Ethernet, Token Ring,
etc., while logical interface is a combination of physical interface with a
specific frame type, e.g. 802.2 or SNAP. When user bind two frame types onto a
single physical interface, there are actually two logical network nodes on the
wire. If there should be any interface information interesting to the network
manager, it will be logical interfaces, not physical interfaces.

I believe that including MIB-II interface group is useful for network interface
management, but the correlation between printer mib and MIB-II interface is too
primitive. It has to be redesigned before it can become really useful.

Eugene

-- 
_____________________________________________________________
Eugene Chen               Sr. Software Engineer, Networking.
-------------------------------------------------------------
 DIR:(415) 286-8372            Electronics for Imaging, Inc.
OPER:(415) 286-8600            2855 Campus Drive
email:[email-masked]  San Mateo, CA 94403

---

From: Chris Wellens <[email-masked]>
Date: Mon, 17 Mar 1997 19:25:34 -0800 (PST)

When we were putting together the Test Plan for the February
interop testing, we excluded MIB-II.  The reason we excluded it
is that in order to get the Printer MIB to DRAFT standard, we
had to test all 179 of its objects and prove them interoperable.
We had a limited amount of time, and we knew we had some big
problems (like the alert tables).  

MIB-II is the most widely deployed MIB.  It is installed on
hundreds of thousands of network devices.  It is already
advanced on the standards track.  Therefore, there was no need
for the PWG to do interoperability testing on MIB-II.  (Printer
vendors still need to test their MIB-II implementations, but they can
do that testing on their own.)

Recently, there have been discussions about multiple interfaces and
changes to MIB-II.  I referred the email describing these issues to
InterWorking Labs' Advisory Board (listed on www.iwl.com) to get a
second opinion.  The general consensus is that the situations
are special cases and should be worked out with specialists or
consultants, but that a change to the specification was not
warranted.

Finally, deleting the requirement to implement MIB-II would
prevent us from moving to DRAFT standard, as it would be
considered a significant change.