Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Fri, 1 Jul 2011 06:08:18 -0500

Hello,

As Juergen has mentioned, while the first version has been released to
solicit feedback, some of the concepts are still debated.
The perspectives from the email list would be useful to shape the draft.

I shall post some of the discussion points. 

Thanks
Mouli

------------

There is a requirement -
http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt

5.1.1.  Type of powered entity

   The energy management standard must provide means to retrieve and
   report the type of powered entities.

I think it would be useful to expand this requirement. Device Type could
be inferred as "IP Phone" or "Line Card 3", ...

One possibility is to consider is a description of the device and then
the type of device. 

Powered Devices Description

   The energy management standard must provide means for identifying the
   entity with a powered device description, the domain to which the
   device belongs.

Powered Entity Type

   The energy management standard must provide means to identify the
   powered device type such as consumer, provider, meter.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Quittek
Sent: Thursday, June 30, 2011 2:56 PM
To: eman mailing list
Subject: Re: [eman] New draft on eman requirements

Dear all,

I am sorry for posting another version just one day after the previous
one.
Now out is version -03 to be found at
 
http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt

The reason was that a change in terminology ("powered device" ->
"powered
entity") was not done consistently in all sections, particularly not in
the
battery section.

There are no further changes, particularly no technical changes compared
to
the previous version.

Thanks,

    Juergen

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Fri, 1 Jul 2011 06:18:07 -0500

Hello,

There is a requirement -

on identity 

4.1.  Identifying powered entities

   The energy management standard must provide means for uniquely
   identifying powered entities that are monitored or controlled by an
   energy management system.  Uniqueness must be given in a domain that
   is large enough to avoid collisions of identities at potential
   receivers of monitored information.

Firstly, it would be useful to link this unique ID to other indices that
may be deployed - in other words, link to other MIB modules. 

Powered Entities Other Identifier

   The energy management standard must provide means to link the powered
   device unique id to existing other identifiers currently used in
   network management.

Secondly, it would be useful to specify if the identity should
persistent. 

Thanks
Mouli

-----Original Message-----

Dear all,

Thanks,

    Juergen

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

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Fri, 1 Jul 2011 06:25:42 -0500

There are two requirements -

5.3.2.  Corresponding power outlet

   The energy management standard must provide means for identifying the
   power outlet that provides the power received at a power inlet.

5.3.3.  Corresponding power inlets

   The energy management standard must provide means for identifying the
   list of power inlets that receive the power provided at a power
   outlet

It would be useful to explain the context of this requirement. This
seems tracing the power distribution tree. 

Secondly, for a power outlet or inlet, do all the power monitoring
requirements apply or only some of them (such as power quality, ...) 

Thanks
Mouli

-----Original Message-----

Dear all,

Thanks,

    Juergen

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Fri, 1 Jul 2011 06:38:15 -0500

It would be useful to have consistent definitions of Power, Energy and
Demand since these terms are used in many of the documents. 

Thanks
Mouli

-----Original Message-----

Dear all,

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 1 Jul 2011 14:10:21 +0200

Hi Mouli,

I'm glad you comment on this. It was too vague so far.
Please see plies inline.

> I shall post some of the discussion points. 

Yes. The question is what is needed?

>   device belongs

Is this two in one (description and domain)?

What would be the requirement for a "description"? 
Offering a text string for descriptions where arbitrary content can be entered?

I don't think the domain should be part of the device description-

>   powered device type such as consumer, provider, meter.

It's still vague. What are device types? 
Is there a fixed list? Is it maintained by IANA? 
Is it a string where operators may enter arbitrary types?

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 1 Jul 2011 14:28:13 +0200

> may be deployed - in other words, link to other MIB modules. 

I have two comments on this. 

First, the text in the draft says "means for identifying". 
It does not say that "means" is a single identifier as you 
appear to imply in your comment. The requirement in the draft
would support multiple identifiers linked with each other if necessary
as "means for identifying powered entities".

Second, I definitely do not want to have a requirement for using more 
than one identifier? If solutions can go with a single identifier, 
then why forcing them by requirement to have more.

>   device unique id to existing other identifiers currently used in

Well, as said before, I would not like to see a requirement like this 
without having a requirement to use more than one identifier for the
same entity.

> Secondly, it would be useful to specify if the identity should

Would this be covered by 
OLD
   "means for uniquely identifying powered entities"
NEW
   "means for uniquely and persistently identifying powered entities"
?

Thanks,

    Juergen

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Fri, 1 Jul 2011 07:29:09 -0500

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Friday, July 01, 2011 5:40 PM
To: Mouli Chandramouli (moulchan)
Cc: eman mailing list
Subject: Re: [eman] New draft on eman requirements - issue 1 - Device
type

Hi Mouli,

What would be the requirement for a "description"? 
Offering a text string for descriptions where arbitrary content can be
entered?

Mouli>> OK. My intent is to spell out the requirement in to
sub-requirements - Description (Text string) 
MOuli>> Agreed.  Domain to which the device belong could be another
sub-requirement. 

Mouli>> Thinking very simplistically, to further characterize a powered
entity  there can be three possibilities   ' + ' or ' - ' or neutral. 
MOuli>> So, a device can be consuming power or proving power or neutral.
This information can be useful to validate the reading of power recorded
from a device. 

Thanks,

    Juergen

Thanks
Mouli

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 1 Jul 2011 14:42:27 +0200

> seems tracing the power distribution tree. 

Yes, good point. Let's add such text to the next version.
Anyway, in your terminology these relationships are just 
"power supply parent" and "power supply child".

> requirements apply or only some of them (such as power quality, ...)

As said in the abstract and in the introduction: This requirements draft
just asks a standard to provide means for reporting quality and all the 
other attributes. However, which must be implements for compliance
needs to be specified by the MIB modules or other standards track 
documents.

Obviously, there must be a clause in those standards documents allowing
not to implement many things, such as power quality measurements 
at outlets.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 1 Jul 2011 14:48:58 +0200

Yes, of course.

You have my full agreement.
However, we are not that far yet.
There will be a new and probably better definition of these terms 
in the next update of the framework. You can make the same comment then.
There will also be a new definition of "demand". I did not include any of the 
ones we had so far in the requirements draft, because they were not usable.

However, as long as we are continuously improving our definitions 
we do not have to take much care of having the same one in all drafts. 
Once we all think we have arrived at a final definition, we should make 
sure every document uses the same.

Thanks,

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Fri, 01 Jul 2011 16:09:20 +0200

Dear all,

Specifically dealing with the domain...

Since the domain is mentioned here, isn't it a case for a specific 
requirement regarding the domain?

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 1 Jul 2011 14:46:16 +0000

Hi Benoit,

This requirement is already in the draft:

> 5.1.2.  Grouping of powered entities
> 
>    The energy management standard must provide means for grouping
>    powered entities, for example, into energy monitoring domains, energy
>    control domains, power supply domains, groups of entities of the same
>    type, etc.

Does it cover what you are looking for?

Thanks,

    Juergen

---

From: Bruce Nordman <[email-masked]>
Date: Fri, 1 Jul 2011 14:50:44 -0700

One possible reference is:
  IEEE 100, "The Authoritative Dictionary of IEEE Standards Terms", IEEE.
I have the Seventh Edition, 2000, which appears to be the most recent
(perhaps it is now only revised electronically).
I am not an engineer, but have chaired an IEEE working group.

A measurement standard that I am very familiar with is IEC 62301 (Ed. 2),
"Household electrical appliances – Measurement of standby power" - which
addresses measurements of individual devices.  It does NOT define power
or energy in the standard, but instead references:
IEC 60050-131, International Electrotechnical Vocabulary (IEV) – Part 131:
Circuit theory
IEC 60050-300, International Electrotechnical Vocabulary (IEV) – Electrical
and electronic measurements and measuring instruments – Part 311: General
terms relating to measure- ments – Part 312: General terms relating to
electrical measurements – Part 313: Types of electrical measuring
instruments – Part 314: Specific terms according to the type of instrument
So, would be good if someone could see what these say, or perhaps we can
do the same and simply reference these without defining energy or power
(except to specify the units).  I do think we should reference 62301, at
least
as informative.  It is widely referenced in energy test procedures for
electronics
(and presumably for appliances as well).

Back to the IEEE Dictionary.
Energy in the context of "metering" is:
"The integral of active power with respect to time."

Demand in the context of "electrical power systems in commercial buildings"
is.
"The electrical load at the receiving terminals averaged over a
 specified interval of time.  Demand is expressed in kilowatts,
 kilovoltamperes, kilovars, amperes, or other suitable units.
 The interval of time is generally 15 minutes, 30 minutes, or 60 minutes."
Other definitions listed are:
"The average value of power or a related quantity over a specified interval
of time"
"The rate at which electrical energy is being used"
"The rate of consumption, e.g. power, volume/hour."

Power (most applicable definition) is:
"The rate of generating, transferring, or using energy."

Power--Active is:
"The time average of the instantaneous power over one period of the wave."
This same definition is listed for metering for "Active Power".

Some terms have extremely lengthy definitions.  Examples include
electric energy, and active power.

Electric Energy begins:
"The electric energy delivered by an electric circuit during a time interval
 is the integral with respect to time of the instantaneous power at the
 terminals of entry of the circuit to a delineated region."
A second definition is in its entirety
"Usually, electric demand integrated over the period of one hour".

Also worthy of consideration:
Electricity Meter:
"A device that measures and registers the integral of an electrical quantity
with
 respect to time"
A similar definition exists for "watthour meter".

I would be in favor of short definitions that then point to IEC or IEEE.

--Bruce

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 06 Jul 2011 06:33:47 +0000

Hi Juergen,

I think that the draft looks good!

I have some comments on the open issues sections 12.3 and 12.4. In this
email I will only
address 12.3. In another email I will address 12.4.

Regarding Section 12.3 Inlet/outlet combinations:
--------------------------------

I am in favour of introducing a new kind of hybrid in/outlets. This is
because such sockets are different than the typical inlet and outlet
sockets.

If these hybrid sockets are used then the requirements associated with
inlet/outlet socket have to somehow be modified, see below:

Change_1 related to Inlet/outlet combinations:

5.3.  Power inlet and power outlet

   Powered entities have power inlets at which they are supplied with
   electric power.  Many entities just have a single power inlet, while
   others have multiple ones.  Often different power inlets are
   connected to separate power distribution trees.  For energy
   monitoring, it is important information which power inlets an entity
   has, if power is available at an inlet and which of them are actually
   in use.

   Some entities have power outlets for supplying other entities with
   electric power.  An entity may have multiple power outlets.  Examples
   are a Power Distribution Units (PDU) and a Power over Ethernet (PoE)
   Power Sourcing Equipment (PSE).

   For identifying and potentially controlling the source of power
   received at an inlet, it is useful to identify the power outlet of
   another entity at which the received power is provided.  Analogously,
   for each outlet it is of interest to identify the power inlets that
   receive the power provided at a certain outlet.

   Static properties of each power inlet and each power outlet are
   useful information for energy management.  Static properties include
   the kind of electric current (Alternating Current (AC) or Direct
   Current (DC)), the nominal voltage, the nominal AC frequency, and the
   number of AC phases.

INTO something like:

5.3.  Power inlet, power outlet and hybrid power inlet/outlet

   Powered entities have power inlets at which they are supplied with
   electric power.  Many entities just have a single power inlet, while
   others have multiple ones.  Often different power inlets are
   connected to separate power distribution trees.  For energy
   monitoring, it is important information which power inlets an entity
   has, if power is available at an inlet and which of them are actually
   in use.

   Some entities have power outlets for supplying other entities with
   electric power.  An entity may have multiple power outlets.  Examples
   are a Power Distribution Units (PDU) and a Power over Ethernet (PoE)
   Power Sourcing Equipment (PSE).

   There are entities where the inlet or outlet changes during
   operation from one kind to the other.  An example is a battery that
   receives power at a socket at one time.  Then the socket is an inlet.
   At another time the battery provides power at the same socket.  Then
   it's an outlet.  The same holds for entities with integrated power
   generators. This type of socket is denoted as a hybrid power
inlet/outlet.

   For identifying and potentially controlling the source of power
   received at an inlet, it is useful to identify the power outlet of
   another entity at which the received power is provided.  Analogously,
   for each outlet it is of interest to identify the power inlets that
   receive the power provided at a certain outlet. For hybrid power
inlet/outlet
   it is for interest to identify and control when and for how long a
   hybrid socket operates as a power inlet and for how long it operates
   as a power outlet.

   Static properties of each power inlet and each power outlet are
   useful information for energy management.  Static properties include
   the kind of electric current (Alternating Current (AC) or Direct
   Current (DC)), the nominal voltage, the nominal AC frequency, and the
   number of AC phases.

Change_2: related to Inlet/outlet combinations:

Please change from:

INto something like:

   The energy management standard must provide means for identifying the
   power outlet that provides the power received at a power inlet or at a
hybrid power
   inlet/outlet.

-----------------------

Change_3: related to Inlet/outlet combinations:

Please change from:

   outlet.

INto something like:

   The energy management standard must provide means for identifying the
   list of power inlets that receive the power provided at a power
   outlet or a hybrid power inlet/outlet.

---------------

Change_4 related to Inlet/outlet combinations:

Include a new section in 5.3, after section 5.3.3, something like:

5.3.x Corresponding hybrid power inlets/outlets

   The energy management standard must provide means for identifying the
   hybrid power inlet/outlet that provides the power received at a power
inlet or
   another hybrid power inlet/outlet.

------------------

Change_5 related to Inlet/outlet combinations:

Please change from:

5.3.4.  Availability of power

   The energy management standard must provide means for monitoring the
   availability of power at each power inlet and each power outlet.
   This information indicates whether at a power providing outlet power
   supply is switched on or off.

INto something like:

5.3.4.  Availability of power

   The energy management standard must provide means for monitoring the
   availability of power at each power inlet, at each power outlet and at
each
   hybrid power inlet/outlet.
   This information indicates whether at a power providing outlet
   the power supply is switched on or off. For a hybrid power
inlet/outlet this indicates whether
   the hybrid inlet/outlet operates as an inlet or as an outlet.

--------------

Change 6 related to Inlet/outlet combinations:

Please change from:

5.3.5.  Use of power

   The energy management standard must provide means for monitoring for
   each power inlet and each power outlet if it is in actual use.  For
   the inlet this means that the entity actually receives power at the
   inlet.  For the outlet this means that actually power is provided to
   one or more entities at the outlet.

INTO something like:

5.3.5.  Use of power

   The energy management standard must provide means for monitoring for
   each power inlet, for each power outlet and for each hybrid power
inlet/outlet
   if it is in actual use.  For
   the inlet this means that the entity actually receives power at the
   inlet.  For the outlet this means that actually power is provided to
   one or more entities at the outlet. For the hybrid inlet/outlet this
means
   that the energy management standard must be able to distinguish whether
   power is received to the hybrid inlet/outlet or power is provided by
the
   hybrid inlet/outlet to one or more entities.

------------------

Change 7 related to Inlet/outlet combinations:

Please a new subsection after subsection 6.2

6.2.x Controlling power supply and consumption
   The energy management standard must provide means for switching power
   supply off or turning power supply on at power outlets providing
   power to one or more powered entity.

INTO something like:

6.2.x Controlling power supply and consumption

   The energy management standard must provide means for switching power
   supply off or turning power supply on at hybrid power inlet/outlets.
   Furthermore, the energy management standard must provide means for
switching
   the power consumption off or turning power consumption on at hybrid
power inlet/outlets.

---------------

Best regards,
Georgios
PS: I will provide some comments on the aggregation related issue in
another email

On 6/30/2011, "Juergen Quittek" <[email-masked]> wrote:

>Dear all,
>
>I am sorry for posting another version just one day after the previous one.
>The reason was that a change in terminology ("powered device" -> "powered
>entity") was not done consistently in all sections, particularly not in the
>battery section.
>
>There are no further changes, particularly no technical changes compared to
>the previous version.
>
>Thanks,
>
>    Juergen
>
>Am 29.06.11 16:53 schrieb "Juergen Quittek" unter <[email-masked]>:
>
>> Dear all,
>>
>> I just posted a new version on the requirements draft.
>> Please find it at
>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-02.txt
>>
>> We had intensive discussions among the authors and received a lot of useful
>> comments from John Parello. This resulted in many changes and a modified
>> structure. We consider the version posted today as an intermediate one and
>> intend to post another update before the cut-off date.
>>
>> Please have a look at the new structure and give us your feedback.
>>
>> Issues that we definitely want to solve for the next version are described
>> in section 12. Among them are
>>   - High/Low power notifications
>>   - Power and energy time series?
>>   - Inlet/outlet combinations
>>   - Aggregation functions
>> Your advice on these issues is highly appreciated.
>>
>> Thanks,
>>
>>     Juergen
>>

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 6 Jul 2011 01:50:36 -0500

Hi Georgios,

It would help if you can provide some more of the context of what is a
hybrid inlet/outlet. Where are these used ?  

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Georgios Karagiannis
Sent: Wednesday, July 06, 2011 12:04 PM
To: Juergen Quittek; eman mailing list
Subject: Re: [eman] New draft on eman requirements

Hi Juergen,

INTO something like:

Please change from:

INto something like:

   The energy management standard must provide means for identifying the
   power outlet that provides the power received at a power inlet or at
a
hybrid power
   inlet/outlet.

-----------------------

Please change from:

INto something like:

---------------

------------------

Please change from:

INto something like:

   availability of power at each power inlet, at each power outlet and
at

--------------

Please change from:

5.3.5.  Use of power

INTO something like:

5.3.5.  Use of power

   that the energy management standard must be able to distinguish
whether

------------------

INTO something like:

---------------

Best regards,
Georgios

one.
"powered
the

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 06 Jul 2011 07:30:24 +0000

Hi Mouli

Examples are given in Sectin 12.3 of the requirements draft:

An example is a battery that
   receives power at a socket at one time.  Then the socket is an inlet.
   At another time the battery provides power at the same socket.  Then
   it's an outlet.  The same holds for entities with integrated power
   generators.

Best regards,
Georgios

---

From: Benoit Claise <[email-masked]>
Date: Wed, 06 Jul 2011 11:32:36 +0200

Hi Juergen,

Not exactly.

There are actually two different concepts
1. the domain
2. grouping of powered entities. Practically, this is done with the 
keyword list in [EMAN-AWARE]

The requirement 5.1.2 covers "grouping of powered entities"
We're missing in section 4 a requirement such as:

    The energy management standard must provide means for identifying 
the domain to which the
    powered entity belongs.

Regards, Benoit.
> Am 01.07.11 16:09 schrieb "Benoit Claise" unter<[email-masked]>:
>
>>    Dear all,
>>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 06 Jul 2011 11:26:57 +0200

> Yes. The question is what is needed?
We don't want we redo the ENTITY-MIB work, but  I believe that having a 
way to map to the ENTITY-MIB index is important.
The more generic requirements should be something such as:

    The energy management standard must provide means to map the power entities
    to existing managed device inventory such as the ENTITY-MIB.

    The energy management standard must provide means to map the power entities
    to existing energy related MIBs such as the POE and LLPD MIBs

Those two requirements should be in the section 4. Identification of 
Powered Entities

Coming back to this requirement

I believe the "type" is misleading. The main requirement is that we want 
the ability to group powered entities based on something, which could be 
the type, what the type definition you want.
Therefore, I would remove the requirement 5.1.1 and only keep the 
current 5.1.2

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 06 Jul 2011 11:45:00 +0200

Juergen,

[reading my emails in sequence. So this comment might overlap with my 
previous email]
> as "means for identifying powered entities".
It would be better to clarify this text then.
> then why forcing them by requirement to have more.
I'm not sure how you deduce a requirement for multiple identifiers from:

    "Firstly, it would be useful to link this unique ID to other indices that
    may be deployed - in other words, link to other MIB modules."

I don't believe that there is a requirement for multiple identifiers. A 
primary identifier in MIB module is what's required.
However, a _link _to other indices make sense.

> without having a requirement to use more than one identifier for the
See my previous comment.
>     "means for uniquely and persistently identifying powered entities"
Regarding the persistence, there are cases where the persistence is 
required and some others where it doesn't make sense.
So the requirement should be something such as (in section 4 
Identification of Powered Entities)

    The energy management standard must provide means for indicating
    whether the powered entities identification is persistent across a reboot.

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 6 Jul 2011 12:40:15 +0200

Hi Benoit,

OK, for me a domain is a group of entities.
A domain could be 
  - "4th floor": all energy consumers on the 4th floor of a building
  - "desktop phones": all desktop phone in an enterprise
  - "Fuse 321": all powered entities receiving power via main fuse 123 in the energy distribution tree
  - "meter 7": all entities that are metered by power meter 7
There are  certainly many more examples.
Why would a domain not be a group of entities?

Thanks,

    Juergen

Am 06.07.2011 um 11:32 schrieb Benoit Claise:

> 2. grouping of powered entities. Practically, this is done with the keyword list in [EMAN-AWARE]
> 
>   The energy management standard must provide means for identifying the domain to which the
>   powered entity belongs.
> 
> Regards, Benoit.
>> Hi Benoit,
>>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 06 Jul 2011 13:00:57 +0200

Hi Juergen,

Because the domain is used for identity uniqueness, while the group goal 
is helping the reporting

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 6 Jul 2011 13:03:26 +0200

Am 06.07.2011 um 11:45 schrieb Benoit Claise:

> Juergen,
> 
> [reading my emails in sequence. So this comment might overlap with my previous email]
> I don't believe that there is a requirement for multiple identifiers. A primary identifier in MIB module is what's required.
> However, a link to other indices make sense.

OK. I see your point. 
But if we require links to other indices, we must give a concrete list of them
Otherwise I would not know how to check if the requirement is met.
If we can agree on finite list of indices to which an energy management standard MUST link entity identiites, 
then I'd be glad to include it in the requirements. 
>> without having a requirement to use more than one identifier for the

Well here we switched from indices to identifiers, not necessarily the same.
Again, I would like to know which identifiers are currently used in network management that we must link to.

> Regarding the persistence, there are cases where the persistence is required and some others where it doesn't make sense.
> So the requirement should be something such as (in section 4 Identification of Powered Entities)
> 
>    whether the powered entities identification is persistent across a reboot
Fine. What about the following?

4.3.  Persistency of Identifiers

   The energy management standard must provide means for indicating
   whether identifiers of powered entities are persistent across a re-
   start of the entity that provides the identifiers.

Thanks,

    Juergen

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 6 Jul 2011 06:12:04 -0500

From: Juergen Quittek [mailto:[email-masked]] 
Sent: Wednesday, July 06, 2011 4:33 PM
To: Benoit Claise (bclaise)
Cc: Mouli Chandramouli (moulchan); eman mailing list
Subject: Re: [eman] New draft on eman requirements - issue 2 - Device
Identity

Juergen,

	Hello,

	There is a requirement -

	on identity 

	  The energy management standard must provide means for uniquely
	  identifying powered entities that are monitored or controlled
by an
	  energy management system.  Uniqueness must be given in a
domain that
	  is large enough to avoid collisions of identities at potential
	  receivers of monitored information.

	Firstly, it would be useful to link this unique ID to other
indices that
	may be deployed - in other words, link to other MIB modules. 

"Firstly, it would be useful to link this unique ID to other indices
that
may be deployed - in other words, link to other MIB modules." 

OK. I see your point. 

But if we require links to other indices, we must give a concrete list
of them

If we can agree on finite list of indices to which an energy management
standard MUST link entity identiites, 

Mouli>>>  IMHO, the link to the indices to the other MIB modules was to
reuse the capabilities (indices) of MIB modules for the scope of the
devices in EMAN.

Mouli>>> If the requirement were to restrict to indices of a  finite
number of MIB modules,  I am not sure that is the intended goal. 

Thanks

Mouli

			  The energy management standard must provide
means to link the powered
			  device unique id to existing other identifiers
currently used in
			  network management.

		Well, as said before, I would not like to see a
requirement like this 
		without having a requirement to use more than one
identifier for the
		same entity.

	See my previous comment.

Well here we switched from indices to identifiers, not necessarily the
same.

Again, I would like to know which identifiers are currently used in
network management that we must link to.

			Secondly, it would be useful to specify if the
identity should
			persistent. 

		Would this be covered by 
		OLD
		   "means for uniquely identifying powered entities"
		NEW
		   "means for uniquely and persistently identifying
powered entities"

	Regarding the persistence, there are cases where the persistence
is required and some others where it doesn't make sense.
	So the requirement should be something such as (in section 4
Identification of Powered Entities)

	   The energy management standard must provide means for
indicating
	   whether the powered entities identification is persistent
across a reboot

Thanks,

    Juergen

	Regards, Benoit.

	?
	 
	Thanks,
	 
	    Juergen

		Thanks
		Mouli

		-----Original Message-----
		From: [email-masked]
[mailto:[email-masked]] On Behalf Of
		Juergen Quittek
		Sent: Thursday, June 30, 2011 2:56 PM
		To: eman mailing list
		Subject: Re: [eman] New draft on eman requirements
		 
		Dear all,
		 
		I am sorry for posting another version just one day
after the previous
		one.
		Now out is version -03 to be found at

		The reason was that a change in terminology ("powered
device" ->
		"powered
		entity") was not done consistently in all sections,
particularly not in
		the
		battery section.
		 
		There are no further changes, particularly no technical
changes compared
		to
		the previous version.
		 
		Thanks,
		 
		   Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 6 Jul 2011 13:53:33 +0200

Hi Mouli,

Am 06.07.2011 um 13:12 schrieb Mouli Chandramouli (moulchan):

[snip]

> Mouli>>>  IMHO, the link to the indices to the other MIB modules was to reuse the capabilities (indices) of MIB modules for the scope of the devices in EMAN.
> Mouli>>> If the requirement were to restrict to indices of a  finite number of MIB modules,  I am not sure that is the intended goal.

But then, how will you be able to check the requirement is met?
Is it met, when there is a link to just one other MIB module?
Or only if all MIB modules that apply to any device in scope get linked?

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 6 Jul 2011 13:56:25 +0200

Hi Benoit,

Am 06.07.2011 um 13:00 schrieb Benoit Claise:

> Hi Juergen,
> 
> Because the domain is used for identity uniqueness, while the group goal is helping the reporting
Wouldn't in this context the domain be the group of all devices that are managed by the involved 
energy management systems?

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 6 Jul 2011 13:59:28 +0200

On 06.07.2011  11:26, Benoit Claise wrote:

> We don't want we redo the ENTITY-MIB work, but  I believe that having a way to map to the ENTITY-MIB index is important.
> Those two requirements should be in the section 4. Identification of Powered Entities

I agree on moving it to section 4.  The discussion on the content is going on in another email thread.

> I believe the "type" is misleading. The main requirement is that we want the ability to group powered entities based on something, which could be the type, what the type definition you want.
> Therefore, I would remove the requirement 5.1.1 and only keep the current 5.1.2
I agree. I do not know what an entity type is. So let's remove 5.1.1.
However, 5.1.2 also talks about entities of the same type :-)
Shall we remove "type" also here?

Thanks,

    Juergen

---

From: JinHyeock Choi <[email-masked]>
Date: Wed, 6 Jul 2011 23:22:34 +0900

Bruce

> I would be in favor of short definitions that then point to IEC or IEEE.

agree.

In Physics,
‘Power (unit of watt)’ and ‘Energy (unit of joule)’ are well defined terms
just like ‘Force (unit of newton)’.

For ‘power’ and ‘energy’
we can just use the definitions made in Physics.

Also it will help to specify power/ energy relationship such as
‘energy is integral of power of time’ and
‘power is energy consumption rate, i.e. derivative of energy w.r.t time’

best regards

JinHyeock

On Sat, Jul 2, 2011 at 6:50 AM, Bruce Nordman <[email-masked]> wrote:
> On Fri, Jul 1, 2011 at 4:38 AM, Mouli Chandramouli (moulchan)
> <[email-masked]> wrote:
>>
> Bruce Nordman

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 06 Jul 2011 20:35:09 +0000

Hi Juergen,

Aggregated functions may be related to:

o) power states of grouped entities
o) power levels associated with grouped entities
o) energy levels associated with grouped entities.

The main Aggregation functions could be concatenation, sumation,
calculated averages.

I could list some requirements related to aggregation of power states,
power levels and energy levels if needed.

Best regards,
Georgios

The requirements on aggregation functions  and

---

From: Benoit Claise <[email-masked]>
Date: Fri, 08 Jul 2011 02:06:54 +0200

Hi Juergen,
> energy management systems?
I believe that we have too many notions behind domains and groups
     domain = identification uniqueness domain
     domain = the group of all devices that are managed by the 
involved energy management system
     domain = metering domain
     group = arbitrary group

[EMAN-REQ] must clearly specify the requirement for the identification 
uniqueness.

We must address the open issue in [EMAN-AWARE]

         1. Length and format of PowerMonitorId. The pmPowerMonitorID
           should be a unique id that identfies the device in the
           universe. A UUID usingRFC 4122  <http://tools.ietf.org/html/rfc4122>  seems to suffice. However an
           x.509 certificate conforming toRFC 5280  <http://tools.ietf.org/html/rfc5280>  could also be
           appropriate. We have specified the field as variable 16 bytes
           but would like feedback and consensus on the format that is
           appropriate.

Regards, Benoit.
>>>>>>>> From:[email-masked]  [mailto:[email-masked]] On Behalf Of
>>>>>>>> Juergen Quittek

---

From: Bruce Nordman <[email-masked]>
Date: Fri, 8 Jul 2011 00:16:50 -0700

On Wed, Jul 6, 2011 at 4:59 AM, Juergen Quittek <[email-masked]> wrote:

> ....
> the ability to group powered entities based on something, which could be the
> type, what the type definition you want.

I have to disagree completely on this point.
A major barrier to understanding energy use in
buildings and in doing things to reduce it is
lack of information about what devices are
present in a building and how much each
one is using.  We are going into great detail
about the quantities of energy, but seem to
want to avoid saying anything about what
the device actually is.

Accomplishing this and meeting the needs of
energy efficiency need not be burdensome.
Just a few variables can point to a standard
index of device types (or "product types" in
my line of work) and short brand/model
information.

Thanks,

--Bruce

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 8 Jul 2011 11:25:08 +0200

Hi Benoit,

>     domain = identification uniqueness domain

Sorry, I don't know what this is.

>     domain = the group of all devices that are managed by the involved energy management system

That would be a domain.
>     domain = metering domain

That's another domain.

>     group = arbitrary group

If you see it from the side of a network/energy management system, 
the requirement for EMAN is 
  - having all entity identifiers be unique for all involved energy management systems
  - being able to group entities into domains, such as
      - all energy consumers
      - all energy consumers in a building, on a floor, etc.
      - all energy consumers of a certain type, such as phone, PC, switch, display, etc.
      - all energy consumers supplied by a certain branch of the electricity distribution tree
          - all supplied by a certain PoE PSE
          - all suppliec by a certain PDU
          - all supplied via a certain fuse cabinet
      - all measured by a given set of power meters
      - etc.

Memberships to all of these domains could be assigned within the management system.
In addition we can make energy consumer aware of the domains they are a member of.

Within each domain uniqueness for the identifiers must be given.
But it might be a good idea to use globally unique identifiers 
that can be used by other management systems as well.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 11 Jul 2011 13:53:06 +0000

OK. It put requirement 5.1.1 back in and added an entry to the open issues
unitl we come to a conclusion.

    Juergen

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Mon, 25 Jul 2011 14:18:08 -0500

I fear that the term "type" may be overloaded in the discussion below, or I could be wrong.  I am not clear on what Benoit means when he states "The main requirement is that we want the ability to group powered entities based on something, which could be the type ...".

Grouping for what purpose?

Bruce on the other hand appears to be using the term to mean literally what type of device it is, e.g. a light bulb, a network router, a refrigerator, etc.  This usage seems unrelated to grouping although it could be used as a means of identying all the light bulbs, or all the refrigerators.

I agree with Bruce that we should be supporting some sort of device type identification information.  This would be useful for identifying, for example, which "Unit of Useful Work" would be applicable to a given device to derive a meaningful efficiency metric for it. 

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [email-masked] <mailto:[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 

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Bruce Nordman
	Sent: Friday, July 08, 2011 3:17 AM
	To: eman mailing list
	Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type

				

				

	
	
	Thanks,
	
	--Bruce

---

From: Benoit Claise <[email-masked]>
Date: Mon, 25 Jul 2011 21:39:24 -0400

Georgios,

So basically you want to model the battery interface.
Isn't it an overkill?

However, the EMAN requirements doesn't speak at all about 
producer/consumer, and I believe it should.
Actually, I do believe in the "Standardized reporting of energy data 
using "odometer" structures (consumed energy, generated energy and net 
energy). ", as explained by Rich Morgan (ODVA).

Regards, Benoit (as a contributor)
> On 7/6/2011, "Mouli Chandramouli (moulchan)"<[email-masked]>  wrote:
>
>> Hi Georgios,
>>
>>
>> On 6/30/2011, "Juergen Quittek"<[email-masked]>  wrote:
>>
>>> Dear all,
>>>
>>> Am 29.06.11 16:53 schrieb "Juergen Quittek" unter<[email-masked]>:
>>>
>>>> Dear all,
>>>>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 25 Jul 2011 22:54:04 -0400

Juergen,
>> We don't want we redo the ENTITY-MIB work, but  I believe that having 
>> a way to map to the ENTITY-MIB index is important.
I would appreciate if you could either introduce this text in the draft, 
or list this as an open issue, instead of just ignoring it.

---

From: Benoit Claise <[email-masked]>
Date: Mon, 25 Jul 2011 23:19:32 -0400

Hi Bill,
> I fear that the term "type" may be overloaded in the discussion below, or I could be wrong.  I am not clear on what Benoit means when he states "The main requirement is that we want the ability to…
Sorry for being really unclear. I should have written. The main 
requirement is that we want the ability to group powered entities based 
on something, whatever this criteria is .... Let me explain. If we do 
EMAN monitoring, it's to report on power/energy. Those reports can be 
based on the device type (PC, Phone, printer, router, switch, ..), based 
on the business context, based on the software/hardware version, based 
on your own criteria, ...

So basically, I agree with you. In the following requirement, the term 
"type" is overloaded.

> Grouping for what purpose?
For reporting.
> I agree with Bruce that we should be supporting some sort of device type identification information.  This would be useful for identifying, for example, which "Unit of Useful Work" would be applica…
Hence my previous request to have a pointer to the ENTITY-MIB clearly 
mentioned in the requirements, just in case the MIB is present.

Regards, Benoit.
> Email: [email-masked]<mailto:[email-masked]>
> Phone: 614 367 5628
> Fax: 614 367 5965
>
> 	On Wed, Jul 6, 2011 at 4:59 AM, Juergen Quittek<[email-masked]>  wrote:
> 	
>

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 26 Jul 2011 13:35:41 -0400

Yes. done.

Sorry for missing this item.

    Juergen

Am 25.07.2011 um 22:54 schrieb Benoit Claise:

> I would appreciate if you could either introduce this text in the draft, or list this as an open issue, instead of just ignoring it.
>

---

From: "John Parello (jparello)" <[email-masked]>
Date: Wed, 27 Jul 2011 11:30:57 -0700

Hi Bill

There's a few classification and grouping terms mixed but I agree with
you and Bruce. 

- When looking at a device we need to identify it uniquely in the
management domain or universe (uuid in the framework).

- Once identified it's helpful to know type and as you say it's
overloaded. So along the lines of vendor-type-species helps here(ex:
Ford,Model-T,Lightbulb)
 
- Next the role of the device is needed. What's its purpose in the
deployment (we have role in the framework Ex: Decorative Lighting)

After that there's arbitrary grouping (keywords in the framework)

Example:

Object uuid: 17
Vendor,type,species: Ford,Model-T,lightbulb
Role: decorative lighting
Keywords: conference,public,room17

We further add importance in the framework to give it ranking.

So I agree the requirements should call out the need for descriptive
typing and categorization.

Jp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mielke, William F (Bill)
Sent: Monday, July 25, 2011 12:18 PM
To: eman mailing list
Subject: Re: [eman] New draft on eman requirements - issue 1 - Device
type

I fear that the term "type" may be overloaded in the discussion below,
or I could be wrong.  I am not clear on what Benoit means when he states
"The main requirement is that we want the ability to group powered
entities based on something, which could be the type ...".

Bruce on the other hand appears to be using the term to mean literally
what type of device it is, e.g. a light bulb, a network router, a
refrigerator, etc.  This usage seems unrelated to grouping although it
could be used as a means of identying all the light bulbs, or all the
refrigerators.

I agree with Bruce that we should be supporting some sort of device type
identification information.  This would be useful for identifying, for
example, which "Unit of Useful Work" would be applicable to a given
device to derive a meaningful efficiency metric for it. 

William F. Mielke
Alcatel-Lucent

Phone: 614 367 5628
Fax: 614 367 5965

    - Albert Einstein 

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bruce Nordman
	Sent: Friday, July 08, 2011 3:17 AM
	To: eman mailing list
	Subject: Re: [eman] New draft on eman requirements - issue 1 -
Device type

	On Wed, Jul 6, 2011 at 4:59 AM, Juergen Quittek
<[email-masked]> wrote:

				
				The energy management standard must
provide means to retrieve and
				report the type of powered entities.

			I believe the "type" is misleading. The main
requirement is that we want the ability to group powered entities based
on something, which could be the type, what the type definition you
want.
			Therefore, I would remove the requirement 5.1.1
and only keep the current 5.1.2

				   The energy management standard must
provide means for grouping
				   powered entities, for example, into
energy monitoring domains, energy
				   control domains, power supply
domains, groups of entities of the same
				   type, etc.

		I agree. I do not know what an entity type is. So let's
remove 5.1.1.
		However, 5.1.2 also talks about entities of the same
type :-)
		Shall we remove "type" also here?

	
	Thanks,
	
	--Bruce