PMP Mail Archive: Re: PMP> FEb-18-ConfCall minutes

Re: PMP> FEb-18-ConfCall minutes

Bill Wagner (bwagner@digprod.com)
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