Subject: [eman] Comments on draft-ietf-eman-requirements-01

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Tue, 29 Mar 2011 02:59:49 -0500

Below please find my comments on draft-ietf-eman-requirements-01.  I also have some minor textual formatting or rewording comments which I will provide to Benoit directly in a separate email.

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-requirements-01
-------------------------------------------

Section 1:

We should clarify what we mean by "building networks" and "home networks".  For example, do these networks explicitly include or exclude things like environmental management systems for heating, air conditioning, lighting control, etc?

Sections 2.4, 2.5, and 2.6:

It occurs to me that sections 2.4, 2.5, and 2.6 are all simply different examples of the same "energy proxying scenario".  If we want to call these out as separate and distinct cases perhaps the sections should be updated to illustrate why they are unique from one another (i.e. for reasons other than simply the domain to which the proxying has been applied).

Section 2.8:

I am not certain on how best to address this point but I believe that the current thinking relative to batteries may be too narrow in scope.  For example, telephone switching offices often employ huge banks of batteries which are used to power the entire office when the grid is unavailable.  Another example is many alternative energy sources also employ batteries as a fundamental storage facility where accumulated energy can be saved until needs to be supplied to its connected devices.

Both of these examples extend batteries beyond the simple concept of an on-board battery embedded within a simple device.  Is this a separate scenario (e.g. for "energy storage devices") or an example of how the thinking on the battery scenario may need to be broadened?

Section 3.4.4

The current text states "These devices can consume energy when turned off or to sleep mode, because in these modes they still can charge their batteries."

>From an energy consumtion point of view this is not technically correct.  Energy which is used to recharge a battery is not technically consumed (i.e. used up) but is rather merely transferred and stored for later use.  The stored energy is only consumed when the device is actually discharging the battery.  So, the proper way to account for the energy use of a device is:

Energy(Consumed) = Energy(TransferedFromMains) - Energy(RemainingInBattery)

Thus, when the device is technically "off" but charging the amount of energy actually consumed by the device remains unchanged, and when the main power is off and the device is draining the battery only then is the energy stored in the battery actually consumed (and is reflected in the decreasing value of Energy(RemainingInBattery).

So I think that we need to be careful in how we define "energy consumption".

Section 4:

The text states: "However, the overhead of pull model monitoring is typically higher than for push model monitoring, particularly when large numbers of values are to be collected, such as time series of power values."

I would like to better understand why you are asserting this to be true.  The inherent efficiency of a transfer is not a function of which side initiates the transfer (i.e. push or pull).  So you must be thinking of something else or I am misunderstanding the point.

Perhaps you are equating "pull mode" with "polling" vs. "push mode" with "event driven".  To me these are not equivalent statements so perhaps that is the source of my concern and/or perhaps I am merely splitting hairs too finely on this distinction.

Consider an example where readings are pushed 1 per minunte vs. pulled 5 at a time every 5 minutes:

Time -->
+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+
| 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 |
+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+
     |    |    |    |    |    |    |    |    |    |    |    |    |    |    |
     V    V    V    V    V    V    V    V    V    V    V    V    V    V    V
   PU01 PU02 PU03 PU04 PU05 PU06 PU07 PU08 PU09 PU10 PU11 PU12 PU13 PU14 PU15
                         |                        |                        |
                         V                        V                        V
                       PL01                     PL06                     PL11
                       PL02                     PL07                     PL12
                       PL03                     PL08                     PL13
                       PL04                     PL09                     PL14
                       PL05                     PL10                     PL15

Where PUnn is a push mode transfer and PLnn is a pull mode transfer.  Whether I push the values 1 at a time or pull them 5 at a time I still transfer the same number of values.  So it is unclear to me why you are saying that the push mode approach is inherently more efficient than the pull mode approach.

In fact, depending on the transfer protocol being used and the size of the packets involved I could actually argue that the pull mode approach is more efficient because it will (or at least it could) involve less network overhead per reading/unit transfered.

The text states "The only exceptions are notifications on power state changes and high volume time series of energy consumption values."

Until I better understand why you believe this is true I respectfully disagree that this is a fundamental implication/conclusion.

So there is some confusion which may need to be cleared up here and I understand that the confusion may be on my part.  Either way some additional clarification may be needed in the document to justify the main conclusions stated there.

Section 7.1.2:

The text states "For associating the provided information to specific components of a device, the ENTITY STATE MIB module makes use of the means provided by the ENTITY MIB module [RFC4133]. Particularly, it uses the entPhysicalIndex for identifying entities.".

This is interesting information which seems to be trying to make a specific point however the point itself has not been articulated and so it lost.  Add something to explain the implications of these points.

This section seems to be articulating that the existing ENITITY STATE MIB facilities are insufficient for our larger purpose.  This naturally implies that something additional needs to be defined but it is unclear from the existing text whether extending these existing facilities or defining new ones is the best approach.  Perhaps that decision is left to later documents?