WBMM> PWG Counter MIB - 3 model choices

WBMM> PWG Counter MIB - 3 model choices

McDonald, Ira imcdonald at sharplabs.com
Thu Mar 11 13:24:34 EST 2004


Hi Bill and Harry,

Thanks for the good feedback.  I'll turn to and try to generate
a detailed sketch of a PWG Counter MIB with model 2 ASAP.  It
will actually yield the most accessible XML schema translation,
I believe.

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

-----Original Message-----
From: Wagner,William [mailto:WWagner at NetSilicon.com]
Sent: Thursday, March 11, 2004 9:40 AM
To: McDonald, Ira; wbmm at pwg.org
Subject: RE: WBMM> PWG Counter MIB - 3 model choices


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 




More information about the Wims mailing list