PMP Mail Archive: RE: PMP> Comments on Printer Port Monitor

RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft dated March 21, 2005

From: Bergman, Ron (Ron.Bergman@rpsa.ricoh.com)
Date: Mon Mar 28 2005 - 13:21:39 EST

  • Next message: McDonald, Ira: "RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d ated March 21, 2005"

    Dennis' comments seem to echo the concern I voiced last week. And I agree with Dennis that a unique
    value of hrDeviceIndex is not needed for each service. I have also reviewed the document and do not find
    any text that indicates the value of hrDeviceIndex cannot be the same for all services.
     
    hrDeviceIndex references a "device" and should not be overloaded to also indicate a port within a device.
    Although I cannot speak for all printers, in the implementations I am familiar with, it is very unlikely that
    only an LPR port or a raw socket port is "down". If a port is disabled (per the configuration), as Dennis
    stated, it will not be present in the MIB. The MIB should be essentially "Static" and only be modified by
    a configuration change.
     
        Ron

    -----Original Message-----
    From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf Of Dennis Carney
    Sent: Monday, March 28, 2005 9:10 AM
    To: pmp@pwg.org; McDonald, Ira
    Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d ated March 21, 2005

    Hi Ira,

    I would have said that if specifically the LPR port is down for whatever reason, it wouldn't be listed in the MIB. This opinion was my first (intuitive) reaction, but it also does not seem to be wrong based on a quick reading of the document.

    Is there a feeling among the people who have been working the most on this MIB that it is supposed to be "static"--have essentially hard-coded rows and values for a given printer model? If so, this should probably be made clear in the document.

    Dennis Carney
    IBM Printing Systems
    Inactive hide details for "McDonald, Ira" ' src="cid:141164917@28032005-2019" width=16>"McDonald, Ira" <imcdonald@sharplabs.com>

            "McDonald, Ira" <imcdonald@sharplabs.com>

            03/27/2005 09:30 AM

    To

    Dennis Carney/Boulder/IBM@IBMUS, "McDonald, Ira" <imcdonald@sharplabs.com>, pmp@pwg.org

    cc

            

    Subject

    RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d ated March 21, 2005
                     

    Hi Dennis,

    OK - I probably picked an unwise example.

    If one software channel (LPR) is down, because the thread
    crashed (or the operator took down the LPR service), then
    EVERY software channel is going to show as down, on your
    network printer (remember MS does NOT read Printer MIB).

    You're conflating all hardware status with the software
    status of channels/interpreters.

    But you're welcome to decide this is 'normal' behavior.

    Cheers,
    - Ira

    Ira McDonald (Musician / Software Architect)
    Blue Roof Music / High North Inc
    PO Box 221 Grand Marais, MI 49839
    phone: +1-906-494-2434
    email: imcdonald@sharplabs.com
    -----Original Message-----
    From: Dennis Carney [ mailto:dcarney@us.ibm.com]
    Sent: Saturday, March 26, 2005 4:37 PM
    To: McDonald, Ira; pmp@pwg.org
    Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d
    ated March 21, 2005

    Hi Ira,

    Ira wrote:
    >If a vendor implements a single 'hrDeviceIndex' value for all ports (i.e.,
    channels)
    >on the "same" printer, then if ANY port is 'down' in 'hrDeviceStatus' they
    will ALL
    >be shown 'down' in the MS tools. That's not acceptable behaviour.

    To me, that *does* seem like acceptable behavior (or if you'd prefer,
    "behaviour"--is that your proximity to Canada showing? :-).

    If I am a single network printer advertising both an LPR port and a RAW
    port, if my one input tray is out of paper, then *both* ports *should* be in
    an "out of paper" state in the host resources MIB.

    If instead I want to differentiate between the two (I really can't think of
    many good reasons to do this on a network printer), I can do this using two
    different indices into the hr MIB. But I would have guessed that 99% of
    network printers would simply have all advertised ports (correctly, IMHO)
    point to the same hr MIB entry.

    Dennis Carney
    IBM Printing Systems
    "McDonald, Ira" <imcdonald@sharplabs.com>

    "McDonald, Ira" <imcdonald@sharplabs.com>
    03/26/2005 09:12 AM

    To
    Dennis Carney/Boulder/IBM@IBMUS, pmp@pwg.org

    cc
    "Adams, Charles A" <charles.a.adams@office.xerox.com>, "'Bergman, Ron'"
    <Ron.Bergman@rpsa.ricoh.com>, mfenelon@windows.microsoft.com

    Subject
    RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d ated March
    21, 2005

    Hi Dennis,

    The Introduction and Background were recently added, for boilerplate
    reasons.
    They are not authoritative and in fact have not been reviewed.

    Microsoft is NOT using the Printer MIB for status at all in Longhorn (per
    Mike
    Fenelon). The 'hrDeviceTable' and 'hrPrinterTable' in the Host Resources MIB

    are the only status that will be displayed by Longhorn for printer ports.

    If a vendor implements a single 'hrDeviceIndex' value for all ports (i.e.,
    channels)
    on the "same" printer, then if ANY port is 'down' in 'hrDeviceStatus' they
    will ALL
    be shown 'down' in the MS tools. That's not acceptable behaviour.

    Cheers,
    - Ira

    Ira McDonald (Musician / Software Architect)
    Blue Roof Music / High North Inc
    PO Box 221 Grand Marais, MI 49839
    phone: +1-906-494-2434
    email: imcdonald@sharplabs.com
    -----Original Message-----
    From: Dennis Carney [ mailto:dcarney@us.ibm.com]
    Sent: Friday, March 25, 2005 2:43 PM
    To: pmp@pwg.org
    Cc: Adams, Charles A; McDonald, Ira; 'Bergman, Ron';
    mfenelon@windows.microsoft.com
    Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d
    ated March 21, 2005

    Ira, My reading of the "Introduction" and the "Background" of the document
    seems to make it clear that the main MS model *IS* an embedded printer.

    Mike Fenelon, is it really true that your port monitor makes it such that
    each port *has to* have a different ppmPortHrDeviceIndex? If a network
    printer implemented this MIB and advertised both an LPR and a RAW port,
    would you really have a problem if both ports had a ppmPortHrDeviceIndex of
    1?

    Dennis
    "McDonald, Ira" <imcdonald@sharplabs.com>

    "McDonald, Ira" <imcdonald@sharplabs.com>
    Sent by: pmp-owner@pwg.org
    03/25/2005 09:14 AMTo
    "'Bergman, Ron'" <Ron.Bergman@rpsa.ricoh.com>, "McDonald, Ira"
    <imcdonald@sharplabs.com>, "Adams, Charles A"
    <charles.a.adams@office.xerox.com>, pmp@pwg.org
    cc
    Subject
    RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d ated March
    21, 2005

    Hi Ron,

    Going all the way back to the first Microsoft draft and ever since,
    it's clear that the MS "port" entry has to have a separate device
    index for each port, because the 'hr...' status objects have to be
    separate for EACH port.

    Remember the main MS model is NOT an embedded printer. It's either
    an external network adaptor or a spooler. In both of these cases,
    only ONE protocol is being exposed fore each "port".

    This isn't a new restriction.

    In the case of an external network adaptor, each "port" is literally
    a different direct-connect printer.

    Cheers,
    - Ira

    Ira McDonald (Musician / Software Architect)
    Blue Roof Music / High North Inc
    PO Box 221 Grand Marais, MI 49839
    phone: +1-906-494-2434
    email: imcdonald@sharplabs.com

    -----Original Message-----
    From: Bergman, Ron [ mailto:Ron.Bergman@rpsa.ricoh.com]
    Sent: Thursday, March 24, 2005 3:03 PM
    To: McDonald, Ira; Adams, Charles A; pmp@pwg.org
    Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft
    dated March 21, 2005

    Ira,

    Regarding your comment:

    2. ppmPortHrDeviceIndex - This seems to imply an hrDeviceTable entry is
    needed for each port on the system. Is this the expected behavior?
    Or is this just the hrDeviceIndex of the printer?
    Or is the the hrDeviceIndex for the network card?

    <ira> For the Microsoft tool (TCPMon), EACH port (channel) has to
    have a separate 'hrDeviceIndex' - this is different than typical
    Printer MIB implementations, but it's a Microsoft tool limitation.
    Note that Microsoft TCPMon _only_ supports LPR and Raw ports (no
    other protocol is supported or contemplated according to co-editor
    Mike Fenelon from the Microsoft Longhorn printing team), so this
    only means two 'hrDeviceIndex' values at most (for each printer).
    </ira>

    I do not recall ever hearing this. It certainly is not clear from
    the MIB text (see below) that this is the case. If this is true
    then it is not really hrDeviceIndex that is indicated but is just
    ppmPortIndex.

    Also, for the printers I work with there will be a minimum of 10
    ports reported. If IPP is enable, there will be a minimum of 15.
    The maximum number will be 192.

    Ron

    From the MIB:
    ppmPortHrDeviceIndex OBJECT-TYPE
     SYNTAX Integer32 (0..2147483647)
     MAX-ACCESS read-only
     STATUS current
     DESCRIPTION
    "The value of 'hrDeviceIndex' in the IETF Host Resources MIB
    (RFC 1514/2790), to be used for status queries for this port if
    the value of 'ppmPortSnmpStatusQueryEnabled' is 'true'.

    If this object is zero, then monitoring applications MUST NOT
    attempt status queries for this port in the IETF Host Resources
    MIB (RFC 1514/2790) and/or IETF Printer MIB (RFC 1759/3805)."
     REFERENCE
    "hrDeviceStatus, hrPrinterStatus, hrPrinterDetectedErrorState i
    n IETF Host Resources MIB (RFC 1514/2790).
    prtChannelStatus in IETF Printer MIB (RFC 1759/3805)."
     DEFVAL { 0 } -- no host device index
     ::= { ppmPortEntry 7 }



    graycol.gif

    ecblank.gif



    This archive was generated by hypermail 2b29 : Mon Mar 28 2005 - 13:21:55 EST