Subject: [eman] Updates to terminology from discussion

From: "John Parello (jparello)" <[email-masked]>
Date: Fri, 9 Mar 2012 19:06:13 -0800

Hi All,

I have collected the following from the list based on feedback and
discussions. I'm adding these as in a revision 5 to the draft:

I) Additions:
------------------------------------------------------
>From the list the consensus seemed to be....
"""
Provide Energy:
An Energy Object "provides" energy to another Energy Object if there is
an energy flow from this Energy Object to the other one.

Reference: herein

Receive Energy:
An Energy Object "receives" energy from another Energy Object if there
is an energy flow from the other Energy Object to this one.

Reference: herein 
"""

II) Relationship edits:
------------------------------------------------------- 
I revised the relationships to denote the cardinality and reworded the
general relationship definition with reference. The following is the
text for the relationship itself with the types all following the same
pattern as aggregation. See the draft for each - I supplied aggregation
only to keep the email shorter.

"""
Energy Object Relationship
An Energy Object Relationship is a functional association among Energy
Objects

NOTES
1.	Relationships can be named and could include Aggregation,
Metering, Power Source, Proxy and Dependency. 

2.	The Energy Object is the noun or entity in the relationship with
the relationship described as the verb.

Example: If EO x is a piece of Electrical Equipment and EO y is an
electrical meter clamped onto x's power cord, then x and y have a
Metering Relationship. It follows that y meters x and that x is metered
by y.

Reference: Adapted from [CHEN]

Aggregation Relationship
An Aggregation Relationship is an Energy Object Relationship where one
Energy Object aggregates the Energy Management information of one or
more other Energy Objects. 
These Energy Objects are referred to as having an Aggregation
Relationship.  

Reference: herein
"""

III) Minor edit:
---------------------------------------------------------
EnMS "... a network with the primary purpose being" MODIFIED

Jp

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 12 Mar 2012 08:14:28 +0000

Hi John,

Thanks for taking care of our terminology.

When you update the relationships,
Please consider the following.

There are two kinds of relationships, that we do not distinguish
sufficiently, so far:
  - relationships between a hardware child and a hardware parent
    This includes the poweredBy and the meteredBy relationship
  - relationships between a hardware child and a software parent
    This includes the aggregatedBy and the proxiedBy relationship

The big difference between these two relationships is that in the
first case, the hardware parent always is an Energy Object as you
defined it.  The relationship is on providing power and on metering
power.  Both needs hardware and is located at a fixed point in the
power distribution tree.

In the second case, the parent part is just a piece of software.
This can be located at a concrete box, but it can also be a service
running somewhere in the cloud.  Take, for example home network
energy management.  Energy readings from EOs are often aggregated
or proxied by the home gateway.  And the home gateway is - like the
settop box - currently a job that has the trend to become
virtualized and moved to the cloud without any concrete location
and without a concrete association with a hardware box as the
current set of definitions assume.

It would be very good to have a clear distinction between the two
Types of relationships.

Thanks,
    Juergen

On 10.03.12 04:06, "John Parello (jparello)" <[email-masked]> wrote:

>_______________________________________________
>eman mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/eman

---

From: "John Parello (jparello)" <[email-masked]>
Date: Mon, 12 Mar 2012 12:13:16 -0700

Hi Juergen,

Thanks

 That is a good distinction perhaps in the example. I'm not sure about
defining the relationship as hardware or software etc. That's an
implementation choice.

Surely aggregation could be hardware for example.

So I propose some summary of your text below in the example or note of
the definition. As I've released 05 revision I can put that I the next
revision.

Jp

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Monday, March 12, 2012 1:14 AM
To: John Parello (jparello); eman mailing list
Subject: Re: [eman] Updates to terminology from discussion

Hi John,

The big difference between these two relationships is that in the first
case, the hardware parent always is an Energy Object as you defined it.
The relationship is on providing power and on metering power.  Both
needs hardware and is located at a fixed point in the power distribution
tree.

In the second case, the parent part is just a piece of software.
This can be located at a concrete box, but it can also be a service
running somewhere in the cloud.  Take, for example home network energy
management.  Energy readings from EOs are often aggregated or proxied by
the home gateway.  And the home gateway is - like the settop box -
currently a job that has the trend to become virtualized and moved to
the cloud without any concrete location and without a concrete
association with a hardware box as the current set of definitions
assume.

It would be very good to have a clear distinction between the two Types
of relationships.

Thanks,
    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Mon, 12 Mar 2012 22:21:59 +0100

Dear all,
> the definition. As I've released 05 revision I can put that I the next
See http://tools.ietf.org/html/draft-parello-eman-definitions-05

Regards, Benoit.
> On 10.03.12 04:06, "John Parello (jparello)"<[email-masked]>  wrote:
>
>> Hi All,
>>

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 13 Mar 2012 00:21:58 +0000

John,

Yes, you are right.  I was not phrasing it well.

Aggregation and proxy do not have to be software functions.
Of course, they can be implemented in hardware.

Still there remains the difference to metering and powering.
These are hardware functions that cannot be moved somewhere
To the cloud.

Thanks,
    Juergen