Subject: Re: [eman] Terminology: power states - battery state - power supplystate

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Nov 2011 18:01:00 +0800

Juergen, all,

Checking consensus here.
Are we now fine with the Power State and Power State Set from 
http://tools.ietf.org/html/draft-parello-eman-definitions-03?
Btw, I don't think that we need the Manufacturer Power State in any of 
the draft, do we?

Regards, Benoit.
> Hi,
>
> For states I put the terms Power State and Power Series to reflect what
> we discussed at the last two meetings.
>
> I don't see a distinction between the state as they refer to a battery
> or a simple device. As we discussed at IETF81 (I think Juergen S brought
> it up) why not keep the same information for the battery.
>
> I kept it simple in the definition and if there's new terms from this
> thread please do let me know.
>
> Jp
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Juergen Quittek
> Sent: Saturday, August 13, 2011 5:32 PM
> To: eman mailing list
> Subject: [eman] Terminology: power states - battery state - power
> supplystate
>
> Dear all,
>
> Here are some thoughts on what a power state is and how it relates to
> the battery state and the power supply state of a device.
>
> So far, there is no document where we clearly define what a power state
> is and what it is not. Please find a list of definitions that I
> collected from other documents further below.  This email mainly serves
> for sharing some thoughts on this issue in order to jointly work on a
> more clear definition of a power state.
>
> My main question is: What is characteristic for a power state?
> 1. the operational state (Is the device not/fully/partially
> operational)?
> 2. the power consumption in a power state? (min/max/average
> power/demand)?
> 3. the power supply state (running on mains/battery/self-generated
> power)?
> 4. the total power balance (consuming/providing power)?
>
> As we have discussed it in the eman WG and as other standards bodies
> including DMTF, ACPI, PWG see it, it is just 1. with some implications
> on 2. Here is another try on a definition of a power state:
>
>     "A power state represents one or multiple operational states of a
> device.
>     A power state indicates specific properties of a device concerning
> its the energy
>     consumption when being in this state."
>
> Of course this one cries for definitions of an operational state.
>
> Operational state:
>     "An operational state defines the availability of services provided
> by a device."
>
> We certainly need some more text elaborating on power states beyond the
> plain definition, maybe in the framework document.  There is one note
> that I would definitely like to add there:
>
>     "Energy consumption of a device is not the only state to be
> considered
>     when managing the power supply of a device. If the device contains
> batteries
>     or facilities for energy harvesting/generation, also the battery
> charging state
>     and the power supply state of a device need to be considered. For
> example,
>     a device in a non-operational state such as "off" or "sleep" may
> still draw
>     a considerable power for charging its batteries. Or it may be in
> state "on" and
>     not draw any mains power at all, because it runs on battery or
> supplies itself
>     with a built-in generator."
>
> This leads us to the definition of battery state and power supply state:
>
> Battery state:
> The battery state indicates the flow of energy into or out of a battery.
>
> Power supply state:
> The power supply state indicates which power supply is in use at a
> device.
> Examples are: mains power, secondary mains power, battery, built-in
> generator
>
> We definitely need the battery state for the battery MIB (see object
> batteryChargingState in draft-ietf-eman-battery-mib-03). I think we also
> need something like the power supply state. But my ideas on it are much
> less clear than on the battery state that we have been discussing for
> some months already.
>
>
> Here are the definitions of power state that we have tried so far:
>
> 1. draft-ietf-eman-framework-02 and draft-parello-eman-definitions-0
>     A Power State is a way to classify a Power setting on an Energy
>     Managed Object (e.g., on, off, or sleep).  A Power State can be
>     viewed as a method for Energy Control
>
> Comments:
>    - Yes, a power state may be used to classify power setting.
>       But this is a way to use it, not a way define it.
>    - No, a power state is definitely not a method.
>
> 2. draft-ietf-eman-requirements-03
>     Power state of an entity is defined as a specific settings of an
>     entity that influences its power.  Examples of power states of an
>     entity are on, off, hibernate, and sleep.
>
> Comment:
>    - This is correct, but it neglects the relationship to operational
> states
>
> 3. draft-quittek-power-mib-02
>     A power state defines a limitations of services provided by a device
>     and implicitly limits energy consumption.  Examples for commonly
>     implemented power states include 'on', 'full power', 'low power',
>     'sleep', 'stand-by', and 'off'.  There is no commonly agreed
>     convention for power states naming and semantics.  Therefore power
>     states with the same names may have different semantics and different
>     names may be in use for the same power state.
>     But the actual energy consumption of a device depends on more than
>     just its power state.  Also the current load, the kind of load, and
>     many other factors influence energy consumption.
>
> Comments:
>    - first line is OK. It explains a power state as an operational state
>       without using the term "operational state" (which might be
> desirable).
>    - second line does not seem to be correct. A power state may have
>      power limitations. But this is not a necessary property of it.
>    - rest seems correct, but examples are not a definition and the
> following
>      text does not belong into the definition.
>
> 4. draft-ietf-eman-energy-monitoring-mib-00
>     A Power State is defined as a specific power setting for a
>     Power Monitor (e.g., shut, hibernate, sleep, high). Within the
>     context of a Power State  Set, the Power State of a device is
>     one of the power saving modes in that Power State Set.
>
> Comments:
>    - First sentence correct, but it neglects the relationship to
> operational states
>    - The second sentence does not belong to the definition.
>    - Second sentence explains power state as power saving mode.
>       What is a power saving mode? Is "full power" a power saving mode?
>
>
> Thanks,
>
>      Juergen
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>

---

From: Bruce Nordman <[email-masked]>
Date: Mon, 14 Nov 2011 03:00:46 -0800

I agree that Manufacturer Power State should be dropped.

For the definitions from
http://tools.ietf.org/html/draft-parello-eman-definitions-03
I do have some concerns.  That defines power state as:
A Power State is a generalized way to classify a setting on an Energy
Object (e.g., on, off, or sleep).
IEEE 1621 defines a power state as:
A condition or mode of a device that broadly characterizes its
capabilities, power consumption, power indicator coding, and responsiveness
to input.
"classify a setting" seems vague to me.  The "power indicator coding" is
off-topic
for EMAN but I think the rest is workable.  We can't and shouldn't make any
guarantees in our definitions, since a device can be asleep but charging its
battery and so drawing substantial power, but while asleep its capabilities
and responsiveness are different from on or off.

Also, I agree that power states can be used for control, but I don't see
that as part of their definition so would remove that from both.  (for
"set",
simply end the definition at "grouping".

--Bruce

On Mon, Nov 14, 2011 at 2:01 AM, Benoit Claise <[email-masked]> wrote:

> http://tools.ietf.org/html/**draft-parello-eman-**definitions-03<http://tools.ietf.org/html/draft-parello-eman-definitions-03>
> ?
> Btw, I don't think that we need the Manufacturer Power State in any of the
> draft, do we?
>
> Regards, Benoit.
>
>  Hi,
>>
>> batteryChargingState in draft-ietf-eman-battery-mib-**03). I think we
>> also
>> 1. draft-ietf-eman-framework-02 and draft-parello-eman-**definitions-0
>> 2. draft-ietf-eman-requirements-**03
>> 4. draft-ietf-eman-energy-**monitoring-mib-00
>> ______________________________**_________________
>> eman mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/eman<https://www.ietf.org/mailman/listinfo/eman>
>> ______________________________**_________________
>> eman mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/eman<https://www.ietf.org/mailman/listinfo/eman>
>>
>>
> ______________________________**_________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/eman<https://www.ietf.org/mailman/listinfo/eman>
>

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Mon, 14 Nov 2011 05:09:07 -0600

I would agree that Manufacturer Power State can be dropped. 

We had used the following definitions in the energy monitoring MIB
module. 

Thanks

Mouli

Power State Set

          A Power State Set is defined as a sequence of incremental

          energy saving modes of an Energy Object.  The elements of this
set can

          be viewed as an interface for the underlying device-

          implemented power settings of an Energy Object.  Examples of
Power

          State Sets include DTMF [DMTF], IEEE1621 [IEEE1621], ACPI

          [ACPI]. 

        Power State

          Energy Object (e.g., shut, hibernate, sleep, high). Within the

          context of a Power State  Set, the Power State of an Energy
Object  is

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bruce Nordman
Sent: Monday, November 14, 2011 4:31 PM
To: Benoit Claise (bclaise)
Cc: eman mailing list
Subject: Re: [eman] Terminology: power states - battery state -
powersupplystate

For the definitions from

A condition or mode of a device that broadly characterizes its
capabilities, power consumption, power indicator coding, and
responsiveness to input.

"classify a setting" seems vague to me.  The "power indicator coding" is
off-topic
for EMAN but I think the rest is workable.  We can't and shouldn't make
any
guarantees in our definitions, since a device can be asleep but charging
its
battery and so drawing substantial power, but while asleep its
capabilities
and responsiveness are different from on or off.

--Bruce

On Mon, Nov 14, 2011 at 2:01 AM, Benoit Claise <[email-masked]>
wrote:

Juergen, all,

Checking consensus here.

Regards, Benoit.

	Hi,
	
	For states I put the terms Power State and Power Series to
reflect what
	we discussed at the last two meetings.
	
	I don't see a distinction between the state as they refer to a
battery
	or a simple device. As we discussed at IETF81 (I think Juergen S
brought
	it up) why not keep the same information for the battery.
	
	I kept it simple in the definition and if there's new terms from
this
	thread please do let me know.
	
	Jp
	
	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf Of
	Juergen Quittek
	Sent: Saturday, August 13, 2011 5:32 PM
	To: eman mailing list
	Subject: [eman] Terminology: power states - battery state -
power
	supplystate
	
	Dear all,
	
	Here are some thoughts on what a power state is and how it
relates to
	the battery state and the power supply state of a device.
	
	So far, there is no document where we clearly define what a
power state
	is and what it is not. Please find a list of definitions that I
	collected from other documents further below.  This email mainly
serves
	for sharing some thoughts on this issue in order to jointly work
on a
	more clear definition of a power state.
	
	My main question is: What is characteristic for a power state?
	1. the operational state (Is the device not/fully/partially
	operational)?
	2. the power consumption in a power state? (min/max/average
	power/demand)?
	3. the power supply state (running on
mains/battery/self-generated
	power)?
	4. the total power balance (consuming/providing power)?
	
	As we have discussed it in the eman WG and as other standards
bodies
	including DMTF, ACPI, PWG see it, it is just 1. with some
implications
	on 2. Here is another try on a definition of a power state:
	
	   "A power state represents one or multiple operational states
of a
	device.
	   A power state indicates specific properties of a device
concerning
	its the energy
	   consumption when being in this state."
	
	Of course this one cries for definitions of an operational
state.
	
	Operational state:
	   "An operational state defines the availability of services
provided
	by a device."
	
	We certainly need some more text elaborating on power states
beyond the
	plain definition, maybe in the framework document.  There is one
note
	that I would definitely like to add there:
	
	   "Energy consumption of a device is not the only state to be
	considered
	   when managing the power supply of a device. If the device
contains
	batteries
	   or facilities for energy harvesting/generation, also the
battery
	charging state
	   and the power supply state of a device need to be considered.
For
	example,
	   a device in a non-operational state such as "off" or "sleep"
may
	still draw
	   a considerable power for charging its batteries. Or it may be
in
	state "on" and
	   not draw any mains power at all, because it runs on battery
or
	supplies itself
	   with a built-in generator."
	
	This leads us to the definition of battery state and power
supply state:
	
	Battery state:
	The battery state indicates the flow of energy into or out of a
battery.
	
	Power supply state:
	The power supply state indicates which power supply is in use at
a
	device.
	Examples are: mains power, secondary mains power, battery,
built-in
	generator
	
	We definitely need the battery state for the battery MIB (see
object
	batteryChargingState in draft-ietf-eman-battery-mib-03). I think
we also
	need something like the power supply state. But my ideas on it
are much
	less clear than on the battery state that we have been
discussing for
	some months already.

	Here are the definitions of power state that we have tried so
far:
	
	1. draft-ietf-eman-framework-02 and
draft-parello-eman-definitions-0
	   A Power State is a way to classify a Power setting on an
Energy
	   Managed Object (e.g., on, off, or sleep).  A Power State can
be
	   viewed as a method for Energy Control
	
	Comments:
	
	2. draft-ietf-eman-requirements-03
	   Power state of an entity is defined as a specific settings of
an
	   entity that influences its power.  Examples of power states
of an
	   entity are on, off, hibernate, and sleep.
	
	Comment:
	  - This is correct, but it neglects the relationship to
operational
	states
	
	3. draft-quittek-power-mib-02
	   A power state defines a limitations of services provided by a
device
	   and implicitly limits energy consumption.  Examples for
commonly
	   implemented power states include 'on', 'full power', 'low
power',
	   'sleep', 'stand-by', and 'off'.  There is no commonly agreed
	   convention for power states naming and semantics.  Therefore
power
	   states with the same names may have different semantics and
different
	   names may be in use for the same power state.
	   But the actual energy consumption of a device depends on more
than
	   just its power state.  Also the current load, the kind of
load, and
	   many other factors influence energy consumption.
	
	Comments:
	  - first line is OK. It explains a power state as an
operational state
	     without using the term "operational state" (which might be
	desirable).
	  - second line does not seem to be correct. A power state may
have
	    power limitations. But this is not a necessary property of
it.
	  - rest seems correct, but examples are not a definition and
the
	following
	    text does not belong into the definition.
	
	   Power Monitor (e.g., shut, hibernate, sleep, high). Within
the
	
	Comments:
	  - First sentence correct, but it neglects the relationship to
	operational states
	  - The second sentence does not belong to the definition.
	  - Second sentence explains power state as power saving mode.
	     What is a power saving mode? Is "full power" a power saving
mode?

	Thanks,
	
	    Juergen

-- 
Bruce Nordman

---

From: Bruce Nordman <[email-masked]>
Date: Mon, 14 Nov 2011 03:17:28 -0800

See below.

On Mon, Nov 14, 2011 at 3:09 AM, Mouli Chandramouli (moulchan) <
[email-masked]> wrote:

>  I would agree that Manufacturer Power State can be dropped. ****
>
> ** **
>
> We had used the following definitions in the energy monitoring MIB module.
> ****
>
> ** **
>
> Thanks****
>
> Mouli****
>
> ** **
>
> Power State Set****
>
> ** **
>
>           A Power State Set is defined as a sequence of incremental****
>
> set can****
>           be viewed as an interface for the underlying device-****
>
> Power****
>           State Sets include DTMF [DMTF], IEEE1621 [IEEE1621], ACPI****
>
>           [ACPI].
>
I think the last two sentences are appropriate NOTEs below a definition, but
don't say what a power state is.  I also don't think we need to or want to
imply
that the states are in a specific sequence.  The DMTF ones in particular do
not fall into a definitive sequence. Also, while energy saving is a fine
goal,
that is why we created more states, not what the states actually are.

        Power State****
>
> ** **
>
>           A Power State is defined as a specific power setting for a****
>
>           Energy Object (e.g., shut, hibernate, sleep, high). Within the**
> **
>
> Object  is****
I still think the "broadly characterizes capabilities,
power consumption, and responsiveness" wording actually defines the term.
I also think "a specific power setting" implies something about the power
levels possible in a state.

--Bruce

> ****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Bruce Nordman
> *Sent:* Monday, November 14, 2011 4:31 PM
> *To:* Benoit Claise (bclaise)
> *Cc:* eman mailing list
> *Subject:* Re: [eman] Terminology: power states - battery state -
> powersupplystate****
>
> ** **
>
> I do have some concerns.  That defines power state as:****
>
> Object (e.g., on, off, or sleep).****
>
> IEEE 1621 defines a power state as:****
>
> to input.****
> ****
> On Mon, Nov 14, 2011 at 2:01 AM, Benoit Claise <[email-masked]> wrote:*
> ***
>
> Juergen, all,
>
> Checking consensus here.
> Regards, Benoit.****
> ** **
> https://www.ietf.org/mailman/listinfo/eman****
>
>
> https://www.ietf.org/mailman/listinfo/eman****
>
>
>
>
> --
> *Bruce Nordman*
> m: 510-501-7943****

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Mon, 14 Nov 2011 06:25:39 -0600

> From: Bruce Nordman

I agree with your general point but I think it would be best merged with the proposal I just posted.  How about this?

"Power States are a generalized way to classify the operational settings on an Energy Object which then broadly characterize the capabilities, power consumption, and responsiveness of an Energy Object.  An individual Power State (e.g. on, off, or sleep) is intended to identify a well defined set of those characteristics where that set may be Energy Object type specific.  For example, consider what it would mean for something like a refrigerator to be in a sleep state vs. a computer."

Feel free to continue tweaking. :)

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
224 Brookhill Drive
Gahanna, OH  43230
Email: [email-masked]
Phone: 614 718 6308

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Nov 2011 14:01:18 +0100

> "Power States are a generalized way to classify the operational settings on an Energy Object which then broadly characterize the capabilities, power consumption, and responsiveness of an Energy Obj…

I like the direction. Trying to simplify it a bit...

   Power States classify the operational settings on an Energy Object
   that characterize the power consumption of the Energy Object. The
   operational settings implied by a specific Power State (e.g., on,
   off, sleep, or hybernate) may be Energy Object type specific.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "John Parello (jparello)" <[email-masked]>
Date: Mon, 14 Nov 2011 09:31:18 -0800

We have a definition coming to some consensus on another thread.

I think the IEEE 1621 should be used verbatim.

 

From: Bruce Nordman [mailto:[email-masked]] 
Sent: Monday, November 14, 2011 3:01 AM
To: Benoit Claise (bclaise)
Cc: John Parello (jparello); eman mailing list
Subject: Re: [eman] Terminology: power states - battery state - power
supplystate

For the definitions from

--Bruce

Juergen, all,

Checking consensus here.

Regards, Benoit.

	Hi,

	
	
	Jp
	
	-----Original Message-----
	
	Dear all,

	

	
	
	Operational state:

	
	
	Battery state:
	
	Power supply state:

	
	
	Comments:

	Comment:

	Comments:

	Comments:

	Thanks,
	
	    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Wed, 16 Nov 2011 10:58:08 +0800

Trying to get closure on this one
It seems that we have two Power State proposal

     1. Power States classify the operational settings on an Energy 
Object that characterize the power consumption of the Energy Object. The 
operational settings implied by a specific Power State (e.g., on, off, 
sleep, or hybernate) may be Energy Object type specific.

     2. Vertabim from IEEE 1621: A condition or mode of a device that 
broadly characterizes its capabilities, power consumption, power 
indicator coding, and responsiveness to input.

To be discussed here or during the meeting.

Regards, Benoit.

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Tue, 15 Nov 2011 21:10:52 -0600

I like the key phrases "classify the operational settings" and "broadly characterizes its capabilities, power consumption, power indicator coding, and responsiveness to input".

I like the first because it indicates that we were are doing by creating power states and power state sets, and I like the second in its entirety because I believe that it provides a good summarization of the high level implications of the classifications.

Any wording that includes these two phrases is fine with me but I am certainly open to other suggestions or options.

William F. Mielke
Alcatel-Lucent

> From: Benoit Claise [mailto:[email-masked]] 
> Sent: Tuesday, November 15, 2011 9:58 PM
> To: Mielke, William F (Bill); [email-masked]
> Subject: Re: [eman] Terminology: power states - battery state 
> - powersupplystate
> 
> >> I agree with your general point but I think it would be 
> best merged with the proposal I just posted.  How about this?
> >>
> >> "Power States are a generalized way to classify the 
> operational settings on an Energy Object which then broadly 
> characterize the capabilities, power consumption, and 
> responsiveness of an Energy Object.  An individual Power 
> State (e.g. on, off, or sleep) is intended to identify a well 
> defined set of those characteristics where that set may be 
> Energy Object type specific.  For example, consider what it 
> would mean for something like a refrigerator to be in a sleep 
> state vs. a computer."

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Nov 2011 11:16:02 +0100

On Wed, Nov 16, 2011 at 10:58:08AM +0800, Benoit Claise wrote:
> Object that characterize the power consumption of the Energy Object.
> The operational settings implied by a specific Power State (e.g.,
> on, off, sleep, or hybernate) may be Energy Object type specific.
> 

I do not know what "power indicator coding" is. 

/js

---

From: Bruce Nordman <[email-masked]>
Date: Wed, 16 Nov 2011 18:24:15 +0800

> I do not know what "power indicator coding" is.

Strictly speaking it is the color of the LED on an electronic device,
often green, yellow, or off.
That said, I would be in favor of dropping those three words and
saying "adapted from IEEE 1621" is they are really off-topic from
EMAN's purposes.

--Bruce

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Wed, 16 Nov 2011 05:53:10 -0600

I would be OK dropping that particular portion.  Power consumption and responsiveness are the most important bits IMHO.  Capabilities comes in at a close third.  These all seem to be important dimensions which are affected by the setting of power states.

William F. Mielke
Alcatel-Lucent

________________________________
From: Bruce Nordman [mailto:[email-masked]]
Sent: Wednesday, November 16, 2011 5:24 AM
To: Juergen Schoenwaelder; Benoit Claise; Mielke, William F (Bill); [email-masked]
Subject: Re: [eman] Terminology: power states - battery state - powersupplystate

On Wed, Nov 16, 2011 at 6:16 PM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

/js

--Bruce

--
Bruce Nordman
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman<http://eetd.lbl.gov/ea/nordman>
[email-masked]
510-486-7089
m: 510-501-7943

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 16 Nov 2011 21:37:29 -0600

Hello all, 

As an action item from the WG meeting, here is a definition of Power
State. Rewrote from the definitions and WG email discussions. 

Thanks

Mouli

A Power State is defined as a power saving setting of an Energy Object
that influences the power consumption, functionality and the
responsiveness of the Energy Object. In addition, a Power State can be
viewed as an interface to the device-specific operational modes
implemented by an Energy Object.  Examples of Power States include (on,
off, sleep, hibernate).

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mielke, William F (Bill)
Sent: Wednesday, November 16, 2011 5:23 PM
To: [email-masked]
Subject: Re: [eman] Terminology: power states - battery state -
powersupplystate

I would be OK dropping that particular portion.  Power consumption and
responsiveness are the most important bits IMHO.  Capabilities comes in
at a close third.  These all seem to be important dimensions which are
affected by the setting of power states.

William F. Mielke
Alcatel-Lucent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Nov 2011 04:56:01 +0100

> implemented by an Energy Object.  Examples of Power States include (on,

Why do we need the second sentence?

/js

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Wed, 16 Nov 2011 22:10:13 -0600

> From: Mouli Chandramouli (moulchan) [mailto:[email-masked]]
>
> A Power State is defined as a power saving setting of an Energy Object that influences 
> the power consumption, functionality and the responsiveness of the Energy Object. In 
> addition, a Power State can be viewed as an interface to the device-specific operational 
> modes implemented by an Energy Object.  Examples of Power States include (on, off, sleep, 
> hibernate).

Thanks Mouli.  I believe that this is good merger of the two previous definitions.  I am OK with this version as-is if others prefer it, but I would otherwise offer the following slightly modified version which I believe helps clarify the intended meaning:

    A Power State is defined as a power saving setting of an Energy Object that influences 
    the power consumption, the available functionality, and the responsiveness of the Energy 
    Object. A Power State setting can be viewed as an interface for controlling the device-
    specific operational modes implemented by an Energy Object.  Examples of Power States 
    include (on, off, sleep, and hibernate).

William F. Mielke
Alcatel-Lucent

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Wed, 16 Nov 2011 22:28:50 -0600

> From: Juergen Schoenwaelder 
> 

I do not mean to speak for Mouli here, but let me try to answer this from my own personal perspective.

In my opinion the second sentence makes the relationship between the setting of Power States and the device-specific operational behavior explicit.  Without the second sentence this relationship might still be implicit, but I personally prefer to make things explicit.

I am open to dropping or rewording the second sentence but I would like to not loose the notion that the detailed behavioral characteristics of each Power State are expected to be necessarily device type specific.

William F. Mielke
Alcatel-Lucent
Phone: +1 614 718 6308

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Nov 2011 06:06:04 +0100

> In my opinion the second sentence makes the relationship between the setting of Power States and the device-specific operational behavior explicit.  Without the second sentence this relationship mi…

The first sentence already states that the power state influences the
functionality. The phrase "interfaces to the device-specific
operational modes" in the second sentence is a bit abstract for me and
hence of little value to me. For me, this second sentence raises more
questions (How does a device relate to an Energy Object? What are
"operational modes"?) than it answers.

> I am open to dropping or rewording the second sentence but I would
> like to not loose the notion that the detailed behavioral
> characteristics of each Power State are expected to be necessarily
> device type specific.

Again, what is the relationship between device and Energy Object?  Is
it not necessarily device type specific or even device specific?  What
exactly is a device type? Is it now implicitely expected that all
devices of the same type share the same "detailed behavioral
characteristics" for a given power state?

I guess I prefer the short version - it is simple and self-contained.

/js

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Wed, 16 Nov 2011 23:20:24 -0600

OK, I understand your concerns.  I do not believe that the second sentence is critical and I personally am OK with removing it.  Given the discussion thus far, could you please propose a final wording that you would find acceptable?

William F. Mielke
Alcatel-Lucent

> [mailto:[email-masked]] 
> Sent: Thursday, November 17, 2011 12:06 AM
> To: Mielke, William F (Bill)
> Cc: [email-masked]
> Subject: Re: [eman] Terminology: power state
> 
> > I do not mean to speak for Mouli here, but let me try to 
> answer this from my own personal perspective.
> > 
> > In my opinion the second sentence makes the relationship 
> between the setting of Power States and the device-specific 
> operational behavior explicit.  Without the second sentence 
> this relationship might still be implicit, but I personally 
> prefer to make things explicit.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Nov 2011 06:57:04 +0100

> OK, I understand your concerns.  I do not believe that the second sentence is critical and I personally am OK with removing it.  Given the discussion thus far, could you please propose a final word…

If I remove the second sentence, I have this left:

A Power State is defined as a power saving setting of an Energy Object
that influences the power consumption, functionality and the
responsiveness of the Energy Object. Examples of Power States include
(on, off, sleep, hibernate).

/js

---

From: Rolf Winter <[email-masked]>
Date: Thu, 17 Nov 2011 06:05:28 +0000

A nit really but a "full power" state is currently defined as a power savings setting. Maybe just "setting" instead?

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

> Juergen Schoenwaelder
> Sent: Donnerstag, 17. November 2011 06:57
> > OK, I understand your concerns.  I do not believe that the second
> sentence is critical and I personally am OK with removing it.  Given
> the discussion thus far, could you please propose a final wording that
> you would find acceptable?
> >
>

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 17 Nov 2011 00:21:40 -0600

Hi Juergen,

I am ok. With dropping the second sentence if that is the consensus. 

Bill is right. That was intent of the second sentence. 
Let me explain - there are many devices (router, switches, PCs, ...) and
every device have its own way of implementing/realising its internal
power saving states.
For e.g. I know my laptop is sleep state and I do not know what are the
components shut down. 
For. e.g. a power state of sleep for a router is different from sleep of
a PC or a mobile phone. 

In the second sentence device and Energy Object are synonyms. Did not
want to use the same word multiple times in the same sentence. 
There is no reference to device type in the definition does not refer to
device type. 

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Schoenwaelder
Sent: Thursday, November 17, 2011 11:27 AM
To: Mielke, William F (Bill)
Cc: [email-masked]
Subject: Re: [eman] Terminology: power state

On Wed, Nov 16, 2011 at 11:20:24PM -0600, Mielke, William F (Bill)
> OK, I understand your concerns.  I do not believe that the second
sentence is critical and I personally am OK with removing it.  Given the
discussion thus far, could you please propose a final wording that you
would find acceptable?

/js

---

From: Ira McDonald <[email-masked]>
Date: Thu, 17 Nov 2011 11:10:34 -0500

Hi,

Rather than changing "power saving setting" to "power setting",
how about "power usage setting".

As Rolf observed, obviously full on is not a saving setting.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, Nov 17, 2011 at 1:05 AM, Rolf Winter <[email-masked]> wrote:

> A nit really but a "full power" state is currently defined as a power
> savings setting. Maybe just "setting" instead?
>
>

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Thu, 17 Nov 2011 22:17:41 -0600

+1

William F. Mielke
Alcatel-Lucent

________________________________
From: Ira McDonald [mailto:[email-masked]]
Sent: Thursday, November 17, 2011 11:11 AM
To: Rolf Winter; Ira McDonald
Cc: Juergen Schoenwaelder; Mielke, William F (Bill); [email-masked]
Subject: Re: [eman] Terminology: power state

Hi,

Cheers,
- Ira

mailto:[email-masked]<mailto:[email-masked]>

On Thu, Nov 17, 2011 at 1:05 AM, Rolf Winter <[email-masked]<mailto:[email-masked]>> wrote:
A nit really but a "full power" state is currently defined as a power savings setting. Maybe just "setting" instead?

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Juergen Schoenwaelder
> Cc: [email-masked]<mailto:[email-masked]>
> Phone: +49 421 200 3587<tel:%2B49%20421%20200%203587>         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103<tel:%2B49%20421%20200%203103>         <http://www.jacobs-university.de/>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eman

---

From: Bruce Nordman <[email-masked]>
Date: Tue, 22 Nov 2011 22:18:47 -0800

I think we should return to the principle of adopting
terms and definitions from other sources unless we
have some specific reason they are problematic.

I also think that it is important that the definition
stick to what something IS, and not wander into
commentary about its usefulness, application, etc.
If that is important, commentary can be added
below the definition, but distinct from it.

I am obviously biased on this topic, having written
IEEE 1621, but it does reflect a lot of time trying to
distill the essence of the term, and be widely
useful and product-type independent.  After removing
three words, its first sentence is:

power state: A condition or mode of a device that broadly characterizes its
capabilities, power consumption, and responsiveness to input.

I think this does what we need, but there may be others
from other standards equally worth considering.
(1621 also notes that 'The term “power mode” may be substituted and has
identical meaning.').

I am mindful that whatever is selected will not change any
EMAN implementations, so I think we should try to wrap this
up quickly and move on to the more difficult topics (like time
series reporting as Bill has noted recently on the list).

Thanks,

--Bruce

On Thu, Nov 17, 2011 at 8:17 PM, Mielke, William F (Bill) <
[email-masked]> wrote:

>  ------------------------------
> *From:* Ira McDonald [mailto:[email-masked]]
> *Sent:* Thursday, November 17, 2011 11:11 AM
> *To:* Rolf Winter; Ira McDonald
> *Cc:* Juergen Schoenwaelder; Mielke, William F (Bill); [email-masked]
>
> *Subject:* Re: [eman] Terminology: power state
>
> Hi,
>
> On Thu, Nov 17, 2011 at 1:05 AM, Rolf Winter <[email-masked]>wrote:
>
>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
>> London W3 6BL | Registered in England 2832014
>>
>>
>> > Phone: +49 421 200 3587 <%2B49%20421%20200%203587>         Campus Ring
>> 1, 28759 Bremen, Germany

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Nov 2011 08:03:40 +0100

> capabilities, power consumption, and responsiveness to input.

I thought we were here:

   A Power State is defined as a power setting of an Energy Object
   that influences the power consumption, functionality and the
   responsiveness of the Energy Object. Examples of Power States
   include (on, off, sleep, hibernate).

> series reporting as Bill has noted recently on the list).

I tend to agree and I felt we had reached agreement...

/js

---

From: Rolf Winter <[email-masked]>
Date: Wed, 23 Nov 2011 07:18:46 +0000

I tend to agree with Bruce. If there are well used definitions for terms we will be using, then there is not much use in redefining them since they will mean the exact same thing using different words. I also generally like short definitions. Having that said, the IEEE definition works for me. 

> Sent: Mittwoch, 23. November 2011 07:19
> I think we should return to the principle of adopting terms and
> definitions from other sources unless we have some specific reason they
> are problematic.
> 
> I also think that it is important that the definition stick to what
> something IS, and not wander into commentary about its usefulness,
> application, etc.
> If that is important, commentary can be added below the definition, but
> distinct from it.
> 
> I am obviously biased on this topic, having written IEEE 1621, but it
> does reflect a lot of time trying to distill the essence of the term,
> and be widely useful and product-type independent.  After removing
> power state: A condition or mode of a device that broadly characterizes
> its capabilities, power consumption, and responsiveness to input.
> 
> 
> I think this does what we need, but there may be others from other
> standards equally worth considering.
> (1621 also notes that 'The term "power mode" may be substituted and has
> identical meaning.').
> 
> I am mindful that whatever is selected will not change any EMAN
> implementations, so I think we should try to wrap this up quickly and
> move on to the more difficult topics (like time series reporting as
> Bill has noted recently on the list).
> 
> Thanks,
> 
> --Bruce
> 
> 
> On Thu, Nov 17, 2011 at 8:17 PM, Mielke, William F (Bill)
> <[email-masked]> wrote:
> 
> 
> 
> 	+1
> 
> 	William F. Mielke
> 	Alcatel-Lucent
> 			A nit really but a "full power" state is currently
> defined as a power savings setting. Maybe just "setting" instead?
> 
> 
> 			NEC Europe Limited | Registered Office: NEC House, 1
> Victoria Road, London W3 6BL | Registered in England 2832014
> 
> 
> 
> 			> Phone: +49 421 200 3587
> <tel:%2B49%20421%20200%203587>          Campus Ring 1, 28759 Bremen,
> Germany
> 			> Fax:   +49 421 200 3103
> <tel:%2B49%20421%20200%203103>          <http://www.jacobs-
> university.de/>

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 23 Nov 2011 01:30:55 -0600

Either we accept the definition verbatim, but the subsequent email
discussions have been on tweaking the definition. 

Let us go with the definition - 

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rolf Winter
Sent: Wednesday, November 23, 2011 12:49 PM
To: Bruce Nordman; Mielke, William F (Bill)
Cc: [email-masked]
Subject: Re: [eman] Terminology: power state

I tend to agree with Bruce. If there are well used definitions for terms
we will be using, then there is not much use in redefining them since
they will mean the exact same thing using different words. I also
generally like short definitions. Having that said, the IEEE definition
works for me. 

> 			> On Wed, Nov 16, 2011 at 11:20:24PM -0600,
Mielke,
> William F (Bill)
> 			> wrote:
> 			> > OK, I understand your concerns.  I do not
believe
> that the second
> 			> sentence is critical and I personally am OK
with
> removing it.  Given
> 			> the discussion thus far, could you please
propose a
> final wording that
> 			> A Power State is defined as a power saving
setting
> of an Energy Object
> 			> responsiveness of the Energy Object. Examples
of
> Power States include
> 			> Juergen Schoenwaelder           Jacobs
University
> Bremen gGmbH

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Wed, 23 Nov 2011 11:04:44 -0600

>    include (on, off, sleep, hibernate).

As long as this is still being discussed, I would argue for one additional tweak to this version of the definition.  I would like to change "functionality" to "available functionality" because strictly speaking the power setting does not "influence the functionality supported by an Energy Object", it merely determines which subset of the Energy Object's supported functionalities are available within that power state.  But this is admittedly a nit.

This would yield (with minor punctuation changes):

    A Power State is defined as a power setting of an Energy Object
    that influences the power consumption, the available functionality, and the
    responsiveness of the Energy Object.  Examples of Power States
    include: on, off, sleep, and hibernate.

Can people please weigh in on which of the above two versions they prefer?  The original one or the newly tweaked one?  I'll be happy to accept the consensus of the group either way on this point.

On the issue of deciding between adopting a verbatim IEEE1621 version or an EMAN specific version, I acknowledge the merits of Bruce's point about not redfining terms just for the sake of defining terms.  So I see the trade off as boiling down to the following points:

(a) I don't believe that there is a subtantive difference between the two options in terms of their actual meaning in the grand scheme of things.

(b) I believe that the IEEE1621 option has the advantage that we aren't redefining terms needlessly.

(c) I believe that the EMAN specific option has the advantages of specifically relating the definition to our preferred terminology of "Energy Object" as opposed to "device", and it provides concrete examples of power states to help clarify the meaning.

Given these points I do not have a strong preference either way and would be OK adopting either option.  If pressed to make a choice I have a slight preference for the EMAN specific option (with or without my latest tweaks).

William F. Mielke
Alcatel-Lucent

---

From: Ira McDonald <[email-masked]>
Date: Wed, 23 Nov 2011 13:11:29 -0500

Hi,

I can live with the plain IEEE 1621 definition.

But I prefer the last tweaked definition, especially the
qualification of "available functionality" in Bill's latest
reply.

Separately, I find "Energy Object" a gloriously obscure
term that is sure to confuse everyone not intimately
involved in EMAN for the indefinite future - but oh well.

Cheers,
- Ira

On Wed, Nov 23, 2011 at 12:04 PM, Mielke, William F (Bill) <
[email-masked]> wrote:

> As long as this is still being discussed, I would argue for one additional
> tweak to this version of the definition.  I would like to change
> "functionality" to "available functionality" because strictly speaking the
> power setting does not "influence the functionality supported by an Energy
> Object", it merely determines which subset of the Energy Object's supported
> functionalities are available within that power state.  But this is
> admittedly a nit.
>
> Can people please weigh in on which of the above two versions they prefer?
>  The original one or the newly tweaked one?  I'll be happy to accept the
> consensus of the group either way on this point.
>
> On the issue of deciding between adopting a verbatim IEEE1621 version or
> an EMAN specific version, I acknowledge the merits of Bruce's point about
> not redfining terms just for the sake of defining terms.  So I see the
> trade off as boiling down to the following points:
>
> (a) I don't believe that there is a subtantive difference between the two
> options in terms of their actual meaning in the grand scheme of things.
>
> (c) I believe that the EMAN specific option has the advantages of
> specifically relating the definition to our preferred terminology of
> "Energy Object" as opposed to "device", and it provides concrete examples
> of power states to help clarify the meaning.
>
> Given these points I do not have a strong preference either way and would
> be OK adopting either option.  If pressed to make a choice I have a slight
> preference for the EMAN specific option (with or without my latest tweaks).
>
> William F. Mielke
> Alcatel-Lucent

---

From: "John Parello (jparello)" <[email-masked]>
Date: Wed, 23 Nov 2011 10:15:52 -0800

My preference in writing the definition is to go with verbatim or quoted
definitions from a source. So I prefer the IEEE 1621 definition.

IF after that the group would like an additional definition from this
group I can add as a second definition or in a note.

I'll add the IEEE 1621 and wait for consensus on adding a second or
note.

Thanks

Jp

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ira McDonald
Sent: Wednesday, November 23, 2011 10:11 AM
To: Mielke, William F (Bill); Ira McDonald
Cc: [email-masked]
Subject: Re: [eman] Terminology: power state

Hi,

Cheers,
- Ira

<http://sites.google.com/site/blueroofmusic> 
<http://sites.google.com/site/highnorthinc> 

>    include (on, off, sleep, hibernate).

As long as this is still being discussed, I would argue for one
additional tweak to this version of the definition.  I would like to
change "functionality" to "available functionality" because strictly
speaking the power setting does not "influence the functionality
supported by an Energy Object", it merely determines which subset of the
Energy Object's supported functionalities are available within that
power state.  But this is admittedly a nit.

   that influences the power consumption, the available functionality,
and the

Can people please weigh in on which of the above two versions they
prefer?  The original one or the newly tweaked one?  I'll be happy to
accept the consensus of the group either way on this point.

On the issue of deciding between adopting a verbatim IEEE1621 version or
an EMAN specific version, I acknowledge the merits of Bruce's point
about not redfining terms just for the sake of defining terms.  So I see
the trade off as boiling down to the following points:

(a) I don't believe that there is a subtantive difference between the
two options in terms of their actual meaning in the grand scheme of
things.

(b) I believe that the IEEE1621 option has the advantage that we aren't
redefining terms needlessly.

(c) I believe that the EMAN specific option has the advantages of
specifically relating the definition to our preferred terminology of
"Energy Object" as opposed to "device", and it provides concrete
examples of power states to help clarify the meaning.

Given these points I do not have a strong preference either way and
would be OK adopting either option.  If pressed to make a choice I have
a slight preference for the EMAN specific option (with or without my
latest tweaks).

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
Email: [email-masked]
Phone: +1 614 718 6308 <tel:%2B1%20614%20718%206308>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Nov 2011 20:27:47 +0100

> definitions from a source. So I prefer the IEEE 1621 definition.

I do not see how "power indicator coding" applies to us (and this is
part of the verbatim IEEE 1621 definition as far as I have been told).

To me, it seems the definition emerging out of this (lengthy)
discussion is slowly but surely getting better than what IEEE 1621
offers (and mind you that IEEE 1621 is a standard for "User Interface
Elements in Power Control" and as such it is OK that it talks about
"power indicator coding" - but that just means it is not necessarily
the authoritative source for a generic power state definition).

/js (my last words on this thread)