Last Call Review of draft-ietf-eman-applicability-statement-08
review-ietf-eman-applicability-statement-08-opsdir-lc-baker-2014-11-21-00

Hello,
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.

Summary:
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.

Major:

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?

Minor:

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
accomplished
"
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:
OLD TEXT:
"
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 " NEW TEXT: " 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 phone). " 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: e.g., 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: E.g.,
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