PMP Mail Archive: Re: PMP> prtChannelIfIndex

Re: PMP> prtChannelIfIndex

Harry Lewis (harryl@vnet.ibm.com)
Wed, 19 Feb 97 18:22:24 MST

Bill Wagner wrote: (my response bracketed by HRL - key point in final response)

One argument suggests that only the network node being that the
printer is being viewed through is of interest with respect to network
node infromation. But the status of the printer must include the
effect of every interface to the printer (network or local).

HRL - I'll buy that. I think we're really talking about whether the
HRL - printer status (derived from the magic cookie) is BUSY or not.
HRL - Right? I think this largely boils down to hrPrinterStatus
HRL - of IDLE (3) or PRINTING (4). Other states like "Moving off line"
HRL - "Unavailable" etc, as they apply to the overall printer, won't
HRL - likely be effected by the status of one interface.

1. If there is more than one NIC, in viewing the printer through
one NIC, the SNMP presentation must be aware of the other NIC to the
same degree that it must be aware of all alternate inputs to the
printer which may affect printer and status. This means the interface
table must identify all interfaces.

HRL - Unless I'm mistaken, it doesn't seem we've captured the MIB-II
HRL - Interfaces table in the MIB walk. Did we? Anyway, I agree.

2. The view should also be able to identify that the printer is (or
is not) equipped with a second NIC. I think that a MIB-2 interface
table entry is sufficient since this is what is referenceed in the
printer MIB (that is, HR MIB inclusion as a network device seems of
dubious value).

3. It would be unreasonable and of questionable utility to provide
full MIB 2 support for one NIC through the other. This does leave
Interface table rows with nothing but ifIndex, ifDescr, and ifType
populated. Is this a problem?

HRL - I think you're making an assumption that the total number of
HRL - packets flowing to a particular network printer is of no
HRL - value. If so, I guess you could be right.

4. The report on the printer status and capabiltiesm as viewed
through an interfacem should reflect the capabities of the printer
accessible though that interface. What is the trouble youi see with
this?

HRL - **I DON'T THINK YOU CAN CLEARLY DISTINGUISH CAPABILITIES!**
HRL -
HRL - For example, see pgs 4 and 5 of the MIB walk. Not trying to
HRL - pick on any one particular vendor, but notice how vendor 1
HRL - has 15 channel types listed (pg 5) but only one ifIndex (pg 4)
HRL - and all the channel types are listed twice! This vendor says
HRL - they had 2 NIC cards in. Vendor 4 also indicated, if they'd
HRL - had 2 NICs results would be the same.
HRL -
HRL - It so happens that capabilities (services) of each NIC were
HRL - identical so you could argue there is no problem. But, what
HRL - if one NIC had a different set of services? How, then, would
HRL - the management app be able to discern capabilities with any
HRL - accuracy?
HRL -
HRL - Bill, I see what the problem is with agents in the NICs, but
HRL - I think, to assert this as a valid implementation, you almost
HRL - have to take your argument to it's extreme and state, repeating
HRL - your words, "only the network node that the printer is being
HRL - viewed through is of interest..." PERIOD!
HRL -
HRL - Of course, this still doesn't cover total packets to the printer!

Harry Lewis - IBM Printing Systems