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

[Bruce Nordman <[e-mail]>]

Review of draft-ietf-eman-framework-09
(I think little of this any different in -10)

The EMAN Framework draft is improving, as has been noted.  That said,
the comments below plus those in the review a few days ago from Juergen
Quittek indicate that the document still has far to go.  This list
is not comprehensive--that is not feasible with so much to address.
In addition, fixes that these comments lead to are likely to introduce
new issues or make clear existing ones that are not now readily apparent.
As this document has changed considerably over the past three+ years,
new issues continue to crop up.


Conceptual issues:

The mechanisms described for importance and role are non-standard and
arbitrary.  We might do well to have standard mechanisms for some
of these, but creating an anecdotal set solely in the context of EMAN
seems unlikely to contribute to that.  Until such time as there is some
basis for incorporating specific content, these should be left as
free-form keywords encoded in some standard syntax.

The "relationship" concept is not necessary.  Simpler methods can express
what is required.  It makes the document harder to understand, and so
is a barrier to it being widely adopted.

It is stated that a device should be labeled as "a consumer, producer,
or meter, distributor, or store of energy".  It isn't explained what the
value of making this distinction is.

The concept of "caliber"is not needed; accuracy is sufficient.

The draft states that a device must have at least two states: one
on state and one off state.  There are devices for sale that have
two states, on and sleep (but no off) and devices with only one
state.  Why have this restriction?  and why require a device to
report power states at all?  most will certainly but some might
appropriately not do so.

The explanation of power state semantics in 4.5 is not consistent
with general usage of the concept of power state.  Power limitation
may be useful, but it is a different concept from power state and
should not be conflated.

4.5.4. These are arbitrary.  It would be better to specify registration
of the Cisco power state set since that is presumably already in use.

4.6. Power Source Relationship and Metering Relationship are redundant.
As the text points out, both are about wiring topologies.

4.6.3. The second and last paragraphs seem to be contradictory as
to whether two non-connected PIs can have a Power Source Relationship.

4.6.3. It is not clear how metering is to be applied.

4.6.4. It is stated that "Establishing aggregation relationships within
the same device would make modeling more complex…".  The ER Framework
accomplishes this without any complexity burden, so the statement in
general is not true.  It may be true of the EMAN Framework but that is
simply a flaw in the document.

4.6.5. The text leaves "proxy" relationships for future development,
but there are requirements (8.1) for proxy control that the framework
seems to not cover.

6. It is stated that some products cannot support power interfaces.
Any device can and could simply report "unknown" for data they do not know.

6.1. The draft indicates that power interfaces can be between devices and
components.  This adds a lot of complexity to the PI concept.  It would
be much simpler to not allow PIs between components.  For those niche
applications that desire that, the component in question could be modeled
as a distinct device.  Thus, complexity of EMAN could be reduced without
sacrificing capability.

Aggregation:

4.6. It is completely unclear how the Aggregation Relationship mentioned
is supposed to operate.

4.6.4.  It is suggested that a device can report only a single aggregation.
Is that true?

6.3. explains what aggregation is, but not how it actually works.
The two sentences in the middle paragraph contradict each other.

Corrections:

The introductions states that "The framework introduces the concept of
a power interface".  This is not true.  The power interface concept
was introduced in draft-quittek-eman-reference-model-02, over two
years ago.  Also, the definition provided for Power Interface doesn't
make sense, and does not correspond to the concept described in the
Reference Model, or the ER Framework.  The latter has a clear explanation,
the first sentence of which could be a definition.

The bulleted text under 4.5.2 on IEEE 1621 is wrong.  I have pointed
this out many many times without it being fixed.  Also, for 4.5.5,
IEEE 1621 does NOT say that hibernate is a form of sleep; it says that
hibernate should be presented as a form of off.  This error has also
been pointed out many times.

Details:

2. Definition of "Meter".  Change "intended to measure" to "that measures".
In general, what is the difference intended when "are intended to" is
used as opposed to what the referenced concepts actually do?

Unnecessary text:

The document is burdened throughout by text that is unnecessary to
accomplish what is needed.  This makes reading it more difficult and
so would impede use of the standard.  An example is defining and
discussing Non-Electrical Equipment.  This is more appropriate to
an application/implementation discussion document, not a framework.
Other examples include the list of target devices in Section 3.1, all
of Section 3.4, sections 4.3.3, 4.3.4, 4.3.5, the second half of 4.3.6,
and the middle two paragraphs of 4.4.

The requirements RFC says:
5.5.1.  Energy Measurement
   The standard must provide means for reporting measured values of
   energy and the direction of the energy flow received or provided by
   an entity.  The standard must also provide the means to report the
   energy passing through each Power Interface.
The Framework says:
    4.4.3. Measurements: Energy
        Optionally, an Energy Object that can report actual power
        readings will have energy attributes that provide the
        energy used, produced, or stored in kWh.
Aside from noting that kWh are to be used, what is the point of saying
this at all?  and if this is about reporting energy, why does the text
talk about power?



On Fri, Sep 27, 2013 at 9:56 PM, Juergen Quittek <[e-mail]> wrote:

> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Nevil Brownlee
> > Sent: Dienstag, 10. September 2013 23:28
> > To: [e-mail]
> > Cc: [e-mail]
> > 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: [phone] x88941             The University of Auckland
> >   FAX: [phone]   Private Bag 92019, Auckland 1142, New Zealand
> > _______________________________________________
> > eman mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/eman
> _______________________________________________
> eman mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/eman
>



-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
*nordman.lbl.gov*
[e-mail]
510-486-7089
m: 510-501-7943