Ira,
In checking with Harry, the (yet unpublished) minutes of the last phone conference indicate that the consensus was to proceed with your alternative 2. We appreciate your efforts on this. Although we recognize that defining the counters in MIB form requires more effort, the inital idea was that we were defining these new counter elements as desirable management objects, not just for WBMM but for other management protocols. So our preference to go through the MIB process. But, of course, the schema is our primary requirment.
Bill Wagner
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Sun 2/29/2004 4:03 PM
To: 'wbmm at pwg.org'
Cc:
Subject: WBMM> PWG Counter MIB - 3 model choices
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