Subject: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

From: "Rolf Winter" <[email-masked]>
Date: Mon, 7 Jun 2010 15:02:10 +0200

Hi,

I have a comment on the draft draft-claise-energy-monitoring-mib-03 regarding the power levels which somewhat goes into the direction of an earlier comment by Bruce Nordman. I personally see little value having a large number of predefined power-levels if it turns out that these are either

1. all different in terms of the amount of energy that they consume (across different devices)
2. do not match what is implemented or ever will be implemented (although the latter is hard to foresee)
3. need to be mapped to something that is in fact implemented
4. need additional configuration on the NMS side to interpret these levels correctly

Especially the last point I guess will happen in practice, i.e. the power state reading needs to be correlated with numbers from e.g. the device data sheet. If that is the case I would rather have only freely configurable power levels (which you allow in the draft) rather than having predefined ones that in practice mean different things and are therefore prone to misinterpretation. You have an example of where the ACPI states are mapped to whatever is implemented. I believe instead of being helpful this can be confusing in practice. Alternatively, a small number of "buckets" as described by Bruce and freely configurable power levels/modes/states per bucket are fine too.

Best,

	Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "Brad Schoening" <[email-masked]>
Date: Tue, 8 Jun 2010 11:18:35 -0400

Hi Rolf,

Thanks for your feedback here.

I have to respectfully disagree with your first point that power levels
should match some known measurement of energy consumption in watts or
watt-hrs.  Consider manual transmission cars, which typically have 'levels'
or gears 1-5.  Most drivers don't know the rpm and torque a given gear
delivers, but can happily drive their car or even an unfamiliar rental
knowing that gear one is the lowest, and five the highest, with intermediate
gears 2-3-4.  The engine power provided in 1st gear by a Land Rover vs. an
MG Midget are vastly different, but yet with a meaning crystal clear to that
driver.

In addition to the ACPI standard, I would also ask that you consider the
DMTF Power State Management Profile (DSP1027 -
http://www.dmtf.org/standards/published_documents/DSP1027.pdf) which defines
fixed power levels for on, sleep-light, sleep-deep, off-soft, off-hard.

DSP1027 has a 'PowerStatesSupported' property:

	7.2.3 CIM_PowerManagementCapabilities.PowerStatesSupported
	The PowerStatesSupported property array is used to represent the
power states 
	that are supported by the associated computer system.

PowerStatesSupported works similar to our proposed model, whereby the device
supports a subset of levels defined in the standard.  Indeed, we support all
of the Power State Management Profile levels in our model.

Given that existing devices implement ACPI levels and existing management
standards (DMTF) defining levels, how would using these cause confusion?
Instead, wouldn't we cause confusion if we didn't leverage existing fixed
power levels?

I would very much like to find more use cases here.  Perhaps there are NMS
power management standards that don't define fixed levels, but thus far I'm
not aware of any.

Regards,

Brad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rolf Winter
Sent: Monday, June 07, 2010 9:02 AM
To: [email-masked]
Subject: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi,

I have a comment on the draft draft-claise-energy-monitoring-mib-03
regarding the power levels which somewhat goes into the direction of an
earlier comment by Bruce Nordman. I personally see little value having a
large number of predefined power-levels if it turns out that these are
either

1. all different in terms of the amount of energy that they consume (across
different devices)
2. do not match what is implemented or ever will be implemented (although
the latter is hard to foresee)
3. need to be mapped to something that is in fact implemented
4. need additional configuration on the NMS side to interpret these levels
correctly

Especially the last point I guess will happen in practice, i.e. the power
state reading needs to be correlated with numbers from e.g. the device data
sheet. If that is the case I would rather have only freely configurable
power levels (which you allow in the draft) rather than having predefined
ones that in practice mean different things and are therefore prone to
misinterpretation. You have an example of where the ACPI states are mapped
to whatever is implemented. I believe instead of being helpful this can be
confusing in practice. Alternatively, a small number of "buckets" as
described by Bruce and freely configurable power levels/modes/states per
bucket are fine too.

Best,

	Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London
W3 6BL | Registered in England 2832014 

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Tom Taylor <[email-masked]>
Date: Tue, 08 Jun 2010 13:34:36 -0400

I think you are reinforcing one point that Rolf made, that interpretation of the 
levels requires additional knowledge on the manager side. Basically the question 
is whether one is using the MIB module for monitoring the behaviour of the 
equipment or the actual power consumption. As you say, use cases are needed.

---

From: "Rolf Winter" <[email-masked]>
Date: Tue, 8 Jun 2010 20:50:17 +0200

Hi,

While we're at the ACPI topic. I wonder whether the draft as it stands now violates the ACPI spec. As far as I remember the ACPI power states only mention that one means less power consumption than the other etc. >From the draft, it seems you allow to map the same freely-defined state to multiple ACPI states. Is that violating the ACPI spec as multiple ACPI states do not differ in reality anymore? 

Best,

	Rolf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brad Schoening
Sent: Dienstag, 8. Juni 2010 17:19
To: Rolf Winter; [email-masked]
Subject: Re: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Rolf,

Regards,

Brad

-----Original Message-----

Hi,

Best,

	Rolf

---

From: "Juergen Quittek" <[email-masked]>
Date: Tue, 8 Jun 2010 21:29:08 +0200

Hi Brad,

It's good to get deeper into this discussion.

The DMTF model that you pointed to has defined at least 16 power states
(not counting 'DMTF reserved' and 'Vendor specific'):
   Other, On, Sleep - Light, Sleep -Deep, Power Cycle (Off - Soft),
   Off - Hard, Hibernate (Off - Soft), Off - Soft, Power Cycle (Off-Hard),
   Master Bus Reset, Diagnostic Interrupt (NMI), Off - Soft Graceful,
   Off - Hard Graceful, Master Bus Reset Graceful,
   Power Cycle (Off - Soft Graceful), Power Cycle (Off - Hard Graceful),
   DMTF Reserved, Vendor Specific

Your model has 'just' 12.
How did you select the ones from DMTF that you support?

Anyway, I don't think we should argue about the 'right' number
of power states. In the MIB module that we suggest there is a
power state table instead of an enumeration of pre-defined states.

There you can specify a name for each state, for example,
"DMTF-sleep-Light" or "ACPI-hard-off", and optionally add things
like 'average power in this state' or 'maximum power in this state'.

This is fully flexible for supporting DMTF as well as ACPI as well as
any other (future) standard with a different fixed number or different
definitions of power states. It would also be fine to follow the
minimalistic approach from EnergyStar to just have three states
(off/low-power/on).

Best regards,

    Juergen

> Hi Rolf,
 [snip]

---

From: "Brad Schoening" <[email-masked]>
Date: Tue, 8 Jun 2010 15:41:16 -0400

Tom,

I'm sorry, but I don't follow your comment that "interpretation of the
levels requires additional knowledge on the manager side"  Could you please
elaborate on why you feel the DMTF PowerState enumeration level are flawed.

As I see them, DMTF PowerState and ACPI provide :

1) useful and clear levels 

2) excellent integration points for manageability and 

3) correspondence between the two models. 

Finally, is it a realistic to ignore these two standards?  I'd guess
practitioners would prefer that an IETF MIB standard offer correspondence as
well.

>From DSP1027:

Table 3 - DMTF PowerState Values and ACPI States PowerState enum Value
(interpreted as a verb in the RequestPowerStateChange( ) method) 

Description 

Corresponding ACPI State 

2 (On) 

Bring system to full On from any state (Sleep, Hibernate, Off) 

G0 or S0 Working 

3 (Sleep-Light) 

Standby 

S1 or S2 

4 (Sleep-Deep) 

Suspend 

S3 

5 (Power Cycle (Off-Soft)) 

Reset system without removing power 

S0 with context fully lost: 

. Requires master bus reset of entire system 

. Requires full boot from POST and BIOS 

6 (Off-Hard) 

Power Off performed through mechanical means like unplugging power cable or
UPS On 

G3 

7 (Hibernate (Off-Soft)) 

System context and OS image written to non-volatile storage; system and
devices powered off 

S4 

8 (Off-Soft) 

System power off but auxiliary or flea power may be available 

G2 or S5 

9 (Power Cycle (Off-Hard)) 

Equivalent to Off-Hard followed by 

Go to G3, then return to S0 

10 (Master Bus Reset) 

Hardware reset 

S5 

11 (Diagnostic Interrupt (NMI)) 

Hardware reset 

S5 

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]] 
Sent: Tuesday, June 08, 2010 1:35 PM
To: Brad Schoening
Cc: 'Rolf Winter'; [email-masked]
Subject: Re: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

I think you are reinforcing one point that Rolf made, that interpretation of
the 

levels requires additional knowledge on the manager side. Basically the
question

---

From: "Juergen Quittek" <[email-masked]>
Date: Tue, 8 Jun 2010 22:07:29 +0200

Hi Brad,

Thanks for sending the mapping of your power state model
to the DMTF power states. DMTF power states 12-16 seem
to be missing in your table.

Are there good reasons for not considering them?

Best regards,

    Juergen

---

From: "Brad Schoening" <[email-masked]>
Date: Tue, 8 Jun 2010 16:10:13 -0400

Juergen,

We used the widely implemented ACPI as the starting point and don't define
the transition requests found in DMTF like Power Cycle (Off - Soft),
Diagnostic Interrupt, Master Bus Reset, etc.  Perhaps they'd be useful. 

I'd refer you to DSP1027 Table 3 which provides a cross reference, which
I've reproduced in image below and annotated with our PowerMonitorLevels 

 

Regards,

Brad

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Tuesday, June 08, 2010 3:29 PM
To: Brad Schoening; [email-masked]
Subject: Re: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Brad,

(off/low-power/on).

Best regards,

    Juergen

 [snip]

---

From: "Brad Schoening" <[email-masked]>
Date: Tue, 8 Jun 2010 16:18:57 -0400

Juergen,

That table is not mine, but take from DMTF DSP1027, Table 3.  Please see
attached GIF.

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Tuesday, June 08, 2010 4:07 PM
To: Brad Schoening; Tom Taylor
Cc: [email-masked]
Subject: Re: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Brad,

Best regards,

    Juergen

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 8 Jun 2010 13:39:27 -0700

Hi -

> From: "Brad Schoening" <[email-masked]>
> To: "'Juergen Quittek'" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, June 08, 2010 1:10 PM
...

It seems to me that there are perhaps two attributes here:
  - current power state: read only, values are
    on, light sleep, deep sleep, soft off, hard off
  - "power" actions: write
    on, light sleep, deep sleep, soft off, hard off, 
    soft cycle, hard cycle, hibernate, reset, NMI

But this still leaves me wondering...
Why are actions like Master Bus reset and the application of
a non-maskable interrupt (NMI) included in these lists?  They're
clearly not states, and don't seem to have much to do with
adjusting the level of power consumption.

Randy

---

From: "Juergen Quittek" <[email-masked]>
Date: Tue, 8 Jun 2010 22:39:29 +0200

Hi Brad,

The DMTF standards publishing procedures can be even more
Confusing than the IETF RFC publishing procedures ;-)

You probably cited version 1.0.0c of DSP1027 from 2007-02-13
which is labeled "preliminary standard".
This one indeed shows 12 power states in Table 3 but it was
already outdated in 2008 and is not listed anymore on the DMTF
"published standards" web page.

After this there was version 1.0.0 of DSP1027 from 2008-05-23
labeled "final standard".
This one shows 16 states in Table 3, see
http://www.dmtf.org/standards/published_documents/DSP1027_1.0.0.pdf

Then there was version 1.0.1 of DSP1027 with Table 3 unchanged, see
http://www.dmtf.org/standards/published_documents/DSP1027_1.0.1.pdf

The most recent version is 2.0.0 of DSP1027 showing only 6 power
states in Table 3, see
http://www.dmtf.org/standards/published_documents/DSP1027_2.0.0.pdf

I am optimistic that this series has not come to an end and will
continue contributing material to our discussion.

I still suggest not to fix the number of power states.

Best regards,

    Juergen

---

From: "Brad Schoening" <[email-masked]>
Date: Wed, 9 Jun 2010 01:16:32 -0400

Hi Rolf,

You did not include as reasons for a Power State attribute what we see as
the most important reason by far, 

	C) monitor and control of the current energy consumption of a
device.  For monitoring, to query if
         a device is in a energy conserving state or fully powered.  For
configuration control, to 
         switch a device from a high power operational state into a lower
one; or to transition
         a device into a non-operational state like sleep, hibernate or soft
off.  Management of
         power state can be effected on a schedule, such as using low-power
or sleep modes overnight.

I suppose if we can agree on these reasons for having a Power State
variable, then we can more easily reach the correct conclusion.  Given that
you might accept that C) this is somewhat important, let us consider two
typical power management use cases:

	1. set a device into an operation but low-power state during
expected idle hours
	2. set a device from an operational into a sleep state 

How would a free-form text field for state be efficiently managed by a NMS?
If state names vary from product-to-product and vendor-to-vendor, it would
seem very hard to define at the NMS what state to pick for 'sleep' for a
device. Juergen suggests we could have a variety of names like
"DMTF-sleep-deep", "ACPI-hibernate", and perhaps "vendorB-hibernate",
"hbrnt-vendorC", "not-awake-vendorD".  I don't see how an NMS could
effectively handle the two use cases above in this environment.  Indeed,
this doesn't seem any better than just using the vendors proprietary MIB for
power management.  Finally, in this situation, a device that supports both
DMTF, ACPI, and custom levels would have a conflict over which name string
to use.

Regarding the history of ACPI, it has been a standard for almost 15 years,
since 1996, and with the latest revision 4.0 released recently, in June
2009.  Sure, ACPI could always change or be abandoned, but is the accepted,
de facto PC and CPU power management standard today.  

Regards,

Brad

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: Tuesday, June 08, 2010 12:26 PM
To: Brad Schoening
Subject: RE: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Brad,

Leaving automobiles for a minute, to me, there are two main reasons to have
power states:

A) equipment that has no instrumentation to report measured power
consumption can report a power state and a NMS can deduct what that might
mean in terms of power consumption, even if obviously not precisely (this is
not defined by ACPI. But I think this is important for an efficient power
management strategy unless you're happy knowing that on average you use less
power than, say D2, which is what you seem to suggest with your analogy,
without knowing what D2 means in practice)

B) the power state is an operational state which can show you things like
utilization (i.e. low power state might mean low utilization) and current
capabilities (i.e. low power state might mean that the full functionality is
not available right now or it might tell you how fast you can get from the
current into the another state)

Whatever the power state is, the NMS needs to know what that actually means,
i.e. it needs to be configuring with the needed knowledge as ACPI is vague
on these issues. The above will also be vastly different from device to
device and will evolve over time. Having fixed classes potentially either
miss much of the above, or people will start to map their own stuff to these
fixed classes over time. In either case the NMS needs to know what all this
means as it is not encoded in an ACPI state. Actually, with ACPI you would
also need to add the device class on top, which I believe is not part of
your MIB. 

Additionally, ACPI had a predecessor (APM) and there might be another one
after ACPI or changes to ACPI etc. Having user defined-only states will make
the MIB independent from these developments. These states could come spiced
up with the information needed by the NMS. Also, some people have expressed
a quite different perception of the power states as implemented and proposed
in standards. Maybe Bruce Nordman could expand on an earlier Email?

Best,

	Rolf

-----Original Message-----
Brad Schoening

Hi Rolf,

Regards,

Brad

-----Original Message-----

Hi,

Best,

	Rolf

---

From: "Rolf Winter" <[email-masked]>
Date: Wed, 9 Jun 2010 14:13:08 +0200

Hi Brad,

you missed two important points in my mail. I said I am fine with a low number of buckets as proposed by Bruce. I think this solves your first problem. Additionally, I mentioned that these states should be spiced up with additional information, i.e. it should not be "just" an arbitrary string but something that hands useful information to the NMS.

Best,

	Rolf

-----Original Message-----
From: Brad Schoening [mailto:[email-masked]] 
Sent: Mittwoch, 9. Juni 2010 07:17
To: Rolf Winter
Cc: [email-masked]
Subject: RE: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Rolf,

Regards,

Brad

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: Tuesday, June 08, 2010 12:26 PM
To: Brad Schoening
Subject: RE: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Brad,

Best,

	Rolf

-----Original Message-----

Hi Rolf,

Regards,

Brad

-----Original Message-----

Hi,

Best,

	Rolf

---

From: "Juergen Quittek" <[email-masked]>
Date: Wed, 9 Jun 2010 14:24:49 +0200

Hi Brad,

You claim that without fixed names for power states the NMS would not
know how to switch on or off a device, because it may be difficult to
Guess from the name which state is an "on", "sleep", or "off" state.

Well, in our proposal you can specify for each power state an estimated
average power and a peak power value. I think an NMS could easily
identify off states by checking for average and peak power values
equal to or very close to zero, while on power states could easily
be identified by a peak power value close to the the nameplate power.

Thus, the identification of on and off states should not be a real issue.

Still, I would have no problem with adopting the bucket approach
suggested by Bruce and supported by Rolf. This could be implemented
As an attribute of a power state with allowed values
( "off" | "sleep" | "on" | "other" ).

Best regards,

    Juergen

---

From: "Brad Schoening" <[email-masked]>
Date: Wed, 9 Jun 2010 09:18:44 -0400

Rolf,

Actually, the first use case I gave was to set a device into a lower power
but still operational state.  We haven't really discussed this yet, but I
would like to learn more details of how the NEC proposal would work.  

For example, on Microsoft Windows there are three operational states:
Power saver, Balance, High performance.  How would the NEC MIB work to
transition a PC from High performance to Power saver?

Regarding three state 'buckets', I have two specific concerns:

1. soft-off is missing.  For PC's, this state allows Wake-on-LAN to
function.  Also, forthcoming IP phones will have a soft-off mode.  I think
it would be a mistake to ignore this.

2. Existing hardware already implement sleep state "nerd knobs" of ACPI
S1..S4. if we should plan to ignore these, its critical we give detailed and
cogent argument as to why we won't support ACPI sleep states.  Without
recognizing S1..S4, we probably won't be able to put a ACPI device to sleep,
since we won't know if it should be in ready, hibernate or save-to-ram.
Thus, using a single bucket for sleep may prevent us from using sleep mode
on real devices.

I'd like to hear more about your "spice" for these states.

Regards,

Brad

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: Wednesday, June 09, 2010 8:13 AM
To: Brad Schoening
Cc: [email-masked]
Subject: RE: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Brad,

you missed two important points in my mail. I said I am fine with a low
number of buckets as proposed by Bruce. I think this solves your first
problem. Additionally, I mentioned that these states should be spiced up
with additional information, i.e. it should not be "just" an arbitrary
string but something that hands useful information to the NMS.

Best,

	Rolf

-----Original Message-----
From: Brad Schoening [mailto:[email-masked]] 
Sent: Mittwoch, 9. Juni 2010 07:17
To: Rolf Winter
Cc: [email-masked]
Subject: RE: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Rolf,

Regards,

Brad

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: Tuesday, June 08, 2010 12:26 PM
To: Brad Schoening
Subject: RE: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Brad,

Best,

	Rolf

-----Original Message-----

Hi Rolf,

Regards,

Brad

-----Original Message-----

Hi,

Best,

	Rolf

---

From: "Rolf Winter" <[email-masked]>
Date: Wed, 9 Jun 2010 16:07:16 +0200

Hi Brad,

Quoting myself here from an earlier Email:

"Alternatively, a small number of "buckets" as described by Bruce and freely configurable power levels/modes/states per bucket are fine too.". So you're not restricted to three, also not to 12. As for the spice, see Juergen's Email earlier for examples. 

Best,

	Rolf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brad Schoening
Sent: Mittwoch, 9. Juni 2010 15:19
To: Rolf Winter
Cc: [email-masked]
Subject: Re: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Rolf,

Regards,

Brad

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: Wednesday, June 09, 2010 8:13 AM
To: Brad Schoening
Cc: [email-masked]
Subject: RE: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Brad,

Best,

	Rolf

-----Original Message-----
From: Brad Schoening [mailto:[email-masked]] 
Sent: Mittwoch, 9. Juni 2010 07:17
To: Rolf Winter
Cc: [email-masked]
Subject: RE: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Rolf,

Regards,

Brad

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: Tuesday, June 08, 2010 12:26 PM
To: Brad Schoening
Subject: RE: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Brad,

Best,

	Rolf

-----Original Message-----

Hi Rolf,

Regards,

Brad

-----Original Message-----

Hi,

Best,

	Rolf

---

From: "Juergen Quittek" <[email-masked]>
Date: Wed, 9 Jun 2010 16:11:57 +0200

Hi Brad,

> transition a PC from High performance to Power saver?

I think my previous email on this list explained how we do it.

> Thus, using a single bucket for sleep may prevent us from using sleep mode

I don't claim that it is useful to know more about the managed systems.
But you can add an arbitrary number of power management use cases where
some more information is needed. And each of them requires you to add
another power state.
To pick up your example where you claim it is important to understand
whether a sleeping device is in hibernate or in save-to-RAM mode.
I would claim that for correctly reporting save-to-RAM you would need
two states: 
  - save-to-RAM-with-save-to-disc (MacOS)
  - save-to-RAM-without-save-to-disc (Windows XP)

And I could go on being picky on other states. There are too many of them
And it would be hard to fix the number of required ones.

If you really want to have many of them fixed, then probably the right
way to do so in the IETF is going for a IANA registry.

Maybe we can take this as a reasonable compromise for solving this issue.

Best regards,

    Juergen

---

From: "Brad Schoening" <[email-masked]>
Date: Wed, 9 Jun 2010 10:31:43 -0400

>  - save-to-RAM-without-save-to-disc (Windows XP)

Mac & Windows both use Intel architectures, so they must both map to known
ACPI states.

>way to do so in the IETF is going for a IANA registry.

ACPI and DMTF we able to settle on a few, well understood states.  DMTF felt
it useful to correlate their CIM model with ACPI.  We ought to be able to do
no less.

---

From: "Juergen Quittek" <[email-masked]>
Date: Wed, 9 Jun 2010 17:01:48 +0200

Hi Brad,

> Mac & Windows both use Intel architectures, so they must both map to known

You seem to contradict yourself. You argued that for OPERATIONAL reasons
it is necessary to distinguish certain states. I brought an example
where ACPI is not sufficient for operational reasons.

Of course Windows and MacOS can map to the limited list of ACPI states - in
the absence of better fitting ones. But sometimes it does not make perfect
sense to do so - for operational reasons.

> it useful to correlate their CIM model with ACPI.  We ought to be able to do

In the first versions (1.0.0/1.0.1) of their standard,
the DMTF mapped all their 15 power states to ACPI.
However, in the most recent version (2.0.0) they changed this.
Only 6 out of 15 power states are still mapped to ACPI.

What do you mean with "We ought to be able to do no less"?
No less than 6? No less than 15?

Best regards,

    Juergen

---

From: "Rolf Winter" <[email-masked]>
Date: Wed, 9 Jun 2010 17:22:13 +0200

Hi,

Maybe a little more descriptive text helps. There are a few states that are sort of well understood on a high level (but ill defined and implemented in vastly different ways). Now, these I see as buckets, but let's not get into discussion of whether 3 or 4 is the right number for now. Only as an example here I pick 3 (on, sleep, off). Now within those buckets you are free to define whatever modes you have implemented. If they are ACPI, fine, if something else, not an issue. For existing standards you could define a textual convention to represent them, that's good, but I see no value in solely allowing those states. Bruce earlier gave a bunch of examples of things you might want to consider to manage using this MIB module as well such as appliances, cars... you name it. So ACPI fit nicely into this model I believe, but anything else does too.

I hope this makes things clearer.

Best,

	Rolf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf Winter
Sent: Mittwoch, 9. Juni 2010 16:07
To: Brad Schoening
Cc: [email-masked]
Subject: Re: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Brad,

Best,

	Rolf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brad Schoening
Sent: Mittwoch, 9. Juni 2010 15:19
To: Rolf Winter
Cc: [email-masked]
Subject: Re: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Rolf,

Regards,

Brad

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: Wednesday, June 09, 2010 8:13 AM
To: Brad Schoening
Cc: [email-masked]
Subject: RE: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Brad,

Best,

	Rolf

-----Original Message-----
From: Brad Schoening [mailto:[email-masked]] 
Sent: Mittwoch, 9. Juni 2010 07:17
To: Rolf Winter
Cc: [email-masked]
Subject: RE: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Rolf,

Regards,

Brad

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: Tuesday, June 08, 2010 12:26 PM
To: Brad Schoening
Subject: RE: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Brad,

Best,

	Rolf

-----Original Message-----

Hi Rolf,

Regards,

Brad

-----Original Message-----

Hi,

Best,

	Rolf

---

From: "Brad Schoening" <[email-masked]>
Date: Wed, 9 Jun 2010 11:31:56 -0400

Juergen,

As Randy Presuhn pointed out, the DMTF table in 1.0.0 includes both current
power states & power actions.  Version 2.0.0 just includes the current power
states.  So, there was a change of format, but not of substance. 

IMHO, we ought to be able to do no less than what the DMTF Power State
Management Profile does in supporting existing hardware standards.
Otherwise, users will by necessity have to use CIM for power management.

I don't see the contradiction you point out.  I presume MacOS
save-to-RAM-with-save-to-disc can be mapped to a single ACPI S-state. 

Regards,

Brad

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Wednesday, June 09, 2010 11:02 AM
To: Brad Schoening; Rolf Winter
Cc: [email-masked]
Subject: Re: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Brad,

Best regards,

    Juergen

---

From: "Juergen Quittek" <[email-masked]>
Date: Wed, 9 Jun 2010 22:04:25 +0200

Hi Brad,

> states.  So, there was a change of format, but not of substance.

There was a change. If you read the text above Table 3, you will find:
   
    "The PowerState values not represented in Table 3
     do not have any corresponding ACPI power states."

There are only 6 values in the table, the other 9 values are not listed.
Consequently, the DMTF does not have a mapping to ACPI for them anymore
as it had in the past.

> Otherwise, users will by necessity have to use CIM for power management.

Since the CIM standard for power management is out for some time
already, I am sure that several users do this already.

What do you think about the proposal of creating an IANA registry
for power states?  

We could register all DMTF power states there and as well we could
register all possible combinations of ACPI global System states G0-G3,
power states D0-D3, sleeping states S1-S5, processor power states C0-C3,
and device performance states P0-Pn.

What I think we definitely should NOT do is defining another
set of power states by ourselves, even if we can map them to
some members of the huge of the ACPI power state family.
Then let's rather say we adopt the DMTF states 2-16 and take
them as defined in the DMTF standard without re-defining them.

But I would rather prefer to move that to a registry. The registry
could start like the DMTF power stae list with number 1 for
"other" states and then use numbers 2-16 for DMTF states 2-16.
Further ACPI states that you consider important could be added
as well to the registry.

> save-to-RAM-with-save-to-disc can be mapped to a single ACPI S-state.

Well, of course MacOS maps this state to ACPI S3. But the mapping is
not perfect, because ACPI does not provide such a state sufficiently.
And if we look closer at other operating systems of PCs and of network
Devices, we will find more situations where ACPI does not provide
a good match or at least does not clearly indicate which state to
choose. Maybe this is one of the reasons why the DMTF withdraw ist
Mapping to many ACPI states. Is anyone reading this involved in the
DMTF and can tell us the real reason?

Best regards,

    Juergen

---

From: "Brad Schoening" <[email-masked]>
Date: Wed, 9 Jun 2010 17:09:15 -0400

Juergen,

DSP 1027 Version 1.0.0 "Table 3" has states 2..16
DSP 1027 Version 2.0.0 "Table 3" has states 2..4 and 6..8 

The "PowerState" enum values removed in version 2.0.0 of Table 3 were all
transition actions, not really states at all.  So the correspondence between
DMTF v1 and v2 with ACPI remained the same as far as I can see.

Here are the 9 items removed that really aren't states but actions:

5) Power Cycle (Off-Soft)
9) Power Cycle (off-Hard)
10) Master Bus Reset
11) Diagnostic Interrupt
12) Off-Soft (Graceful) 
13) Off-Hard (Graceful)
14) Master Bus Reset Graceful
15) Power Cycle Off-Soft Graceful
16) Power Cycle Off-Hard Graceful

Thus, what remains in Version 2.0.0 are:

2) On				S0
3) Sleep - light		S1 or S2
4) Sleep - deep		S3
6) Off - hard		G3
7) Hibernate		S4
8) Off - soft		S5

Here the DMTF has combined S1 & S2 into a single state.  Otherwise, it
matches both ACPI and our draft mib's 6 non-operational states.

Now, you can partition these into Bruce's buckets and you would get a tree
(right-to-left):

	Operational			On

	Non-Operational:		Sleep - light
	Non-Operational:		Sleep - deep
			
	Non-Operational:		Off - hibernate
	Non-Operational:		Off - soft
	Non-Operational:		Off - hard

I would have to research a little on how IANA registration of power states
would work to give you a fair answer.  Are there examples of other MIBs that
use IANA registrations for enumerations and/or values?

Regards,

Brad

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Wednesday, June 09, 2010 4:04 PM
To: Brad Schoening
Cc: [email-masked]
Subject: Re: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Brad,

   

Best regards,

    Juergen

>>> mean in terms of power consumption, even if obviously not precisely
(this
>> is
>>> capabilities (i.e. low power state might mean that the full
functionality
>> is