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

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.

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?

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?

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.

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?)

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?

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?

Thanks for addressing my discuss points

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