Well, you'd think so, wouldn't you? But then you wonder
what it means for an instance of QueuingService to
surface this one piece of state information to CIM in,
say, bytes, while feeding queue-depth information to a
RED dropper that has its thresholds specified in packets.
Note that QDDIM says on page 15 that the job of modelling
state has really not been done, and hence that this
CurrentQueueDepth property is something of an anomaly.
So maybe it's OK to have a queue that will only tell *us*
its current depth in bytes, yet is perfectly willing to
tell a dropper its current depth in packets.

I see three choices we might make:

- Remove the current depth property from QueuingService,
and have it wait for the rest of the state model.
- Pick a unit for it, either bytes or packets, and
define it to always have that as its unit.
- Add a units enum as you suggest.

I could live with any of these.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore <at> us.ibm.com

"Andrea Westerinen" <andreaw <at> cisco.com>

"Andrea Westerinen" <andreaw <at> cisco.com> 05/15/02 10:16 AM

To: "Policy <at> Ietf. Org" <policy <at> ietf.org>, Robert Moore/Raleigh/IBM <at> IBMUS cc: Subject: QDDIM Question

Don't you need a DepthUnits enum for QueuingService.CurrentQueueDepth as we
have in the REDDropperService for the thresholds?

Andrea