Subject: Re: [eman] WG Last Call for EMAN Framework -09

From: Juergen Quittek <[email-masked]>
Date: Sat, 28 Sep 2013 04:56:43 +0000

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.

Seeing the list off issues I found, I believe that there is still a long way to go to get this draft into reasonable shape.

I tried to make constructive comments by suggesting text replacements to solve some of the issues that I describe below, but some comments need more work, such as 15. (missing reference model definition), 16. (confused list of concerns), etc.
	
I have not yet fully checked the examples in Section 6, since I expect that this would better be done after some of the issues in Sections 1-5 have been settled.

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.

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

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.

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.  

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.

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

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
}

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'.

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."

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."

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

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.

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.

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

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

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:" 

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

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.  

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. 

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.

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.

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.

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. 

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

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?
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. 
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?
19.5. The model is lacking information on batteries.

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

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"

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.

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.

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.

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

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

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

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

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.

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.

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

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?

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.

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

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." 

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

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.

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.
 
39. Section 4.5.4. "Power State Set: IETF EMAN"
Shouldn't we call this rather "Power State Set: Cisco EnergyWise"? 

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.

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

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"

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.

Cheers,
    Juergen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Nevil Brownlee
> Sent: Dienstag, 10. September 2013 23:28
> To: [email-masked]
> Cc: [email-masked]
> Subject: [eman] WG Last Call for EMAN Framework -09
> 
> 
> Hi all:
> 
> A new revision of the EMAN Framework draft was published yesterday.
> Version -09 has many changes, improvements and clarifications since the -08
> version (published just before IETF-87 in Berlin).
> 
> The WG Last Call for it starts now, and will end on Friday, 27 September.
> 
> Please read it now, and send your comments/suggestions/etc to the EMAN list.
> Comments like "seems fine now" are good, as are suggestions for further
> improvement (accompanied by OLD/NEW text).
> 
> Cheers, Nevil
> 
> --
> ---------------------------------------------------------------------
>   Nevil Brownlee                          Computer Science Department
>   Phone: +64 9 373 7599 x88941             The University of Auckland
>   FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman