Subject: [eman] Comments on draft-ietf-eman-framework-03

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Tue, 15 Nov 2011 03:38:56 -0600

See below.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
224 Brookhill Drive
Gahanna, OH  43230
Email: [email-masked]
Phone: 614 718 6308

----------------------------------------
Comments on draft-ietf-eman-framework-03
----------------------------------------

I will provide an annotated PDF file to the authors which should be easier to follow than the textual description below.  The PDF version also highlights some minor typos and simple wording changes which may not appear below.  In the comments below the convention I used was to quote a relevent section of text to indicate where I was commenting on, and then to simply provide the comment.  The comments are broken down by sections, as indicated.

To Do List:
-----------

"Comment from Prantl on the list, related to energy control: non-discrete power-states are not supported -> Section 5.5.":

This is yet another example to illustrate that a simple enumeration of power states is likely to be brittle and insufficient.  While there is certainly a need to support an enumerated style of defining power states we really need to consider how to support a wider range of options.  Percentage style and cap style would seem to be two such alternatives.

I had not considered a power capping capability wherein the EnMS simply indicates that the Energy Object should self-monitor and insure that it stays within it's allocation.  It is an interesting concept and worth considering.

Section 4:
----------

"Therefore, IPFIX [RFC5101] is also mentioned as the appropriate solution in the following figures, even if there are no documents describing the IPFIX solution at the time of writing these lines. Note that this framework doesn't exclude another solution than IPFIX.":

The following diagrams mention IPFIX [RFC5101] as one possible solution for implementing a push mode transfer, however this is for illustration purposes only.  The EMAN standard does not require the use of IPFIX and acknowledges that other alternative solutions may also be acceptable.

Section 5:
----------

"Relationship or capabilities of an Energy Object to an electrical or smart grid":

This seems to actually be in scope. If not then where is the line drawn between in scope and out of scope within the power distribution tree?

"Supply chain analysis of energy sources or Energy Object deployment":

Same issue. Where does the EMAN power distribution tree model end and the supply chain distribution tree begin?  If these topics are not in scope for EMAN the where?

"Conversion of the usage or production of energy to units expressed from the source of that energy (such as the greenhouse gas emissions associated with 1000kW from a diesel source).":

The information required to implement the tracking, analysis, and aggregation of these  values is tightly aligned with the EMAN energy objects and the power relationship.

If EMAN does not address these concepts in some form we should consider how the EMAN standards could be easily extended to efficiently facilitate their support.

I agree that these values can be considered lower priority than the currently defined scope, but they seem to be in the long range scope for this working group to address.

"An Energy Object is part of a single Energy Management Domain.  The Energy Management Domain should be configured on an Energy Object.":

I don't think that this is a valid assumption. How do we address the case of an energy object which has redundant and diverse power sources for reliability, or an energy object which has access to alternative power sources with the ability to dynamically switch between them to optimize cost and/or carbon footprint impacts. Are these not examples of different metering domains?

Section 5.2.1:
--------------

"universal identifier (UUID)" -> "universally unique identifier (UUID)"

"Every Energy Object should have a unique printable name.":

Unique in what scope?

Section 5.2.4:
--------------

"characters and symbols, such as" -> "characters and symbols (other than a comma), such as"

"In such cases, the keywords are separated by commas and no spaces between keywords are allowed.":

If this is the case then can keywords themselves contain spaces?  If not this should be made explicit.

"Another keyword use case is the virtual grouping of Energy Objects.":

Are we overloading the use of keywords here?  If the field is used for this purpose does that preclude it's use for its original purpose?  Are these uses actually in conflict?

Section 5.4:
------------

"Other forms of Energy Objects that use or produce non-electrical energy may be part of an Energy Management Domain":

This is too abstract and requires some concrete example to clarify the meaning.  I say this because I admit that I am at a loss to think of such an example.

"Each Energy Object will have information that describes Power information along with how that measurement was obtained or derived. For Energy Objects that can report actual Power readings an optional Energy measurement can be provided."

I don't understand what this is trying to say.  Please clarify.

"along a description of accuracy" -> "along with a description of accuracy"

Section 5.4.1:
--------------

"BaseValue * 10 raised to the power of the scale" -> ""

The wording doesn't convey the proper precedence.  Use BaseValue * (10 ^ ScaleFactor) instead.

"depending on the value of the scaling factor":

Provide an example or two.  For example, 3W implies BaseValue = 3 and ScaleFactor = 0, whereas 3mW implies BaseValue = 3 and ScaleFactor = -3.

Section 5.4.2:
--------------

"used as a measurement" -> "part of the calculation"

Section 5.5.3:
--------------

"IEEE1621 Power(off):":

The following presentation is confusing and either requires rework or an explanation of what is going on.  The appearance of IEEE1621 states intermixed with EMAN states using different indenting makes this non-obvious and difficult to follow, IMHO.  I think I understand the intent but it took me a while to figure it out.

Section 6:
----------

"UML Diagram":

This go around I took the opportunity to look more closely at the UML diagram and it is not clear to me what UML relationships are being specified here in the ASCIIfied UML diagram.  Please provide a legend to make your conventions for mapping to UML clear.

"parentProxyAbilities":

We need to identify the specific abilities to be supported in this bitmap and how the bitmap is used.

"meterDomainName | string":

We need to discuss the assumption of one meter domain more.  It is not clear to me that a single domain name is sufficient.

General Comment on the UML diagram:

I think we need to conduct a thorough sanity check of these diagrams to make certain that we have meaningful types and names being used.  I won't have time to do that before the meeting tomorrow but I may be able to get to it later this week before I head home on Saturday.  How prescriptive and accurate is this diagram intended to be? I assume it is intended to be very closely aligned with the MIB specifications, correct?  I haven't done a cross check myself at this point so I can't say whether it is currently well aligned, or not.  I am trying to get a a more detailed feel for it's current content and intent.
 
Section 7:
----------

"Energy Object Power State: Specifies the current Power State (0..12) for the Energy Object.":

This is actually one of the values from the IANA power state registry, correct?  So what is this "(0..12)" for?  Leftover from previous version?

Section 8:
----------

"Such requirements are fulfilled via the pmPowerStateChange NOTIFICATION-TYPE [EMAN-MON-MIB].":

I assume that "notification" means the same as "trap" in this context.  If not please let me know.

Is an SNMP notification sufficient given that it is only a best effort mechanism?  Do we provide sufficient mechanisms that an EnMS can detect a lost notification to avoid losing important errors and/or data values?

"Regarding high and low thresholding mechanism, the RMON alarm and event [RFC2819] allows to periodically takes statistical samples from Energy Object variables, compares them to previously configured thresholds, and to generate an event (i.e. an SNMP notification) if the monitored variable crosses a
threshold."

Ditto the concerns over notifications being best effort.

Open Issues Identified:
-----------------------

(1) How many energy management domains can an energy object be associated with?  Is one really sufficient?