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

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Wed, 27 Jul 2011 00:13:07 -0500

Provided below.  I will forward a copy of my annotated PDF file to the authors.  The PDF version also includes some minor corrections/suggestions which are not reproduced below.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [email-masked]
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

----------------------------------------------------------------
Comments on draft-ietf-eman-framework-02
----------------------------------------------------------------

General Comments:

1. Some portions of this document call out communications networks as a subset of the larger energy management problem space.  It is not clear to me why we are doing so.  Perhaps we should be writing from a less communications network developer frame of mind?

2. What is the intended relationship between this document and the Reference Model that Juergen and Bruce have been developing?  Does their's replace this?  Augment it somehow?  What?  They seem to be covering similar ground unless there is a nuance I am missing.

Deatiled Comments:

> - IPFIX or not? (Page 3)

I am OK with IPFIX being identified as an appropriate choice for PUSH mode time series data.  I would prefer not to preclude other options for that as well, but I have none to offer at this time.  I feel that the standard cannot mandate that compliant implementations include the use of IPFIX so any mention of it must be considered optional, IMHO.  It's use in diagrams as an example it likewise fine as long as this is made clear.

> EDITOR'S NOTE: [EMAN-MON-MIB] and [EMAN-AS] are not EMAN working
> group documents. Hence, these references will be changed in the
> future. (Page 5)

I am confused by this statement.  What are the implications here?  Will these eventually become WG documents even though they are not officially so now, or does it mean that their contents will be merged into something else that IS a WG document?

> For an Energy Management framework to be useful, it should also
> apply to these types of separate networks as they connect and
> interact with a communications network. (Page 6)

I understand the point being made here but I believe the presentation can be simplified by simply declaring that there are two separate networks: the power distribution network which is responsible for the supply of electrical energy to various devices and their components, and the control network which is used to to monitor and control the flow of energy throughout the power distribution network.

In network management systems we frequently talk about there being a "Data Plane" and a "Control Plan".  This is a similar concept to what we have as well.

> 3. Terminology (Page 6)

There seems to be an effort underway to standardize on some of this terminology.  I assume that this section will be updated to be consistent with the outcome of that effort.

> An Energy Managed Object (EMO) is a device that is part of or
> attached to a communications network that is monitored,
> controlled, or aids in the management of another device for
> Energy Management. (Page 8)

We seem to be focusing on the communications connectivity here rather than the fact that and EMO is a powered device (i.e. connected to a Power Distribution Network) whose energy consumption can be monitored and controlled via a communications network (Control Network).

> Energy Managed Object Parent (Page 10)

As they are currently defined EMO Parent and EMO Child represent a type of proxy relationship.  What is the difference between being a proxy for an EMO and being an EMO Parent?  This distinction needs to be clarified somehow. 

> An Energy Managed Object Parent is an Energy Managed Object that
> provides one or more of the Energy Managed Object Relationships
> capabilities.  (Page 11)

I find this notion of "providing a capability" confusing.  What does it mean for one EMO to "provide" a "capability" to (for?) another EMO.  I don't understand the intended meaning here.

> The framework addresses Energy Management but excludes Energy
> Procurement and the environmental impact of energy use. As such
> the framework does not include: (Page 14)

The energy management systems can be reasonably be envisioned to become the central point for corporate reporting for both cost and environmental impact especially where compliance to regulations is concerned. We should have a plan for how these dimensions will be accommodated.  At a minimum the EMO should optionally allow for the setting and retention of an applicable set of attributes which can then be read by other EnMS applications.

> An Energy Managed Object Child may inherit the domain value from an Energy
> Managed Object Parent (Page 15)

I think that sub-domains need to be better thought out or clarified here.  If an EMO is part of a subdomain it is not also part of the encompassing domain as well?  This means that each EMO may actually be part of multiple Energy Domains.  This seems to assume that the EMO is only part of a single domain which will be determined by its closest meter in the power distribution tree.  It is not yet clear to me that this is the only and/or the correct way to look at it.

> Energy Managed Objects establish a parent and child relationship
> when one Energy Managed Object provides capabilities for another
> Energy Managed Object. (Page 18)

The notion of "capability" here seems ill defined, or at least not intuitively obvious to me.  The relationships (capabilities?) mentioned thus far are: Aggregation, Metering, Power Source, Proxy and Dependency.  I do not think of Aggregation, Proxy, or Dependency as being "capabilities" which are provided.  I think we need to find a better way of describing what it intended.

> Energy Managed Objects may have Manufacturer Power States Sets
> and can map these to the EMAN Power State Sets. (Page 26)

Given the introduction of IANA registered power state series I think that this manufacturer power state sets discussion can be removed as it appears to be no longer necessary or applicable.  Agreed?

> powerMonitorId | UUID (Page 29)

Needs to be adjusted given the changes in terminology section(s) ... e.g. we have done away with the term Power Monitor.

> | manufacturerLevels[0..n]: State |
> | emanLevels[0..11] : State | (Page 33)

These require some adjustment given the adoption of power state series.

> When an Energy Managed Object requires a mapping with the
> Manufacturer Power State, the Energy Managed Object
> configuration is done via the Power State settings, and not
> directly via the Manufacturer Power States, which are read-only.
> Taking into account Figure 7, where the LowMinus Power State
> corresponds to three different Manufacturer Power States (11 for
> 1%, 12 for 2%, and 13 for 3%), the implication is that this
> framework will not set the Manufacturer Power State to one
> percent granularity without communicating over or configuring
> the proprietary protocol for this Energy Managed Object. (Page 34)

I think that this section can be removed given the introduction of the IANA registered Power State Series.  I believe that this is no longer relevant.

> Note that the Wake-up-on-Lan (WoL)
> mechanism allows to transition a device out of the Off Power
> State. (Page 34)

Seems out of place somehow.  It seem logically unconnected with the rest of the paragraph.

> 8. Fault Management (Page 34)

I am not clear on what this section is trying to convey.  Additional clarification is required.

---

From: "John Parello (jparello)" <[email-masked]>
Date: Wed, 27 Jul 2011 14:09:17 -0700

Hi Bill,

Thanks so much. I'll try to address the issues as much as possible in
the session. Please see in line

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mielke, William F (Bill)
Sent: Tuesday, July 26, 2011 10:13 PM
To: eman mailing list
Subject: [eman] Comments on draft-ietf-eman-framework-02

Provided below.  I will forward a copy of my annotated PDF file to the
authors.  The PDF version also includes some minor
corrections/suggestions which are not reproduced below.

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

General Comments:

1. Some portions of this document call out communications networks as a
subset of the larger energy management problem space.  It is not clear
to me why we are doing so.  Perhaps we should be writing from a less
communications network developer frame of mind?

[jp] yes I'll reword

2. What is the intended relationship between this document and the
Reference Model that Juergen and Bruce have been developing?  Does
their's replace this?  Augment it somehow?  What?  They seem to be
covering similar ground unless there is a nuance I am missing.

[jp] I'm confused by that myself. I try to make sure the framework can
cover all kinds of topologies so the one in the ref draft is clearly one
to cover.

> - IPFIX or not? (Page 3)

I am OK with IPFIX being identified as an appropriate choice for PUSH
mode time series data.  I would prefer not to preclude other options for
that as well, but I have none to offer at this time.  I feel that the
standard cannot mandate that compliant implementations include the use
of IPFIX so any mention of it must be considered optional, IMHO.  It's
use in diagrams as an example it likewise fine as long as this is made
clear.

[jp] agree we'll clarify 

> group documents. Hence, these references will be changed in the

I am confused by this statement.  What are the implications here?  Will
these eventually become WG documents even though they are not officially
so now, or does it mean that their contents will be merged into
something else that IS a WG document?

[jp] They are not official wg documents yet but are the only ones
proposed so far as per the charter.

> interact with a communications network. (Page 6)

I understand the point being made here but I believe the presentation
can be simplified by simply declaring that there are two separate
networks: the power distribution network which is responsible for the
supply of electrical energy to various devices and their components, and
the control network which is used to to monitor and control the flow of
energy throughout the power distribution network.

In network management systems we frequently talk about there being a
"Data Plane" and a "Control Plan".  This is a similar concept to what we
have as well.

[jp] very good point I'll reword along these lines

> 3. Terminology (Page 6)

There seems to be an effort underway to standardize on some of this
terminology.  I assume that this section will be updated to be
consistent with the outcome of that effort.

> Energy Management. (Page 8)

We seem to be focusing on the communications connectivity here rather
than the fact that and EMO is a powered device (i.e. connected to a
Power Distribution Network) whose energy consumption can be monitored
and controlled via a communications network (Control Network).

[jp]  yes also note though there can be multiple control networks.
Ethernet/ip and then serial/bacnet for example.

> Energy Managed Object Parent (Page 10)

As they are currently defined EMO Parent and EMO Child represent a type
of proxy relationship.  What is the difference between being a proxy for
an EMO and being an EMO Parent?  This distinction needs to be clarified
somehow. 

[jp] OK I see your point I'll add clarification

> provides one or more of the Energy Managed Object Relationships

I find this notion of "providing a capability" confusing.  What does it
mean for one EMO to "provide" a "capability" to (for?) another EMO.  I
don't understand the intended meaning here.

[jp] I meant to say is participating in a relationship. I'll present
that to clarify 

> the framework does not include: (Page 14)

The energy management systems can be reasonably be envisioned to become
the central point for corporate reporting for both cost and
environmental impact especially where compliance to regulations is
concerned. We should have a plan for how these dimensions will be
accommodated.  At a minimum the EMO should optionally allow for the
setting and retention of an applicable set of attributes which can then
be read by other EnMS applications.

[jp] Ok do you want an arbitrary set of information or some formatted
ones? What types of data do you envision.

> Managed Object Parent (Page 15)

I think that sub-domains need to be better thought out or clarified
here.  If an EMO is part of a subdomain it is not also part of the
encompassing domain as well?  This means that each EMO may actually be
part of multiple Energy Domains.  This seems to assume that the EMO is
only part of a single domain which will be determined by its closest
meter in the power distribution tree.  It is not yet clear to me that
this is the only and/or the correct way to look at it.

[jp] True it is simpler to map to one metered domain which is what I
implemented already. I've had people ask for multiple domains but when I
explain the complexity we've have no one push further. So the domain is
like a l2 broadcast domain on size and restriction not communication.

> Energy Managed Object. (Page 18)

The notion of "capability" here seems ill defined, or at least not
intuitively obvious to me.  The relationships (capabilities?) mentioned
thus far are: Aggregation, Metering, Power Source, Proxy and Dependency.
I do not think of Aggregation, Proxy, or Dependency as being
"capabilities" which are provided.  I think we need to find a better way
of describing what it intended.

[jp] Yes relationship is better.

> and can map these to the EMAN Power State Sets. (Page 26)

Given the introduction of IANA registered power state series I think
that this manufacturer power state sets discussion can be removed as it
appears to be no longer necessary or applicable.  Agreed?

[jp] I thought to leave it in to show how someone could use the existing
registered sets and not have to define a new one. I thought to remove it
as well but I thought someone might think they need to create a set for
every device and manufacturer. 

> powerMonitorId | UUID (Page 29)

Needs to be adjusted given the changes in terminology section(s) ...
e.g. we have done away with the term Power Monitor.

[jp] yes thanks I'll remove.

> the proprietary protocol for this Energy Managed Object. (Page 34)

I think that this section can be removed given the introduction of the
IANA registered Power State Series.  I believe that this is no longer
relevant.

[jp] ok

> mechanism allows to transition a device out of the Off Power

Seems out of place somehow.  It seem logically unconnected with the rest
of the paragraph.

[jp] Yes I'll move. IIRC we were trying to call out WoL type protocols
since they inevitably come up when we discuss states. 

> 8. Fault Management (Page 34)

I am not clear on what this section is trying to convey.  Additional
clarification is required.

[jp] I'll remove we have things addresses now in the requirements so
this was left over before we had that draft.
_______________________________________________
eman mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eman