Subject: PMP> FEb-18-ConfCall minutes

From: "Harry Lewis <[email-masked]>" <[email-masked]>
Date: Tue, 18 Feb 97 16:51:29 MST

I posted a text only version of the minutes as appended below: (feb18cal.txt)

Minutes of the Feb-18-1997 conference call on Stardust Interoperability
test results:

Present: Jay Martin
         Bob Pentecost
         Lloyd Young/Evan/Matt
         Gail Songer
         Ron Bergman
         Peter Zeller
         Stuart Rawley
         Chuck Adams
         Harry Lewis

Review of MIB WALK

 hrDeviceID - 2 of 6 vendors returned 0.0 rather than a device OID from the
 private enterprise. Jay emphasized that, if drivers are to self configure
 based on the SNMP information, the hrDeviceID needs to be unique to the
 printer model. One way to think of it is if a different PPD (Postscript)
 file would be required than the device should have a different OID. OID's
 should not be so granular as to represent configurations which can be
 discerned from the Printer MIB itself, such as how many input trays are
 installed.

 hrDeviceDesc - Serial and Parallel are considered optional interfaces
 since the Printer MIB is largely network oriented. 1 or 6 vendors
 described their Serial and Parallel interfaces.

 hrDeviceStatus - One vendor indicated "down" because the interface "slot"
 existed (and presumably was pre-configured for a particular NIC card)
 but the card was not installed. Matt will clarify that subunit status
 for hrDeviceStatus should not indicate down if the interface is not
 installed.

 hrDevice - Do we need a table for storage if we have a disk? Only one
 vendor tested with a hard disk installed. Can the storage table be
 indexed to the printer or should it be indexed to a separate device
 (storage) type? Unresolved. Perhaps vendors should retest, individually,
 and report what they do for HDD?

 hrPrinterDetectedErrorState - One vendor appears to have reported 4
 bytes while the rest reported 1 byte. One vendor used a different tool
 however. Vendors should individually determine if they send 1 or 4 bytes.

 hrSystemDate - Wide differences. No realtime clock. Not useful. Two
 printers have exact same value for hrSystemDate and hrInitialLoadParms.
 One vendor's value is nontrivial. Unexplained.

 hrSysUpTime - Half did it. System group has sysUpTime. Used by applications
 to correlate Power Recycles with config change counter.

 prtChannelCurrentJobCntLangIndex and prtChannelDefaultPageDescLangIndex -
 Since these are indices (not enums), what if you don't have a current
 job control language (possible) or a default PDL (hard to imagine).
 Matt will clarify that (0) means don't have.

 prtChannelIfIndex - Most implementations can't distinguish between
 two NICs in terms of ifIndex. At least one printer can. It was decided
 to accept this and let it pass. It's not clear if printers that don't
 distinguish NICs with separate indexes actually report only the services
 for one NIC or if they lump all the services together.

 prtChannelStatus - Some of the definitions for subUnitStatus are pretty
 ambiguous... like Idle vs Standby and Active vs Busy. Some printers assume
 different Available or Unavailable states under, otherwise, similar conditions.
 Chuck will try to clarify. One option is to indicate 0, 4 and 6 are all
 acceptable states when the printer is Available.

 prtGeneralConfigChanges - Wide variance here. Need more examples. What
 actually constitutes a config change? Matt to clarify.

 prtInputStatus - Wide variance (if taken at face value). What if the
 Input subUnit is available but the whole printer is in standby? In general,
 subUnit status is part of the Alert top 25 project and this topic should
 be addressed in a separate call.

 Next call will take up with prtInputDefaultCharSet.

Harry Lewis - IBM Printing Systems

---

From: [email-masked] (Bill Wagner)
Date: Tue, 18 Feb 1997 22:37:02 -0500

Sorry I missed the teleconference. When is the next one?
     
     One item that disturbs me is the lack of MIB II data, at least the 
     systems group and the Interfaces Table. RFC 1759 states:

        "All objects in the system group of MIB-II (RFC 1213) must be
        implemented.
     
      ...
     
      The System Controller is represented by the Storage and Device groups
      of the Host Resources MIB (RFC 1514).  These are the only groups that
      are required to be implemented.  Other Groups (System, Running
      Software, Running Software Performance, and Installed Software) may
      be implemented at the discretion of the implementor.
     
     ...
     
        All objects in the Interfaces Group of MIB-II (RFC 1213) shall be
        implemented. "

     Yet, the comments seem to suggest that MIB II systems group 
     information is disregarded in favor of HRDevice and HRSystem 
     information.
     
     1. Jay's comment about a device OID is well taken, but a reasonable 
     interpretation of RFC1759 suggests that the OID in MIB II should be 
     adequate (except in the case of non-network printers attached to a 
     separte network node)
     
     2. "hrDeviceDesc - Serial and Parallel are considered optional 
     interfaces since the Printer MIB is largely network oriented. " 
     Fine... but what about the interfaces table? One cannot give the 
     status of a printer (or of jobs in the printer) unless all potential 
     sources of jobs  are accounted for.
     What about RAM, ROM, NVRAM and all of the other storage mechanisms? 
     Should they  be listed as devices? Isn't this the way someone 
     determoned how much RAM is in a printer? Onj the other hand, where 
     does one stop?

     3. "Can the storage table be indexed to the printer or should it be 
     indexed to a separate device (storage) type?"   My understanding was 
     that the storage table was for logical storage; that is, storage 
     aviable through the network as storage not storage incidental to the 
     printing function.
     
 4. "hrPrinterDetectedErrorState - One vendor appears to have reported 4 bytes 
 while the rest reported 1 byte." On one hand, since the SNMP message indicates 
 the lenth of a variable, one can argue that a four-byte length is valid. But 
 which byte has the code. I suggest it should the the most significant. Also, I 
 believe that Open View did not share this tolerate approach.
     
 5. "hrSystemDate" This is, most certainly optional. What about MIB-2 
 uptime. -.
     
 4. "hrSysUpTime" Again, by rfc1759, optional. But MIB-2 system up time is 
 mandatory. 
     
     I guess I do not understand the order in which items are being 
     addressed. Dealing with the HRMIB objects and not the 
     
         prtStorageRefSeqNumber  
         prtStorageRefIndex      
         prtDeviceRefSeqNumber   
         prtDeviceRefIndex       
     
     is missing some of the more interesting pptentials for inconsistency 
     and confusion. Or was there no problem here?
     
     Likewise, dealing with the channel objects without first dealing with 
     the MIB 2 interface group seems cart-before-the-horseish. 
     
     Bill Wagner, DPI

---

From: [email-masked] (JK Martin)
Date: Wed, 19 Feb 97 10:21 EST

Bill,

>      adequate (except in the case of non-network printers attached to a 

If the sysObjectId object in the System Group of MIB II identifies the
PRINTER and not just the INTERFACE CARD (aka NIC), then sysObjectId can
be used.  But this is *rarely* the case, based on our last studies of
the existing implementations.

Furthermore, just "clarifying" the situation by instructing Printer MIB
implementors to use sysObjectId is not acceptable, either.  The existing
market for NICs (and related interface technology) is so explicit that
it can be impossible to control how the NIC vendor implements the MIB-II
support on the card with respect to the Printer MIB implementation that
might be inside the printer.

Therefore, in the interests of consistency (and general sanity), it would
be best for Printer MIB implementors and and app developers to rely on the
corresponding hrDeviceId object in the Host Resources MIB.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03015-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------