Subject: [eman] Comments on draft-ietf-eman-requirements-04

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Wed, 27 Jul 2011 15:07:51 -0500

Provided below.  I will forward a copy of my annotated PDF file to the authors.  The PDF version also includes some minor corrections/suggestions which are not reproduced below.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [email-masked]
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

----------------------------------------------------------------
Comments on draft-ietf-eman-requirements-04
----------------------------------------------------------------

General Comments:

1. In general I think that both the requirements and the framework documents are looking much better.  Still room for improvement most likely but they definitely seem to be much improved, IMHO.

Deatiled Comments:

> The basic objective of energy management is operating communication
> networks and other equipment with minimal amount of energy, while
> maintaining a certain level of service. (Page 8)

The focus of energy management is not specifically communications networks, that is only one possible use of these standards.  Consider a less communications oriented point of view.  The main point is energy management, not energy management of communications networks.

> 5.2.5. List of supported power states (Page 13)

Are we envisioning having powered entities that support only a subset of the declared power state sets?  How does this come about?  Is this an implication of supporting multiple power state sets concurrently and therefore the need to map between them? 

> 5.4.1. Real power (Page 16)

What is "real power"?

> Besides the real power, at least two out of the following
> three quantities need to be reported: apparent power, reactive power,
> phase angle. (Page 17)

What are "apparent power" and "reactive power"?

> 5.4.7. Actual AC frequency (Page 17)

For these parameters like "actual frequency" should we be reporting statistical quantities such as max, min, average, std deviation, etc?

> 5.5.2. Time intervals (Page 19)

Should we include some examples for where the different reporting categories may apply?

> 5.6.2. Battery charging state (Page 20)

>From the title I would expect: "charged, discharged" -> "charging, discharging"

> 5.6.4. Actual battery capacity (Page 20)

I know that this has bounced back and forth between "actual" and "current" but actual seems like it might get confused with "nominal".  Perhaps consider "available" or "remaining" instead?

> Even for self-managed powered entities such interface may be
> required for overruling local policy decisions by global ones from an
> energy management system. (Page 21)

Actually I believe that these interfaces would be useful for configuring local policy parameters (especially for "headless" and "lights out" equipment in networking data centers and central offices), in addition to allowing overrides of the policies based on EnMS level decisions.

Consider:

Even for self-managed powered entities such interfaces may be
required for configuring local policy parameters and for overruling local policy decisions by global ones from an energy management system.

> Still, requirements for power state control apply accordingly to power supply control. (Page 21)

I am not clear on what this sentence is trying to convey.  Please clarify it.

> 7.7. Indicating source of remote information (Page 23)

Needs a different title.  This is a duplicate from 7.6 but it is talking about different information.

> 8.2. Controlling power supply of other powered entities (Page 24)

While I am following the meaning here clearly enough I recognize that I am already part of the choir so to speak and so I may follow it better than someone who is not already familiar with the concepts.  All of these references to "powered entity" get confusing because in each case there is a nuance that is obvious to us but which is not being conveyed to the reader.

I wonder if the document might not benefit from making these nuances explicit by defining the concept of a "role" that powered entities can take on depending on their context.  So, for example, we are talking about powered entities that can control the power sources of other powered entities.  Might we not refer to a powered entity which is playing this role as being a "PowerController"?  Other roles might be things like "PowerMonitor" or "PowerSensor", "PowerGateway" for the case of proxies as they are being discussed here, and so forth.

> 8.2.1. Control of power supply of other powered entities (Page 25)

It seems that we should discuss here a bit the implications of turning a power outlet on and off when it is connected to multiple powered entities.  In some cases it may not be possible to individually power on or off an individual powered entity without affecting others.  This probably applies to other sections as well.

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 27 Jul 2011 17:42:15 -0400

Hi Bill,

Thank you for all your comments.
Please find replies inline.

> Learn like you're going to live forever."

Right. This needs to be changed.

> Are we envisioning having powered entities that support only a subset of the declared power state sets?  How does this come about?  Is this an implication of supporting multiple power state sets co…

This is a good question. A device that does only have a number of, say, five different power states may want to support the DMTF set of power states. What should it do? 

Should it pretend to support all DMTF power states?
Should it list only the five states that it really supports?
What if a management station tries to set the device to a state that is not supported?

>> 5.4.1. Real power (Page 16)

When using AC the power is in general described by a complex number.
It has a real component called real power or active power.
It has an imaginary component called reactive power.
The combination of both is the complex power.
The apparent power is the absolute value of the complex power.

You get to complex power when the sinusoidal voltage and current are not in synch.
The deviation between their cycles is indicated by a phase angle of the current compared to the voltage.
Finally, there is the power factor which is the ration between real and apparent power.
For most devices in telecommunications the power factor is close to 1.
Note that the power factor does not necessarily indicate efficiency of a device. 
 
> For these parameters like "actual frequency" should we be reporting statistical quantities such as max, min, average, std deviation, etc?

Maybe. I am not an expert for power quality.
Is there someone on the list who has experience with this?

> Should we include some examples for where the different reporting categories may apply?

Good idea.
I would be grateful if anybody provides text.

> From the title I would expect: "charged, discharged" -> "charging, discharging"

Right. This needs to be fixed.

> I know that this has bounced back and forth between "actual" and "current" but actual seems like it might get confused with "nominal".  Perhaps consider "available" or "remaining" instead?

We got more comments suggesting to call it remaining, 
Let's switch to remaining as long as nobody objects.

> required for configuring local policy parameters and for overruling local policy decisions by global ones from an energy management system.

Sounds good. Let's make this change if nobody objects.

> I am not clear on what this sentence is trying to convey.  Please clarify it.

Right. This sentence needs to be changed or removed.

> Needs a different title.  This is a duplicate from 7.6 but it is talking about different information.

I think what we need here is "source" --> "content"

> I wonder if the document might not benefit from making these nuances explicit by defining the concept of a "role" that powered entities can take on depending on their context.  So, for example, we…

This would make things clearer here. But it would need to introduce all of this terminology.
Let's see if we find an easy way for making things easier.

> It seems that we should discuss here a bit the implications of turning a power outlet on and off when it is connected to multiple powered entities.  In some cases it may not be possible to individu…

Right. In which sections do you think we should mention this? 
Or do you think that we should list the other sections?

Thanks,

    Juergen

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

---

From: Bruce Nordman <[email-masked]>
Date: Thu, 28 Jul 2011 00:56:15 -0400

On Wed, Jul 27, 2011 at 5:42 PM, Juergen Quittek <[email-masked]> wrote:

> ...
> > Are we envisioning having powered entities that support only a subset of
> the declared power state sets?  How does this come about?  Is this an
> implication of supporting multiple power state sets concurrently and
> therefore the need to map between them?
>
> This is a good question. A device that does only have a number of, say,
> five different power states may want to support the DMTF set of power
> states. What should it do?
>

This is already true today.  While ACPI defines S1 and S2, I am not aware
that
any products actually implement them.  So, supporting fewer power states
than are defined is the norm, not the exception.

> ...
> > For these parameters like "actual frequency" should we be reporting
> statistical quantities such as max, min, average, std deviation, etc?
>
>

Does anyone have a use case for this?  Wouldn't the AC frequency be
shared by the whole building?  I am willing to believe there is a use case,
but I expect it is rare.

--Bruce

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