Thanks Juergen for the detailed review. I've applied the majority of your comments which will apear in -11
See inline:
(+) Applied in the draft
(-) Regretfully not applied for the reasons listed
(!) Not applied needing more clarification and/or see further comment or thread

<deletia> for better reading....


------
Dear all,

Here is my review of draft-ietf-eman-framework-10. I did not review version -09 for which the call was made, but the newer version -10 that was posted during last call.

<deletia>

General comments:

A. The document rather looks like a documentation of a software design (with some extensions) than like a framework for energy management. Modeling focusses on abstractions, classes, attributes, but issues of the physical world are neglected.

JP : Hopefully cleared up with your comments below

B. Do we claim that energy management is (a) a part of network management extending FCAPS or do we see this energy management (b) as something separate from network management? Several statements in the draft seem to assume (b).

JP : It's clearly both. For example Security is a an area of mgt that can stand apart from network management and is also a part of it.

C. The text has improved from earlier versions. Still, phrasing is often sloppy and not up to the quality we should have for RFCs. Many phrasings sound nice, but only as long as you are not interested in understanding exactly what they mean. I commented on several instances below, but by far not on all of them.

JP : Obviously by submitting the draft to  WGLC we feel it is ready to progress.  I'd hate for you to withdraw as an author but considering your strong value judgement on the rest of our work I would completely understand if you did and wanted to remain a valued reviewer.  I'll progress on your comments and edits below in the hope that you can reconcile your feelings on this.

D. I have not thoroughly reviewed the ridiculously long terminology section on pages 5-10. This can be cut significantly. Do we really want to re-define terms you can find in text books, such as power-->Power, energy-->Energy, device-->Device, etc., etc.?  It is certainly necessary to define a term like "Power State", But defining "Power State Set" as a set of power states, etc., etc. is just a waste.

JP : We moved the modeling terms out as well so this shortened the section. As a WG, we, you included, have spent many a call and draft revision on the terms. I'll consider this as a +1 from you on the separate terminology draft that I both proposed as work for the group and I asked for as a WG document at IETF 87.

E. The physical reference model in section 3.2 is missing most of the required content. Basic components of the model are not defined, see item 15. below. Further missing is the physical mode of a meter and of a power interface.

JP : For the physical I hope you can see we tried to trim the draft to a reasonable discussion on the physical topologies. Please see modifications in -11 and described below. As for the physical mode of a power interface as a meter we discussed that in
http://www.ietf.org/mail-archive/web/eman/current/msg01993.html
http://www.ietf.org/mail-archive/web/eman/current/msg01996.html
and concluded that metering is an overloaded term and should be used to describe a device that is a meter not the act of measuring. Measuring != metering.


F. The information model in this draft is lacking elements for battery management.

JP : Which elements from the battery MIB should be provided back in the abstract model of the framework? We included store and the stored energy fields. We could as in other threads put the charging states in the state registries and consolidate the models.


G. Technically, I would like to make a proposal for Sections 4.3.2-4.3.6, the context information as there are currently: category, importance, keywords, role, and domain. I see that all of them can have their value in certain deployments. However, I see two limitations:
G.1. The set of content information is fixed.
All of the included attributes have potential to be useful in certain deployments. However, in other scenarios, or with other management systems, other context information will be relevant, such as, for example, the devices location or its power-down-priority.
G.2. There is only one instance of each per Energy Object
The current model allows for only one instance of each context attribute. This is often not sufficient, particularly for type, role, and domain. As discussed many times on the list, a device can be contained in multiple metering domain, ad device can have multiple roles, and it can match multiple categories, such as, for example, distributor and meter.
What I think is needed is a more open and extensible framework for context information, that allows arbitrary context information and multiple instances of each context. The result could, for example, in XML look like
<context>
    <category>distributor</category>
    <category>meter</category>
    <role>PDU</role>
    <location>East Wing</location>
    <location>Server Room</location>
    <meteringDomain>Building A</meteringDomain>
    <meteringDomain>East Wing Level 3</meteringDomain>
    <costFactor>0.7</costFactor>
</context>
or in JSON look like
"context": {
    "category": [ "distributor", "meter" ],
    "role": "PDU",
    "location": [ "East Wing", "Server Room" ],
    "meteringDomain": [ "Building A", "East Wing Level 3" ],
    "costFactor": 0.7
}

JP : We've discussed this at length and the approach we chose was to use a vector for the keywords to allow for further defining context you describe. We proposed scalar for the PRIMARY category and the PRIMARY role.

LOCATION: I think you are mistaking a vector as a way to provide a syntactic/semantic definition of an attribute. Clearly location  is not a vector as you describe it above. Recall RFC3814 has syslocation as a scalar. I doubt you propose a device can exist in two locations, but what I glean from your example is the desire for a syntax and semantic description of a specific location.  I think adding a syntax and semantic to a scalar location attribute such as described in rfc4776 (or geopriv) would be more appropriate. So +1 on that, but just making it a vector does nothing.

ROLE: So I think what you want is a syntax and  semantic description of Role as well. In the absence of that work I think (based on feedback in deployments) it best to keep the attributes a scalar with guidelines to avoid the same kind of mistake you propose with location.  In general making the values a vector in case it might be needed is over engineering the attribute.  Given the experience we've had from our deployments of these fields for quite some years now we've settled without the need for a vector for role, category, and domain. So -1 on vector for the same reasons as location and +1 on working on a semantic in later work.

CATEGORY: We discussed this previously. We said the category represents the primary purpose w.r.t. EM.
See reply here http://www.ietf.org/mail-archive/web/eman/current/msg02026.html
We implemented this in our devices and systems as a vector and changed to a scalar for reason's that echo Brad's description. The value of the field was marginalized when it was a vector.

ETC: We can separate this to a thread not to debate but to remind you of the approach if that's helpful (ex: not sure what you're talking about for metering domain? and cost "factor" is specifically out of scope.)


Specific comments:

1. Abstract, line 1: "This document defines a framework for providing Energy Management ..."
Why for only for 'providing' energy management? Why not as well for operating, maintaining, etc. I suggest deleting 'providing'.

+ JP - removed "providing"

2. Abstract, lines 5-7: "The information model consists of an Energy Management Domain as a set of Energy Objects. Each Energy Object is identified, classified, and given context."
Obviously, the first sentence is nonsense. The second sentence is only correct if it is mandatory to add context and classification to every energy object. I do not see this in the framework. I suggest replacing the quoted text it with "The information model describes Energy Objects to which information on their identity, classification, and context can be attributed."

+ JP - ignoring the value judgement (especially since we reviewed this abstract at length together) your point under it all was to make sure the abstract do not infer mandatory. Done.

3. Abstract, lines 7-9: "Energy Objects can be monitored and controlled with respect to Power, Power State, Energy, Demand, Power Attributes, and Battery."
Control is only available for power states and for battery states. The current text implies much more. I suggest clarifying this, for example, using the following text as replacement: "The framework covers monitoring of Power, Power State, Energy, Demand, Power Attributes, battery properties and battery states of Energy Objects. It also covers control of power states and battery states."

! JP : Not sure how the current text implies more. For example by controlling power states you will control energy so I think the text as it stands is more concise with the same meaning esp. for an abstract.  I think the text you have is equal and less concise than the original. If you give me an idea / example of what you think it implies that it should not then I am sure I  can craft something simpler.

4. Section 1 "Introduction", 2nd paragraph, lines 3-4 (page 3): "router" --> ""

+ JP : done

5. Section 1 "Introduction", 2nd paragraph, lines 8-9 (page 4): "If a device contains batteries, these can also be monitored and controlled."
Obviously, it is not sufficient that a device just contains batteries for being able to control them. I suggest replacing the text by "Monitoring and control of batteries contained in devices is also covered by the EMAN framework.

+ JP : change to "The framework also covers monitoring and control of batteries contained in devices."

6. Section 1 "Introduction", 5th paragraph, last 2 lines: "and an understanding of the potential aggregation (ex: does a meter aggregate values from other devices)"
I do not think it is clear at this place what "aggregation"/"aggregate" means.

+ JP: Carried the alliteration along and replaced it with
"""
An EnMS (Energy Management System) generally requires an understanding of the power topology (who provides power to whom), the metering topology (who meters whom), and an understanding of the potential aggregation (who aggregate values of others).
"""

7. Section 2: Terminology, page 9, "Power Interface"
The text says: "A Power Interface (...) is an information model (class) that represents ...". This is wrong. A Power interface is located at a device and is not an abstract class. The abstract class is called "Power Interface Class", see section 4.2.3

- JP : The Power Interface (class) is an abstract representation on a Device (class) of a physical inlet or outlet which is located on a physical device.

8. Section 2: Terminology, page 9, "Energy Object"
See point 7. above. These are physical objects, not classes.

- JP : We've made the distinction between the abstract representation in the model versus the physical. Ex: I've tripped over many devices in my life but never an Energy Object. So Energy Object is the class and device being a piece of equipment is the physical thing.

9. Section 3.1, 3rd paragraph, last sentence: "These target devices include:"
I don't think the list below is exclusive. Suggestion: "These target devices include, for example:"

+ JP : Done

10. Section 3.1, 4th paragraph, line 1: "Target devices will primarily communicate via Internet Protocols"
Why "will"? Probably correct would be "do".

+ JP : Deleted "will"

11. Section 3.1, 4th paragraph, lines 2-3: "The target devices may also include those communicating via non-IP protocols ..."
What's this? Do we here defining a standard? Either the standard includes non-IP devices or not.
12. Section 3.1, 4th paragraph, lines 4-5: "These types of target devices are expected to be managed through gateways ..."
What means "are expected"? What if this is not the case?
A proposal for solving 10., 11., and 12.:
OLD
        Target devices will primarily communicate via Internet
        Protocols (IP). The target devices may also include those
        communicating via non-IP protocols deployed among the power
        distribution and IP communication network. These types of
        target devices are expect to be managed through gateways or
        proxies that can communicate using IP.
NEW
        Target devices include devices that communicate via the Internet
        Protocol (IP) as well as devices using other means for communication.
        The latter are managed through gateways or proxies that can
        communicate using IP.

+ JP : applied NEW

13. Section 3 "Concerns Specific to Energy Management"
This section describes target devices, a physical reference model, and "major concerns specific to Energy Management". Giving it a title that covers only the third item contained is inappropriate.

+ JP: "3. Target Devices, Physical Reference Model and Management Concerns"

14. Section 3 "Concerns Specific to Energy Management", 2nd sentence: "physical reference models" and Section 3.2 "Physical Reference Model", first sentence: "The following reference models describe ..."
Here we have a terminology issue: The title of the section is  "Physical Reference Model" and also the Abstract of the draft states "The framework presents a physical reference model ...". Both use the singular form of model.  But the second sentence of Section 3 and the first sentence of section 3.2 talk about multiple models. I think the Abstract and the section title are correct, but the sentence is wrong. There seem to be just a single model which is used to illustrate different scenarios in the figures in this section.

+ JP : singular for model and plural for topologies

15. Section 3.2 "Physical Reference Model"
A model is used, but I cannot find it described in the draft, neither in this section where one would expect it, nor anywhere else. Where is it? Just to be clear, a reference model typically consists of a set of roles, such as, for example, device, energy management system, power source, etc., and of relations, such as a power source relationship, a monitoring relationship, a control relationship, etc. I cannot find these defined as components of the model.

! JP : We have defined the components of the model as diagrammed. If there's more you think we need to add to describe the role, etc, in the model can you provide concise text?


16. Section 3.3 "Concerns Differing from Network Management"
This section rather looks like a power point slide that can hardly be understood without a person presenting it. The bullets in this section are too short for the reader to easily understand what issue is addressed at all and what the consequences are. Some of the bullets do not make any sense to me. At least 6 out of 7 seem to be broken:
  - bullet #1: This does not seem to be different from network management
  - bullet #2:  I don't understand the last line: "controlling a simple light by controlling its outlet". How does this work?
  - bullet #3: What special coordination do devices need if there is more than one PDU in a power distribution network?
  - bullet #4: What means "require a separate interface model from Network Management"?
  - bullet #5: Seems to be broken. I don't get the message. Is there a typo in the last line?
  - bullet #7: I am not sure what is really a difference to network management where we have the entity MIB and different models for managing devices (e.g. routers) and components (e.g. line cards). The third paragraph of Section 4.1 claims that this is very similar to network management.

! JP : Yes. As an editorial exercise I condensed the pages you all wrote that covered this section from the previous drafts to a list. So I'm trying to capture what you all as the authors want in this section. I don't think we need pages of description just a few paragraphs simply listing the differences - if the section is needed at all. @Authors So what points would you like in? I'll proposed a new section.

17.  Section 3.4 "Concerns Not Addressed", 1st paragraph, line 4: "normalized to the electrical units for power and energy". This is nonsense. There is indeed an "electrical" units for power (Voltamperes,VA), but we are using rather "non-electrical ones, such as Watts (Joule per second) and Watt-hours.
OLD
        Non-Electrical Equipment

        The primary focus of this framework is the management of
        Electrical Equipment.  Some Non-Electrical Equipment may be
        connected to communication networks and could have their
        energy managed if normalized to the electrical units for
        power and energy. Non-
        Electrical equipment that do not convert-to or present-as
        equivalent to Electrical Equipment is not addressed.
NEW
        Non-Electrical Equipment

        The primary focus of this framework is the management of
        Electrical Equipment.  Non-Electrical Equipment can be covered
        by the framework only if it provides interfaces that comply with
        the framework. For example, it must use the same units for power
        and energy.

+ JP : Again ignoring the value judgement as we meant the units we selected for electrical equipment (W not VA since that is different for real and apparent power). Changed to NEW


18. Section 4 "Energy Management Abstraction"
The first paragraph is identical with the first paragraph of Section 1 "Introduction" and can be removed.

+ JP : Deleted.

19. Section 4.1 "Conceptual Model"
I am missing here a lot of information on the model.
19.1. Is the model normative or informational?

! JP : question for the chair to indicate. @Nevil the entire draft is informational what should be listed here?

19.2. Is it a model to be implemented inside the EnMS only or as well on the Energy Objects?
19.3. If it is implemented at the Energy Objects, why storing context information? This typically resides in the management system only.

- JP : we've discussed this on numerous threads. On the device for reasons described. It may be set on the device to be included in the EnMS and vice versa.

19.4. If it is implemented on Energy Objects, how does it specify which information is included for a device, and which (more limited) information is included for a component or power interface?

- JP : It's not limited for a component see class Component.

19.5. The model is lacking information on batteries.

! JP : See Benoit reply

20. Section 4.1, 3rd paragraph, line 1: "Therefore"-->""

+ JP : done

21. Section 4.1, 4th paragraph, line 2: "a Device, a Component, and a Power Interface"
-->"a Device class, a Component class, and a Power Interface class"

+ JP : done

22. Section 4.1, 5th paragraph, line 2
OLD
        For modeling additional attributes, this section describes
        attributes of an Energy Object for: identification,
        classification, context, control, power and energy.
NEW
        This section describes attributes of an Energy Object for identification,
        classification, context, control, power and energy.

+ JP : done

23. Section 4.1, 6th paragraph.
The first sentence seems to be broken. The "interconnections for Network Management" are also used for Energy Management. Energy management needs at least some of them to communicate between the EnMS and devices.

! JP : "may have no relation" so that covers your concern I think.

24. Section 4.1, title
This section is titled "Conceptual Model". But as the last paragraph of it states, the conceptual model is actually not in this section, but in the following sections 4.2-4.6. The title should be changed after fixing 20.-23.

+ JP : changed to  "next sections"

25. Section 4.2, title
"Energy Object" --> "Energy Object Class"

+ JP : done

26. Section 4.2.1, 2nd paragraph, line 2: "may represent" --> "represents"

+ JP : done

27. Section 4.2.1, 2nd paragraph:
Is this list exclusive? Are there no other kinds of devices supported?

! JP : nothing to do here. If there are more categories of devices in this context (EM) feel free to suggest and we can discuss. These categories are based on years of deployments and we've found little to no overlap in indicating one primary category per device. Also it's been exhaustive for our deployments. We can surely add more but we've found it to be enough.

28. Section 4.2.1, 2nd paragraph:
A device may be both, a meter and a distributor. How is this modeled?

- JP : We discussed this with you already and this is described as the primary purpose. For the problem space on EM these categories rarely overlap and when they do the primary purpose always outweighs the others.
http://www.ietf.org/mail-archive/web/eman/current/msg02026.html

29. Section 4.2.1, 3rd paragraph:
OLD
        A Device Class instance may represent a physical device
        that contains other components.
NEW
        A Device Class instance may represent a physical device
        that contains other components.

- JP : Nothing to do here??

30. Section 4.3.1, 2nd sentence: "Ideally, the UUID is used to distinguish the Energy Object within the EnMS". Why ideally? What can be ideal for us info model designer does not necessarily have to be ideal for the EnMS developer.

+ JP : Since we have RFC4122 now, this is
"""
A Universal Unique Identifier (UUID) [RFC4122] is used to uniquely and persistently identify an Energy Object.
"""

31. Section 4.3.2. "Context in General"
What I am missing in this section

- JP : Can't read your mind ;)

32. Section 4.3.2, last paragraph:
I do not see the point made by this paragraph. How would context information help the EnMS in this case?

+ JP : I agree with that. I deleted
"""
For example, metered usage reported by a meter and consumption usage reported by a device connected to that meter may measure the same usage. With the two measurements identified by category and context an EnMS can make summarizations and inferences.
"""

33. Section 4.4, "Measurements", 2nd paragraph:
This is similar to item 17. There is no electrical or non-electrical Watt-hour.
OLD
        For the purposes of this framework, energy will be limited
        to electrical energy in watt-hours.  Other forms of Energy
        Objects that use or produce non-electrical energy may be
        modeled as an Energy Object but must provide information
        converted to and expressed in watt-hours.
NEW
        Within this framework, energy will only be quantified in units of
        in watt-hours. Energy Objects and Meters measuring Energy in
        other units must convert values to Watt-hours before reporting them.

+ JP : Done
"""
Within this framework, energy will only be quantified in units of in watt-hours. Energy Objects measuring Energy in other units must convert values to watt-hours.
"""

34. Section 4.4.1 "Measurements: Power", line 1:
"Each Energy Object contains a Nameplate Power attribute that describes the nominal power as specified by the manufacturer." I am not sure, you will always find someone reading all the nameplate power values and entering them to the device or the EnMS.
OLD
        Each Energy Object contains a Nameplate Power attribute
NEW
        Each Energy Object may contain a Nameplate Power attribute

35. Section 4.4.1 "Measurements: Power", 2nd paragraph, line 1:
OLD
        Each Energy Object will have information that describes the
NEW
        Each Energy Object may have information that describes the
OR NEW
        Each Energy Object has information that describes the

- JP : Left this out. I see your point for the device but this is describing the  class. The class in the information model contains the attribute. The device may not provide it but the attribute is defined in the class and does exist there.

35. Section 4.4.4, last sentence: "Demand measurements can be provided when the Energy Object is capable of measuring actual power."
This is wrong. Either delete this sentence (preferred) or use this one instead: "Demand measurements can only be provided when the Energy Object is capable of measuring demand."

- JP : Again we'd all like to be the harbinger of right and wrong but I'll comment on your opinion. What you have suggested is a tautology. We could say that for any attribute. However the point was, If a device is not capable of measuring power I'm not sure how it could measure demand (even energy) for that matter. So if the device is not capable of actual power measurements demand and energy would be non existent.

36. Section 4.5 "Control", first sentence: An Energy Object can be controlled by setting a Power State or a battery state.

! JP : Defer that. Can battery be listed as a power state series? see other thread.

37. Section 4.5 "Control"
Power States and Power State sets are introduced in Section "Control". That's wrong. Many devices will allow monitoring of power states only, particularly devices, that control power states by themselves or by manual users interaction only. The concept of power states should be explained outside of section 4, either in a subsection of section 3 or in a new separate section between current sections 3 and 4.

- JP : We had this exact conversion on authors call with you and decided that it could be introduced as control. Of course you can monitor states but they are more naturally introduced  and explained w.r.t control  @Benoit we had this discussion and IIRC you preferred to leave it as control section as well.  @All Reviewed last author call we thought it ok to introduce here.

38. section 4.5.1 "Power State Sets"
Why is the ACPI power state set excluded from the list of existing sets?
ACPI power states should have their own subsection as IEEE1621 and DMTF have.

! JP : We never listed the ACPI states as a series since DMTF is a super set and it would suffice. We could add it but it would have to cover the ranked P states (which you said can't be done BTW for the ordering and definition of lower states) If we get consensus that it's needed we can add it. IMO we have it covered by DMTF but I could see a reason to have them as a series.
http://www.ietf.org/mail-archive/web/eman/current/msg02027.html

39. Section 4.5.4. "Power State Set: IETF EMAN"
Shouldn't we call this rather "Power State Set: Cisco EnergyWise"?

- JP : See Benoit reply +1 on that.

40. Section 4.5.4, first sentence:
"An EMAN Power State Set represents an attempt at a standard approach for modeling the different levels of power of a device." The same holds for every other power state set, particularly for the ones mentioned in the subsections above. I suggest removing this sentence.

+ JP : See Benoit's reply. He meant for IETF. I removed it.

41. Section 4.5.4.
I am fine with the non-operational power states that also other ACPI and DMTF support similarly, but I have problems with the operational states (7-12). They are defined only relatively to each other stating that one with a lower number "provides less usage" than a higher number.
41.1: Is "providing usage" proper terminology?
41.2: What is meant with "provide less usage"? Does it mean that usage numbers are ALWAYS lower than in a higher state? Even if measured in short time intervals? Such a behavior would hardly be implementable on many devices.

+ JP : "...use less energy than ..."

41.3: In the real world, power states have ranges of power values that they cover and some have wider ranges than others. This can hardly be modeled by a power state set that only knows a strict consecutive order of power states and power values.

! JP : With ranges you can indicate the maximums of the ranges and order those so not sure of your point here.  The ACPI P states are defined identical to this. Asked and answered numerous times.

42. Section 4.6, 2nd paragraph, first sentence: "Relationships are modeled with a Relationship class that contains the UUID of the participants in the relationship ...":
"of  the participants" --> "of the other participant"

+ JP : Done

43. Section 5 "Energy Management Information Model"
The text states that this model is a "reference for implementers". Obviously, the model is useful for management system implementers. What is not discussed is how to use it for implementations of EMAN on devices, components and interfaces. The model does not give guidance for these. Among the missing information for these cases is what needs to be implemented on different classes of devices.

! JP : See Benoit reply this is part of applicability.

Cheers,
    Juergen

Thanks for the detailed review!!
Jp