Requirements for Energy Management
draft-ietf-eman-requirements-14

[Ballot comment]
I have just checked -14 and I wonder about this text part:
"(the instantaneous power, as opposed to the demand, which is an averaged power),"

Power demand is not an average, as it is more complex than this. It also included peak power demand, etc.

[Ballot discuss]

Thanks: version -13 addresses all my discuss points except (3)
below, which I'd still like to discuss some more since I don't
think we've bottomed out on that.

(3) 6.1, 6.2 and section 8 may have serious consequences - are
we really ready to go straight there? I think the
authorization implied by this is maybe too onerous to attempt
now except in limited cases (e.g. a data centre's separate
control VLAN).  I don't believe saying "sufficiently
protected" is enough, as you do in section 9. Again an
applicability statement might help here limiting these
features to networks that are reasonably well managed.

[Ballot discuss]
Just a note that I don't think -12 addresses these discuss
points. I didn't check the comments.

(1) cleared

(2) cleared

(3) 6.1, 6.2 and section 8 may have serious consequences - are
we really ready to go straight there? I think the
authorization implied by this is maybe too onerous to attempt
now except in limited cases (e.g. a data centre's separate
control VLAN).  I don't believe saying "sufficiently
protected" is enough, as you do in section 9. Again an
applicability statement might help here limiting these
features to networks that are reasonably well managed.

(4) cleared

[Ballot discuss]
Picking up Robert's DISCUSS...

There is a lot of text in this document that tries to constrain how to build an
Energy Management System, and don't have anything to do with placing
requirements on standards documents for interacting with what they measure. The
instance that elevated this to a DISCUSS for me is in 5.7 where the document
says "It should be avoided that time series data can only be obtained through
regular polling by the energy management system." Why should the IETF be making
such a statement in this document?

[Ballot discuss]

Just a note that I don't think -12 addresses these discuss
points. I didn't check the comments.

(1) Are sleepy nodes, power harvesting and self-controlling
devices included? (By self-controlling I mean devices that set
their own sleep-thresholds based on history.) They need to be
in some eventual standards. Maybe eman standards (and this
document) ought have some kind of applicability statement
limiting scope to "reasonably ok infrastructure" use-cases.
You might even be better off splitting battery powered devices
out at first as well.

(2) section 4, "Entities must be uniquely identified" is plain
wrong - 10.0.0.1 is just fine in lots of places.  Other parts
of section 4 based on this error will likely also need
changing. (2nd paragraph for example.) Note that this is not
the same as objecting to 4.1, which is fine.  Having
well-defined ways to identify things is fine but insisting
that all things are identified in any particular way (or ways)
is not. (7.4 and 8.1.4 have the same problem with their
combinations of "must" and "all".)

(3) 6.1, 6.2 and section 8 may have serious consequences - are
we really ready to go straight there? I think the
authorization implied by this is maybe too onerous to attempt
now except in limited cases (e.g. a data centre's separate
control VLAN).  I don't believe saying "sufficiently
protected" is enough, as you do in section 9. Again an
applicability statement might help here limiting these
features to networks that are reasonably well managed.

(4) section 9, the relevant privacy protection needed here
relates to stored data. Transmitted data will require
confidentiality but stored data has serious privacy
consequences, especially for home network devices.

[Ballot comment]
Thank you for addressing my Discuss and for Sterling work on my Comments.

Looking at the diff I find the following points remaining...

---

> The term "power properties" is used in the Abstract and Introduction,
> and then shows up in Section 3.5.  No clue is given as to what it means
> until Section 5.3; and then only definition by examples.
>
> Could you add it to the terminology section?

Your email said "yes"

---

> Shouldn't Section 4 expand on "subtended devices"? Or is this a forward
> pointer to Section 7?

No discusison in email, no change in text.

---

> I'm not sure, but it seemed to me that there is confusion between
> Secitons 5.2 and 5.3. 5.2 is supposed to describe the capabilities
> of the power interfaces, while 5.3 monitors what is happening at them.
>
> In some cases, the issue is simply not enough flexibility. For example,
> in 5.2.7 the "nominal voltage" on an interface may actually be a range.
> Consider devices that can be plugged into a varieties of supply and
> auto-detect.
>
> In some cases there seems to be direct overlap. For example, 5.2.5. says
> "The standard must provide means for monitoring for each Power Interface
> if it is in actual use." On the other hand, Section 5.2 seems to be
> missing an entry for nominal power ranges (especially maxima).

No discusison in email, no change in text.

---

> High/low power notifications in 5.3.6 are good. Did you consider high/
> low voltage and high/low frequency notifications?

No discusison in email, no change in text.

[Ballot comment]
Having looked into the matter, I am satisfied that this work has received satisfactory review in the power community.

---------


5.3.1.  Real power

  The standard must provide means for reporting the real power for each
  Power Interface as well as for an entity.  Reporting power includes
  reporting the direction of power flow.

It might be useful to Ref section 5.3.7 WRT which are you sure that complex power is the best heading. Most power engineers that I have spoken to seem to think in terms of the power factor of major equipment

[Ballot discuss]
Please can you confirm that you have verified that these are the power characteristics most useful to those that operate the power managements side of typical large installations.

Please confirm that some practicing power engineers have been involved in the compilation of this list of terms.

[Ballot comment]
5.3.1.  Real power

  The standard must provide means for reporting the real power for each
  Power Interface as well as for an entity.  Reporting power includes
  reporting the direction of power flow.

It might be useful to Ref section 5.3.7 WRT which are you sure that complex power is the best heading. Most power engineers that I have spoken to seem to think in terms of the power factor of major equipment

[Ballot comment]
I have some comments, mostly in the form of questions asking
for clarification.


the name intended to be a unique identifier?  Does that identifier
encode information about the type of the entity?  Or is the "name" a
type identifier for the entity?

5.2.4.  Availability of power

  The standard must provide means for monitoring the availability of
  power at each Power Interface.  This indicates whether at a Power
  Interfaces power supply is switched on or off.

I can't parse the last sentence, and I'm not sure what the intended
meaning is.

5.3.1.  Real power

  The standard must provide means for reporting the real power for each
  Power Interface as well as for an entity.  Reporting power includes
  reporting the direction of power flow.

Is "real power" a term of art (a brief definition would have helped
me).

5.3.4.  Accuracy of power and energy values

  The standard must provide means for reporting the accuracy of
  reported power and energy values.

Would the precision of the measurement be useful as well?

6.2.  Controlling power supply

  The standard must provide means for switching power supply off or
  turning power supply on at power interfaces providing power to one or
  more device.

This requirement raises a small philosophical question.  Does "Power
State" apply to power supplies (and, more generally, entities that
provide pwoer to a power outlet)?  If so, is thee a need to call out
power supplies as special entities or can they be controlled by their
Power State like other entities?

[Ballot discuss]
(1) Are sleepy nodes, power harvesting and self-controlling
devices included? (By self-controlling I mean devices that set
their own sleep-thresholds based on history.) They need to be
in some eventual standards. Maybe eman standards (and this
document) ought have some kind of applicability statement
limiting scope to "reasonably ok infrastructure" use-cases.
You might even be better off splitting battery powered devices
out at first as well.

(2) section 4, "Entities must be uniquely identified" is plain
wrong - 10.0.0.1 is just fine in lots of places.  Other parts
of section 4 based on this error will likely also need
changing. (2nd paragraph for example.) Note that this is not
the same as objecting to 4.1, which is fine.  Having
well-defined ways to identify things is fine but insisting
that all things are identified in any particular way (or ways)
is not. (7.4 and 8.1.4 have the same problem with their
combinations of "must" and "all".)

(3) 6.1, 6.2 and section 8 may have serious consequences - are
we really ready to go straight there? I think the
authorization implied by this is maybe too onerous to attempt
now except in limited cases (e.g. a data centre's separate
control VLAN).  I don't believe saying "sufficiently
protected" is enough, as you do in section 9. Again an
applicability statement might help here limiting these
features to networks that are reasonably well managed.

(4) section 9, the relevant privacy protection needed here
relates to stored data. Transmitted data will require
confidentiality but stored data has serious privacy
consequences, especially for home network devices.

[Ballot comment]
- section 2, I think it'd be better to distinguish "mains"
power inlets and power harvesting or "dodgy supply" inputs as
those have very different characteristics.

- 3.1 - it seems odd to not reference existing power state
standards here as those are widely used (S0 etc.)

- 3.2 - not all energy management is about simply using less,
in the case of power harvesting devices, one may need to
preserve energy so that it can be used when communications are
needed (with radios being the most expensive power consumers)

- section 4, 2nd para: "important to" do X is not stating a
requirement.

- 4.1, "The standard..." seems badly phrased. What if more
than one is needed?

- 4.2 seems like it'd need a new grand unified naming scheme.
I doubt that such will be done.

- is 5.1.1 really needed? seems too fine grained to be useful
to me

- 5.1.3 seems very vague

- 5.2, a solar panel connected to a charge controller doesn't
seem like a transmission medium to me

- 5.2, some devices supply power

- 5.2.5 might be impossible for a sleepy router (if you can't
ask cause its asleep which isn't instantaneously
distinguishable from broken)

- 5.6.1, in what units do you define battery charge? don't you
need to say?

- 5.6.4, isn't that temperature dependent? maybe actual
voltage would be as or more useful (I dunno, but that's worked
better for us with gel/VRLA batteries)

- 5.6.7, charge cycles are not the only causes of replacement
notifications I think - doesn't that depend on the battery
technology? e.g. memory effects

- 5.6.8 is too much - some arrangements of cells can only be
handled as a group

- 7.2 note that reporting for aggregates rather than lists of
individual indentifiers might be more useful

- 9.1 s/privacy/confidentiality/

- 9.1 protection against traffic analysis seems very hard here
in some cases but would be implied by referring to 3711, 1.4 -
do you really want that?

[Ballot comment]
3.2: The title of the section is a bit restrictive; delete the word "Agreements"

5.2: Though mentioned in the main body of 5.2, none of the 5.2 subsections mention that the standard must provide means to determining whether any particular interface is currently operating as an inlet or an outlet for those interfaces that change.

5.6: I find it a bit weird for batteries to be dealt with as something that an entity "contains" rather than being a full-fledged entity unto themselves. Batteries have a power interface that may be used as an outlet, and inlet, or both; they have voltage and power states on that interface; etc. Batteries are a special kind of entity in that they store charge, but calling them out as part of another entity seems weird. (By the way: Temperature is an awfully important property of batteries when it comes to power management; should it be required to be dealt with by eman standards?)

[Ballot discuss]
I was surprised that Power State is consistently capitalized, but is really a pretty fuzzy concept.

Instead of broad power states, most of the equipment I know of works by enabling / disabling or tuning subsystems in order to control the current being drawn overall.  For instance, turning off radio amplifiers, dimming or turning off displays, turning off hard disks, stepping down CPU performance, etc.

Are those sub-states of a Power State?  Apologies if it's clear to the authors or other readers, but I was not understanding this from the rough description in the document.

It isn't clear to me that this requires supporting conveyance of that kind of state, or management of that level of state.  Instead it's talking more about inlets and outlets, which sounds more like it's for managing a rough-grained set of power buses, but not so much for really working at managing the energy used by a network of functioning devices.

To resolve this DISCUSS:

If that's supposed to be in-scope, then I don't think it's clear.  I'll go to 'No Objection' if I'm the only one confused.

If that's NOT supposed to be in-scope, then I think it should be said explicitly.

[Ballot discuss]
I have a large number of Comments, some of which I think are quite
significant and I would appreciate it if the authors, shepherd, and AD
looked at them carefully. However, I am only elevating two of them to
the level of a Discuss

---

I'm not convinced by the indirection of reading/controlling the power
consumption/supply of/to one entity by accessing a different entity. I
understand the practicalities of this (for example, we have had IP-
connected power supplies for a number of decades), but I don't see the
correlation between powered entity and power supply being made anywhere.
That is, this indirection relies on manual configuration made in the
management system or possibly in the power supply.

I think you should observe this reliance, note its potential failings
and the potential for attacks, and discuss how this conifiguration could
be verified. (Noting that the security issue here is not one of direct
control - which you call out in Section 9 - but of making attempted
control of power to one entity actually affect the power to another
entity.)

There is a *tiny* amount of information found in 5.2.2 and 5.2.3. But,
the mechanisms discussed in that section appear to simply allow one
entity to be configured with the identity of a paower-partner entity,
which doesn't seem to close many holes - imaging if we did routing
like that!

---

Some of your references are used in a Normative way. In particular,
those referenced from Section 4.3 and also from 5.3 where it says:
  For reporting accuracy, the
  accuracy classes specified in IEC 62053-21 [IEC.62053-21] and IEC
  62053-22 [IEC.62053-22] should be considered.
Additionally, the reference from 9.1 is normative.

[Ballot comment]
0) Support Stephen's discuss wrt privacy/confidentiality.  Attackers are going to go after the most significant entity first, so we need to keep their data private when stored and protected in transit. 

1) abstract: r/functions:/functions.

2) abstract/intro: is actual power consumed power?  No wait it's supposed to be power state?

3) intro: The 2nd paragraph's last two sentences are repeated in the 4th so maybe just delete the 2nd paragraph's last two sentences and merge the 2nd and 4th paragraph?

4) I echo Adrian's kudos for avoiding 2119.

5) s1.2: Hoping that the authentication/authorization scheme to allow one device to monitor another is going to be a requirement later on.

6) s2: Had the same issue Barry did with Energy Management definition.

7) s3.1: Agree with Adrian on power states.  There's also always standby as opposed to sleep - or are they the same thing?  Maybe also full power = on for those simple entities.

8) s3: Is energy management all about actually using less energy?  I would have thought energy management was about informing the management entity about the power consumption to allow them to take some action, which just as well might be no action because it's operating in some normal range.  I mean I can run a nuclear reactor right at the minimum Level of Energy needed or maybe I can be somewhere above that minimum in a safety zone.  Then again, maybe minimal is the lower bar of the safety bar.  Regardless, I'm sticking with my first sentence ;)

9) s3.2: Awkward (well at least for me)

OLD:

Then a trade-off
needs to be dealt with between service level objectives and energy
  minimization.

NEW:

In this case, a trade-off needs to be made between service level
objections and energy minimization.

10) s3.3: I guess we need some kind of requirement for synching clocks?

11) s?: Do you also need to know who's been assigned to manage the entity?  Is that in context of an entity?  Also do you need to know location data or is that provided through another mechanism?

12) s5.4: Does this section cover the timers set on local systems for stuff like System Sleep Timer, Disk Sleep Timer, etc?

[Ballot discuss]
There is a lot of text in this document that tries to constrain how to build an Energy Management System, and don't have anything to do with placing requirements on standards documents for interacting with what they measure. The instance that elevated this to a DISCUSS for me is in 5.7 where the document says "It should be avoided that time series data can only be obtained through regular polling by the energy management system." Why should the IETF be making such a statement in this document?

[Ballot comment]
Many logging systems in existing energy management systems only create records when the thing being measured changes by a threshold (such as a temperature changing by so much). It's not clear how the data from this type of system and the requirements at 5.7.1, 5.7.2, and 5.5.2 interact.

How does section 3 (particularly section 3.2) inform requirements on standards documents. It would help to recast these in what difference it makes to what's required of those standards documents.

[Ballot comment]
The discussion of time series measurements in 5.7 raises the question of time synchronization.  Is there a need to ensure that time is synchronized between data collectors and data generators?

[Ballot discuss]

(1) Are sleepy nodes, power harvesting and self-controlling
devices included? (By self-controlling I mean devices that set
their own sleep-thresholds based on history.) They need to be
in some eventual standards. Maybe eman standards (and this
document) ought have some kind of applicability statement
limiting scope to "reasonably ok infrastructure" use-cases.
You might even be better off splitting battery powered devices
out at first as well.

(2) section 4, "Entities must be uniquely identified" is plain
wrong - 10.0.0.1 is just fine in lots of places.  Other parts
of section 4 based on this error will likely also need
changing. (2nd paragraph for example.) Note that this is not
the same as objecting to 4.1, which is fine.  Having
well-defined ways to identify things is fine but insisting
that all things are identified in any particular way (or ways)
is not. (7.4 and 8.1.4 have the same problem with their
combinations of "must" and "all".)

(3) 6.1, 6.2 and section 8 may have serious consequences - are
we really ready to go straight there? I think the
authorization implied by this is maybe too onerous to attempt
now except in limited cases (e.g. a data centre's separate
control VLAN).  I don't believe saying "sufficiently
protected" is enough, as you do in section 9. Again an
applicability statement might help here limiting these
features to networks that are reasonably well managed.

(4) section 9, the relevant privacy protection needed here
relates to stored data. Transmitted data will require
confidentiality but stored data has serious privacy
consequences, especially for home network devices.

[Ballot comment]

- section 2, I think it'd be better to distinguish "mains"
power inlets and power harvesting or "dodgy supply" inputs as
those have very different characteristics.

- 3.1 - it seems odd to not reference existing power state
standards here as those are widely used (S0 etc.)

- 3.2 - not all energy management is about simply using less,
in the case of power harvesting devices, one may need to
preserve energy so that it can be used when communications are
needed (with radios being the most expensive power consumers)

- section 4, 2nd para: "important to" do X is not stating a
requirement.

- 4.1, "The standard..." seems badly phrased. What if more
than one is needed?

- 4.2 seems like it'd need a new grand unified naming scheme.
I doubt that such will be done.

- is 5.1.1 really needed? seems too fine grained to be useful
to me

- 5.1.3 seems very vague

- 5.2, a solar panel connected to a charge controller doesn't
seem like a transmission medium to me

- 5.2, some devices supply power

- 5.2.5 might be impossible for a sleepy router (if you can't
ask cause its asleep which isn't instantaneously
distinguishable from broken)

- 5.6.1, in what units do you define battery charge? don't you
need to say?

- 5.6.4, isn't that temperature dependent? maybe actual
voltage would be as or more useful (I dunno, but that's worked
better for us with gel/VRLA batteries)

- 5.6.7, charge cycles are not the only causes of replacement
notifications I think - doesn't that depend on the battery
technology? e.g. memory effects

- 5.6.8 is too much - some arrangements of cells can only be
handled as a group

- 7.2 note that reporting for aggregates rather than lists of
individual indentifiers might be more useful

- 9.1 s/privacy/confidentiality/

- 9.1 protection against traffic analysis seems very hard here
in some cases but would be implied by referring to 3711, 1.4 -
do you really want that?

[Ballot discuss]
I have a large number of Comments, some of which I think are quite
significant and I would appreciate it if the authors, shepherd, and AD
looked at them carefully. However, I am only elevating two of them to
the level of a Discuss

---

I'm not convinced by the indirection of reading/controlling the power
consumption/supply of/to one entity by accessing a different entity. I
understand the practicalities of this (for example, we have had IP-
connected power supplies for a number of decades), but I don't see the
correlation between powered entity and power supply being made anywhere.
That is, this indirection relies on manual configuration made in the
management system or possibly in the power supply.

I think you should observe this reliance, note its potential failings
and the potential for attacks, and discuss how this conifiguration could
be verified. (Noting that the security issue here is not one of direct
control - which you call out in Section 9 - but of making attempted
control of power to one entity actually affect the power to another
entity.)

There is a *tiny* amount of information found in 5.2.2 and 5.2.3. But,
the mechanisms discussed in that section appear to simply allow one
entity to be configured with the identity of a paower-partner entity,
which doesn't seem to close many holes - imaging if we did routing
like that!

Incidentally these sections would benefit from inserting the word
"entity" so...

5.2.2.  Corresponding power outlet

  The standard must provide means for identifying the entity and power
  outlet that provides the power received at a power inlet.

5.2.3.  Corresponding power inlets

  The standard must provide means for identifying the list of entities
  and power inlets that receive the power provided at a power outlet.

---

Some of your references are used in a Normative way. In particular,
those referenced from Section 4.3 and also from 5.3 where it says:
  For reporting accuracy, the
  accuracy classes specified in IEC 62053-21 [IEC.62053-21] and IEC
  62053-22 [IEC.62053-22] should be considered.
Additionally, the reference from 9.1 is normative.

[Ballot comment]
Congratulations on resisting the use of 2119 language. Well done!

---

In Section 2

  Energy control

      Energy control is a part of energy management that deals with
      directing influence over network elements and attached devices and
      their components.

"Directing influence" is too imprecise for me. For example, as written,
this could involve controlling fatures of a network element so as to
reduce power consumption. But, according to the Abstract/Introduction,
the control that you are talking about is limited to "controlling power
supply and power state". Could you tighten up this definition?

---

Section 3.1

  In principle, there are three basic types of Power
  States for an entity or for a whole system:
  o  full Power State
  o  sleep state (not functional, but immediately available)
  o  off state (may require significant time to become operational)
  In specific devices, the number of Power States and their properties
  varies considerably.

Superficially, it seems hard to conceive that the variation in a total
of 3 basic types of state cold vary significantly!
                                                                                                     
I would suggest that you introduce a 2nd entry in the list, viz.
  o reduced power operational state (not fully functional, but still
    operational)

It is this basic type that has the widest potential for variation and
fits with your subsequent statement:

  However, more finely grained Power States can be implemented.

Indeed, there are no granularities of the the three absolutes that
form your list!

---

A little surprised to find no mention of allowing local policy to
override attempted control of power state. The is some hint in Section
3.3, but nothing much.

It seems to me that there is a need for both:
- An entity to have a good reason to know better than the management
  system
- A management system to be able to override the local entity

I would suggest that this needs to be discussed so that it can be built
into the framework and solutions.

---

The term "power properties" is used in the Abstract and Introduction,
and then shows up in Section 3.5.  No clue is given as to what it means
until Section 5.3; and then only definition by examples.

Could you add it to the terminology section?

---

Shouldn't Section 4 expand on "subtended devices"? Or is this a forward
pointer to Section 7?

---

4.2.  Persistence of identifiers

  The standard must provide means for indicating whether identifiers of
  entities are persistent across a re-start of the entity.

This is important, but doesn't go far enough.
In *any* case where the identity of an entity or its components can
change there has to be a mechanism in place to ensure that the control
exerted by a management system is applied to the correct component.

---

4.3.  Using entity identifiers of other MIB modules

s/other/existing/

---

5.1

  it may be important to exclude
  some vital network devices from being switched to lower power or even
  from being switched off

I think you have your two cases reversed.

  it may be important to exclude
  some vital network devices from being switched off or even from being
  switched to lower power

FWIW, "vital" might actually be being used correctly here, but I suspect
you mean a more general "mission critical" type term.

---

5.1.1.  Type of entity

  The standard must provide means to configure, retrieve and report a
  textual name or a description of an entity.

I don't feel that a textual name/description helps to classify the type
of an entity. Furthermore, this hasn't really helped me understand what
you mean by "type of entity".

---

I found 5.1.2 and 5.1.3 a bit vague notwithstanding the examples
provided.

  tags associated with an entity
  that indicate the entity's role.

What roles have you in mind?

  how
  important the entity is.

Important to whom? Important for what? In what context?

---

I'm not sure, but it seemed to me that there is confusion between
Secitons 5.2 and 5.3. 5.2 is supposed to describe the capabilities
of the power interfaces, while 5.3 monitors what is happening at them.

In some cases, the issue is simply not enough flexibility. For example,
in 5.2.7 the "nominal voltage" on an interface may actually be a range.
Consider devices that can be plugged into a varieties of supply and
auto-detect.

In some cases there seems to be direct overlap. For example, 5.2.5. says
"The standard must provide means for monitoring for each Power Interface
if it is in actual use." On the other hand, Section 5.2 seems to be
missing an entry for nominal power ranges (especially maxima).

---

Not that it matters, but if you are reporting instantaneous power and
actual voltage, you probably don't need to also report actual current.

---

High/low power notifications in 5.3.6 are good. Did you consider high/
low voltage and high/low frequency notifications?

[Ballot comment]
No objection, and nothing blocking here -- just some clarity points:

This document is going to get a lot of editing from the RFC Editor, so be prepared for that during AUTH48, and give it careful review to make sure they didn't make any mistakes in the process.  I'm not going to try to do their job, but I will try to call out a few of the items that I found actually confusing when I reviewed it.

-- General --
You capitalize "Power Interface" and "Power State", but not "power inlet" and "power outlet".  This seems purposeful, but the purpose isn't clear.  What's the purpose?  Is it worth explaining that in the document (quite possibly it isn't)?

-- Section 1 --
  Subject of energy management are entities in the network.  An entity
  is either a device or one of a device's components that is subject to
  individual energy monitoring or control or both.

Too many "or"s make it a bit confusing what the "or both" means.  Is it "a device, a component, or both," or is it "monitoring, control, or both"?  It's also not clear whether the "that is subject to" part applies to both devices and components, or just to components.  Maybe this is crisper?:

NEW
  Subjects of energy management are entities in the network.  An entity
  is a device or one of a device's components, which is subject to
  individual energy monitoring and/or control.
END

  In detail, the requirements listed are focused on the following
  features: identification of entities, monitoring of their Power
  State, power inlets, power outlets, actual power, power properties,
  received energy, provided energy, and contained batteries.  Further
  included is control of entities' power supply and Power State.

As I read this, I get a list of features:
1. Identification of entities.
2. Monitoring of their [the entities'] Power State.
3. Power inlets.
4. Power outlets.
5. Actual power.
... etc ...

You can see that 1 and 2 have verbs, but the rest don't.  Or did you mean for "monitoring" to apply to all of them?  If that's the case, let me suggest using semicolons to group the comma-separated lists, this way>

NEW
  In detail, the requirements listed are focused on the following
  features: identification of entities; monitoring of their Power
  State, power inlets, power outlets, actual power, power properties,
  received energy, provided energy, and contained batteries; and 
  control of their power supply and Power State.
END

-- Section 2 --
      Energy Management is a set of functions for measuring, modeling,
      planning, and optimizing networks to ensure that the network
      elements and attached devices use energy efficiently and is
      appropriate for the nature of the application and the cost
      constraints of the organization [ITU-M.3400].

One gets lost in such a long sentence, and by the time "and is appropriate" comes along, one can't decide what the subject of "is" is.  It looks like it should be "Energy Management", but that can't be right, because breaking out a sentence such as, "Energy Management is appropriate for the nature..." doesn't work.

I think maybe you mean this, yes?:

NEW
      Energy Management is a set of functions for measuring, modeling,
      planning, and optimizing networks to ensure that the network
      elements and attached devices use energy efficiently and in a
      manner appropriate to the nature of the application and the cost
      constraints of the organization [ITU-M.3400].
END

Oh, and you can't seem to decide whether it's "energy management" (the definition heading and subsequent usage) or "Energy Management" (the definition body).  The same is true for "energy management system", which follows.

Please be sure you're consistent in your capitalization of all these terms; the RFC Editor will call that out, so save time now.

-- Section 3.1 --
  However, more finely grained Power
  States can be implemented.

Perhaps it's worth giving an example or two of what finer-grained Power States might look like (or providing a citation to where such examples are)?

-- Section 3.2 --
  In many cases there is
  no way of reducing power without the consequence of a potential
  performance, service, or capacity degradation.

Aren't performance degradation and capacity degradation *types* of service degradation?

IANA has reviewed draft-ietf-eman-requirements-10, which is currently
in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Requirements for Energy Management) to Informational RFC


The IESG has received a request from the Energy Management WG (eman) to
consider the following document:
- 'Requirements for Energy Management'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines requirements for standards specifications for
  energy management.  The requirements defined in this document concern
  monitoring functions as well as control functions: Monitoring
  functions include identification of energy-managed devices and their
  components, monitoring of their power states, power inlets, power
  outlets, actual power, power properties, received energy, provided
  energy, and contained batteries.  Control functions serve for
  controlling power supply and power state of energy-managed devices
  and their components.
  This document does not specify the features that must be implemented
  by compliant implementations but rather features that must be
  supported by standards for energy management.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Informational.  This is the EMAN Requirements draft, defining
what an energy management system does, it will be followed up by
the EMAN Framework draft.  Yes.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

This document defines requirements for standards specifications for
energy management.  These concern monitoring functions as well as
control functions: Monitoring functions include identification of
energy-managed devices and their components, monitoring of their power
states, power inlets, power outlets, actual power, power properties,
received energy, provided energy, and contained batteries.  Control
functions serve for controlling power supply and power state of
energy-managed devices and their components.

Working Group Summary:

Version -08 of this draft was presented in the EMAN session at
IETF 84 (Vancouver).  The authors published -09, resolving the
open issues discussed at that meeting.  The draft's Working Group
Last Call ran from 4 October to 22 October this year, and raised
several more issues.  After IETF-85, the authors published its
-10 version; we believe it is now ready to submit to IESG.

Document Quality:

Are there existing implementations of the protocol?
  This is a requirements draft, not a protocol.
Have a significant number of vendors indicated their plan to implement
the specification?
  At least two vendors have implemented Energy Management systems,
  and - presumably - will make them EMAN-compliant.
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?
  Since September the following have contributed comments on the
  EMAN list:  Ira McDonald, John Parello, Brad Schoening, Georgios
Karagian.
  However, the draft's authors/editors have done most of the work
  in developing it.
If there was a MIB Doctor, Media Type or other expert review, what was
its course (briefly)?
  The draft hasn't had any kind of expert review.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd:      Nevil Brownlee
Area Director: Ron Bonica

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have read the draft carefully, it explains what 'energy management'
means in a networked environment, what goals an energy management system
needs to achieve, and how managed entities in such a system are
expected to behave.  I believe the draft is ready for IESG submission.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

No issues of concern.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

This is a typical Requirements draft, I don't believe it needs any IPR
declarations (it has none).  Further, its editors are all well aware of
IPR considerations.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No, see (7) above.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is strong consensus for this draft within the EMAN WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

I-D-nits checker says "No nits found."

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

This draft has no sections of this kind.

(13) Have all references within this document been identified as
either normative or informative?

Yes.  All its references are Informative; it will become a Normative
reference for EMAN's three MIB drafts.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

No.  One Informative reference is to an unpublished EMAN draft.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existny programing RFCs? Are those RFCs listed on the title page header,
listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

It has no IANA Considerations.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

It has no IANA Considerations.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No part of this draft is in any formal language.