WBMM> PWG Counter MIB - 3 model choices

WBMM> PWG Counter MIB - 3 model choices

McDonald, Ira imcdonald at sharplabs.com
Sun Feb 29 16:03:15 EST 2004


Hi,                               Sunday (29 February 2004 - 'leap day')

Here are three alternatives for structuring a PWG Counter MIB:


(1) Object-Oriented Model
    - see my recent PWG Imaging System MIB proposal
    - delete Attribute table (no configuration for services/devices)
    - define Counter table w/ dictionary counter enums, e.g.,

    IcCounterTypeTC ::= TEXTUAL-CONVENTION
    ...
    SYNTAX      INTEGER {
        other(1),                           -- non-standard counter
        unknown(2),                         -- unknown counter type

        -- impression counters
        totalImpressions(51),               -- INTEGER - Counter32
            -- total impressions printed by this system/service/device
        blankImpressions(52),               -- INTEGER - Counter32
            -- blank impressions printed by this system/service/device
        ...
    }

    - Pros: Most compact definition
            Most similar to Job MIB
            Easily extended (register new enums in separate TCs MIB)
    - Cons: Most complex for implementors


(2) Hybrid Model
    - see my recent PWG Imaging System MIB proposal
    - delete Attribute table (no configuration for services/devices)
    - define Counter table w/ classic columnar objects (not enums), e.g.

    IcCounterEntry ::= SEQUENCE {
        icCounterParentClassIndex           Integer32, -- service/device
        icCounterParentObjectIndex          Integer32, -- pointer
        icCounterInputImages                Counter32,
        icCounterOutputImages               Counter32,
        icCounterImpressions                Counter32,
        icCounterBlankImpressions           Counter32,
        icCounterBlackImpressions           Counter32,
        icCounterFullColorImpressions       Counter32,
        icCounterHighlightColorImpressions  Counter32,
        ...
    }

    - Pros: Fairly compact definition
    - Cons: Still complex for implementors
            Differs from both Job MIB and Printer MIB models
            All counters must be OPTIONAL (w/ many conformance groups)


(3) Classic Model
    - see my recent PWG Imaging System MIB proposal
    - delete Attribute table (no configuration for services/devices)
    - define _many_ counter tables w/ classic columnar objects, e.g.

    IcCopyCounterEntry ::= SEQUENCE {
        icCopyServiceIndex                  Integer32, -- pointer
        icCopyDeviceIndex                   Integer32, -- pointer
        icCopyInputJobs                     Counter32,
        icCopyInputImages                   Counter32,
        icCopyImpressions                   Counter32,
        icCopyBlankImpressions              Counter32,
        icCopyBlackImpressions              Counter32,
        icCopyFullColorImpressions          Counter32,
        ...
    }

    IcPrintCounterEntry ::= SEQUENCE {
        icPrintServiceIndex                 Integer32, -- pointer
        icPrintDeviceIndex                  Integer32, -- pointer
        icPrintInputJobs                    Counter32,
        icPrintInputKOctets                 Counter32,
        icPrintImpressions                  Counter32,
        icPrintBlankImpressions             Counter32,
        icPrintBlackImpressions             Counter32,
        icPrintFullColorImpressions         Counter32,
        icPrintHighlightColorImpressions    Counter32,
        ...
    }

    - Pros: Least complex for implementors
            Most similar to Printer MIB
    - Cons: Very high redundancy
            Very large MIB (w/ many conformance groups)
            Requires revised MIB for a new service (not just enums)



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 at sharplabs.com



More information about the Wims mailing list