Last Call Review of draft-ietf-eman-applicability-statement-08

Request Review of draft-ietf-eman-applicability-statement
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-12-01
Requested 2014-11-18
Authors Brad Schoening, Mouli Chandramouli, Bruce Nordman
Draft last updated 2014-11-21
Completed reviews Secdir Last Call review of -08 by Melinda Shore (diff)
Opsdir Last Call review of -08 by Qin Wu (diff)
Opsdir Last Call review of -08 by Fred Baker (diff)
Assignment Reviewer Fred Baker
State Completed
Review review-ietf-eman-applicability-statement-08-opsdir-lc-baker-2014-11-21
Reviewed rev. 08 (document currently at 11)
Review result Has Nits
Review completed: 2014-11-21


As part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG, Fred and I joined together and discussed this draft. Here is our combined view on this draft. These comments were written primarily for the benefit of the operational area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document is well written and provides a lot of examples and use cases to discuss how energy management information model can be applied to various scenarios. I believe it is almost ready for publication.


1.Section 3.
It seems section 3 summarizes some of patterns that are abstracted from use cases in section 2, but some of patterns are missing, e.g., Second level management doesn't provide metering capability but responsible for aggregate data for further reporting.

The energy object having metering capability should also be responsible for reporting energy data, it may either report the data to the NMS or report the data firstly to second level manager, and then second level manager report the data to the NMS, In this case, the second level manager is also a energy object but this energy object should support management function.

Also it seems energy consumption control should not be used without energy consumption metering, since we need to verify if operation is correct by relying on metering mechanism when any energy consumption control is applied.
But metering and control on some device doesn't need to be performed by the same energy object, e.g., we can have energy object A perform metering on device D and have energy object B perform control on device D. In this case, energy object A need to report energy data to energy object B.

Therefore it is better to summarize these energy object patterns from metering pespective, control perspective, power method perspective separately.

2. Section 3.
Patterns to be abstracted from use cases are only applied to energy object. They are not applied to Energy Management System. It is better to make this clear in the draft.

3. Section 3.
What is the metering? What is the control? It is better to have a clear definitions for them in the terminology section, e.g., who perform metering, who perform control, if one device aggregate the data reported from the other device, can we view aggregation as some kind of control?
Do we consider Energy Management System perform control on some device?


1.Section 1.4 said
The EMAN framework provides mechanisms for energy control in addition to passive monitoring.  There are many cases where active energy management of devices is desirable 

>From what I read the 1st paragraph of section 1.4, it seems to indicate that passive monitoring is referred to simply report energy consumption while active energy management is referred to energy control, e.g., provide dynamic response to reduce energy consumption in case of power shortage, it is better make this explicit if the answer is yes.

2.Section 1.4, 4th paragraph said:
from centralized  management by a network management station, to autonomous 
control by individual devices 

When we talk about supporting centralized approach and autonomous control based approach for energy object control in section 1.4, Do we need to support control function in both network management system and managed individual device? or we just mean to use management function to provide control on energy object?

When we talk about support control function in the EnMS, do we mean only EnMS need to support control function? or some Individual device also need to support control function?

It is better to make a clear clarification for this in the draft.

3. Section 2, 1st paragraph said:
Each scenario lists target devices 
for which the energy management framework can be applied, how 
the reported-on devices are powered, and how the reporting is 
energy object control is also important capability provided by Energy management. 
The last two cases in section 2 ,i.e.,  Demand Response use case in section 2.13 and Power Capping use case in the section 2.14 focus on discussing how energy object control can be performed. Suggested to 

change 1st paragraph in section 2 as follows:
Each scenario lists target devices for which the energy management framework can be applied, how the reported-on devices are powered, and how the reporting is accomplished
Each scenario lists target devices for which the energy management framework can be applied, how the reported-on devices are powered, how the reporting or control is accomplished.
4. Section 2.2, first paragraph said:
This scenario covers Power over Ethernet (PoE) devices.  A PoE
Power Sourcing Equipment (PSE) device [RFC3621] (e.g. a PoE
switch) provides power to a Powered Device (PD) (e.g. a desktop
We think the MIB will be used for lots of things that aren't POE. it appears this draft targets POE without other electrical configurations, was it intentional to use MIB only for POE in this draft?

5. Section 2.13
Unlike other use case, this case didn't discuss the target device for which the EMAN framework can be applied and how reported on device are powered and how report is accomplished. Instead, it discuss how Energy Management system react to energy shortfall?

To consistent with other use cases, it is better to add essential properties of this use case:
Target Devices: Any Device
How Powered: Any method
Control: Demand Response based on Policy or Priority.

6. Section 2.14
Unlike other use cases in section 2.1~ Section 2.12, it discusses how managed device adjust its operation mode based on Power threshold.
To consistent with other use cases, suggest to add essential properties as other use cases:
Target Device: Any Device
How Powered: Any method
Control: Power Capping.

7. Section 5, 1st paragraph said:
EMAN addresses the needs of energy monitoring in terms of 
measurement and, considers limited control capabilities  of 
energy monitoring of networks.

Can you give an example of limited control capabilities?

8. Section 5, 2nd paragraph said:
EMAN does not address questions regarding Smart Grid, electricity producers, and distributors

I don't understand this statement. It looks The metering part of the model proposed by ASHRAE overlaps with the EMAN framework.
ASHRAE is related to smart grid. So EMAN does address some question regarding smart grid, what am I missing?

9. Section 4.
I was very happy to see direct call-out of comparative work, especially IEC 61970 (CIM) and IEC 61850. It would be good if the information model (the set of attributes, definitions thereof, and units) behind the MIB came from those specifications and IEC 62301. It's not clear that they did; if they didn't, a future task will be providing a direct translation from this MIB to those frameworks, as that is what businesses use.

10. General comment
There is a fundamental flaw in the model, which should at least be called out. It treats electricity like water. If I put a liter of water into a pipe, a liter of water will come out somewhere else. That's not true of electricity, at least not in a direct sense. Leakage, heat, and other mechanisms dissipate energy, so that a quantum of electricity placed into a medium will deliver a fraction of a quantum of electricity at the far end. This affects statements such as a measurement of the electricity placed into POE for a set of downstream devices may be treated as an aggregate of them. It would be more accurate to say that a measurement using a technology in a place is just that: measurement using a technology in a place. It may be correlated with other measurements, but an expectation that it will read exactly the same is misplaced.

11. Section 2.1
The third paragraph of section 2.1, which starts with "The ENTITY-MIB provides the containment model", needs work. The second sentence is a run-on sentence. Also, the fact that it CAN be one thing raises the question in my mind whether it CAN be something else that remains unidentified; replace with:

A component IS an Energy Object. The ENTITY-MIB identifies WHETHER one Energy Object belongs to another Energy Object (e.g. ...)

The final "sentence" isn't a sentence. Thinking about how to reword it, I come up with at least two and probably three or four possible intended meanings.

Thank you.
Qin & Fred