Web-based Imaging Management Services: RE: WIMS> Counter MIB

RE: WIMS> Counter MIB - Alert table/trap proposal

From: Harry Lewis (harryl@us.ibm.com)
Date: Wed Jan 26 2005 - 11:56:07 EST

  • Next message: Wagner,William: "WIMS> No Feb 2 call...what about Feb 3?"

    Got it... thanks for the clarification.
    ----------------------------------------------
    Harry Lewis
    IBM STSM
    Chairman - IEEE-ISTO Printer Working Group
    http://www.pwg.org
    IBM Printing Systems
    http://www.ibm.com/printers
    303-924-5337
    ----------------------------------------------

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

    To
    Harry Lewis/Boulder/IBM@IBMUS, "McDonald, Ira" <imcdonald@sharplabs.com>
    cc
    "'wims@pwg.org'" <wims@pwg.org>
    Subject
    RE: WIMS> Counter MIB - Alert table/trap proposal

    Hi Harry,

    Poor names on my part. Change (for example):

                     counterErrors --> counterForErrors
                     counterWarnings --> counterForWarnings

    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: Harry Lewis [mailto:harryl@us.ibm.com]
    Sent: Wednesday, January 26, 2005 1:02 AM
    To: McDonald, Ira
    Cc: 'wims@pwg.org'
    Subject: Re: WIMS> Counter MIB - Alert table/trap proposal

    Sounds like it might be a good idea. Not sure I understand exact usage of
    "counter errors". Is this problems with the counters, counts of errors...?

    ----------------------------------------------
    Harry Lewis
    IBM STSM
    Chairman - IEEE-ISTO Printer Working Group
    http://www.pwg.org
    IBM Printing Systems
    http://www.ibm.com/printers
    303-924-5337
    ----------------------------------------------

    "McDonald, Ira" <imcdonald@sharplabs.com>
    Sent by: owner-wims@pwg.org
    01/25/2005 07:56 PM To"'wims@pwg.org'" <wims@pwg.org>
    cc
    SubjectWIMS> Counter MIB - Alert table/trap proposal

    Hi folks, Tuesday (25 January 2005)

    I propose that we add an Alert group (objects) and an Alert Trap group
    (notification) to the Counter MIB and a Counter events class to the WIMS
    Events schema.

    A monitor application that registers for 'icAlertV2Trap' notifications
    can effectively use the Counter MIB stand-alone, typically without data
    from any other MIB.

    Comments?

    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
    ----------------------------------------

    IcCounterEventTypeTC ::= TEXTUAL-CONVENTION
       STATUS current
       DESCRIPTION
           "The type of counter event in this 'icAlertTable' entry."
       REFERENCE
           "prtAlertCode in Printer MIB (RFC 1759/3805).
           PrtAlertCodeTC in IANA Printer MIB (RFC 3805
               and http://www.iana.org/assignments/ianaprinter-mib)."
       SYNTAX INTEGER {
           other(1), -- non-standard type
           unknown(2), -- unknown type

           counterCreated(3) -- counter created
           -- any counter element

           counterErrors(4), -- counter errors
           -- icTimeDownSeconds
           -- icMonitorCriticalAlerts
           -- icMonitorAbortedJobs
           -- icMonitorMemoryAllocErrors
               -- see prtAlertCriticalEvents in Printer MIB v2 (RFC 3805)
           -- icMonitorStorageAllocErrors

           counterReset(5), -- counter reset
           -- any counter element

           counterWarnings(6), -- counter warning
           -- icTimeMaintenanceSeconds
           -- icMonitorTotalAlerts (for warning alerts)
               -- see prtAlertAllEvents in Printer MIB v2 (RFC 3805)
           -- icMonitorCanceledJobs
           -- icMonitorMemoryAllocWarnings
           -- icMonitorStorageAllocWarnings

           counterWrap(7) -- counter wrap (to zero)
           -- any counter element
       }

    --
    --  Alert Group (Optional)
    --
    

    IcAlertEntry ::= SEQUENCE { -- alert index elements icAlertKeyIndex Integer32, icAlertCycleType IcCycleTypeTC, icAlertWorkType IcWorkTypeTC, icAlertIndex Integer32,

    -- alert description elements icAlertCounterEventType IcCounterEventTypeTC, icAlertCounterName DisplayString, icAlertCounterValue Integer32, icAlertDateAndTime DateAndTime, icAlertTime TimeTicks }

    -- -- Alert Trap Group (Optional) --

    icAlertV1Prefix OBJECT-IDENTITY STATUS current DESCRIPTION "The value of the enterprise-specific OID in an SNMPv1 trap sent signaling a counter event in the prtAlertTable." ::= { icAlertTrap 1 }

    icAlertV2Prefix OBJECT IDENTIFIER ::= { icAlertV1Prefix 0 }

    icAlertV2Trap NOTIFICATION-TYPE OBJECTS { icAlertCounterEventType, icAlertCounterName, icAlertCounterValue, icAlertDateAndTime } STATUS current DESCRIPTION "This trap is sent whenever a counter event is added to the icAlertTable.

    Note: The values of the icAlertKeyIndex, icAlertCyclceType, icAlertWorkType, and icAlertIndex objects are included in the instance qualifiers of the explicit variable bindings in this trap. The value of icAlertTime (i.e., sysUpTime in IETF MIB-II, RFC 1213) is always included in SNMP traps, per RFC 3416." ::= { icAlertV2Prefix 1 }

    -- Note that the SNMPv2 to SNMPv1 translation rules dictate that -- the preceding statement will result in SNMPv1 traps of the -- following form: -- -- icAlertV1Trap TRAP-TYPE -- ENTERPRISE icAlertV1Prefix -- VARIABLES { icAlertCounterEventType, icAlertCounterName, -- icAlertCounterValue, icAlertDateAndTime } -- DESCRIPTION -- "This trap is sent whenever a counter event is added -- to the icAlertTable." -- ::= 1



    This archive was generated by hypermail 2b29 : Wed Jan 26 2005 - 11:56:29 EST