From bclaise@cisco.com Tue Aug 2 15:31:29 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE00311E80A1 for ; Tue, 2 Aug 2011 15:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcQU3lSQi+Mk for ; Tue, 2 Aug 2011 15:31:27 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D956221F8586 for ; Tue, 2 Aug 2011 15:31:26 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p72MVTJ7011414; Wed, 3 Aug 2011 00:31:29 +0200 (CEST) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p72MVNTV006901; Wed, 3 Aug 2011 00:31:23 +0200 (CEST) Message-ID: <4E381298.2020500@cisco.com> Date: Tue, 02 Aug 2011 17:07:04 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Brad Schoening References: <9C329342B62B87498B92834DEC9FF51E0D6187D8@fig.raritan.com> <22B2909DCC2E62418BE369A1F10488994B79886F@ex01.noveda.com> In-Reply-To: <22B2909DCC2E62418BE369A1F10488994B79886F@ex01.noveda.com> Content-Type: multipart/alternative; boundary="------------090601000603030606030107" Cc: eman mailing list Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:31:30 -0000 This is a multi-part message in MIME format. --------------090601000603030606030107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Trying to combine all the different arguments (discussed on the mailing list and during the meeting), why do we have to have to specify which time series the EMAN standard must support as a pull model? Why not have a generic requirement, such as: The EMAN tandard must not limit time series (for example Power, Energy, Demand) to a pull mechanism; the push mechanism must be considered. Regards, Benoit. > An energy time series is can be reported as an odometer reading. I > think you'll need to be adaptable to allow either an absolute value > like instantaneous kW, kWh over a sample period or odometer sampling > for kWh. > > *From:*eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] *On Behalf > Of *Michael Suchoff > *Sent:* Thursday, July 28, 2011 2:25 PM > *To:* John Parello (jparello); Juergen Quittek; Juergen Quittek > *Cc:* eman mailing list > *Subject:* Re: [eman] new revision of eman requirements - open issue > 12.3:timeseries of energy/power values > > I would add current to the series as well. Most AC devices presently > don't have circuitry to report power or energy, they simply report AC > current. Also, for capacity planning, current is very useful (it is > current that limits how many devices can be placed on an electrical > branch circuit or PDU -- not power). > > Ideally, the time series would be structured as a table with the > columns being measurements (i.e. column 1 = time stamp, 2 = power, 3 = > energy, 4 = current, 5 = voltage, etc). The columns could be > partitioned into SNMP augmented tables (tables sharing same index). > This would allow easy addition of new columns for products that offer > more information. > > I don't see reason for demand as a special table. Demand (watts) is > easily computed from the energy readings. For example, if kWh = 1000 > at 1PM and kWh = 2000 at 1:15PM, then average power over the 15 minute > interval is (2000kWh -- 1000kWh) * 60minutes/15minutes = 4kW. Doesn't > it seem a lot simpler for management program to compute demand based > on polled energy readings (i.e. a simple SQL query) -- rather than > having to write a procedure to configure the power agent to perform > demand computations? > > ------------------------------------------------------------------------ > > *From:*eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] *On Behalf > Of *John Parello (jparello) > *Sent:* Thursday, July 28, 2011 2:06 PM > *To:* Juergen Quittek; Juergen Quittek > *Cc:* eman mailing list > *Subject:* Re: [eman] new revision of eman requirements - open issue > 12.3:timeseries of energy/power values > > I can't vote no when there'sand or and more on the bill. > > I don't see any reason to restrict to just power. IMO a series of > power, energy, and demand is useful if a device can support it. > > So no don't restrict it to just power and please allow series for > power, demand, and energy > > Jp > > > -----Original Message----- > From: Juergen Quittek [mailto:Quittek@neclab.eu] > Sent: Wed 7/27/2011 7:13 AM > To: John Parello (jparello); Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] new revision of eman requirements - open issue > 12.3:time series of energy/power values > > Hi John, > > my Question was > > "Do I understand right that you would support a requirement for specifying > a standard for time series of power but not for time series of energy?" > > > I take you answer as a no. This would mean we keep both requirements (time > series of power and time series of energy). Is this correct? > > Thanks, > > Juergen > > > On 26.07.11 18:10, "John Parello (jparello)" wrote: > > > > >Hi Jeurgen, > > > >We need to express power, energy as a measurement (scalar). > > > >For time series (vector) IMO having the capability of providing power > >over time series (which is demand) or energy over time is valuable and > >should not be excluded. Even though for energy an odometer can suffice I > >see no need to prevent this for devices that have this capability. > > > > > >Please take a look at the draft-claise-energy-monitoring-mib. I think > >they did a good job of providing time series modeling that covers this. > > > >thanks > >Jp > > > > > > > > > > > > > > > > > >-----Original Message----- > >From: Juergen Quittek [mailto:ietf@quittek.at] > >Sent: Tue 7/26/2011 12:39 PM > >To: John Parello (jparello) > >Cc: Mouli Chandramouli (moulchan); eman mailing list > >Subject: Re: [eman] new revision of eman requirements - open issue > >12.3:time series of energy/power values > > > >Hi John, > > > >We are currently not discussing optional or mandatory implementation. > > > >The question is whether or not we have a requirement for specifying a > >standard for reporting both, energy time series and power time series, or > >just one of them. What compliant devices must implement is an issue to be > >discussed later. > > > >Do I understand right that you would support a requirement for specifying > >a standard for time series of power but not for time series of energy? > > > >Thanks, > > > > Juergen > > > >Am 26.07.2011 um 13:08 schrieb John Parello (jparello): > > > >> Hi Jeurgen, > >> > >> I tend to agree, for simple devices an energy odometer(s) as describe > >> from the comments and what I presented from the ODVA suffices. > >> > >> For time series of data like historical demand devices such as PDUs very > >> typically store this. Some our as long as a year's worth of data on the > >> device. For the very reason that Bill pointed out. > >> > >> So it would seem that a power value and an energy odometer could be a > >> required minimum and then time series of power or demand can be > >> optional. > >> > >> We specified a power value as required in the monitoring mib with time > >> series of power and demand as optional. > >> > >> Jp > >> > >> -----Original Message----- > >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > >> Juergen Quittek > >> Sent: Wednesday, July 13, 2011 5:53 AM > >> To: Mouli Chandramouli (moulchan) > >> Cc: eman mailing list > >> Subject: Re: [eman] new revision of eman requirements - open issue > >> 12.3:time series of energy/power values > >> > >> Dear Mouli, > >> > >> Thank you for commenting on this issue. I would like to have a look at > >> the following point of view: > >> > >> So far, storing time series of measurements on managed nodes is rarely > >> standardized and rarely available as implementation. > >> > >> Typically, it is the job of a network management system to collect time > >> series and store them. > >> > >> Take for example byte and packet counters at line cards. You see many > >> curves showing time series of traffic rate/volume in the Internet, but > >> almost all of them were collected at management stations or data > >> collector modules, but not within MIB modules. (Please correct me if I'm > >> wrong.) > >> > >> Now the question is: Is energy management so much different from other > >> network management tasks, that we need the rarely used mechanism of > >> storing time series in MIB modules? > >> > >> If not, it would be sufficient to just report the number of total energy > >> consumed since the last re-start as you do it with packet and byte > >> counters. > >> This would be just a single managed object to be specified and > >> implemented. > >> > >> Thanks, > >> > >> Juergen > >> > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --------------090601000603030606030107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Trying to combine all the different arguments (discussed on the mailing list and during the meeting), why do we have to have to specify which time series the EMAN standard must support as a pull model?

Why not have a generic requirement, such as:
The EMAN tandard must not limit time series (for example Power, Energy, Demand) to a pull mechanism; the push mechanism must be considered.

Regards, Benoit.

RE: [eman] new revision of eman requirements - open issue 12.3:time series of energy/power values

An energy time series is can be reported as an odometer reading.  I think you’ll need to be adaptable to allow either an absolute value like instantaneous kW, kWh over a sample period or odometer sampling for kWh.

 

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Michael Suchoff
Sent: Thursday, July 28, 2011 2:25 PM
To: John Parello (jparello); Juergen Quittek; Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values

 

I would add current to the series as well.  Most AC devices presently don’t have circuitry to report power or energy, they simply report AC current.  Also, for capacity planning, current is very useful (it is current that limits how many devices can be placed on an electrical branch circuit or PDU – not power).

 

Ideally, the time series would be structured as a table with the columns being measurements (i.e. column 1 = time stamp, 2 = power, 3 = energy, 4 = current, 5 = voltage, etc).  The columns could be partitioned into SNMP augmented tables (tables sharing same index).  This would allow easy addition of new columns for products that offer more information.

 

I don’t see reason for demand as a special table.  Demand (watts) is easily computed from the energy readings.  For example, if kWh = 1000 at 1PM and kWh = 2000 at 1:15PM, then average power over the 15 minute interval is (2000kWh – 1000kWh) * 60minutes/15minutes = 4kW.  Doesn’t it seem a lot simpler for management program to compute demand based on polled energy readings (i.e. a simple SQL query) – rather than having to write a procedure to configure the power agent to perform demand computations?

 

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of John Parello (jparello)
Sent: Thursday, July 28, 2011 2:06 PM
To: Juergen Quittek; Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values

 

 

I can't vote  no when there'sand or and more on the bill.

I don't see any reason to restrict to just power. IMO a series of power, energy, and demand is useful if a device can support it.

So no don't restrict it to just power and please allow series for power, demand, and energy

Jp


-----Original Message-----
From: Juergen Quittek [mailto:Quittek@neclab.eu]
Sent: Wed 7/27/2011 7:13 AM
To: John Parello (jparello); Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:time series of energy/power values

Hi John,

my Question was

"Do I understand right that you would support a requirement for specifying
a standard for time series of power but not for time series of energy?"


I take you answer as a no. This would mean we keep both requirements (time
series of power and time series of energy). Is this correct?

Thanks,

    Juergen


On 26.07.11 18:10, "John Parello (jparello)" <jparello@cisco.com> wrote:

>
>Hi Jeurgen,
>
>We need to express power, energy as a measurement (scalar).
>
>For time series (vector) IMO having the capability of providing power
>over time series (which is demand) or energy over time is valuable and
>should not be excluded.  Even though for energy an odometer can suffice I
>see no need to prevent this for devices that have this capability.
>
>
>Please take a look at the draft-claise-energy-monitoring-mib.  I think
>they did a good job of providing time series modeling that covers this.
>
>thanks
>Jp
>
>
>
>
>
>
>
>
>-----Original Message-----
>From: Juergen Quittek [mailto:ietf@quittek.at]
>Sent: Tue 7/26/2011 12:39 PM
>To: John Parello (jparello)
>Cc: Mouli Chandramouli (moulchan); eman mailing list
>Subject: Re: [eman] new revision of eman requirements - open issue
>12.3:time series of energy/power values
>
>Hi John,
>
>We are currently not discussing optional or mandatory implementation.
>
>The question is whether or not we have a requirement for specifying a
>standard for reporting both, energy time series and power time series, or
>just one of them. What compliant devices must implement is an issue to be
>discussed later.
>
>Do I understand right that you would support a requirement for specifying
>a standard for time series of power but not for time series of energy?
>
>Thanks,
>
>    Juergen
>
>Am 26.07.2011 um 13:08 schrieb John Parello (jparello):
>
>> Hi Jeurgen,
>>
>> I tend to agree, for simple devices an energy odometer(s) as describe
>> from the comments and what I presented from the ODVA suffices.
>>
>> For time series of data like historical demand devices such as PDUs very
>> typically store this. Some our as long as a year's worth of data on the
>> device. For the very reason that Bill pointed out.
>>
>> So it would seem that a power value and an energy odometer could be a
>> required minimum and then time series of power or demand can be
>> optional.
>>
>> We specified a power value as required in the monitoring mib with time
>> series of power and demand as optional.
>>
>> Jp
>>
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
>> Juergen Quittek
>> Sent: Wednesday, July 13, 2011 5:53 AM
>> To: Mouli Chandramouli (moulchan)
>> Cc: eman mailing list
>> Subject: Re: [eman] new revision of eman requirements - open issue
>> 12.3:time series of energy/power values
>>
>> Dear Mouli,
>>
>> Thank you for commenting on this issue. I would like to have a look at
>> the following point of view:
>>
>> So far, storing time series of measurements on managed nodes is rarely
>> standardized and rarely available as implementation.
>>
>> Typically, it is the job of a network management system to collect time
>> series and store them.
>>
>> Take for example byte and packet counters at line cards. You see many
>> curves showing time series of traffic rate/volume in the Internet, but
>> almost all of them were collected at management stations or data
>> collector modules, but not within MIB modules. (Please correct me if I'm
>> wrong.)
>>
>> Now the question is: Is energy management so much different from other
>> network management tasks, that we need the rarely used mechanism of
>> storing time series in MIB modules?
>>
>> If not, it would be sufficient to just report the number of total energy
>> consumed since the last re-start as you do it with packet and byte
>> counters.
>> This would be just a single managed object to be specified and
>> implemented.
>>
>> Thanks,
>>
>>    Juergen
>>



_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman

--------------090601000603030606030107-- From bclaise@cisco.com Tue Aug 2 15:35:14 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8896B21F8669 for ; Tue, 2 Aug 2011 15:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HUEL0aFsPS8 for ; Tue, 2 Aug 2011 15:35:13 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5056121F8640 for ; Tue, 2 Aug 2011 15:35:13 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p72MVXTK011434; Wed, 3 Aug 2011 00:31:34 +0200 (CEST) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p72MVXVD007061; Wed, 3 Aug 2011 00:31:33 +0200 (CEST) Message-ID: <4E3823B0.70509@cisco.com> Date: Tue, 02 Aug 2011 18:20:00 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Mielke, William F (Bill)" References: <4E30D605.6000400@cisco.com><8F79AC58-23C4-4D5C-BB61-CADBAD084612@quittek.at><791AD3077F94194BB2BDD13565B6295D1D031EA5@DAPHNIS.office.hd><4E318194.1060506@cisco.com> <791AD3077F94194BB2BDD13565B6295D1D033326@DAPHNIS.office.hd> <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DDF2@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DDF2@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: eman mailing list Subject: Re: [eman] [EMAN-BATTERY]: power state set X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:35:14 -0000 So, as discussed during the meeting, on based on this dicussion on the list, the battery should be integrated to the framework, with its own UUID, with its own power state set/power state, and on the top of this, it should support the battery-mib. Correct? Regards, Benoit. > +1 I believe that the two sets of states are orthogonal. > > When people talk about a device charging they are simply being imprecise and conflating the two. It is an artifact of informal speech. > > William F. Mielke > Alcatel-Lucent > Distinguished Member of Technical Staff > 6200 East Broad Street > Room: 4B01-1V > Columbus, OH 43213-1530 > Email: Bill.Mielke@alcatel-lucent.com > 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 > > > >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On >> Behalf Of Rolf Winter >> Sent: Thursday, July 28, 2011 12:50 PM >> To: John Parello (jparello); Bruce Nordman; Benoit Claise (bclaise) >> Cc: eman mailing list >> Subject: Re: [eman] [EMAN-BATTERY]: power state set >> >> I think these states are completely independent. Take the >> three power states on, sleep, off and the charging states >> charging, discharging, maintaining charge. Which ones are >> dependent on each other? I think any of these combinations >> work. Answering Benoit's question, I believe these are orthogonal. >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >> Road, London W3 6BL | Registered in England 2832014 >> >> >>> -----Original Message----- >>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] >> On Behalf Of >>> John Parello (jparello) >>> Sent: Donnerstag, 28. Juli 2011 18:29 >>> To: Bruce Nordman; Benoit Claise (bclaise) >>> Cc: eman mailing list >>> Subject: Re: [eman] [EMAN-BATTERY]: power state set >>> >>> >>> OK but thinking about it. I'm not sure the battery state is >> independent >>> of the device in all cases. >>> >>> Tablet example. We refer to them as on, off, charging, etc. We don't >>> say the device is on and the battery is off. It's merged. >>> >>> So while I agree they can be separate we have to allow for the case >>> when they are combined as well. >>> >>> Jp >>> >>> >>> >>> -----Original Message----- >>> From: eman-bounces@ietf.org on behalf of Bruce Nordman >>> Sent: Thu 7/28/2011 9:12 AM >>> To: Benoit Claise (bclaise) >>> Cc: eman mailing list >>> Subject: Re: [eman] [EMAN-BATTERY]: power state set >>> >>> On Thu, Jul 28, 2011 at 11:34 AM, Benoit Claise >>> wrote: >>> >>>> Rolf, >>>> >>>> +1 >>>>> The problem is that the power states of a "regular" >> device conflate >>>>> operational state information and energy related state >> information. >>>>> The battery charging state does not I in the same way. >>>>> >>>> This is actually my question. >>>> Is the battery power state set orthogonal to the other 3 >> power state >>> sets? >>> A power state is (in principle) something independent of >> the device (or >>> component) type. >>> It is universal. >>> >>> The battery state is specific to a single type of component >>> >>> I can imagine setting a power state for a battery to "off": to >>> electrically disconnect it to prevent charging or discharging (this >>> might be done prior to removal for example). In this case, >> a battery >>> would want both a power state and a charging state (the power state >>> variable would be in the other MIB so not added to the Battery MIB). >>> >>> If new battery states might be needed, how about simply having a >>> registry of the current states so that individual states >> could be added, >>> rather than entire new series as we have with power states. >> This would >>> give flexibility to add in future with minimal complexity, and not >>> conflate with power states. >>> >>> --Bruce >>> >>>> Regards, Benoit. >>>> >>>> ... >>>> >>> -- >>> *Bruce Nordman* >>> Lawrence Berkeley National Laboratory >>> eetd.lbl.gov/ea/nordman >>> BNordman@LBL.gov >>> 510-486-7089 >>> m: 510-501-7943 >>> >>> >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >> > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From bclaise@cisco.com Tue Aug 2 15:55:46 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457A311E80ED for ; Tue, 2 Aug 2011 15:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2nA7QLu9u+R for ; Tue, 2 Aug 2011 15:55:45 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4183711E80EC for ; Tue, 2 Aug 2011 15:55:45 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p72MViWK011483 for ; Wed, 3 Aug 2011 00:31:44 +0200 (CEST) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p72MVW0l007025; Wed, 3 Aug 2011 00:31:32 +0200 (CEST) Message-ID: <4E38229F.4020504@cisco.com> Date: Tue, 02 Aug 2011 18:15:27 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "John Parello (jparello)" , "eman@ietf.org" , me References: <20110728164503.GA30392@elstar.local> <20110728184235.GD30565@elstar.local> <20110728212016.GA31474@elstar.local> In-Reply-To: <20110728212016.GA31474@elstar.local> Content-Type: multipart/alternative; boundary="------------000400080709020708030206" Subject: Re: [eman] iana powerstate tc proposal X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:55:46 -0000 This is a multi-part message in MIME format. --------------000400080709020708030206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 28/07/2011 23:20, Juergen Schoenwaelder wrote: > On Thu, Jul 28, 2011 at 10:47:40PM +0200, John Parello (jparello) wrote: > >> The code (value& 0xff) is not that complex. What I find complex is >> the following: >> >> - I always have to poll two OIDs to retrieve the power state. This >> adds runtime verbosity and overhead. >> >> [jp] If you define a numeric value to each set then this is an index to a state series subtree so you don't have to poll twice It would be in a the tree. If you keep it the way you have it you have to poll the base number first remember the series and then know to avoid or use that range to find out what is supported. With a seperate power state set number it's implicit in the data. You just traverse or get the entire table. > But that particular table design I think you are refering to is > awkward in the first place since it indexes and thus duplicates > objects that are really not specific to the set. Point taken. Will be corrected. > That said, once > stored, a single integer is simply self-contained (and you even get a > meaningful descriptor with typical generic SNMP tools). I still don't get your argument about two OIDs to retrieve the power state. pmPowerEntry OBJECT-TYPE SYNTAX PmPowerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes the power usage of a Power Monitor." INDEX { pmPowerIndex, pmPowerStateSetIndex} ::= { pmPowerTable 1 } PmPowerEntry ::= SEQUENCE { ... pmPowerAdminState Integer32, pmPowerOperState Integer32, I will be polling pmPowerAdminState.pmPowerIndex.pmPowerStateSetIndex to get the value of the pmPowerAdminState > >> - I need to implement and enforce atomic sets with two varbinds in >> order to change from a value in one power state set to a value in a >> different power state set. >> >> [jp] If you have an index for the set first you get the same ability > Well, not completely true. If you have dmtf off and you want to change > to eman on, how does set look like? I know that you assume magic > implementation specific translations between the power state sets, > which I find ugly. Too much magic if our goal is interoperability. Practically, the ENMS will do a discovery of the possible power states within the power state set, with the snmpwalk of: pmPowerStateTable(2) | +--pmPowerStateEntry(1) | | [pmPowerIndex, | | pmPowerStateSet, | | pmpowerStateIndex] | +-- --- Integer32 pmPowerStateIndex(1) | +-- r-n Interger32 pmPowerStateMaxPower (2) | +-- r-n UnitMultiplier | pmPowerStatePowerUnitMultiplier (3) | +-- r-n TimeTicks pmPowerStateTotalTime(4) | +-- r-n Counter64 pmPowerStateEnterCount(5) Actually, I even envision the ENMS asking a device: do you support THIS Power State Set, by doing a snmpwalk on pmPowerStateTable.pmPowerStateEntry.pmPowerIndex.pmPowerStateSet From there, practically, one ENMS will manager (configure and monitor) _a single_ Power State Set for a single monitor. SNMPset of pmPowerAdminState.pmPowerIndex.pmPowerStateSetIndex to If the easy translation was possible between Power State Set/Power States, then we would have defined a single Power State Set. Regards, Benoit (as a contributor) >> Compared to this, doing (value& 0xff) or (value>> 8) is rather >> cheap. And in addition, with this this appraoch, >> >> - I have _all_ IANA maintained power states defined in a machine >> readable format, something that can drive tools and automation. >> >> [jp] Having an index to the series first is still machine >> readable. > The value is machine readable. There is not machine readable > definition of the power state definitions themself. > >> Also BTW you are limiting power states to 256. There was lengthy >> discussions on not limiting it. I can see a series with 1000 as >> percentage increments. > We have 32 bits to play with. If 8 bits are not enough, we pick > 16. Gives you ~65000 power states. Still not enough? We are after all > talking about _states_. > > /js > --------------000400080709020708030206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 28/07/2011 23:20, Juergen Schoenwaelder wrote: 
On Thu, Jul 28, 2011 at 10:47:40PM +0200, John Parello (jparello) wrote:


The code (value & 0xff) is not that complex. What I find complex is
the following:

- I always have to poll two OIDs to retrieve the power state. This
  adds runtime verbosity and overhead.

[jp] If you define a numeric value to each set then this is an index to a state series subtree so you don't have to poll twice It would be in a the tree. If you keep it the way you have it you have to poll the base number first remember the series and then know to avoid or use that range to find out what is supported. With a seperate power state set number it's implicit in the data.  You just traverse or get the entire table.

But that particular table design I think you are refering to is
awkward in the first place since it indexes and thus duplicates
objects that are really not specific to the set.
Point taken. Will be corrected.
That said, once
stored, a single integer is simply self-contained (and you even get a
meaningful descriptor with typical generic SNMP tools).
I still don't get your argument about two OIDs to retrieve the power state.
        pmPowerEntry OBJECT-TYPE
            SYNTAX          PmPowerEntry
            MAX-ACCESS      not-accessible
            STATUS          current
            DESCRIPTION
               "An entry describes the power usage of a Power Monitor."
            INDEX           { pmPowerIndex, pmPowerStateSetIndex}
            ::= { pmPowerTable  1 }
        
        PmPowerEntry ::= SEQUENCE {
                ...
                pmPowerAdminState               Integer32,
                pmPowerOperState                 Integer32,

I will be polling pmPowerAdminState.pmPowerIndex.pmPowerStateSetIndex to get the value of the pmPowerAdminState
 

- I need to implement and enforce atomic sets with two varbinds in
  order to change from a value in one power state set to a value in a
  different power state set.

[jp] If you have an index for the set first you get the same ability

Well, not completely true. If you have dmtf off and you want to change
to eman on, how does set look like? I know that you assume magic
implementation specific translations between the power state sets,
which I find ugly. Too much magic if our goal is interoperability.
Practically, the ENMS will do a discovery of the possible power states within the power state set, with the snmpwalk of:
pmPowerStateTable(2)
          |      +--pmPowerStateEntry(1)
          |      |     [pmPowerIndex, 
          |      |      pmPowerStateSet, 
          |      |      pmpowerStateIndex]
          |      +-- --- Integer32       pmPowerStateIndex(1)
          |      +-- r-n Interger32      pmPowerStateMaxPower (2)
          |      +-- r-n UnitMultiplier 
          |                  pmPowerStatePowerUnitMultiplier (3)
          |      +-- r-n TimeTicks       pmPowerStateTotalTime(4)
          |      +-- r-n Counter64       pmPowerStateEnterCount(5)

Actually, I even envision the ENMS asking a device: do you support THIS Power State Set, by doing a snmpwalk on pmPowerStateTable.pmPowerStateEntry.pmPowerIndex.pmPowerStateSet

From there, practically, one ENMS will manager (configure and monitor) a single Power State Set for a single monitor. SNMPset of pmPowerAdminState.pmPowerIndex.pmPowerStateSetIndex to <value>

If the easy translation was possible between Power State Set/Power States, then we would have defined a single Power State Set.

Regards, Benoit (as a contributor)
Compared to this, doing (value & 0xff) or (value >> 8) is rather
cheap. And in addition, with this this appraoch,

- I have _all_ IANA maintained power states defined in a machine
  readable format, something that can drive tools and automation.

[jp] Having an index to the series first is still machine
readable. 

The value is machine readable. There is not machine readable
definition of the power state definitions themself.


Also BTW you are limiting power states to 256. There was lengthy
discussions on not limiting it. I can see a series with 1000 as
percentage increments.

We have 32 bits to play with. If 8 bits are not enough, we pick
16. Gives you ~65000 power states. Still not enough? We are after all
talking about _states_.

/js

--------------000400080709020708030206-- From bclaise@cisco.com Tue Aug 2 15:55:46 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B366D11E80EC for ; Tue, 2 Aug 2011 15:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkXFdAdFjNt6 for ; Tue, 2 Aug 2011 15:55:46 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 128B811E80E8 for ; Tue, 2 Aug 2011 15:55:45 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p72MVV6R011426; Wed, 3 Aug 2011 00:31:31 +0200 (CEST) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p72MVQdX006945; Wed, 3 Aug 2011 00:31:26 +0200 (CEST) Message-ID: <4E3815B9.6040703@cisco.com> Date: Tue, 02 Aug 2011 17:20:25 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: eman mailing list Subject: Re: [eman] new revision of eman requirements - Requirement 7.2 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:55:46 -0000 Hi Juergen, That would be better to group the requirements in 7.x somehow logically, because, to be frank, I missed the 7.6. I mean going from 7.2 to 7.6, you have completely different requirement interleaved. We should group 7.2 and 7.6 Regards, Benoit (as a contributor) > Hi Mouli, > > All that you miss is in requirement 7.6. > > Thanks, > > Juergen > > > Am 27.07.2011 um 00:16 schrieb Mouli Chandramouli (moulchan): > >> Hi Juergen, >> >> Requirement 7.2. Identity of other powered entities on which is reported >> >> Focuses on the Parent having knowledge of the children. >> >> It is also useful to add a requirement - in the other direction also. >> >> The energy management standard must provide means for specifying the >> identity of the powered entity >> Which shall monitor and report the power consumption of a given powered >> entity. >> >> Thanks >> Mouli >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From bschoening@noveda.com Tue Aug 2 18:29:34 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A23711E8081 for ; Tue, 2 Aug 2011 18:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0oV1y1262w2 for ; Tue, 2 Aug 2011 18:29:30 -0700 (PDT) Received: from cal3-mh483-a.smtproutes.com (cal3-mh483-a.smtproutes.com [208.70.89.243]) by ietfa.amsl.com (Postfix) with ESMTP id 192A25E8007 for ; Tue, 2 Aug 2011 18:29:29 -0700 (PDT) X-Katharion-ID: 1312334923.27521.cal3-mh483 Received: from ex01.noveda.com ([66.198.105.170]) by cal3-mh483.smtproutes.com [(208.70.89.157)] with ESMTP via TCP; 02 Aug 2011 18:28:43 -0700 Received: from EX01.noveda.com ([::1]) by ex01.noveda.com ([::1]) with mapi; Tue, 2 Aug 2011 21:28:42 -0400 From: Brad Schoening To: Benoit Claise Thread-Topic: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values Thread-Index: AQHMTGdebe5iwHf9hECy9RtMmcgg7pUCCSPVgAABTtCAAELfkIAHqJwAgABTndA= Date: Wed, 3 Aug 2011 01:28:39 +0000 Message-ID: <22B2909DCC2E62418BE369A1F10488994B7ABC78@ex01.noveda.com> References: <9C329342B62B87498B92834DEC9FF51E0D6187D8@fig.raritan.com> <22B2909DCC2E62418BE369A1F10488994B79886F@ex01.noveda.com> <4E381298.2020500@cisco.com> In-Reply-To: <4E381298.2020500@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_22B2909DCC2E62418BE369A1F10488994B7ABC78ex01novedacom_" MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 01:29:34 -0000 --_000_22B2909DCC2E62418BE369A1F10488994B7ABC78ex01novedacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Energy & demand are an essential measurement of smart meters and similar de= vices. It's usually computed at the meter by sampling at the millisecond l= evel. Sampling kW by polling and then averaging values will never be close= to an actual metered value. The draft-claise-energy-monitoring-mib has su= ch a table based upon IEC 61850's demand measurement table. It can be empt= y, since device that don't support kWh aren't required to implement it. Existing Building Management Systems and Energy Management Systems already = use the IEC 61850 data model, so by leveraging this model our data can be u= sed and shared with these existing management systems. When pmEnergyParametersIntervalMode =3D 'total' the table works as an odome= ter. Regards, Brad From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, August 02, 2011 11:07 AM To: Brad Schoening Cc: Michael Suchoff; John Parello (jparello); Juergen Quittek; Juergen Quit= tek; eman mailing list Subject: Re: [eman] new revision of eman requirements - open issue 12.3:tim= eseries of energy/power values Dear all, Trying to combine all the different arguments (discussed on the mailing lis= t and during the meeting), why do we have to have to specify which time ser= ies the EMAN standard must support as a pull model? Why not have a generic requirement, such as: The EMAN tandard must not limit time series (for example Power, Energy, Dem= and) to a pull mechanism; the push mechanism must be considered. Regards, Benoit. An energy time series is can be reported as an odometer reading. I think y= ou'll need to be adaptable to allow either an absolute value like instantan= eous kW, kWh over a sample period or odometer sampling for kWh. From: eman-bounces@ietf.org [mailto:eman-boun= ces@ietf.org] On Behalf Of Michael Suchoff Sent: Thursday, July 28, 2011 2:25 PM To: John Parello (jparello); Juergen Quittek; Juergen Quittek Cc: eman mailing list Subject: Re: [eman] new revision of eman requirements - open issue 12.3:tim= eseries of energy/power values I would add current to the series as well. Most AC devices presently don't= have circuitry to report power or energy, they simply report AC current. = Also, for capacity planning, current is very useful (it is current that lim= its how many devices can be placed on an electrical branch circuit or PDU -= not power). Ideally, the time series would be structured as a table with the columns be= ing measurements (i.e. column 1 =3D time stamp, 2 =3D power, 3 =3D energy, = 4 =3D current, 5 =3D voltage, etc). The columns could be partitioned into = SNMP augmented tables (tables sharing same index). This would allow easy a= ddition of new columns for products that offer more information. I don't see reason for demand as a special table. Demand (watts) is easily= computed from the energy readings. For example, if kWh =3D 1000 at 1PM an= d kWh =3D 2000 at 1:15PM, then average power over the 15 minute interval is= (2000kWh - 1000kWh) * 60minutes/15minutes =3D 4kW. Doesn't it seem a lot = simpler for management program to compute demand based on polled energy rea= dings (i.e. a simple SQL query) - rather than having to write a procedure t= o configure the power agent to perform demand computations? ________________________________ From: eman-bounces@ietf.org [mailto:eman-boun= ces@ietf.org] On Behalf Of John Parello (jparello) Sent: Thursday, July 28, 2011 2:06 PM To: Juergen Quittek; Juergen Quittek Cc: eman mailing list Subject: Re: [eman] new revision of eman requirements - open issue 12.3:tim= eseries of energy/power values I can't vote no when there'sand or and more on the bill. I don't see any reason to restrict to just power. IMO a series of power, en= ergy, and demand is useful if a device can support it. So no don't restrict it to just power and please allow series for power, de= mand, and energy Jp -----Original Message----- From: Juergen Quittek [mailto:Quittek@neclab.eu] Sent: Wed 7/27/2011 7:13 AM To: John Parello (jparello); Juergen Quittek Cc: eman mailing list Subject: Re: [eman] new revision of eman requirements - open issue 12.3:tim= e series of energy/power values Hi John, my Question was "Do I understand right that you would support a requirement for specifying a standard for time series of power but not for time series of energy?" I take you answer as a no. This would mean we keep both requirements (time series of power and time series of energy). Is this correct? Thanks, Juergen On 26.07.11 18:10, "John Parello (jparello)" wrote: > >Hi Jeurgen, > >We need to express power, energy as a measurement (scalar). > >For time series (vector) IMO having the capability of providing power >over time series (which is demand) or energy over time is valuable and >should not be excluded. Even though for energy an odometer can suffice I >see no need to prevent this for devices that have this capability. > > >Please take a look at the draft-claise-energy-monitoring-mib. I think >they did a good job of providing time series modeling that covers this. > >thanks >Jp > > > > > > > > >-----Original Message----- >From: Juergen Quittek [mailto:ietf@quittek.at] >Sent: Tue 7/26/2011 12:39 PM >To: John Parello (jparello) >Cc: Mouli Chandramouli (moulchan); eman mailing list >Subject: Re: [eman] new revision of eman requirements - open issue >12.3:time series of energy/power values > >Hi John, > >We are currently not discussing optional or mandatory implementation. > >The question is whether or not we have a requirement for specifying a >standard for reporting both, energy time series and power time series, or >just one of them. What compliant devices must implement is an issue to be >discussed later. > >Do I understand right that you would support a requirement for specifying >a standard for time series of power but not for time series of energy? > >Thanks, > > Juergen > >Am 26.07.2011 um 13:08 schrieb John Parello (jparello): > >> Hi Jeurgen, >> >> I tend to agree, for simple devices an energy odometer(s) as describe >> from the comments and what I presented from the ODVA suffices. >> >> For time series of data like historical demand devices such as PDUs very >> typically store this. Some our as long as a year's worth of data on the >> device. For the very reason that Bill pointed out. >> >> So it would seem that a power value and an energy odometer could be a >> required minimum and then time series of power or demand can be >> optional. >> >> We specified a power value as required in the monitoring mib with time >> series of power and demand as optional. >> >> Jp >> >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-b= ounces@ietf.org] On Behalf Of >> Juergen Quittek >> Sent: Wednesday, July 13, 2011 5:53 AM >> To: Mouli Chandramouli (moulchan) >> Cc: eman mailing list >> Subject: Re: [eman] new revision of eman requirements - open issue >> 12.3:time series of energy/power values >> >> Dear Mouli, >> >> Thank you for commenting on this issue. I would like to have a look at >> the following point of view: >> >> So far, storing time series of measurements on managed nodes is rarely >> standardized and rarely available as implementation. >> >> Typically, it is the job of a network management system to collect time >> series and store them. >> >> Take for example byte and packet counters at line cards. You see many >> curves showing time series of traffic rate/volume in the Internet, but >> almost all of them were collected at management stations or data >> collector modules, but not within MIB modules. (Please correct me if I'm >> wrong.) >> >> Now the question is: Is energy management so much different from other >> network management tasks, that we need the rarely used mechanism of >> storing time series in MIB modules? >> >> If not, it would be sufficient to just report the number of total energy >> consumed since the last re-start as you do it with packet and byte >> counters. >> This would be just a single managed object to be specified and >> implemented. >> >> Thanks, >> >> Juergen >> _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman --_000_22B2909DCC2E62418BE369A1F10488994B7ABC78ex01novedacom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [eman] new revision of eman requirements - o= pen issue 12.3:time series of energy/power values

Energy & demand are an essential measurement of smart meters and sim= ilar devices.  It’s usually computed at the meter by sampling at= the millisecond level.  Sampling kW by polling and then averaging val= ues will never be close to an actual metered value.  The draft-claise-= energy-monitoring-mib has such a table based upon IEC 61850’s demand = measurement table.  It can be empty, since device that don’t sup= port kWh aren’t required to implement it.

 

E= xisting Building Management Systems and Energy Management Systems already u= se the IEC 61850 data model, so by leveraging this model our data can be us= ed and shared with these existing management systems.

=

 

= When pmEnergyParametersIntervalMode =3D ‘total’ the t= able works as an odometer.

&nb= sp;

Regards,

 

Brad

 =

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, August= 02, 2011 11:07 AM
To: Brad Schoening
Cc: Michael Sucho= ff; John Parello (jparello); Juergen Quittek; Juergen Quittek; eman mailing= list
Subject: Re: [eman] new revision of eman requirements - ope= n issue 12.3:timeseries of energy/power values

<= /div>

 

Dear al= l,

Trying to combine all the different arguments (discussed on the m= ailing list and during the meeting), why do we have to have to specify whic= h time series the EMAN standard must support as a pull model?

Why n= ot have a generic requirement, such as:
The EMAN tandard must not limit = time series (for example Power, Energy, Demand) to a pull mechanism; the pu= sh mechanism must be considered.

Regards, Benoit.


An energy time series is can be reporte= d as an odometer reading.  I think you’ll need to be adaptable t= o allow either an absolute value like instantaneous kW, kWh over a sample p= eriod or odometer sampling for kWh.

 

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On= Behalf Of Michael Suchoff
Sent: Thursday, July 28, 2011 2:25= PM
To: John Parello (jparello); Juergen Quittek; Juergen Quittek=
Cc: eman mailing list
Subject: Re: [eman] new revision= of eman requirements - open issue 12.3:timeseries of energy/power values

 

<= p class=3DMsoNormal>I would add current to the series as well.  Most= AC devices presently don’t have circuitry to report power or energy,= they simply report AC current.  Also, for capacity planning, current = is very useful (it is current that limits how many devices can be placed on= an electrical branch circuit or PDU – not power).<= /p>

 

= Ideally, the time series would be structured as a table with the columns = being measurements (i.e. column 1 =3D time stamp, 2 =3D power, 3 =3D energy= , 4 =3D current, 5 =3D voltage, etc).  The columns could be partitione= d into SNMP augmented tables (tables sharing same index).  This would = allow easy addition of new columns for products that offer more information= .

 

<= p class=3DMsoNormal>I don’t see reason for demand as a special tabl= e.  Demand (watts) is easily computed from the energy readings.  = For example, if kWh =3D 1000 at 1PM and kWh =3D 2000 at 1:15PM, then averag= e power over the 15 minute interval is (2000kWh – 1000kWh) * 60minute= s/15minutes =3D 4kW.  Doesn’t it seem a lot simpler for manageme= nt program to compute demand based on polled energy readings (i.e. a simple= SQL query) – rather than having to write a procedure to configure th= e power agent to perform demand computations?

 

From: eman-bounces@ietf.org [mai= lto:eman-bounces@ietf.org] On Behalf Of John Parello (jparello)<= br>Sent: Thursday, July 28, 2011 2:06 PM
To: Juergen Quitt= ek; Juergen Quittek
Cc: eman mailing list
Subject: Re: = [eman] new revision of eman requirements - open issue 12.3:timeseries of en= ergy/power values

 

 

I can't vote  no when th= ere'sand or and more on the bill.

I don't see any reason to restrict= to just power. IMO a series of power, energy, and demand is useful if a de= vice can support it.

So no don't restrict it to just power and pleas= e allow series for power, demand, and energy

Jp


-----Orig= inal Message-----
From: Juergen Quittek [mailto:Quittek@neclab.eu]
Sent: Wed 7/27/2011 7:13 AM
To: J= ohn Parello (jparello); Juergen Quittek
Cc: eman mailing list
Subject= : Re: [eman] new revision of eman requirements - open issue 12.3:time serie= s of energy/power values

Hi John,

my Question was

&quo= t;Do I understand right that you would support a requirement for specifying=
a standard for time series of power but not for time series of energy?&= quot;


I take you answer as a no. This would mean we keep both re= quirements (time
series of power and time series of energy). Is this cor= rect?

Thanks,

    Juergen


On 26.07.= 11 18:10, "John Parello (jparello)" <jparello@cisco.com> wrote:

>
>Hi Jeurge= n,
>
>We need to express power, energy as a measurement (scalar= ).
>
>For time series (vector) IMO having the capability of pro= viding power
>over time series (which is demand) or energy over time = is valuable and
>should not be excluded.  Even though for energy= an odometer can suffice I
>see no need to prevent this for devices t= hat have this capability.
>
>
>Please take a look at the = draft-claise-energy-monitoring-mib.  I think
>they did a good jo= b of providing time series modeling that covers this.
>
>thanks=
>Jp
>
>
>
>
>
>
>
><= br>>-----Original Message-----
>From: Juergen Quittek [mailto:ietf@quittek.at]
>Sent: Tue 7/26/2= 011 12:39 PM
>To: John Parello (jparello)
>Cc: Mouli Chandramou= li (moulchan); eman mailing list
>Subject: Re: [eman] new revision of= eman requirements - open issue
>12.3:time series of energy/power val= ues
>
>Hi John,
>
>We are currently not discussing = optional or mandatory implementation.
>
>The question is whethe= r or not we have a requirement for specifying a
>standard for reporti= ng both, energy time series and power time series, or
>just one of th= em. What compliant devices must implement is an issue to be
>discusse= d later.
>
>Do I understand right that you would support a requ= irement for specifying
>a standard for time series of power but not f= or time series of energy?
>
>Thanks,
>
>  = ;  Juergen
>
>Am 26.07.2011 um 13:08 schrieb John Parello = (jparello):
>
>> Hi Jeurgen,
>>
>> I tend = to agree, for simple devices an energy odometer(s) as describe
>> = from the comments and what I presented from the ODVA suffices.
>><= br>>> For time series of data like historical demand devices such as = PDUs very
>> typically store this. Some our as long as a year's wo= rth of data on the
>> device. For the very reason that Bill pointe= d out.
>>
>> So it would seem that a power value and an e= nergy odometer could be a
>> required minimum and then time series= of power or demand can be
>> optional.
>>
>> We= specified a power value as required in the monitoring mib with time
>= ;> series of power and demand as optional.
>>
>> Jp>>
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of>> Juergen Quittek
>> Sent: Wednesday, July 13, 2011 5:53 = AM
>> To: Mouli Chandramouli (moulchan)
>> Cc: eman maili= ng list
>> Subject: Re: [eman] new revision of eman requirements -= open issue
>> 12.3:time series of energy/power values
>>=
>> Dear Mouli,
>>
>> Thank you for commenting o= n this issue. I would like to have a look at
>> the following poin= t of view:
>>
>> So far, storing time series of measureme= nts on managed nodes is rarely
>> standardized and rarely availabl= e as implementation.
>>
>> Typically, it is the job of a = network management system to collect time
>> series and store them= .
>>
>> Take for example byte and packet counters at line= cards. You see many
>> curves showing time series of traffic rate= /volume in the Internet, but
>> almost all of them were collected = at management stations or data
>> collector modules, but not withi= n MIB modules. (Please correct me if I'm
>> wrong.)
>>>> Now the question is: Is energy management so much different from = other
>> network management tasks, that we need the rarely used me= chanism of
>> storing time series in MIB modules?
>>
&= gt;> If not, it would be sufficient to just report the number of total e= nergy
>> consumed since the last re-start as you do it with packet= and byte
>> counters.
>> This would be just a single man= aged object to be specified and
>> implemented.
>>
>= ;> Thanks,
>>
>>    Juergen
>>= 




=
_______________________________________________
eman m=
ailing list
eman@ietf=
.org
https://www.ietf.org/mailman/listinfo/eman
 

= --_000_22B2909DCC2E62418BE369A1F10488994B7ABC78ex01novedacom_-- From bschoening@noveda.com Tue Aug 2 19:02:01 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4295D11E8081 for ; Tue, 2 Aug 2011 19:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m86hkeaANAmg for ; Tue, 2 Aug 2011 19:02:00 -0700 (PDT) Received: from cal3-mh482-a.smtproutes.com (cal3-mh482-a.smtproutes.com [208.70.89.239]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8B421F899F for ; Tue, 2 Aug 2011 19:02:00 -0700 (PDT) X-Katharion-ID: 1312336917.30540.cal3-mh482 Received: from ex01.noveda.com ([66.198.105.170]) by cal3-mh482.smtproutes.com [(208.70.89.156)] with ESMTP via TCP; 02 Aug 2011 19:01:57 -0700 Received: from EX01.noveda.com ([::1]) by ex01.noveda.com ([::1]) with mapi; Tue, 2 Aug 2011 22:01:57 -0400 From: Brad Schoening To: Juergen Schoenwaelder , "eman@ietf.org" Thread-Topic: [eman] iana powerstate tc proposal Thread-Index: AQHMTUXAYR9DqA881kq9/zpdhjaDOJUKYvIw Date: Wed, 3 Aug 2011 02:01:55 +0000 Message-ID: <22B2909DCC2E62418BE369A1F10488994B7ABCD2@ex01.noveda.com> References: <20110728164503.GA30392@elstar.local> In-Reply-To: <20110728164503.GA30392@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] iana powerstate tc proposal X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 02:02:01 -0000 Hi Juergen, Just wondering if it would be more relevant to use ECMA states in IANA inst= ead of ieee1621? ECMA is newer, with the same basic states as 1621 but has= additional modes that are relevant to contemporary hardware: ECMA: Off Sleep WoL Sleep=20 ShortIdle LongIdle Active 1621: Off Sleep On http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-383.pdf -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Jue= rgen Schoenwaelder Sent: Thursday, July 28, 2011 12:45 PM To: eman@ietf.org Subject: [eman] iana powerstate tc proposal Hi, here is a proposal for an IANA maintained power state textual convention. T= here are of course other ways of doing this but I thought a concrete propos= al might help the discussion. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From fletchj@us.ibm.com Tue Aug 2 21:10:14 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B04521F84F9 for ; Tue, 2 Aug 2011 21:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2gntdJ4vKlN for ; Tue, 2 Aug 2011 21:10:13 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by ietfa.amsl.com (Postfix) with ESMTP id D591711E8125 for ; Tue, 2 Aug 2011 21:10:13 -0700 (PDT) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p733ox56028767 for ; Tue, 2 Aug 2011 21:50:59 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p734AFvh188890 for ; Tue, 2 Aug 2011 22:10:16 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p734AFCX023986 for ; Tue, 2 Aug 2011 22:10:15 -0600 Received: from d03nm120.boulder.ibm.com (d03nm120.boulder.ibm.com [9.17.195.146]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p734AFrR023974 for ; Tue, 2 Aug 2011 22:10:15 -0600 Auto-Submitted: auto-generated From: Jim Fletcher To: eman@ietf.org Message-ID: Date: Tue, 2 Aug 2011 22:10:14 -0600 X-MIMETrack: Serialize by Router on D03NM120/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 08/02/2011 22:10:14 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBF272DF856F8D8f9e8a93df938690918c08BBF272DF856F8D" Content-Disposition: inline Subject: [eman] AUTO: *** NOTE: Jim Fletcher is on vacation with no consistent access to phone or email until August 12th (returning 08/11/2011) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 04:10:14 -0000 --0__=08BBF272DF856F8D8f9e8a93df938690918c08BBF272DF856F8D Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 08/11/2011. For management needs contact Jim Crosskey For calendar needs, contact Keia Parker Note: This is an automated response to your message "eman Digest, Vol = 13, Issue 1" sent on 8/2/11 16:35:15. This is the only notification you will receive while this person is awa= y.= --0__=08BBF272DF856F8D8f9e8a93df938690918c08BBF272DF856F8D Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 08/11/2011.

For management needs contact Jim Crosskey
For calendar needs, contact Keia Parker


Note: This is an automated re= sponse to your message "eman Digest, V= ol 13, Issue 1" sent= on 8/2/11 16:35:15.

This is the only notification= you will receive while this person is away.= --0__=08BBF272DF856F8D8f9e8a93df938690918c08BBF272DF856F8D-- From j.schoenwaelder@jacobs-university.de Tue Aug 2 21:54:44 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1D211E8087 for ; Tue, 2 Aug 2011 21:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.078 X-Spam-Level: X-Spam-Status: No, score=-103.078 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhNTb6J2GU6J for ; Tue, 2 Aug 2011 21:54:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4355611E8084 for ; Tue, 2 Aug 2011 21:54:42 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B6A320BEA; Wed, 3 Aug 2011 06:54:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sP1s4h7IvrBj; Wed, 3 Aug 2011 06:54:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F222120BE7; Wed, 3 Aug 2011 06:54:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 69CF11A229EA; Wed, 3 Aug 2011 06:54:50 +0200 (CEST) Date: Wed, 3 Aug 2011 06:54:49 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20110803045449.GA43357@elstar.local> Mail-Followup-To: Benoit Claise , "John Parello (jparello)" , "eman@ietf.org" References: <20110728164503.GA30392@elstar.local> <20110728184235.GD30565@elstar.local> <20110728212016.GA31474@elstar.local> <4E38229F.4020504@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E38229F.4020504@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "eman@ietf.org" Subject: Re: [eman] iana powerstate tc proposal X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 04:54:44 -0000 On Tue, Aug 02, 2011 at 06:15:27PM +0200, Benoit Claise wrote: > >That said, once > >stored, a single integer is simply self-contained (and you even get a > >meaningful descriptor with typical generic SNMP tools). > I still don't get your argument about two OIDs to retrieve the power state. > pmPowerEntry OBJECT-TYPE > SYNTAX PmPowerEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry describes the power usage of a Power Monitor." > INDEX { pmPowerIndex, pmPowerStateSetIndex} > ::= { pmPowerTable 1 } > > PmPowerEntry ::= SEQUENCE { > ... > pmPowerAdminState Integer32, > pmPowerOperState Integer32, > > I will be polling > pmPowerAdminState.pmPowerIndex.pmPowerStateSetIndex to get the value > of the pmPowerAdminState And the NMS will display that the power monitor #1 is in the power state 42 of the power state set 0x0a. If you store the state, you actually have to store two values. Yes, you make the set atomic by putting the set into the INDEX. But that does not address other issues nor does it lead to simplicity. > >>- I need to implement and enforce atomic sets with two varbinds in > >> order to change from a value in one power state set to a value in a > >> different power state set. > >> > >>[jp] If you have an index for the set first you get the same ability > >Well, not completely true. If you have dmtf off and you want to change > >to eman on, how does set look like? I know that you assume magic > >implementation specific translations between the power state sets, > >which I find ugly. Too much magic if our goal is interoperability. > Practically, the ENMS will do a discovery of the possible power > states within the power state set, with the snmpwalk of: > pmPowerStateTable(2) > | +--pmPowerStateEntry(1) > | | [pmPowerIndex, > | | pmPowerStateSet, > | | pmpowerStateIndex] > | +-- --- Integer32 pmPowerStateIndex(1) > | +-- r-n Interger32 pmPowerStateMaxPower (2) > | +-- r-n UnitMultiplier > | pmPowerStatePowerUnitMultiplier (3) > | +-- r-n TimeTicks pmPowerStateTotalTime(4) > | +-- r-n Counter64 pmPowerStateEnterCount(5) I believe it is counter productive for the goal of interoperability to have everybody support his own power state set and to make the values somehow dynamically discoverable. I thought this WG had reached agreement to have a small set of power states/sets registered with IANA. > Actually, I even envision the ENMS asking a device: do you support > THIS Power State Set, by doing a snmpwalk on > pmPowerStateTable.pmPowerStateEntry.pmPowerIndex.pmPowerStateSet > > From there, practically, one ENMS will manager (configure and > monitor) _a single_ Power State Set for a single monitor. SNMPset of > pmPowerAdminState.pmPowerIndex.pmPowerStateSetIndex to > > If the easy translation was possible between Power State Set/Power > States, then we would have defined a single Power State Set. But your design aims at reporting a certain true state of the device according to different sets concurrently - so you assume there is a translation which is implementation dependent, that is every device can translate as it likes to do it. Not sure how this really helps with interoperability. (And the same goes to proposals where the power states are expected to be a series with 1000 as percentage increments as mentioned previously - this looks to me like a fine grained control knob and not a power state.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Quittek@neclab.eu Wed Aug 3 00:18:09 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F5E21F8764 for ; Wed, 3 Aug 2011 00:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sriLXV4IxMIy for ; Wed, 3 Aug 2011 00:18:08 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 504B021F8757 for ; Wed, 3 Aug 2011 00:18:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 481632800032B; Wed, 3 Aug 2011 09:18:18 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bh9E297ax8YO; Wed, 3 Aug 2011 09:18:18 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 2D39228000198; Wed, 3 Aug 2011 09:18:03 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.20]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Wed, 3 Aug 2011 09:18:03 +0200 From: Juergen Quittek To: Benoit Claise , Juergen Quittek Thread-Topic: [eman] new revision of eman requirements - Requirement 7.2 Thread-Index: AQHMTGRKCCt98gb4LUiNmOnN3iKrJZUJlRiAgAEtEYA= Date: Wed, 3 Aug 2011 07:18:01 +0000 Message-ID: In-Reply-To: <4E3815B9.6040703@cisco.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [10.1.2.219] Content-Type: text/plain; charset="us-ascii" Content-ID: <817A586A008B964C89FD04246872932A@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] new revision of eman requirements - Requirement 7.2 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 07:18:09 -0000 Hi Benoit, OK. I am fine either way. But if we move 7.6 up, we should move 7.7 as well (7.7 has a wrong title. To be changed for next vorsion.) Juergen On 02.08.11 17:20, "Benoit Claise" wrote: >Hi Juergen, > >That would be better to group the requirements in 7.x somehow logically, >because, to be frank, I missed the 7.6. >I mean going from 7.2 to 7.6, you have completely different requirement >interleaved. >We should group 7.2 and 7.6 > >Regards, Benoit (as a contributor) > >> Hi Mouli, >> >> All that you miss is in requirement 7.6. >> >> Thanks, >> >> Juergen >> >> >> Am 27.07.2011 um 00:16 schrieb Mouli Chandramouli (moulchan): >> >>> Hi Juergen, >>> >>> Requirement 7.2. Identity of other powered entities on which is >>>reported >>> >>> Focuses on the Parent having knowledge of the children. >>> >>> It is also useful to add a requirement - in the other direction also. >>> >>> The energy management standard must provide means for specifying the >>> identity of the powered entity >>> Which shall monitor and report the power consumption of a given powered >>> entity. >>> >>> Thanks >>> Mouli >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Wed Aug 3 02:04:40 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C65F21F8B22 for ; Wed, 3 Aug 2011 02:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6t075FBLI3A for ; Wed, 3 Aug 2011 02:04:39 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 47BED21F8B21 for ; Wed, 3 Aug 2011 02:04:39 -0700 (PDT) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LgBEG-1RBoyG2GQu-00nfs2; Wed, 03 Aug 2011 11:04:44 +0200 References: <4E30D605.6000400@cisco.com><8F79AC58-23C4-4D5C-BB61-CADBAD084612@quittek.at><791AD3077F94194BB2BDD13565B6295D1D031EA5@DAPHNIS.office.hd><4E318194.1060506@cisco.com> <791AD3077F94194BB2BDD13565B6295D1D033326@DAPHNIS.office.hd> <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DDF2@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4E3823B0.70509@cisco.com> In-Reply-To: <4E3823B0.70509@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <8B045E20-2C8A-4ACA-981B-CC768B861356@quittek.at> Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Wed, 3 Aug 2011 11:04:43 +0200 To: Benoit Claise X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:+iVrJJkmh2mEczpurs+tbZKSJu1xbk0oyla6OZ9PDmH m6v1XJoSAxfIeKtVTGTPI7URlYBo0vc+w2uzuNMnKX+SLQNPHK LrBiUBQG+cD+1gFIRxL2hWZT6A4e2mkRI3v3ZnKK5yP8LWeCod fTwknEUwwG6G/IQQSzqUK/R9dmyfbAHpRsxK8z6XRAeSOErxp7 wCCOCrq6gaHfv2fKs5mvNJQZnqvk0A4HqEUjl3tmMk= Cc: eman mailing list Subject: Re: [eman] [EMAN-BATTERY]: power state set X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 09:04:40 -0000 Dear all, The framework should be open to support two ways of representing a = battery: 1. treating the battery as a part of a device (or entity). 2. treating a battery as a separate entity with its own MIB objects for = power and energy. In case 1, there is no separate Power MIB instance for the battery.=20 Power reports on the containing device will include the power=20 received or provided by the internal battery. In case 2, the battery will have it's own Power MIB objects,=20 either hosted by a battery module or a parent of it. In case 1 the battery MAY have a UUID, in case 2 the battery MUST have a = UUID. In both cases the Battery MIB may be used for providing information on = the battery. In case 2 it is not clear what a power state of a battery is. I see two = alternatives (a) and (b): (a) it can be limited to just "on" and "off".=20 How much the battery is charged and the actual charging or discharging = activities=20 would then not be considered as power state, but rather as the battery's = operational state. (b) it can the union of "on" and the set of charging states defined in = the battery MIB In this case we would have to register a battery state set at IANA,=20 because the power state sets of DMTF, ACPI, and EnergyWise would not be = applicable. =20 If we have consensus that power states and charging states are = orthogonal,=20 then our choice should be (a). Thanks, Juergen We would have to define what a power state=20 Am 02.08.2011 um 18:20 schrieb Benoit Claise: > So, as discussed during the meeting, on based on this dicussion on the = list, the battery should be integrated to the framework, with its own = UUID, with its own power state set/power state, and on the top of this, = it should support the battery-mib. Correct? >=20 > Regards, Benoit. >> +1 I believe that the two sets of states are orthogonal. >>=20 >> When people talk about a device charging they are simply being = imprecise and conflating the two. It is an artifact of informal speech. >>=20 >> William F. Mielke >> Alcatel-Lucent >> Distinguished Member of Technical Staff >> 6200 East Broad Street >> Room: 4B01-1V >> Columbus, OH 43213-1530 >> Email: Bill.Mielke@alcatel-lucent.com >> Phone: 614 367 5628 >> Fax: 614 367 5965 >>=20 >> "Live like you're going to die tomorrow. >> Learn like you're going to live forever." >>=20 >> - Albert Einstein >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On >>> Behalf Of Rolf Winter >>> Sent: Thursday, July 28, 2011 12:50 PM >>> To: John Parello (jparello); Bruce Nordman; Benoit Claise (bclaise) >>> Cc: eman mailing list >>> Subject: Re: [eman] [EMAN-BATTERY]: power state set >>>=20 >>> I think these states are completely independent. Take the >>> three power states on, sleep, off and the charging states >>> charging, discharging, maintaining charge. Which ones are >>> dependent on each other? I think any of these combinations >>> work. Answering Benoit's question, I believe these are orthogonal. >>>=20 >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >>> Road, London W3 6BL | Registered in England 2832014 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] >>> On Behalf Of >>>> John Parello (jparello) >>>> Sent: Donnerstag, 28. Juli 2011 18:29 >>>> To: Bruce Nordman; Benoit Claise (bclaise) >>>> Cc: eman mailing list >>>> Subject: Re: [eman] [EMAN-BATTERY]: power state set >>>>=20 >>>>=20 >>>> OK but thinking about it. I'm not sure the battery state is >>> independent >>>> of the device in all cases. >>>>=20 >>>> Tablet example. We refer to them as on, off, charging, etc. We = don't >>>> say the device is on and the battery is off. It's merged. >>>>=20 >>>> So while I agree they can be separate we have to allow for the case >>>> when they are combined as well. >>>>=20 >>>> Jp >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: eman-bounces@ietf.org on behalf of Bruce Nordman >>>> Sent: Thu 7/28/2011 9:12 AM >>>> To: Benoit Claise (bclaise) >>>> Cc: eman mailing list >>>> Subject: Re: [eman] [EMAN-BATTERY]: power state set >>>>=20 >>>> On Thu, Jul 28, 2011 at 11:34 AM, Benoit Claise >>>> wrote: >>>>=20 >>>>> Rolf, >>>>>=20 >>>>> +1 >>>>>> The problem is that the power states of a "regular" >>> device conflate >>>>>> operational state information and energy related state >>> information. >>>>>> The battery charging state does not I in the same way. >>>>>>=20 >>>>> This is actually my question. >>>>> Is the battery power state set orthogonal to the other 3 >>> power state >>>> sets? >>>> A power state is (in principle) something independent of >>> the device (or >>>> component) type. >>>> It is universal. >>>>=20 >>>> The battery state is specific to a single type of component >>>>=20 >>>> I can imagine setting a power state for a battery to "off": to >>>> electrically disconnect it to prevent charging or discharging (this >>>> might be done prior to removal for example). In this case, >>> a battery >>>> would want both a power state and a charging state (the power state >>>> variable would be in the other MIB so not added to the Battery = MIB). >>>>=20 >>>> If new battery states might be needed, how about simply having a >>>> registry of the current states so that individual states >>> could be added, >>>> rather than entire new series as we have with power states. >>> This would >>>> give flexibility to add in future with minimal complexity, and not >>>> conflate with power states. >>>>=20 >>>> --Bruce >>>>=20 >>>>> Regards, Benoit. >>>>>=20 >>>>> ... >>>>>=20 >>>> -- >>>> *Bruce Nordman* >>>> Lawrence Berkeley National Laboratory >>>> eetd.lbl.gov/ea/nordman >>>> BNordman@LBL.gov >>>> 510-486-7089 >>>> m: 510-501-7943 >>>>=20 >>>>=20 >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman >>>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From moulchan@cisco.com Wed Aug 3 02:07:49 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA1A21F850F for ; Wed, 3 Aug 2011 02:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Z6gX0+FVFgH for ; Wed, 3 Aug 2011 02:07:49 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id EF33D21F850B for ; Wed, 3 Aug 2011 02:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=2213; q=dns/txt; s=iport; t=1312362480; x=1313572080; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=iSyu0R/fJ5jUTe0CK1c1LCizozirvIIlnT9QGVKjSrM=; b=DhzC7EJeR04rk/ABOFxSAANjrO6FyZq34qqEVXG22wk7jcC5X9ySc2Za A9wKKLg2tguUM1pyyzMsR7aBIMh6MeACbFrGwgltr/Bi7G+2/aT2hayiV OViWaUsZDORNdCp/Do+6BYTHeNpQIHPilsEeFqvqz5GJ42vtetz+t08w3 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAJoOOU6tJV2d/2dsb2JhbAA5CZgFj1Z3gUABAQEBAwEBAQ8BHQo0CwwEAgEIEQQBAQsGFwEGASYfCQgCBAESCBqHTqBTAZ5egyWCPl8Eh1qQMYty X-IronPort-AV: E=Sophos;i="4.67,309,1309737600"; d="scan'208";a="9143481" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 03 Aug 2011 09:06:18 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p7396I9Z015281; Wed, 3 Aug 2011 09:06:18 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 04:06:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Aug 2011 04:06:13 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] new revision of eman requirements - Requirement 7.2 Thread-Index: AQHMTGRKCCt98gb4LUiNmOnN3iKrJZUJlRiAgAEtEYCAAB04kA== References: <4E3815B9.6040703@cisco.com> From: "Mouli Chandramouli (moulchan)" To: "Juergen Quittek" , "Benoit Claise (bclaise)" , "Juergen Quittek" X-OriginalArrivalTime: 03 Aug 2011 09:06:18.0874 (UTC) FILETIME=[9B567DA0:01CC51BC] Cc: eman mailing list Subject: Re: [eman] new revision of eman requirements - Requirement 7.2 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 09:07:49 -0000 IMHO, Req # 7.6 title can be renamed -=20 s/Indicating source of remote information/Identity of the device to which information is reported to/ Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Wednesday, August 03, 2011 12:48 PM To: Benoit Claise (bclaise); Juergen Quittek Cc: eman mailing list Subject: Re: [eman] new revision of eman requirements - Requirement 7.2 Hi Benoit, OK. I am fine either way. But if we move 7.6 up, we should move 7.7 as well (7.7 has a wrong title. To be changed for next vorsion.) Juergen On 02.08.11 17:20, "Benoit Claise" wrote: >Hi Juergen, > >That would be better to group the requirements in 7.x somehow logically, >because, to be frank, I missed the 7.6. >I mean going from 7.2 to 7.6, you have completely different requirement >interleaved. >We should group 7.2 and 7.6 > >Regards, Benoit (as a contributor) > >> Hi Mouli, >> >> All that you miss is in requirement 7.6. >> >> Thanks, >> >> Juergen >> >> >> Am 27.07.2011 um 00:16 schrieb Mouli Chandramouli (moulchan): >> >>> Hi Juergen, >>> >>> Requirement 7.2. Identity of other powered entities on which is >>>reported >>> >>> Focuses on the Parent having knowledge of the children. >>> >>> It is also useful to add a requirement - in the other direction also. >>> >>> The energy management standard must provide means for specifying the >>> identity of the powered entity >>> Which shall monitor and report the power consumption of a given powered >>> entity. >>> >>> Thanks >>> Mouli >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From Quittek@neclab.eu Wed Aug 3 02:07:56 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA7621F8AE4 for ; Wed, 3 Aug 2011 02:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.051 X-Spam-Level: X-Spam-Status: No, score=-102.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXMwMjUllU4I for ; Wed, 3 Aug 2011 02:07:55 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED5D21F856A for ; Wed, 3 Aug 2011 02:07:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 827262800032B; Wed, 3 Aug 2011 11:06:23 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZecgH3AwAiNi; Wed, 3 Aug 2011 11:06:23 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 5E93C28000198; Wed, 3 Aug 2011 11:05:53 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.20]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Wed, 3 Aug 2011 11:05:53 +0200 From: Juergen Quittek To: eman mailing list Thread-Topic: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values Thread-Index: AQHMUbyLQN8slhq7EUeTtHXmrCW29g== Date: Wed, 3 Aug 2011 09:05:51 +0000 Message-ID: In-Reply-To: <4E381298.2020500@cisco.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [10.1.2.219] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1B663822031CED4986D75FD2DFCCED38@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 09:07:56 -0000 Hi all, Our current requirements just talk about reporting of time series. They do not talk about pull or push and thus could be met with push only. Of course pull only would also meet it. Is there an explicit requirement for having pull or for having push for time series of power and energy values? I don't see it. Thanks, Juergen On 02.08.11 17:07, "Benoit Claise" wrote: > > =20 > =20 > Dear all, > =20 > Trying to combine all the different arguments (discussed on the > mailing list and during the meeting), why do we have to have to > specify which time series the EMAN standard must support as a pull > model?=20 > =20 > Why not have a generic requirement, such as: > The EMAN tandard must not limit time series (for example Power, > Energy, Demand) to a pull mechanism; the push mechanism must be > considered. > =20 > Regards, Benoit. > =20 > =20 > =20 > =20 > =20 > RE: [eman] new revision of eman requirements - open issue > 12.3:time series of energy/power values > =20 > =20 > An > energy time series is can be reported as an odometer > reading. I think you=B9ll need to be adaptable to allow > either an absolute value like instantaneous kW, kWh over a > sample period or odometer sampling for kWh. > =20 > =20 > =20 > From: > eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On > Behalf Of Michael Suchoff > Sent: Thursday, July 28, 2011 2:25 PM > To: John Parello (jparello); Juergen Quittek; > Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] new revision of eman > requirements - open issue 12.3:timeseries of > energy/power values > =20 > =20 > =20 > I > would add current to the series as well. Most AC devices > presently don=B9t have circuitry to report power or energy, > they simply report AC current. Also, for capacity planning, > current is very useful (it is current that limits how many > devices can be placed on an electrical branch circuit or PDU > =AD not power). > =20 > Ideally, > the time series would be structured as a table with the > columns being measurements (i.e. column 1 =3D time stamp, 2 = =3D > power, 3 =3D energy, 4 =3D current, 5 =3D voltage, etc). The > columns could be partitioned into SNMP augmented tables > (tables sharing same index). This would allow easy addition > of new columns for products that offer more information. > =20 > I > don=B9t see reason for demand as a special table. Demand > (watts) is easily computed from the energy readings. For > example, if kWh =3D 1000 at 1PM and kWh =3D 2000 at 1:15PM, th= en > average power over the 15 minute interval is (2000kWh =AD > 1000kWh) * 60minutes/15minutes =3D 4kW. Doesn=B9t it seem a l= ot > simpler for management program to compute demand based on > polled energy readings (i.e. a simple SQL query) =AD rather > than having to write a procedure to configure the power > agent to perform demand computations? > =20 > =20 > =20 > ________________________________________ > > From: > eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On > Behalf Of John Parello (jparello) > Sent: Thursday, July 28, 2011 2:06 PM > To: Juergen Quittek; Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] new revision of eman > requirements - open issue 12.3:timeseries of energy/power > values > =20 > =20 > =20 > I > can't vote no when there'sand or and more on the bill. > =20 > I don't see any reason to restrict to just power. IMO a > series of power, energy, and demand is useful if a device > can support it. > =20 > So no don't restrict it to just power and please allow > series for power, demand, and energy > =20 > Jp > =20 > =20 > -----Original Message----- > From: Juergen Quittek [mailto:Quittek@neclab.eu] > Sent: Wed 7/27/2011 7:13 AM > To: John Parello (jparello); Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] new revision of eman requirements - open > issue 12.3:time series of energy/power values > =20 > Hi John, > =20 > my Question was > =20 > "Do I understand right that you would support a requirement > for specifying > a standard for time series of power but not for time series > of energy?" > =20 > =20 > I take you answer as a no. This would mean we keep both > requirements (time > series of power and time series of energy). Is this correct? > =20 > Thanks, > =20 > Juergen > =20 > =20 > On 26.07.11 18:10, "John Parello (jparello)" > wrote: > =20 > > > >Hi Jeurgen, > > > >We need to express power, energy as a measurement > (scalar). > > > >For time series (vector) IMO having the capability of > providing power > >over time series (which is demand) or energy over time > is valuable and > >should not be excluded. Even though for energy an > odometer can suffice I > >see no need to prevent this for devices that have this > capability. > > > > > >Please take a look at the > draft-claise-energy-monitoring-mib. I think > >they did a good job of providing time series modeling > that covers this. > > > >thanks > >Jp > > > > > > > > > > > > > > > > > >-----Original Message----- > >From: Juergen Quittek [mailto:ietf@quittek.at] > >Sent: Tue 7/26/2011 12:39 PM > >To: John Parello (jparello) > >Cc: Mouli Chandramouli (moulchan); eman mailing list > >Subject: Re: [eman] new revision of eman requirements - > open issue > >12.3:time series of energy/power values > > > >Hi John, > > > >We are currently not discussing optional or mandatory > implementation. > > > >The question is whether or not we have a requirement for > specifying a > >standard for reporting both, energy time series and > power time series, or > >just one of them. What compliant devices must implement > is an issue to be > >discussed later. > > > >Do I understand right that you would support a > requirement for specifying > >a standard for time series of power but not for time > series of energy? > > > >Thanks, > > > > Juergen > > > >Am 26.07.2011 um 13:08 schrieb John Parello (jparello): > > > >> Hi Jeurgen, > >> > >> I tend to agree, for simple devices an energy > odometer(s) as describe > >> from the comments and what I presented from the > ODVA suffices. > >> > >> For time series of data like historical demand > devices such as PDUs very > >> typically store this. Some our as long as a year's > worth of data on the > >> device. For the very reason that Bill pointed out. > >> > >> So it would seem that a power value and an energy > odometer could be a > >> required minimum and then time series of power or > demand can be > >> optional. > >> > >> We specified a power value as required in the > monitoring mib with time > >> series of power and demand as optional. > >> > >> Jp > >> > >> -----Original Message----- > >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] > On Behalf Of > >> Juergen Quittek > >> Sent: Wednesday, July 13, 2011 5:53 AM > >> To: Mouli Chandramouli (moulchan) > >> Cc: eman mailing list > >> Subject: Re: [eman] new revision of eman > requirements - open issue > >> 12.3:time series of energy/power values > >> > >> Dear Mouli, > >> > >> Thank you for commenting on this issue. I would > like to have a look at > >> the following point of view: > >> > >> So far, storing time series of measurements on > managed nodes is rarely > >> standardized and rarely available as > implementation. > >> > >> Typically, it is the job of a network management > system to collect time > >> series and store them. > >> > >> Take for example byte and packet counters at line > cards. You see many > >> curves showing time series of traffic rate/volume > in the Internet, but > >> almost all of them were collected at management > stations or data > >> collector modules, but not within MIB modules. > (Please correct me if I'm > >> wrong.) > >> > >> Now the question is: Is energy management so much > different from other > >> network management tasks, that we need the rarely > used mechanism of > >> storing time series in MIB modules? > >> > >> If not, it would be sufficient to just report the > number of total energy > >> consumed since the last re-start as you do it with > packet and byte > >> counters. > >> This would be just a single managed object to be > specified and > >> implemented. > >> > >> Thanks, > >> > >> Juergen > >> > =20 > =20 > =20 > =20 > _______________________________________________ >eman mailing list >eman@ietf.orghttps://www.ietf.org/mailman/listinfo/eman > =20 > > =20 > =20 > From ietf@quittek.at Wed Aug 3 02:20:43 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A7621F8B33 for ; Wed, 3 Aug 2011 02:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxhMpJgcWSVp for ; Wed, 3 Aug 2011 02:20:36 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 3A74F21F8B3B for ; Wed, 3 Aug 2011 02:20:32 -0700 (PDT) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MURRH-1QxiW11Ijz-00RHNG; Wed, 03 Aug 2011 11:18:50 +0200 References: <9C329342B62B87498B92834DEC9FF51E0D6187D8@fig.raritan.com> <22B2909DCC2E62418BE369A1F10488994B79886F@ex01.noveda.com> <4E381298.2020500@cisco.com> <22B2909DCC2E62418BE369A1F10488994B7ABC78@ex01.noveda.com> In-Reply-To: <22B2909DCC2E62418BE369A1F10488994B7ABC78@ex01.noveda.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--951519294 Message-Id: <5733C145-6B23-4014-A7BF-6E1B20505B90@quittek.at> From: Juergen Quittek Date: Wed, 3 Aug 2011 11:18:49 +0200 To: Brad Schoening , eman mailing list X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:YiQNopaJaJi0vWNUUT6uJ69XODnWOt8F1+783Y1CkDy 4KC+DXJ44ttlc+RHTrGSPJ7EGRAcCJGtpr8lPtXL0ix/ZbKRrv OzJFQcTicMIdbEUei67onB99WD/0bqzC6M7+kIKS8B4OpeJnEE QZh6FLQvlXjWx7EoS4LMuRPyA9iGHKUqkg9Q6FQWL89ZqfzPOk 928MMn/fUI/U2f2SAluU4EV//K/Kqz4LFB9iUVJ8IQ= Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 09:20:45 -0000 --Apple-Mail-1--951519294 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Brad, It is interesting to receive explanations what the current version of = the MIB module specifies.=20 However, we are not reverse engineering our requirements from the draft = of the MIB module.=20 We are rather investigating the requirements first and will then specify = the MIB module accordingly. Thanks, Juergen Am 03.08.2011 um 03:28 schrieb Brad Schoening: > Energy & demand are an essential measurement of smart meters and = similar devices. It=92s usually computed at the meter by sampling at = the millisecond level. Sampling kW by polling and then averaging values = will never be close to an actual metered value. The = draft-claise-energy-monitoring-mib has such a table based upon IEC = 61850=92s demand measurement table. It can be empty, since device that = don=92t support kWh aren=92t required to implement it. > =20 > Existing Building Management Systems and Energy Management Systems = already use the IEC 61850 data model, so by leveraging this model our = data can be used and shared with these existing management systems. > =20 > When pmEnergyParametersIntervalMode =3D =91total=92 the table works as = an odometer. > =20 > Regards, > =20 > Brad > =20 > From: Benoit Claise [mailto:bclaise@cisco.com]=20 > Sent: Tuesday, August 02, 2011 11:07 AM > To: Brad Schoening > Cc: Michael Suchoff; John Parello (jparello); Juergen Quittek; Juergen = Quittek; eman mailing list > Subject: Re: [eman] new revision of eman requirements - open issue = 12.3:timeseries of energy/power values > =20 > Dear all, >=20 > Trying to combine all the different arguments (discussed on the = mailing list and during the meeting), why do we have to have to specify = which time series the EMAN standard must support as a pull model?=20 >=20 > Why not have a generic requirement, such as: > The EMAN tandard must not limit time series (for example Power, = Energy, Demand) to a pull mechanism; the push mechanism must be = considered. >=20 > Regards, Benoit. >=20 >=20 > An energy time series is can be reported as an odometer reading. I = think you=92ll need to be adaptable to allow either an absolute value = like instantaneous kW, kWh over a sample period or odometer sampling for = kWh. > =20 > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of Michael Suchoff > Sent: Thursday, July 28, 2011 2:25 PM > To: John Parello (jparello); Juergen Quittek; Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] new revision of eman requirements - open issue = 12.3:timeseries of energy/power values > =20 > I would add current to the series as well. Most AC devices presently = don=92t have circuitry to report power or energy, they simply report AC = current. Also, for capacity planning, current is very useful (it is = current that limits how many devices can be placed on an electrical = branch circuit or PDU =96 not power). > =20 > Ideally, the time series would be structured as a table with the = columns being measurements (i.e. column 1 =3D time stamp, 2 =3D power, 3 = =3D energy, 4 =3D current, 5 =3D voltage, etc). The columns could be = partitioned into SNMP augmented tables (tables sharing same index). = This would allow easy addition of new columns for products that offer = more information. > =20 > I don=92t see reason for demand as a special table. Demand (watts) is = easily computed from the energy readings. For example, if kWh =3D 1000 = at 1PM and kWh =3D 2000 at 1:15PM, then average power over the 15 minute = interval is (2000kWh =96 1000kWh) * 60minutes/15minutes =3D 4kW. = Doesn=92t it seem a lot simpler for management program to compute demand = based on polled energy readings (i.e. a simple SQL query) =96 rather = than having to write a procedure to configure the power agent to perform = demand computations? > =20 > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of John Parello (jparello) > Sent: Thursday, July 28, 2011 2:06 PM > To: Juergen Quittek; Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] new revision of eman requirements - open issue = 12.3:timeseries of energy/power values > =20 > =20 > I can't vote no when there'sand or and more on the bill. >=20 > I don't see any reason to restrict to just power. IMO a series of = power, energy, and demand is useful if a device can support it. >=20 > So no don't restrict it to just power and please allow series for = power, demand, and energy >=20 > Jp >=20 >=20 > -----Original Message----- > From: Juergen Quittek [mailto:Quittek@neclab.eu] > Sent: Wed 7/27/2011 7:13 AM > To: John Parello (jparello); Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] new revision of eman requirements - open issue = 12.3:time series of energy/power values >=20 > Hi John, >=20 > my Question was >=20 > "Do I understand right that you would support a requirement for = specifying > a standard for time series of power but not for time series of = energy?" >=20 >=20 > I take you answer as a no. This would mean we keep both requirements = (time > series of power and time series of energy). Is this correct? >=20 > Thanks, >=20 > Juergen >=20 >=20 > On 26.07.11 18:10, "John Parello (jparello)" = wrote: >=20 > > > >Hi Jeurgen, > > > >We need to express power, energy as a measurement (scalar). > > > >For time series (vector) IMO having the capability of providing power > >over time series (which is demand) or energy over time is valuable = and > >should not be excluded. Even though for energy an odometer can = suffice I > >see no need to prevent this for devices that have this capability. > > > > > >Please take a look at the draft-claise-energy-monitoring-mib. I = think > >they did a good job of providing time series modeling that covers = this. > > > >thanks > >Jp > > > > > > > > > > > > > > > > > >-----Original Message----- > >From: Juergen Quittek [mailto:ietf@quittek.at] > >Sent: Tue 7/26/2011 12:39 PM > >To: John Parello (jparello) > >Cc: Mouli Chandramouli (moulchan); eman mailing list > >Subject: Re: [eman] new revision of eman requirements - open issue > >12.3:time series of energy/power values > > > >Hi John, > > > >We are currently not discussing optional or mandatory implementation. > > > >The question is whether or not we have a requirement for specifying a > >standard for reporting both, energy time series and power time = series, or > >just one of them. What compliant devices must implement is an issue = to be > >discussed later. > > > >Do I understand right that you would support a requirement for = specifying > >a standard for time series of power but not for time series of = energy? > > > >Thanks, > > > > Juergen > > > >Am 26.07.2011 um 13:08 schrieb John Parello (jparello): > > > >> Hi Jeurgen, > >> > >> I tend to agree, for simple devices an energy odometer(s) as = describe > >> from the comments and what I presented from the ODVA suffices. > >> > >> For time series of data like historical demand devices such as PDUs = very > >> typically store this. Some our as long as a year's worth of data on = the > >> device. For the very reason that Bill pointed out. > >> > >> So it would seem that a power value and an energy odometer could be = a > >> required minimum and then time series of power or demand can be > >> optional. > >> > >> We specified a power value as required in the monitoring mib with = time > >> series of power and demand as optional. > >> > >> Jp > >> > >> -----Original Message----- > >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On = Behalf Of > >> Juergen Quittek > >> Sent: Wednesday, July 13, 2011 5:53 AM > >> To: Mouli Chandramouli (moulchan) > >> Cc: eman mailing list > >> Subject: Re: [eman] new revision of eman requirements - open issue > >> 12.3:time series of energy/power values > >> > >> Dear Mouli, > >> > >> Thank you for commenting on this issue. I would like to have a look = at > >> the following point of view: > >> > >> So far, storing time series of measurements on managed nodes is = rarely > >> standardized and rarely available as implementation. > >> > >> Typically, it is the job of a network management system to collect = time > >> series and store them. > >> > >> Take for example byte and packet counters at line cards. You see = many > >> curves showing time series of traffic rate/volume in the Internet, = but > >> almost all of them were collected at management stations or data > >> collector modules, but not within MIB modules. (Please correct me = if I'm > >> wrong.) > >> > >> Now the question is: Is energy management so much different from = other > >> network management tasks, that we need the rarely used mechanism of > >> storing time series in MIB modules? > >> > >> If not, it would be sufficient to just report the number of total = energy > >> consumed since the last re-start as you do it with packet and byte > >> counters. > >> This would be just a single managed object to be specified and > >> implemented. > >> > >> Thanks, > >> > >> Juergen > >> >=20 >=20 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > =20 --Apple-Mail-1--951519294 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Brad,


It is interesting to = receive explanations what the current version of the MIB module = specifies. 

However, we are not reverse = engineering our requirements from the draft of the MIB = module. 
We are rather investigating the requirements = first and will then specify the MIB module = accordingly.

Thanks,

&nb= sp;   Juergen


Am 03.08.2011 = um 03:28 schrieb Brad Schoening:

Energy & demand are an = essential measurement of smart meters and similar devices.  It=92s = usually computed at the meter by sampling at the millisecond = level.  Sampling kW by polling and then averaging values will never = be close to an actual metered value.  The = draft-claise-energy-monitoring-mib has such a table based upon IEC = 61850=92s demand measurement table.  It can be empty, since device = that don=92t support kWh aren=92t required to implement = it.
 
Existing Building Management Systems and Energy Management = Systems already use the IEC 61850 data model, so by leveraging this = model our data can be used and shared with these existing management = systems.
 
When 
 Benoit Claise = [mailto:bclaise@cisco.com] 
Sent: Tuesday, August 02, 2011 = 11:07 AM
To: Brad = Schoening
Cc: Michael Suchoff; John = Parello (jparello); Juergen Quittek; Juergen Quittek; eman mailing = list
Subject: Re: [eman] new revision of = eman requirements - open issue 12.3:timeseries of energy/power = values
Dear = all,

Trying to combine all the different arguments (discussed on = the mailing list and during the meeting), why do we have to have to = specify which time series the EMAN standard must support as a pull = model? 

Why not = have a generic requirement, such as:
The EMAN tandard must not limit = time series (for example Power, Energy, Demand) to a pull mechanism; the = push mechanism must be considered.

Regards, = Benoit.


An energy time series is can be reported as an = odometer reading.  I think you=92ll need to be adaptable to allow = either an absolute value like instantaneous kW, kWh over a sample period = or odometer sampling for kWh.
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Michael = Suchoff
Sent: Thursday, July 28, 2011 = 2:25 PM
To: John Parello (jparello); = Juergen Quittek; Juergen Quittek
Cc: eman mailing = list
Subject: Re: [eman] new revision of = eman requirements - open issue 12.3:timeseries of energy/power = values
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of John Parello = (jparello)
Sent: Thursday, July 28, 2011 = 2:06 PM
To: Juergen Quittek; Juergen = Quittek
Cc: eman mailing = list
Subject: Re: [eman] new revision of = eman requirements - open issue 12.3:timeseries of energy/power = values
I can't = vote  no when there'sand or and more on the bill.

I don't = see any reason to restrict to just power. IMO a series of power, energy, = and demand is useful if a device can support it.

So no don't = restrict it to just power and please allow series for power, demand, and = energy

Jp


-----Original Message-----
From: Juergen = Quittek [mailto:Quittek@neclab.eu]
Sent: Wed = 7/27/2011 7:13 AM
To: John Parello (jparello); Juergen Quittek
Cc: = eman mailing list
Subject: Re: [eman] new revision of eman = requirements - open issue 12.3:time series of energy/power = values

Hi John,

my Question was

"Do I understand = right that you would support a requirement for specifying
a standard = for time series of power but not for time series of = energy?"


I take you answer as a no. This would mean we keep = both requirements (time
series of power and time series of energy). = Is this correct?

Thanks,

    = Juergen


On 26.07.11 18:10, "John Parello (jparello)" <jparello@cisco.com> wrote:

>
>Hi = Jeurgen,
>
>We need to express power, energy as a = measurement (scalar).
>
>For time series (vector) IMO having = the capability of providing power
>over time series (which is = demand) or energy over time is valuable and
>should not be = excluded.  Even though for energy an odometer can suffice = I
>see no need to prevent this for devices that have this = capability.
>
>
>Please take a look at the = draft-claise-energy-monitoring-mib.  I think
>they did a good = job of providing time series modeling that covers = this.
>
>thanks
>Jp
>
>
>
>
&= gt;
>
>
>
>-----Original = Message-----
>From: Juergen Quittek [mailto:ietf@quittek.at]
>Sent: Tue 7/26/2011 = 12:39 PM
>To: John Parello (jparello)
>Cc: Mouli = Chandramouli (moulchan); eman mailing list
>Subject: Re: [eman] = new revision of eman requirements - open issue
>12.3:time series = of energy/power values
>
>Hi John,
>
>We are = currently not discussing optional or mandatory = implementation.
>
>The question is whether or not we have a = requirement for specifying a
>standard for reporting both, energy = time series and power time series, or
>just one of them. What = compliant devices must implement is an issue to be
>discussed = later.
>
>Do I understand right that you would support a = requirement for specifying
>a standard for time series of power = but not for time series of = energy?
>
>Thanks,
>
>    = Juergen
>
>Am 26.07.2011 um 13:08 schrieb John Parello = (jparello):
>
>> Hi Jeurgen,
>>
>> I = tend to agree, for simple devices an energy odometer(s) as = describe
>> from the comments and what I presented from the = ODVA suffices.
>>
>> For time series of data like = historical demand devices such as PDUs very
>> typically store = this. Some our as long as a year's worth of data on the
>> = device. For the very reason that Bill pointed = out.
>>
>> So it would seem that a power value and an = energy odometer could be a
>> required minimum and then time = series of power or demand can be
>> = optional.
>>
>> We specified a power value as required = in the monitoring mib with time
>> series of power and demand = as optional.
>>
>> Jp
>>
>> = -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On = Behalf Of
>> Juergen Quittek
>> Sent: Wednesday, July = 13, 2011 5:53 AM
>> To: Mouli Chandramouli = (moulchan)
>> Cc: eman mailing list
>> Subject: Re: = [eman] new revision of eman requirements - open issue
>> = 12.3:time series of energy/power values
>>
>> Dear = Mouli,
>>
>> Thank you for commenting on this issue. I = would like to have a look at
>> the following point of = view:
>>
>> So far, storing time series of = measurements on managed nodes is rarely
>> standardized and = rarely available as implementation.
>>
>> Typically, = it is the job of a network management system to collect time
>> = series and store them.
>>
>> Take for example byte and = packet counters at line cards. You see many
>> curves showing = time series of traffic rate/volume in the Internet, but
>> = almost all of them were collected at management stations or = data
>> collector modules, but not within MIB modules. (Please = correct me if I'm
>> wrong.)
>>
>> Now the = question is: Is energy management so much different from = other
>> network management tasks, that we need the rarely used = mechanism of
>> storing time series in MIB = modules?
>>
>> If not, it would be sufficient to just = report the number of total energy
>> consumed since the last = re-start as you do it with packet and byte
>> = counters.
>> This would be just a single managed object to be = specified and
>> implemented.
>>
>> = Thanks,
>>
>>    = Juergen
>>

eman mailing list
eman@ietf.org

X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:HKWnjyIEdHaBM9Wgh+a+fYNRoUddi5SY/+WlDLo2oPN 7112ICDPjO7rEX1rFRNJ4I+hUZiyu+9/OBrxcN6LOWh+wqVk7Z jYxfl8En6KU8veHUt9RjpKhjkEyD6RR0gYQJk4xCUWCVZix88B pDMlv8jccfe1SNH+QhTYn2NTwJa8ZnbjAcxaZylSg8CVhpnE0a aZWklXj5J6AIpdGBT7Xo8jJvWMaZh5pQaW+sr+0SOM=
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - Requirement 7.2
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 09:23:38 -0000

Hi Mouli,

Sorry, I do not understand you new title suggestion:

The current title

    Indicating source of remote information

refers to indicating WHERE (at which device) information on an entity or =
device can be found.
For example, a switch may point to its parent PDU that controls its =
power supply=20
and that has a MIB module where the state of its sockets is reported =
(power "on" or "off").
=20
If we rename it to=20

    Identity of the device to which information is reported to

then we are at something completely different.=20
Who would report to whom?=20
Would the switch report to the PDU?

Thanks,

    Juergen


Am 03.08.2011 um 11:06 schrieb Mouli Chandramouli (moulchan):

> IMHO,   Req # 7.6 title can be renamed  -=20
>=20
> s/Indicating source of remote information/Identity of the device to
> which information is reported to/
>=20
> Thanks
> Mouli
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of
> Juergen Quittek
> Sent: Wednesday, August 03, 2011 12:48 PM
> To: Benoit Claise (bclaise); Juergen Quittek
> Cc: eman mailing list
> Subject: Re: [eman] new revision of eman requirements - Requirement =
7.2
>=20
> Hi Benoit,
>=20
> OK. I am fine either way.
> But if we move 7.6 up, we should move 7.7 as well
> (7.7 has a wrong title. To be changed for next vorsion.)
>=20
>    Juergen
>=20
> On 02.08.11 17:20, "Benoit Claise"  wrote:
>=20
>> Hi Juergen,
>>=20
>> That would be better to group the requirements in 7.x somehow
> logically,
>> because, to be frank, I missed the 7.6.
>> I mean going from 7.2 to 7.6, you have completely different =
requirement
>> interleaved.
>> We should group 7.2 and 7.6
>>=20
>> Regards, Benoit (as a contributor)
>>=20
>>> Hi Mouli,
>>>=20
>>> All that you miss is in requirement 7.6.
>>>=20
>>> Thanks,
>>>=20
>>>     Juergen
>>>=20
>>>=20
>>> Am 27.07.2011 um 00:16 schrieb Mouli Chandramouli (moulchan):
>>>=20
>>>> Hi Juergen,
>>>>=20
>>>> Requirement 7.2. Identity of other powered entities on which is
>>>> reported
>>>>=20
>>>> Focuses on the Parent having knowledge of the children.
>>>>=20
>>>> It is also useful to add a requirement - in the other direction
> also.
>>>>=20
>>>> The energy management standard must provide means for specifying =
the
>>>> identity of the powered entity
>>>> Which shall monitor and report the power consumption of a given
> powered
>>>> entity.
>>>>=20
>>>> Thanks
>>>> Mouli
>>>> _______________________________________________
>>>> eman mailing list
>>>> eman@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/eman
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>>=20
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From moulchan@cisco.com  Wed Aug  3 02:25:20 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4238621F8B18 for ; Wed,  3 Aug 2011 02:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level: 
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1MeQ23rci1B for ; Wed,  3 Aug 2011 02:25:19 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 513F721F8B1A for ; Wed,  3 Aug 2011 02:25:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=3899; q=dns/txt; s=iport; t=1312363531; x=1313573131; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gwtsFAvlbz/k7uxkYmMrIftu8CzoGMAtlStQ2wL7liY=; b=k7jzB3tGZSd9UeiYmJQc/LErOTtsnXljbSfzV0dCeL1adi99Mi130Kix Vs1h2MCyl1MUS9ENnt7+uk3xLEw43cDENvq9TWFcwjsGdocK9mlV0vCk+ RbvaqDVw/IUvstRjHUwjmp0lFOTSsv0Z/kX5AxfXI5uAyALU+t4k9nuM7 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AucAAFITOU6tJXG//2dsb2JhbAA5CZgFj1Z3gUABAQEBAgEBAQEPAR0KNAsFBwQCAQgOAwQBAQEKBhcBBgEmHwkIAQEEEwgah0oEoGABnmGDJYI+XwSHWpAxi3I
X-IronPort-AV: E=Sophos;i="4.67,309,1309737600";  d="scan'208";a="9148655"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 03 Aug 2011 09:25:30 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p739PUbH023243;  Wed, 3 Aug 2011 09:25:30 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 3 Aug 2011 04:25:29 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 3 Aug 2011 04:25:27 -0500
Message-ID: 
In-Reply-To: <53EE2803-DE9F-491E-9A2D-68D5E96CACE4@quittek.at>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - Requirement 7.2
Thread-Index: AcxRvZ6VeTkjUByXR3iNoMFsCuupgwAAONbA
References: <4E3815B9.6040703@cisco.com>   <53EE2803-DE9F-491E-9A2D-68D5E96CACE4@quittek.at>
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Quittek" 
X-OriginalArrivalTime: 03 Aug 2011 09:25:29.0611 (UTC) FILETIME=[493B05B0:01CC51BF]
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - Requirement 7.2
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 09:25:20 -0000

Hi Juergen,

We have requirement 7.2.  Identity of other powered entities on which is
reported - which talks about identities of the children.=20

My initial comment was we may also need to consider the reverse
direction of 7.2. i.e. the powered entities need to indicate the
identity of the device=20
to which information is reported. You had indicated requirement 7.6.
Reading the requirement again, I felt the title can be rephrased.=20

Thanks
Mouli



-----Original Message-----
From: Juergen Quittek [mailto:ietf@quittek.at]=20
Sent: Wednesday, August 03, 2011 2:43 PM
To: Mouli Chandramouli (moulchan)
Cc: Juergen Quittek; Benoit Claise (bclaise); eman mailing list
Subject: Re: [eman] new revision of eman requirements - Requirement 7.2

Hi Mouli,

Sorry, I do not understand you new title suggestion:

The current title

    Indicating source of remote information

refers to indicating WHERE (at which device) information on an entity or
device can be found.
For example, a switch may point to its parent PDU that controls its
power supply=20
and that has a MIB module where the state of its sockets is reported
(power "on" or "off").
=20
If we rename it to=20

    Identity of the device to which information is reported to

then we are at something completely different.=20
Who would report to whom?=20
Would the switch report to the PDU?

Thanks,

    Juergen


Am 03.08.2011 um 11:06 schrieb Mouli Chandramouli (moulchan):

> IMHO,   Req # 7.6 title can be renamed  -=20
>=20
> s/Indicating source of remote information/Identity of the device to
> which information is reported to/
>=20
> Thanks
> Mouli
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
Of
> Juergen Quittek
> Sent: Wednesday, August 03, 2011 12:48 PM
> To: Benoit Claise (bclaise); Juergen Quittek
> Cc: eman mailing list
> Subject: Re: [eman] new revision of eman requirements - Requirement
7.2
>=20
> Hi Benoit,
>=20
> OK. I am fine either way.
> But if we move 7.6 up, we should move 7.7 as well
> (7.7 has a wrong title. To be changed for next vorsion.)
>=20
>    Juergen
>=20
> On 02.08.11 17:20, "Benoit Claise"  wrote:
>=20
>> Hi Juergen,
>>=20
>> That would be better to group the requirements in 7.x somehow
> logically,
>> because, to be frank, I missed the 7.6.
>> I mean going from 7.2 to 7.6, you have completely different
requirement
>> interleaved.
>> We should group 7.2 and 7.6
>>=20
>> Regards, Benoit (as a contributor)
>>=20
>>> Hi Mouli,
>>>=20
>>> All that you miss is in requirement 7.6.
>>>=20
>>> Thanks,
>>>=20
>>>     Juergen
>>>=20
>>>=20
>>> Am 27.07.2011 um 00:16 schrieb Mouli Chandramouli (moulchan):
>>>=20
>>>> Hi Juergen,
>>>>=20
>>>> Requirement 7.2. Identity of other powered entities on which is
>>>> reported
>>>>=20
>>>> Focuses on the Parent having knowledge of the children.
>>>>=20
>>>> It is also useful to add a requirement - in the other direction
> also.
>>>>=20
>>>> The energy management standard must provide means for specifying
the
>>>> identity of the powered entity
>>>> Which shall monitor and report the power consumption of a given
> powered
>>>> entity.
>>>>=20
>>>> Thanks
>>>> Mouli
>>>> _______________________________________________
>>>> eman mailing list
>>>> eman@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/eman
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>>=20
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From ietf@quittek.at  Wed Aug  3 02:29:01 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A83421F8B13 for ; Wed,  3 Aug 2011 02:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[AWL=0.368,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QALmE+KZqcNT for ; Wed,  3 Aug 2011 02:29:00 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 40B6921F8B12 for ; Wed,  3 Aug 2011 02:29:00 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MY0TD-1QuP2837d1-00WpfW; Wed, 03 Aug 2011 11:29:04 +0200
References: <4E3815B9.6040703@cisco.com>   <53EE2803-DE9F-491E-9A2D-68D5E96CACE4@quittek.at> 
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Juergen Quittek 
Date: Wed, 3 Aug 2011 11:29:03 +0200
To: "Mouli Chandramouli (moulchan)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:Tqt48sxb0HErf9aoP0Wmq9FIMEQsokIzSm/usTFj72y xQf3fTzX9xfM3uvJMnEptaOlzs+nAdinVk0+ZEJJL2E6mTXNEH hrEAshRSIvRf97iAfj0KwKpF7m8BzBlhWaYoXTNbqjb9QenqdG WizCaest3cpRF4hByf9qIfKij+awOTRRlRlIio4sJE5mfK/yMw AnUh2r9gIFwS3KEpbgoT9vbe45/hG2yn3FyZz5QPxA=
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - Requirement 7.2
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 09:29:01 -0000

Hi Mouli,

You talk about the identity of the device "TO WHICH" information is reported.

Again, why would a switch as a child report anything to its parent PDU 
that measures and reports power values for the switch?

Thanks,

    Juergen


Am 03.08.2011 um 11:25 schrieb Mouli Chandramouli (moulchan):

> Hi Juergen,
> 
> We have requirement 7.2.  Identity of other powered entities on which is
> reported - which talks about identities of the children. 
> 
> My initial comment was we may also need to consider the reverse
> direction of 7.2. i.e. the powered entities need to indicate the
> identity of the device 
> to which information is reported. You had indicated requirement 7.6.
> Reading the requirement again, I felt the title can be rephrased. 
> 
> Thanks
> Mouli
> 
> 
> 
> -----Original Message-----
> From: Juergen Quittek [mailto:ietf@quittek.at] 
> Sent: Wednesday, August 03, 2011 2:43 PM
> To: Mouli Chandramouli (moulchan)
> Cc: Juergen Quittek; Benoit Claise (bclaise); eman mailing list
> Subject: Re: [eman] new revision of eman requirements - Requirement 7.2
> 
> Hi Mouli,
> 
> Sorry, I do not understand you new title suggestion:
> 
> The current title
> 
>    Indicating source of remote information
> 
> refers to indicating WHERE (at which device) information on an entity or
> device can be found.
> For example, a switch may point to its parent PDU that controls its
> power supply 
> and that has a MIB module where the state of its sockets is reported
> (power "on" or "off").
> 
> If we rename it to 
> 
>    Identity of the device to which information is reported to
> 
> then we are at something completely different. 
> Who would report to whom? 
> Would the switch report to the PDU?
> 
> Thanks,
> 
>    Juergen
> 
> 
> Am 03.08.2011 um 11:06 schrieb Mouli Chandramouli (moulchan):
> 
>> IMHO,   Req # 7.6 title can be renamed  - 
>> 
>> s/Indicating source of remote information/Identity of the device to
>> which information is reported to/
>> 
>> Thanks
>> Mouli
>> 
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
> Of
>> Juergen Quittek
>> Sent: Wednesday, August 03, 2011 12:48 PM
>> To: Benoit Claise (bclaise); Juergen Quittek
>> Cc: eman mailing list
>> Subject: Re: [eman] new revision of eman requirements - Requirement
> 7.2
>> 
>> Hi Benoit,
>> 
>> OK. I am fine either way.
>> But if we move 7.6 up, we should move 7.7 as well
>> (7.7 has a wrong title. To be changed for next vorsion.)
>> 
>>   Juergen
>> 
>> On 02.08.11 17:20, "Benoit Claise"  wrote:
>> 
>>> Hi Juergen,
>>> 
>>> That would be better to group the requirements in 7.x somehow
>> logically,
>>> because, to be frank, I missed the 7.6.
>>> I mean going from 7.2 to 7.6, you have completely different
> requirement
>>> interleaved.
>>> We should group 7.2 and 7.6
>>> 
>>> Regards, Benoit (as a contributor)
>>> 
>>>> Hi Mouli,
>>>> 
>>>> All that you miss is in requirement 7.6.
>>>> 
>>>> Thanks,
>>>> 
>>>>    Juergen
>>>> 
>>>> 
>>>> Am 27.07.2011 um 00:16 schrieb Mouli Chandramouli (moulchan):
>>>> 
>>>>> Hi Juergen,
>>>>> 
>>>>> Requirement 7.2. Identity of other powered entities on which is
>>>>> reported
>>>>> 
>>>>> Focuses on the Parent having knowledge of the children.
>>>>> 
>>>>> It is also useful to add a requirement - in the other direction
>> also.
>>>>> 
>>>>> The energy management standard must provide means for specifying
> the
>>>>> identity of the powered entity
>>>>> Which shall monitor and report the power consumption of a given
>> powered
>>>>> entity.
>>>>> 
>>>>> Thanks
>>>>> Mouli
>>>>> _______________________________________________
>>>>> eman mailing list
>>>>> eman@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>> _______________________________________________
>>>> eman mailing list
>>>> eman@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/eman
>>> 
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>> 
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
> 


From moulchan@cisco.com  Wed Aug  3 03:14:53 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F9121F8B3A for ; Wed,  3 Aug 2011 03:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.128
X-Spam-Level: 
X-Spam-Status: No, score=-3.128 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aT+G5cm++9a8 for ; Wed,  3 Aug 2011 03:14:52 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2E75C21F873A for ; Wed,  3 Aug 2011 03:14:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=5065; q=dns/txt; s=iport; t=1312366504; x=1313576104; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=OdvgMmDgGl5/ERzOc/NT4XwPNcqvPwjTx6U83fURlaQ=; b=N02whVIYyqNe+39jIy3B2CGzdN2zkGSdYOCcye4Y3MqDlsVzRVcYo2xK 0fxduVFwJAHQ25uDPPLtQCzn9Vmu7+Rz2QPnGCYlWy0Mna1+tugknDC4h 0vv75sw7uAI1y4dOfvl0qmCsZjLa5nmo233qjgO17HD/+jDqYobXsHyGl g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AucAAD8fOU6tJV2d/2dsb2JhbAA5CZgFj1Z3gUABAQEBAgEBAQEPAR0KNAsFBwQCAQgOAwQBAQEKBhcBBgEmHwkIAQEEEwgah0oEoF8BnmCDJYI+XwSHWpAxi3I
X-IronPort-AV: E=Sophos;i="4.67,309,1309737600";  d="scan'208";a="9165109"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 03 Aug 2011 10:15:02 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p73AF1o4005529;  Wed, 3 Aug 2011 10:15:01 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 3 Aug 2011 05:15:01 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 3 Aug 2011 05:14:57 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - Requirement 7.2
Thread-Index: AcxRv854EbjDOcxSSc+LF625/ZfGOgABC7mA
References: <4E3815B9.6040703@cisco.com>   <53EE2803-DE9F-491E-9A2D-68D5E96CACE4@quittek.at>  
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Quittek" 
X-OriginalArrivalTime: 03 Aug 2011 10:15:01.0355 (UTC) FILETIME=[34872BB0:01CC51C6]
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - Requirement 7.2
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 10:14:53 -0000

Hi Juergen,

If you consider the scenario of a PC ( a child) that is powered from a
wall outlet but still the PC can report its energy consumption to a
switch.=20
In that scenario, the PC can indicate the identity of the switch to
which the power consumption data can be reported.=20

Thanks
Mouli


-----Original Message-----
From: Juergen Quittek [mailto:ietf@quittek.at]=20
Sent: Wednesday, August 03, 2011 2:59 PM
To: Mouli Chandramouli (moulchan)
Cc: Juergen Quittek; Benoit Claise (bclaise); eman mailing list
Subject: Re: [eman] new revision of eman requirements - Requirement 7.2

Hi Mouli,

You talk about the identity of the device "TO WHICH" information is
reported.

Again, why would a switch as a child report anything to its parent PDU=20
that measures and reports power values for the switch?

Thanks,

    Juergen


Am 03.08.2011 um 11:25 schrieb Mouli Chandramouli (moulchan):

> Hi Juergen,
>=20
> We have requirement 7.2.  Identity of other powered entities on which
is
> reported - which talks about identities of the children.=20
>=20
> My initial comment was we may also need to consider the reverse
> direction of 7.2. i.e. the powered entities need to indicate the
> identity of the device=20
> to which information is reported. You had indicated requirement 7.6.
> Reading the requirement again, I felt the title can be rephrased.=20
>=20
> Thanks
> Mouli
>=20
>=20
>=20
> -----Original Message-----
> From: Juergen Quittek [mailto:ietf@quittek.at]=20
> Sent: Wednesday, August 03, 2011 2:43 PM
> To: Mouli Chandramouli (moulchan)
> Cc: Juergen Quittek; Benoit Claise (bclaise); eman mailing list
> Subject: Re: [eman] new revision of eman requirements - Requirement
7.2
>=20
> Hi Mouli,
>=20
> Sorry, I do not understand you new title suggestion:
>=20
> The current title
>=20
>    Indicating source of remote information
>=20
> refers to indicating WHERE (at which device) information on an entity
or
> device can be found.
> For example, a switch may point to its parent PDU that controls its
> power supply=20
> and that has a MIB module where the state of its sockets is reported
> (power "on" or "off").
>=20
> If we rename it to=20
>=20
>    Identity of the device to which information is reported to
>=20
> then we are at something completely different.=20
> Who would report to whom?=20
> Would the switch report to the PDU?
>=20
> Thanks,
>=20
>    Juergen
>=20
>=20
> Am 03.08.2011 um 11:06 schrieb Mouli Chandramouli (moulchan):
>=20
>> IMHO,   Req # 7.6 title can be renamed  -=20
>>=20
>> s/Indicating source of remote information/Identity of the device to
>> which information is reported to/
>>=20
>> Thanks
>> Mouli
>>=20
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
> Of
>> Juergen Quittek
>> Sent: Wednesday, August 03, 2011 12:48 PM
>> To: Benoit Claise (bclaise); Juergen Quittek
>> Cc: eman mailing list
>> Subject: Re: [eman] new revision of eman requirements - Requirement
> 7.2
>>=20
>> Hi Benoit,
>>=20
>> OK. I am fine either way.
>> But if we move 7.6 up, we should move 7.7 as well
>> (7.7 has a wrong title. To be changed for next vorsion.)
>>=20
>>   Juergen
>>=20
>> On 02.08.11 17:20, "Benoit Claise"  wrote:
>>=20
>>> Hi Juergen,
>>>=20
>>> That would be better to group the requirements in 7.x somehow
>> logically,
>>> because, to be frank, I missed the 7.6.
>>> I mean going from 7.2 to 7.6, you have completely different
> requirement
>>> interleaved.
>>> We should group 7.2 and 7.6
>>>=20
>>> Regards, Benoit (as a contributor)
>>>=20
>>>> Hi Mouli,
>>>>=20
>>>> All that you miss is in requirement 7.6.
>>>>=20
>>>> Thanks,
>>>>=20
>>>>    Juergen
>>>>=20
>>>>=20
>>>> Am 27.07.2011 um 00:16 schrieb Mouli Chandramouli (moulchan):
>>>>=20
>>>>> Hi Juergen,
>>>>>=20
>>>>> Requirement 7.2. Identity of other powered entities on which is
>>>>> reported
>>>>>=20
>>>>> Focuses on the Parent having knowledge of the children.
>>>>>=20
>>>>> It is also useful to add a requirement - in the other direction
>> also.
>>>>>=20
>>>>> The energy management standard must provide means for specifying
> the
>>>>> identity of the powered entity
>>>>> Which shall monitor and report the power consumption of a given
>> powered
>>>>> entity.
>>>>>=20
>>>>> Thanks
>>>>> Mouli
>>>>> _______________________________________________
>>>>> eman mailing list
>>>>> eman@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>> _______________________________________________
>>>> eman mailing list
>>>> eman@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/eman
>>>=20
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>>=20
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>=20


From ietf@quittek.at  Wed Aug  3 03:24:36 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE48221F8891 for ; Wed,  3 Aug 2011 03:24:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.355,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-BVUh+caLHH for ; Wed,  3 Aug 2011 03:24:36 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1029421F888A for ; Wed,  3 Aug 2011 03:24:36 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0Lv4kw-1RXHHY087G-010OtB; Wed, 03 Aug 2011 12:24:47 +0200
References: <4E3815B9.6040703@cisco.com>   <53EE2803-DE9F-491E-9A2D-68D5E96CACE4@quittek.at>   
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <352C36AF-71F1-4A42-A44A-32B4076C728C@quittek.at>
Content-Transfer-Encoding: 7bit
From: Juergen Quittek 
Date: Wed, 3 Aug 2011 12:24:45 +0200
To: "Mouli Chandramouli (moulchan)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:diY8xfgHeJuntHMLNZ93GrEtq0yCo6tIRnNZEBRRuya j6xK9OEfacMwphSZ5KkLMyYHeeZIImMR5AEkm/NPSUXK0or6xY DTIf5cxysGyjjbLgTeLTNauXAuaQA9J/xt3/4xrHak9ZwYRdgc KW8SlHvkOXsq9kQFCfYk6qoOmIJdP4r3RZ2z0OdHihl5iO7pLv AeXlddxqSanp1xu3SfP4/Yq2ktc+NjScUa4gCCzW24=
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - Requirement 7.2
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 10:24:37 -0000

Yes, you talk about relaying power information.
That is possible as well. 

But a standard should also cover both cases.
Your rephrasing of the title would eliminate one case, 
the one that I sketched in the email below. The phrase 
that we currently use in the requirements draft covers both cases.
Ans we want to cover both cases.

    Juergen

Am 03.08.2011 um 12:14 schrieb Mouli Chandramouli (moulchan):

> Hi Juergen,
> 
> If you consider the scenario of a PC ( a child) that is powered from a
> wall outlet but still the PC can report its energy consumption to a
> switch. 
> In that scenario, the PC can indicate the identity of the switch to
> which the power consumption data can be reported. 
> 
> Thanks
> Mouli
> 
> 
> -----Original Message-----
> From: Juergen Quittek [mailto:ietf@quittek.at] 
> Sent: Wednesday, August 03, 2011 2:59 PM
> To: Mouli Chandramouli (moulchan)
> Cc: Juergen Quittek; Benoit Claise (bclaise); eman mailing list
> Subject: Re: [eman] new revision of eman requirements - Requirement 7.2
> 
> Hi Mouli,
> 
> You talk about the identity of the device "TO WHICH" information is
> reported.
> 
> Again, why would a switch as a child report anything to its parent PDU 
> that measures and reports power values for the switch?
> 
> Thanks,
> 
>    Juergen
> 
> 
> Am 03.08.2011 um 11:25 schrieb Mouli Chandramouli (moulchan):
> 
>> Hi Juergen,
>> 
>> We have requirement 7.2.  Identity of other powered entities on which
> is
>> reported - which talks about identities of the children. 
>> 
>> My initial comment was we may also need to consider the reverse
>> direction of 7.2. i.e. the powered entities need to indicate the
>> identity of the device 
>> to which information is reported. You had indicated requirement 7.6.
>> Reading the requirement again, I felt the title can be rephrased. 
>> 
>> Thanks
>> Mouli
>> 
>> 
>> 
>> -----Original Message-----
>> From: Juergen Quittek [mailto:ietf@quittek.at] 
>> Sent: Wednesday, August 03, 2011 2:43 PM
>> To: Mouli Chandramouli (moulchan)
>> Cc: Juergen Quittek; Benoit Claise (bclaise); eman mailing list
>> Subject: Re: [eman] new revision of eman requirements - Requirement
> 7.2
>> 
>> Hi Mouli,
>> 
>> Sorry, I do not understand you new title suggestion:
>> 
>> The current title
>> 
>>   Indicating source of remote information
>> 
>> refers to indicating WHERE (at which device) information on an entity
> or
>> device can be found.
>> For example, a switch may point to its parent PDU that controls its
>> power supply 
>> and that has a MIB module where the state of its sockets is reported
>> (power "on" or "off").
>> 
>> If we rename it to 
>> 
>>   Identity of the device to which information is reported to
>> 
>> then we are at something completely different. 
>> Who would report to whom? 
>> Would the switch report to the PDU?
>> 
>> Thanks,
>> 
>>   Juergen
>> 
>> 
>> Am 03.08.2011 um 11:06 schrieb Mouli Chandramouli (moulchan):
>> 
>>> IMHO,   Req # 7.6 title can be renamed  - 
>>> 
>>> s/Indicating source of remote information/Identity of the device to
>>> which information is reported to/
>>> 
>>> Thanks
>>> Mouli
>>> 
>>> -----Original Message-----
>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
>> Of
>>> Juergen Quittek
>>> Sent: Wednesday, August 03, 2011 12:48 PM
>>> To: Benoit Claise (bclaise); Juergen Quittek
>>> Cc: eman mailing list
>>> Subject: Re: [eman] new revision of eman requirements - Requirement
>> 7.2
>>> 
>>> Hi Benoit,
>>> 
>>> OK. I am fine either way.
>>> But if we move 7.6 up, we should move 7.7 as well
>>> (7.7 has a wrong title. To be changed for next vorsion.)
>>> 
>>>  Juergen
>>> 
>>> On 02.08.11 17:20, "Benoit Claise"  wrote:
>>> 
>>>> Hi Juergen,
>>>> 
>>>> That would be better to group the requirements in 7.x somehow
>>> logically,
>>>> because, to be frank, I missed the 7.6.
>>>> I mean going from 7.2 to 7.6, you have completely different
>> requirement
>>>> interleaved.
>>>> We should group 7.2 and 7.6
>>>> 
>>>> Regards, Benoit (as a contributor)
>>>> 
>>>>> Hi Mouli,
>>>>> 
>>>>> All that you miss is in requirement 7.6.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>>   Juergen
>>>>> 
>>>>> 
>>>>> Am 27.07.2011 um 00:16 schrieb Mouli Chandramouli (moulchan):
>>>>> 
>>>>>> Hi Juergen,
>>>>>> 
>>>>>> Requirement 7.2. Identity of other powered entities on which is
>>>>>> reported
>>>>>> 
>>>>>> Focuses on the Parent having knowledge of the children.
>>>>>> 
>>>>>> It is also useful to add a requirement - in the other direction
>>> also.
>>>>>> 
>>>>>> The energy management standard must provide means for specifying
>> the
>>>>>> identity of the powered entity
>>>>>> Which shall monitor and report the power consumption of a given
>>> powered
>>>>>> entity.
>>>>>> 
>>>>>> Thanks
>>>>>> Mouli
>>>>>> _______________________________________________
>>>>>> eman mailing list
>>>>>> eman@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>>> _______________________________________________
>>>>> eman mailing list
>>>>> eman@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>> 
>>>> _______________________________________________
>>>> eman mailing list
>>>> eman@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/eman
>>> 
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>> 
> 


From ietf@quittek.at  Wed Aug  3 03:26:40 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2843B21F889F for ; Wed,  3 Aug 2011 03:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level: 
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.344,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVpeXtP-llWB for ; Wed,  3 Aug 2011 03:26:39 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1A73121F8891 for ; Wed,  3 Aug 2011 03:26:39 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LsMjU-1RUXI01Hya-011wx8; Wed, 03 Aug 2011 12:26:48 +0200
References: <20110728164503.GA30392@elstar.local> <22B2909DCC2E62418BE369A1F10488994B7ABCD2@ex01.noveda.com>
In-Reply-To: <22B2909DCC2E62418BE369A1F10488994B7ABCD2@ex01.noveda.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <4DD3FEE2-A50D-4C63-9B5E-2E53986E31FE@quittek.at>
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Wed, 3 Aug 2011 12:26:47 +0200
To: Brad Schoening 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:iIb1oDuuDliyDiDcJfmDCsnp6w14KptfRpeSCISp1nu BMhhXPYD/W2H+k2Zxj6OVo2/Thnos0oZSf8QEDgzTKajqxmHMl K8wLFL5t1hehZULNE7cxgdu7NE/3FJ0jepop7k8LAOUVIqMn9L +wBT5WzR2b9K73YC4SK/l/XgWdcC+OPQlxt2ZkLXmeTlcZps7W QMwioUTGb+PGN+gM0b7+XFjhB10r9fWWGsFjIypfMo=
Cc: "eman@ietf.org" 
Subject: Re: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 10:26:40 -0000

Hi Brad,

It looks like it would be a good idea to register ECMA states as a =
separate set at IANA once we have that registry.

Thanks,

    Juergen


Am 03.08.2011 um 04:01 schrieb Brad Schoening:

> Hi Juergen,
>=20
> Just wondering if it would be more relevant to use ECMA states in IANA =
instead of ieee1621?  ECMA is newer, with the same basic states as 1621 =
but has additional modes that are relevant to contemporary hardware:
>=20
> ECMA:
>=20
> 	Off
> 	Sleep
> 	WoL Sleep=20
> 	ShortIdle
> 	LongIdle
> 	Active
>=20
> 1621:
>=20
> 	Off
> 	Sleep
> 	On
>=20
> =
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-383.pdf
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of Juergen Schoenwaelder
> Sent: Thursday, July 28, 2011 12:45 PM
> To: eman@ietf.org
> Subject: [eman] iana powerstate tc proposal
>=20
> Hi,
>=20
> here is a proposal for an IANA maintained power state textual =
convention. There are of course other ways of doing this but I thought a =
concrete proposal might help the discussion.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From moulchan@cisco.com  Wed Aug  3 05:31:53 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F61321F8788 for ; Wed,  3 Aug 2011 05:31:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.111
X-Spam-Level: 
X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYztbPVTME4J for ; Wed,  3 Aug 2011 05:31:52 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A0FB721F8799 for ; Wed,  3 Aug 2011 05:31:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=5732; q=dns/txt; s=iport; t=1312374724; x=1313584324; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=66fjRnSJXILorliWgYpcPaWVeusaizwIr0Z+8eJDQhc=; b=O9Welh0kFWwWkRoqN71UtqWNf8UTqb58PacDMUE5rlBmJ8KSHcXCDkNx 9gBZyHpzhpodTWuC5+LmBC9IuFVq5MxxESuC3VacADuv+iw/ZO3EENYbS BO/urJUY3obAh2b/xFKYWnYJ32YHY3jjPhwfSJUY3WDHfFhLg//OuBZym A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AukAACU/OU6tJV2a/2dsb2JhbAA/A5gGj1l3gUABAQEBAgEBAQEPAR0KNAsFBwICAgEIDgIBBAEBCwYXAQYBGgwfCQgBAQQBEggah0oEoUQBnmQCgzyCJV8Eh1qQMYty
X-IronPort-AV: E=Sophos;i="4.67,310,1309737600";  d="scan'208";a="9201705"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 03 Aug 2011 12:32:04 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p73CW4fN020359;  Wed, 3 Aug 2011 12:32:04 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 3 Aug 2011 07:32:04 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 3 Aug 2011 07:31:58 -0500
Message-ID: 
In-Reply-To: <20110803045449.GA43357@elstar.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] iana powerstate tc proposal
Thread-Index: AcxRmYBr5Pbu3I8LQhSzGxTeBqQfegAPN6Rw
References: <20110728164503.GA30392@elstar.local><20110728184235.GD30565@elstar.local><20110728212016.GA31474@elstar.local> <4E38229F.4020504@cisco.com> <20110803045449.GA43357@elstar.local>
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Schoenwaelder" , "Benoit Claise (bclaise)" 
X-OriginalArrivalTime: 03 Aug 2011 12:32:04.0150 (UTC) FILETIME=[59B21D60:01CC51D9]
Cc: eman@ietf.org
Subject: Re: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 12:31:53 -0000

Hi Juergen,

Thanks for the email.=20

Agreed on the WG consensus that there should be a parsimonious set of
multiple power state sets registered with IANA.=20
In fact, initially, we had even proposed a rigorous threshold for the
IANA registry of power state sets.=20

On the MIB design, some of the guiding principles for the Textual
Convention are:

1. It should be possible to register a small number of Power State sets
with IANA registry.=20

2. It should be possible to discover the Power State Sets supported by
the device (without involving a trial and error type of method.)

3. Regarding the possible duplication of MIB objects, it was felt that
the standard should allow the power monitor to support multiple power
state sets.=20
   The standard should not restrict the power monitor to communicate in
one only power state set.=20
   Often, the device may implement one power state set. So, duplication
of MIB objects across multiple power state sets would not be such an
overhead.=20

As you had also indicated in your initial email, there are several
approaches to solve this MIB design issue.=20
There are pros and cons of every approach. =20

Thanks
Mouli

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Juergen Schoenwaelder
Sent: Wednesday, August 03, 2011 10:25 AM
To: Benoit Claise (bclaise)
Cc: eman@ietf.org
Subject: Re: [eman] iana powerstate tc proposal

On Tue, Aug 02, 2011 at 06:15:27PM +0200, Benoit Claise wrote:

> >That said, once
> >stored, a single integer is simply self-contained (and you even get a
> >meaningful descriptor with typical generic SNMP tools).
> I still don't get your argument about two OIDs to retrieve the power
state.
>         pmPowerEntry OBJECT-TYPE
>             SYNTAX          PmPowerEntry
>             MAX-ACCESS      not-accessible
>             STATUS          current
>             DESCRIPTION
>                "An entry describes the power usage of a Power
Monitor."
>             INDEX           { pmPowerIndex, pmPowerStateSetIndex}
>             ::=3D { pmPowerTable  1 }
>=20
>         PmPowerEntry ::=3D SEQUENCE {
>                 ...
>                 pmPowerAdminState               Integer32,
>                 pmPowerOperState                 Integer32,
>=20
> I will be polling
> pmPowerAdminState.pmPowerIndex.pmPowerStateSetIndex to get the value
> of the pmPowerAdminState

And the NMS will display that the power monitor #1 is in the power
state 42 of the power state set 0x0a. If you store the state, you
actually have to store two values. Yes, you make the set atomic by
putting the set into the INDEX. But that does not address other issues
nor does it lead to simplicity.

> >>- I need to implement and enforce atomic sets with two varbinds in
> >>   order to change from a value in one power state set to a value in
a
> >>   different power state set.
> >>
> >>[jp] If you have an index for the set first you get the same ability
> >Well, not completely true. If you have dmtf off and you want to
change
> >to eman on, how does set look like? I know that you assume magic
> >implementation specific translations between the power state sets,
> >which I find ugly. Too much magic if our goal is interoperability.
> Practically, the ENMS will do a discovery of the possible power
> states within the power state set, with the snmpwalk of:
> pmPowerStateTable(2)
>           |      +--pmPowerStateEntry(1)
>           |      |     [pmPowerIndex,
>           |      |      pmPowerStateSet,
>           |      |      pmpowerStateIndex]
>           |      +-- --- Integer32       pmPowerStateIndex(1)
>           |      +-- r-n Interger32      pmPowerStateMaxPower (2)
>           |      +-- r-n UnitMultiplier
>           |                  pmPowerStatePowerUnitMultiplier (3)
>           |      +-- r-n TimeTicks       pmPowerStateTotalTime(4)
>           |      +-- r-n Counter64       pmPowerStateEnterCount(5)

I believe it is counter productive for the goal of interoperability to
have everybody support his own power state set and to make the values
somehow dynamically discoverable. I thought this WG had reached
agreement to have a small set of power states/sets registered with
IANA.

> Actually, I even envision the ENMS asking a device: do you support
> THIS Power State Set, by doing a snmpwalk on
> pmPowerStateTable.pmPowerStateEntry.pmPowerIndex.pmPowerStateSet
>
> From there, practically, one ENMS will manager (configure and
> monitor) _a single_ Power State Set for a single monitor. SNMPset of
> pmPowerAdminState.pmPowerIndex.pmPowerStateSetIndex to 
>=20
> If the easy translation was possible between Power State Set/Power
> States, then we would have defined a single Power State Set.

But your design aims at reporting a certain true state of the device
according to different sets concurrently - so you assume there is a
translation which is implementation dependent, that is every device
can translate as it likes to do it. Not sure how this really helps
with interoperability. (And the same goes to proposals where the power
states are expected to be a series with 1000 as percentage increments
as mentioned previously - this looks to me like a fine grained control
knob and not a power state.)

/js

--=20
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         
_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman

From bschoening@noveda.com  Wed Aug  3 05:38:03 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2450021F87C9 for ; Wed,  3 Aug 2011 05:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.148
X-Spam-Level: 
X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTkK2rwltWt8 for ; Wed,  3 Aug 2011 05:37:58 -0700 (PDT)
Received: from cal3-mh484-a.smtproutes.com (cal3-mh484-a.smtproutes.com [208.70.89.247]) by ietfa.amsl.com (Postfix) with ESMTP id 954B421F85B1 for ; Wed,  3 Aug 2011 05:37:58 -0700 (PDT)
X-Katharion-ID: 1312375062.97924.cal3-mh484
Received: from ex01.noveda.com ([66.198.105.170]) by  cal3-mh484.smtproutes.com [(208.70.89.158)] with ESMTP via TCP; 03 Aug  2011 05:37:42 -0700
Received: from EX01.noveda.com ([::1]) by ex01.noveda.com ([::1]) with mapi; Wed, 3 Aug 2011 08:37:42 -0400
From: Brad Schoening 
To: Juergen Quittek , eman mailing list 
Thread-Topic: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values
Thread-Index: AQHMUb6xQVYdgtYF7UGRmKy57wMiQ5ULDr0A
Date: Wed, 3 Aug 2011 12:37:41 +0000
Message-ID: <22B2909DCC2E62418BE369A1F10488994B7ABFBA@ex01.noveda.com>
References:   <9C329342B62B87498B92834DEC9FF51E0D6187D8@fig.raritan.com> <22B2909DCC2E62418BE369A1F10488994B79886F@ex01.noveda.com> <4E381298.2020500@cisco.com> <22B2909DCC2E62418BE369A1F10488994B7ABC78@ex01.noveda.com> <5733C145-6B23-4014-A7BF-6E1B20505B90@quittek.at>
In-Reply-To: <5733C145-6B23-4014-A7BF-6E1B20505B90@quittek.at>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_22B2909DCC2E62418BE369A1F10488994B7ABFBAex01novedacom_"
MIME-Version: 1.0
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2011 12:38:03 -0000

--_000_22B2909DCC2E62418BE369A1F10488994B7ABFBAex01novedacom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Juergen,

Perhaps I wasn't clear, I was suggesting we consider the existing model for=
 timeseries data as used in IEC 61850.  That is already widely used by both=
 energy management systems and devices in the field such as revenue grade s=
mart meters.

Regards,

Brad

From: Juergen Quittek [mailto:ietf@quittek.at]
Sent: Wednesday, August 03, 2011 5:19 AM
To: Brad Schoening; eman mailing list
Cc: Benoit Claise; Michael Suchoff; John Parello (jparello); Juergen Quitte=
k
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:tim=
eseries of energy/power values

Hi Brad,

It is interesting to receive explanations what the current version of the M=
IB module specifies.

However, we are not reverse engineering our requirements from the draft of =
the MIB module.
We are rather investigating the requirements first and will then specify th=
e MIB module accordingly.

Thanks,

    Juergen


Am 03.08.2011 um 03:28 schrieb Brad Schoening:


Energy & demand are an essential measurement of smart meters and similar de=
vices.  It's usually computed at the meter by sampling at the millisecond l=
evel.  Sampling kW by polling and then averaging values will never be close=
 to an actual metered value.  The draft-claise-energy-monitoring-mib has su=
ch a table based upon IEC 61850's demand measurement table.  It can be empt=
y, since device that don't support kWh aren't required to implement it.

Existing Building Management Systems and Energy Management Systems already =
use the IEC 61850 data model, so by leveraging this model our data can be u=
sed and shared with these existing management systems.

When pmEnergyParametersIntervalMode =3D 'total' the table works as an odome=
ter.

Regards,

Brad

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, August 02, 2011 11:07 AM
To: Brad Schoening
Cc: Michael Suchoff; John Parello (jparello); Juergen Quittek; Juergen Quit=
tek; eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:tim=
eseries of energy/power values

Dear all,

Trying to combine all the different arguments (discussed on the mailing lis=
t and during the meeting), why do we have to have to specify which time ser=
ies the EMAN standard must support as a pull model?

Why not have a generic requirement, such as:
The EMAN tandard must not limit time series (for example Power, Energy, Dem=
and) to a pull mechanism; the push mechanism must be considered.

Regards, Benoit.



An energy time series is can be reported as an odometer reading.  I think y=
ou'll need to be adaptable to allow either an absolute value like instantan=
eous kW, kWh over a sample period or odometer sampling for kWh.

From: eman-bounces@ietf.org [mailto:eman-boun=
ces@ietf.org] On Behalf Of Michael Suchoff
Sent: Thursday, July 28, 2011 2:25 PM
To: John Parello (jparello); Juergen Quittek; Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:tim=
eseries of energy/power values

I would add current to the series as well.  Most AC devices presently don't=
 have circuitry to report power or energy, they simply report AC current.  =
Also, for capacity planning, current is very useful (it is current that lim=
its how many devices can be placed on an electrical branch circuit or PDU -=
 not power).

Ideally, the time series would be structured as a table with the columns be=
ing measurements (i.e. column 1 =3D time stamp, 2 =3D power, 3 =3D energy, =
4 =3D current, 5 =3D voltage, etc).  The columns could be partitioned into =
SNMP augmented tables (tables sharing same index).  This would allow easy a=
ddition of new columns for products that offer more information.

I don't see reason for demand as a special table.  Demand (watts) is easily=
 computed from the energy readings.  For example, if kWh =3D 1000 at 1PM an=
d kWh =3D 2000 at 1:15PM, then average power over the 15 minute interval is=
 (2000kWh - 1000kWh) * 60minutes/15minutes =3D 4kW.  Doesn't it seem a lot =
simpler for management program to compute demand based on polled energy rea=
dings (i.e. a simple SQL query) - rather than having to write a procedure t=
o configure the power agent to perform demand computations?

________________________________
From: eman-bounces@ietf.org [mailto:eman-boun=
ces@ietf.org] On Behalf Of John Parello (jparello)
Sent: Thursday, July 28, 2011 2:06 PM
To: Juergen Quittek; Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:tim=
eseries of energy/power values



I can't vote  no when there'sand or and more on the bill.

I don't see any reason to restrict to just power. IMO a series of power, en=
ergy, and demand is useful if a device can support it.

So no don't restrict it to just power and please allow series for power, de=
mand, and energy

Jp


-----Original Message-----
From: Juergen Quittek [mailto:Quittek@neclab.eu]
Sent: Wed 7/27/2011 7:13 AM
To: John Parello (jparello); Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:tim=
e series of energy/power values

Hi John,

my Question was

"Do I understand right that you would support a requirement for specifying
a standard for time series of power but not for time series of energy?"


I take you answer as a no. This would mean we keep both requirements (time
series of power and time series of energy). Is this correct?

Thanks,

    Juergen


On 26.07.11 18:10, "John Parello (jparello)"  wrote:

>
>Hi Jeurgen,
>
>We need to express power, energy as a measurement (scalar).
>
>For time series (vector) IMO having the capability of providing power
>over time series (which is demand) or energy over time is valuable and
>should not be excluded.  Even though for energy an odometer can suffice I
>see no need to prevent this for devices that have this capability.
>
>
>Please take a look at the draft-claise-energy-monitoring-mib.  I think
>they did a good job of providing time series modeling that covers this.
>
>thanks
>Jp
>
>
>
>
>
>
>
>
>-----Original Message-----
>From: Juergen Quittek [mailto:ietf@quittek.at]
>Sent: Tue 7/26/2011 12:39 PM
>To: John Parello (jparello)
>Cc: Mouli Chandramouli (moulchan); eman mailing list
>Subject: Re: [eman] new revision of eman requirements - open issue
>12.3:time series of energy/power values
>
>Hi John,
>
>We are currently not discussing optional or mandatory implementation.
>
>The question is whether or not we have a requirement for specifying a
>standard for reporting both, energy time series and power time series, or
>just one of them. What compliant devices must implement is an issue to be
>discussed later.
>
>Do I understand right that you would support a requirement for specifying
>a standard for time series of power but not for time series of energy?
>
>Thanks,
>
>    Juergen
>
>Am 26.07.2011 um 13:08 schrieb John Parello (jparello):
>
>> Hi Jeurgen,
>>
>> I tend to agree, for simple devices an energy odometer(s) as describe
>> from the comments and what I presented from the ODVA suffices.
>>
>> For time series of data like historical demand devices such as PDUs very
>> typically store this. Some our as long as a year's worth of data on the
>> device. For the very reason that Bill pointed out.
>>
>> So it would seem that a power value and an energy odometer could be a
>> required minimum and then time series of power or demand can be
>> optional.
>>
>> We specified a power value as required in the monitoring mib with time
>> series of power and demand as optional.
>>
>> Jp
>>
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-b=
ounces@ietf.org] On Behalf Of
>> Juergen Quittek
>> Sent: Wednesday, July 13, 2011 5:53 AM
>> To: Mouli Chandramouli (moulchan)
>> Cc: eman mailing list
>> Subject: Re: [eman] new revision of eman requirements - open issue
>> 12.3:time series of energy/power values
>>
>> Dear Mouli,
>>
>> Thank you for commenting on this issue. I would like to have a look at
>> the following point of view:
>>
>> So far, storing time series of measurements on managed nodes is rarely
>> standardized and rarely available as implementation.
>>
>> Typically, it is the job of a network management system to collect time
>> series and store them.
>>
>> Take for example byte and packet counters at line cards. You see many
>> curves showing time series of traffic rate/volume in the Internet, but
>> almost all of them were collected at management stations or data
>> collector modules, but not within MIB modules. (Please correct me if I'm
>> wrong.)
>>
>> Now the question is: Is energy management so much different from other
>> network management tasks, that we need the rarely used mechanism of
>> storing time series in MIB modules?
>>
>> If not, it would be sufficient to just report the number of total energy
>> consumed since the last re-start as you do it with packet and byte
>> counters.
>> This would be just a single managed object to be specified and
>> implemented.
>>
>> Thanks,
>>
>>    Juergen
>>





_______________________________________________

eman mailing list

eman@ietf.org

https://www.ietf.org/mailman/listinfo/eman



--_000_22B2909DCC2E62418BE369A1F10488994B7ABFBAex01novedacom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
 
Hi Juergen,
 
Perhaps I wasn’t=
 clear, I was suggesting we consider the existing model for timeseries data=
 as used in IEC 61850.  That is already widely used by both energy man=
agement systems and devices in the field such as revenue grade smart meters=
.
 =

Regards,
 
Brad=

 <=
/p>
From: Juergen Quittek [mailto:ietf@quit=
tek.at] 
Sent: Wednesday, August 03, 2011 5:19 AM
To: B=
rad Schoening; eman mailing list
Cc: Benoit Claise; Michael Sucho=
ff; John Parello (jparello); Juergen Quittek
Subject: Re: [eman] =
new revision of eman requirements - open issue 12.3:timeseries of energy/po=
wer values
 =
;
Hi Brad,
 
It is interestin=
g to receive explanations what the current version of the MIB module specif=
ies. 
 <=
/p>
However, we are not reverse engineering =
our requirements from the draft of the MIB module. 
We are rather investigating the requirements fi=
rst and will then specify the MIB module accordingly.
<=
div>
 
Thanks,
 <=
/p>
    Juergen
 
 
Am 03.08.2011 um =
03:28 schrieb Brad Schoening:

=

Energy & demand are an essential =
measurement of smart meters and similar devices.  It’s usually c=
omputed at the meter by sampling at the millisecond level.  Sampling k=
W by polling and then averaging values will never be close to an actual met=
ered value.  The draft-claise-energy-monitoring-mib has such a table b=
ased upon IEC 61850’s demand measurement table.  It can be empty=
, since device that don’t support kWh aren’t required to implem=
ent it.
=

 
Existing Building Management Systems and Energy Management=
 Systems already use the IEC 61850 data model, so by leveraging this model =
our data can be used and shared with these existing management systems.
&n=
bsp;
When pmEnergyParametersIntervalMode =3D ‘total’ the table works as =
an odometer.
=

 
Regards,<=
/span>
 =

Brad
 
F=
rom: Benoit Claise [mail=
to:bclaise@cisco.com] 
<=
b>Sent: Tuesday, August=
 02, 2011 11:07 AM
To: <=
/span>Brad Schoening
Cc: =
;Michael Suchoff; John Parello (jparello); Juergen Quittek; Juergen =
Quittek; eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issu=
e 12.3:timeseries of energy/power values=

 
Dear all,

Trying to combine all the =
different arguments (discussed on the mailing list and during the meeting),=
 why do we have to have to specify which time series the EMAN standard must=
 support as a pull model? <=
br>
Why not have a generic requirement, such as:
The EMAN tandard mus=
t not limit time series (for example Power, Energy, Demand) to a pull mecha=
nism; the push mechanism must be considered.

Regards, Benoit.


An e=
nergy time series is can be reported as an odometer reading.  I think =
you’ll need to be adaptable to allow either an absolute value like in=
stantaneous kW, kWh over a sample period or odometer sampling for kWh.
 =

From: eman-=
bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Michael Suchoff
Sent: Thursday, July 28, 2011 2:25 PMTo: John Parello (j=
parello); Juergen Quittek; Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] new revision of eman req=
uirements - open issue 12.3:timeseries of energy/power values
 
=

I would add current to the series as well. &nbs=
p;Most AC devices presently don’t have circuitry to report power or e=
nergy, they simply report AC current.  Also, for capacity planning, cu=
rrent is very useful (it is current that limits how many devices can be pla=
ced on an electrical branch circuit or PDU – not power).
 
Ideally, the time series would be structured as a =
table with the columns being measurements (i.e. column 1 =3D time stamp, 2 =
=3D power, 3 =3D energy, 4 =3D current, 5 =3D voltage, etc).  The colu=
mns could be partitioned into SNMP augmented tables (tables sharing same in=
dex).  This would allow easy addition of new columns for products that=
 offer more information.
 
I don’t=
 see reason for demand as a special table.  Demand (watts) is easily c=
omputed from the energy readings.  For example, if kWh =3D 1000 at 1PM=
 and kWh =3D 2000 at 1:15PM, then average power over the 15 minute interval=
 is (2000kWh – 1000kWh) * 60minutes/15minutes =3D 4kW.  Doesn=
217;t it seem a lot simpler for management program to compute demand based =
on polled energy readings (i.e. a simple SQL query) – rather than hav=
ing to write a procedure to configure the power agent to perform demand com=
putations?
 
From:<=
span class=3Dapple-converted-space> eman-bounces@ietf.org [mailt=
o:eman-bounces@ietf.org] On Behalf Of John =
Parello (jparello)
Sent: =
;Thursday, July 28, 2011 2:06 PM
To: Juergen Quittek; Juergen Quittek
Cc: eman mailing list
Subj=
ect: Re: [eman] new rev=
ision of eman requirements - open issue 12.3:timeseries of energy/power val=
ues
 =

 =

I can't vote  no when there'sand or and mor=
e on the bill.

I don't see any reason to restrict to just power. IMO=
 a series of power, energy, and demand is useful if a device can support it=
.

So no don't restrict it to just power and please allow series for =
power, demand, and energy

Jp


-----Original Message-----From: Juergen Quittek [mailto:Quitte=
k@neclab.eu]
Sent: Wed 7/27/2011 7:13 AM
To: John Parello (jparel=
lo); Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] new re=
vision of eman requirements - open issue 12.3:time series of energy/power v=
alues

Hi John,

my Question was

"Do I understand r=
ight that you would support a requirement for specifying
a standard for =
time series of power but not for time series of energy?"


I =
take you answer as a no. This would mean we keep both requirements (timeseries of power and time series of energy). Is this correct?

Thanks=
,

    Juergen


On 26.07.11 18:10, "Joh=
n Parello (jparello)" =
<jparello@cisco.com> wrote:

>
>Hi Jeur=
gen,
>
>We need to express power, energy as a measurement (scal=
ar).
>
>For time series (vector) IMO having the capability of p=
roviding power
>over time series (which is demand) or energy over tim=
e is valuable and
>should not be excluded.  Even though for ener=
gy an odometer can suffice I
>see no need to prevent this for devices=
 that have this capability.
>
>
>Please take a look at th=
e draft-claise-energy-monitoring-mib.  I think
>they did a good =
job of providing time series modeling that covers this.
>
>than=
ks
>Jp
>
>
>
>
>
>
>
>=
;
>-----Original Message-----
>From: Juergen Quittek [mailto:ietf@quittek.at]
>Sent: Tue 7/=
26/2011 12:39 PM
>To: John Parello (jparello)
>Cc: Mouli Chandr=
amouli (moulchan); eman mailing list
>Subject: Re: [eman] new revisio=
n of eman requirements - open issue
>12.3:time series of energy/power=
 values
>
>Hi John,
>
>We are currently not discuss=
ing optional or mandatory implementation.
>
>The question is wh=
ether or not we have a requirement for specifying a
>standard for rep=
orting both, energy time series and power time series, or
>just one o=
f them. What compliant devices must implement is an issue to be
>disc=
ussed later.
>
>Do I understand right that you would support a =
requirement for specifying
>a standard for time series of power but n=
ot for time series of energy?
>
>Thanks,
>
> &=
nbsp;  Juergen
>
>Am 26.07.2011 um 13:08 schrieb John Pare=
llo (jparello):
>
>> Hi Jeurgen,
>>
>> I t=
end to agree, for simple devices an energy odometer(s) as describe
>&=
gt; from the comments and what I presented from the ODVA suffices.
>&=
gt;
>> For time series of data like historical demand devices such=
 as PDUs very
>> typically store this. Some our as long as a year'=
s worth of data on the
>> device. For the very reason that Bill po=
inted out.
>>
>> So it would seem that a power value and =
an energy odometer could be a
>> required minimum and then time se=
ries of power or demand can be
>> optional.
>>
>>=
; We specified a power value as required in the monitoring mib with time>> series of power and demand as optional.
>>
>> J=
p
>>
>> -----Original Message-----
>> From: eman-bounces@ietf.org&nbs=
p;[mailto:eman-bounces@ietf=
.org] On Behalf Of
>> Juergen Quittek
>> Sent: Wednes=
day, July 13, 2011 5:53 AM
>> To: Mouli Chandramouli (moulchan)>> Cc: eman mailing list
>> Subject: Re: [eman] new revisio=
n of eman requirements - open issue
>> 12.3:time series of energy/=
power values
>>
>> Dear Mouli,
>>
>> Th=
ank you for commenting on this issue. I would like to have a look at
>=
;> the following point of view:
>>
>> So far, storing =
time series of measurements on managed nodes is rarely
>> standard=
ized and rarely available as implementation.
>>
>> Typica=
lly, it is the job of a network management system to collect time
>&g=
t; series and store them.
>>
>> Take for example byte and=
 packet counters at line cards. You see many
>> curves showing tim=
e series of traffic rate/volume in the Internet, but
>> almost all=
 of them were collected at management stations or data
>> collecto=
r modules, but not within MIB modules. (Please correct me if I'm
>>=
; wrong.)
>>
>> Now the question is: Is energy management=
 so much different from other
>> network management tasks, that we=
 need the rarely used mechanism of
>> storing time series in MIB m=
odules?
>>
>> If not, it would be sufficient to just repo=
rt the number of total energy
>> consumed since the last re-start =
as you do it with packet and byte
>> counters.
>> This wo=
uld be just a single managed object to be specified and
>> impleme=
nted.
>>
>> Thanks,
>>
>>  &n=
bsp; Juergen
>>



_____________=
__________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman=

 
= --_000_22B2909DCC2E62418BE369A1F10488994B7ABFBAex01novedacom_-- From bschoening@noveda.com Wed Aug 3 06:17:43 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F6821F87FA for ; Wed, 3 Aug 2011 06:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHydTqVq475B for ; Wed, 3 Aug 2011 06:17:43 -0700 (PDT) Received: from was1-mh219a.smtpout.com (was1-mh219a.smtpout.com [174.36.154.159]) by ietfa.amsl.com (Postfix) with ESMTP id 174F321F87E2 for ; Wed, 3 Aug 2011 06:17:43 -0700 (PDT) X-Katharion-ID: 1312377439.58620.was1-mh219 Received: from ex01.noveda.com ([66.198.105.170]) by was1-mh219.smtproutes.com [(174.36.154.108)] with ESMTP via TCP; 03 Aug 2011 08:17:19 -0500 Received: from EX01.noveda.com ([::1]) by ex01.noveda.com ([::1]) with mapi; Wed, 3 Aug 2011 09:17:19 -0400 From: Brad Schoening To: Juergen Quittek Thread-Topic: [eman] iana powerstate tc proposal Thread-Index: AQHMTUXAYR9DqA881kq9/zpdhjaDOJUKYvIwgADVQoD//+yL8A== Date: Wed, 3 Aug 2011 13:17:18 +0000 Message-ID: <22B2909DCC2E62418BE369A1F10488994B7AC026@ex01.noveda.com> References: <20110728164503.GA30392@elstar.local> <22B2909DCC2E62418BE369A1F10488994B7ABCD2@ex01.noveda.com> <4DD3FEE2-A50D-4C63-9B5E-2E53986E31FE@quittek.at> In-Reply-To: <4DD3FEE2-A50D-4C63-9B5E-2E53986E31FE@quittek.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] iana powerstate tc proposal X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:17:43 -0000 That works also! -----Original Message----- From: Juergen Quittek [mailto:ietf@quittek.at]=20 Sent: Wednesday, August 03, 2011 6:27 AM To: Brad Schoening Cc: Juergen Schoenwaelder; eman@ietf.org Subject: Re: [eman] iana powerstate tc proposal Hi Brad, It looks like it would be a good idea to register ECMA states as a separate= set at IANA once we have that registry. Thanks, Juergen Am 03.08.2011 um 04:01 schrieb Brad Schoening: > Hi Juergen, >=20 > Just wondering if it would be more relevant to use ECMA states in IANA in= stead of ieee1621? ECMA is newer, with the same basic states as 1621 but h= as additional modes that are relevant to contemporary hardware: >=20 > ECMA: >=20 > Off > Sleep > WoL Sleep=20 > ShortIdle > LongIdle > Active >=20 > 1621: >=20 > Off > Sleep > On >=20 > http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-383.pdf >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of J= uergen Schoenwaelder > Sent: Thursday, July 28, 2011 12:45 PM > To: eman@ietf.org > Subject: [eman] iana powerstate tc proposal >=20 > Hi, >=20 > here is a proposal for an IANA maintained power state textual convention.= There are of course other ways of doing this but I thought a concrete prop= osal might help the discussion. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Wed Aug 3 08:05:00 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D2021F8B6F for ; Wed, 3 Aug 2011 08:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH2Z2KMMusiM for ; Wed, 3 Aug 2011 08:04:58 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD2621F8B55 for ; Wed, 3 Aug 2011 08:04:58 -0700 (PDT) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0Lo2Ke-1RHOBh0QDA-00gR6w; Wed, 03 Aug 2011 17:05:09 +0200 References: <9C329342B62B87498B92834DEC9FF51E0D6187D8@fig.raritan.com> <22B2909DCC2E62418BE369A1F10488994B79886F@ex01.noveda.com> <4E381298.2020500@cisco.com> <22B2909DCC2E62418BE369A1F10488994B7ABC78@ex01.noveda.com> <5733C145-6B23-4014-A7BF-6E1B20505B90@quittek.at> <22B2909DCC2E62418BE369A1F10488994B7ABFBA@ex01.noveda.com> In-Reply-To: <22B2909DCC2E62418BE369A1F10488994B7ABFBA@ex01.noveda.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--930740197 Message-Id: From: Juergen Quittek Date: Wed, 3 Aug 2011 17:05:08 +0200 To: Brad Schoening X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:ce94nT//meo4OBcAcWOUel6Jish6jelfH/QwKC05scj EQuuCpPCcxLeKp9V0vkBqUsaLrDbuZRDgH/7g86WaxctRSZHu/ xNEJgxyUvaRAxW8untE4Z3bv0Jml2jJCsuTj6ADy9obmzPrwYN D6cN1L0P4/9EMQpvORRZ3y/5jR9AH0i+CeJZS1m0OwN79w9/3d JeA3mf6ZWXLzBzi4nlj/I4KXMXZJoP74jZwKiHIbFY= Cc: eman mailing list Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 15:05:00 -0000 --Apple-Mail-2--930740197 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Brad, Am 03.08.2011 um 14:37 schrieb Brad Schoening: > Hi Juergen, > =20 > Perhaps I wasn=92t clear, I was suggesting we consider the existing = model for timeseries data as used in IEC 61850. That is already widely = used by both energy management systems and devices in the field such as = revenue grade smart meters. OK. I understand. I am not against this time series data model,=20 but I would like to make one more comment: The implication you make: "IEC is 61850 commonly used" =3D> "the IEC 61850 timeseries data = model is commonly used" is not necessarily valid. IEC 61850 is a series of document of which several are widely used.=20 If some are it does not mean that all are widely used. The time series model is specified in IEC 61850-7-4 ed. 2.0. This has just been published a few months ago.=20 I would not take it for granted that this is widely used already. Thanks, Juergen > =20 > Regards, > =20 > Brad > =20 > From: Juergen Quittek [mailto:ietf@quittek.at]=20 > Sent: Wednesday, August 03, 2011 5:19 AM > To: Brad Schoening; eman mailing list > Cc: Benoit Claise; Michael Suchoff; John Parello (jparello); Juergen = Quittek > Subject: Re: [eman] new revision of eman requirements - open issue = 12.3:timeseries of energy/power values > =20 > Hi Brad, > =20 > It is interesting to receive explanations what the current version of = the MIB module specifies.=20 > =20 > However, we are not reverse engineering our requirements from the = draft of the MIB module.=20 > We are rather investigating the requirements first and will then = specify the MIB module accordingly. > =20 > Thanks, > =20 > Juergen > =20 > =20 > Am 03.08.2011 um 03:28 schrieb Brad Schoening: >=20 >=20 > Energy & demand are an essential measurement of smart meters and = similar devices. It=92s usually computed at the meter by sampling at = the millisecond level. Sampling kW by polling and then averaging values = will never be close to an actual metered value. The = draft-claise-energy-monitoring-mib has such a table based upon IEC = 61850=92s demand measurement table. It can be empty, since device that = don=92t support kWh aren=92t required to implement it. > =20 > Existing Building Management Systems and Energy Management Systems = already use the IEC 61850 data model, so by leveraging this model our = data can be used and shared with these existing management systems. > =20 > When pmEnergyParametersIntervalMode =3D =91total=92 the table works as = an odometer. > =20 > Regards, > =20 > Brad > =20 > From: Benoit Claise [mailto:bclaise@cisco.com]=20 > Sent: Tuesday, August 02, 2011 11:07 AM > To: Brad Schoening > Cc: Michael Suchoff; John Parello (jparello); Juergen Quittek; Juergen = Quittek; eman mailing list > Subject: Re: [eman] new revision of eman requirements - open issue = 12.3:timeseries of energy/power values > =20 > Dear all, >=20 > Trying to combine all the different arguments (discussed on the = mailing list and during the meeting), why do we have to have to specify = which time series the EMAN standard must support as a pull model?=20 >=20 > Why not have a generic requirement, such as: > The EMAN tandard must not limit time series (for example Power, = Energy, Demand) to a pull mechanism; the push mechanism must be = considered. >=20 > Regards, Benoit. >=20 >=20 >=20 > An energy time series is can be reported as an odometer reading. I = think you=92ll need to be adaptable to allow either an absolute value = like instantaneous kW, kWh over a sample period or odometer sampling for = kWh. > =20 > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of Michael Suchoff > Sent: Thursday, July 28, 2011 2:25 PM > To: John Parello (jparello); Juergen Quittek; Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] new revision of eman requirements - open issue = 12.3:timeseries of energy/power values > =20 > I would add current to the series as well. Most AC devices presently = don=92t have circuitry to report power or energy, they simply report AC = current. Also, for capacity planning, current is very useful (it is = current that limits how many devices can be placed on an electrical = branch circuit or PDU =96 not power). > =20 > Ideally, the time series would be structured as a table with the = columns being measurements (i.e. column 1 =3D time stamp, 2 =3D power, 3 = =3D energy, 4 =3D current, 5 =3D voltage, etc). The columns could be = partitioned into SNMP augmented tables (tables sharing same index). = This would allow easy addition of new columns for products that offer = more information. > =20 > I don=92t see reason for demand as a special table. Demand (watts) is = easily computed from the energy readings. For example, if kWh =3D 1000 = at 1PM and kWh =3D 2000 at 1:15PM, then average power over the 15 minute = interval is (2000kWh =96 1000kWh) * 60minutes/15minutes =3D 4kW. = Doesn=92t it seem a lot simpler for management program to compute demand = based on polled energy readings (i.e. a simple SQL query) =96 rather = than having to write a procedure to configure the power agent to perform = demand computations? > =20 > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of John Parello (jparello) > Sent: Thursday, July 28, 2011 2:06 PM > To: Juergen Quittek; Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] new revision of eman requirements - open issue = 12.3:timeseries of energy/power values > =20 > =20 > I can't vote no when there'sand or and more on the bill. >=20 > I don't see any reason to restrict to just power. IMO a series of = power, energy, and demand is useful if a device can support it. >=20 > So no don't restrict it to just power and please allow series for = power, demand, and energy >=20 > Jp >=20 >=20 > -----Original Message----- > From: Juergen Quittek [mailto:Quittek@neclab.eu] > Sent: Wed 7/27/2011 7:13 AM > To: John Parello (jparello); Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] new revision of eman requirements - open issue = 12.3:time series of energy/power values >=20 > Hi John, >=20 > my Question was >=20 > "Do I understand right that you would support a requirement for = specifying > a standard for time series of power but not for time series of = energy?" >=20 >=20 > I take you answer as a no. This would mean we keep both requirements = (time > series of power and time series of energy). Is this correct? >=20 > Thanks, >=20 > Juergen >=20 >=20 > On 26.07.11 18:10, "John Parello (jparello)" = wrote: >=20 > > > >Hi Jeurgen, > > > >We need to express power, energy as a measurement (scalar). > > > >For time series (vector) IMO having the capability of providing power > >over time series (which is demand) or energy over time is valuable = and > >should not be excluded. Even though for energy an odometer can = suffice I > >see no need to prevent this for devices that have this capability. > > > > > >Please take a look at the draft-claise-energy-monitoring-mib. I = think > >they did a good job of providing time series modeling that covers = this. > > > >thanks > >Jp > > > > > > > > > > > > > > > > > >-----Original Message----- > >From: Juergen Quittek [mailto:ietf@quittek.at] > >Sent: Tue 7/26/2011 12:39 PM > >To: John Parello (jparello) > >Cc: Mouli Chandramouli (moulchan); eman mailing list > >Subject: Re: [eman] new revision of eman requirements - open issue > >12.3:time series of energy/power values > > > >Hi John, > > > >We are currently not discussing optional or mandatory implementation. > > > >The question is whether or not we have a requirement for specifying a > >standard for reporting both, energy time series and power time = series, or > >just one of them. What compliant devices must implement is an issue = to be > >discussed later. > > > >Do I understand right that you would support a requirement for = specifying > >a standard for time series of power but not for time series of = energy? > > > >Thanks, > > > > Juergen > > > >Am 26.07.2011 um 13:08 schrieb John Parello (jparello): > > > >> Hi Jeurgen, > >> > >> I tend to agree, for simple devices an energy odometer(s) as = describe > >> from the comments and what I presented from the ODVA suffices. > >> > >> For time series of data like historical demand devices such as PDUs = very > >> typically store this. Some our as long as a year's worth of data on = the > >> device. For the very reason that Bill pointed out. > >> > >> So it would seem that a power value and an energy odometer could be = a > >> required minimum and then time series of power or demand can be > >> optional. > >> > >> We specified a power value as required in the monitoring mib with = time > >> series of power and demand as optional. > >> > >> Jp > >> > >> -----Original Message----- > >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On = Behalf Of > >> Juergen Quittek > >> Sent: Wednesday, July 13, 2011 5:53 AM > >> To: Mouli Chandramouli (moulchan) > >> Cc: eman mailing list > >> Subject: Re: [eman] new revision of eman requirements - open issue > >> 12.3:time series of energy/power values > >> > >> Dear Mouli, > >> > >> Thank you for commenting on this issue. I would like to have a look = at > >> the following point of view: > >> > >> So far, storing time series of measurements on managed nodes is = rarely > >> standardized and rarely available as implementation. > >> > >> Typically, it is the job of a network management system to collect = time > >> series and store them. > >> > >> Take for example byte and packet counters at line cards. You see = many > >> curves showing time series of traffic rate/volume in the Internet, = but > >> almost all of them were collected at management stations or data > >> collector modules, but not within MIB modules. (Please correct me = if I'm > >> wrong.) > >> > >> Now the question is: Is energy management so much different from = other > >> network management tasks, that we need the rarely used mechanism of > >> storing time series in MIB modules? > >> > >> If not, it would be sufficient to just report the number of total = energy > >> consumed since the last re-start as you do it with packet and byte > >> counters. > >> This would be just a single managed object to be specified and > >> implemented. > >> > >> Thanks, > >> > >> Juergen > >> >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > =20 > =20 --Apple-Mail-2--930740197 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi = Brad,

Am 03.08.2011 um 14:37 = schrieb Brad Schoening:

Hi = Juergen,
 
Perhaps I wasn=92t clear, I was = suggesting we consider the existing model for timeseries data as used in = IEC 61850.  That is already widely used by both energy management = systems and devices in the field such as revenue grade smart = meters.

OK.&nbs= p;I understand. I am not against this time series data = model, 
but I would like to make one more = comment:

The implication you = make:
    "IEC is 61850 commonly used"  =3D> = "the IEC 61850 timeseries data model is commonly = used"
is not necessarily = valid.

IEC 61850 is a series of document of = which several are widely used. 
If some are it does not = mean that all are widely used.
The time series model is = specified in IEC 61850-7-4 ed. 2.0.
This has just been = published a few months ago. 
I would not take it for = granted that this is widely used = already.

Thanks,

  =   Juergen


 
Regards,
Brad
From: Juergen Quittek = [mailto:ietf@quittek.at] 
Sent: Wednesday, August 03, 2011 = 5:19 AM
To: Brad Schoening; eman = mailing list
Cc: Benoit Claise; Michael = Suchoff; John Parello (jparello); Juergen = Quittek
Subject: Re: [eman] new revision of = eman requirements - open issue 12.3:timeseries of energy/power = values
Hi Brad,
 
It is interesting to = receive explanations what the current version of the MIB module = specifies. 
However, we are not reverse engineering our = requirements from the draft of the MIB = module. 
We are rather = investigating the requirements first and will then specify the MIB = module accordingly.
Thanks,
 
    = Juergen
 
 
Am 03.08.2011 um = 03:28 schrieb Brad Schoening:


Energy & = demand are an essential measurement of smart meters and similar = devices.  It=92s usually computed at the meter by sampling at the = millisecond level.  Sampling kW by polling and then averaging = values will never be close to an actual metered value.  The = draft-claise-energy-monitoring-mib has such a table based upon IEC = 61850=92s demand measurement table.  It can be empty, since device = that don=92t support kWh aren=92t required to implement it.
Existing = Building Management Systems and Energy Management Systems already use = the IEC 61850 data model, so by leveraging this model our data can be = used and shared with these existing management systems.
When  
From:Benoit Claise [mailto:bclaise@cisco.com] 
Sent: Tuesday, August 02, 2011 = 11:07 AM
To: Brad = Schoening
Cc: Michael Suchoff; John = Parello (jparello); Juergen Quittek; Juergen Quittek; eman mailing = list
Subject: Re: [eman] new revision of = eman requirements - open issue 12.3:timeseries of energy/power = valuesDear all,

Trying to combine all the different arguments = (discussed on the mailing list and during the meeting), why do we have = to have to specify which time series the EMAN standard must support as a = pull model? 

Why = not have a generic requirement, such as:
The EMAN tandard must not = limit time series (for example Power, Energy, Demand) to a pull = mechanism; the push mechanism must be considered.

Regards, = Benoit.



An energy time series is can be = reported as an odometer reading.  I think you=92ll need to be = adaptable to allow either an absolute value like instantaneous kW, kWh = over a sample period or odometer sampling for kWh.
 
eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Michael = Suchoff
Sent: Thursday, July 28, 2011 = 2:25 PM
To: John Parello (jparello); = Juergen Quittek; Juergen Quittek
Cc: eman mailing = list
Subject: Re: [eman] new revision of = eman requirements - open issue 12.3:timeseries of energy/power = values
 
 
eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of John Parello = (jparello)
Sent: Thursday, July 28, 2011 = 2:06 PM
To: Juergen Quittek; Juergen = Quittek
Cc: eman mailing = list
Subject: Re: [eman] new revision of = eman requirements - open issue 12.3:timeseries of energy/power = values 
I can't vote  no when there'sand or and more on the = bill.

I don't see any reason to restrict to just power. IMO a = series of power, energy, and demand is useful if a device can support = it.

So no don't restrict it to just power and please allow series = for power, demand, and energy

Jp


-----Original = Message-----
From: Juergen Quittek [mailto:Quittek@neclab.eu]
Sent: Wed 7/27/2011 7:13 = AM
To: John Parello (jparello); Juergen Quittek
Cc: eman mailing = list
Subject: Re: [eman] new revision of eman requirements - open = issue 12.3:time series of energy/power values

Hi John,

my = Question was

"Do I understand right that you would support a = requirement for specifying
a standard for time series of power but = not for time series of energy?"


I take you answer as a no. = This would mean we keep both requirements (time
series of power and = time series of energy). Is this = correct?

Thanks,

    Juergen


On = 26.07.11 18:10, "John Parello (jparello)" <jparello@cisco.com> wrote:

>
>Hi = Jeurgen,
>
>We need to express power, energy as a = measurement (scalar).
>
>For time series (vector) IMO having = the capability of providing power
>over time series (which is = demand) or energy over time is valuable and
>should not be = excluded.  Even though for energy an odometer can suffice = I
>see no need to prevent this for devices that have this = capability.
>
>
>Please take a look at the = draft-claise-energy-monitoring-mib.  I think
>they did a good = job of providing time series modeling that covers = this.
>
>thanks
>Jp
>
>
>
>
&= gt;
>
>
>
>-----Original = Message-----
>From: Juergen Quittek [mailto:ietf@quittek.at]
>Sent: Tue 7/26/2011 = 12:39 PM
>To: John Parello (jparello)
>Cc: Mouli = Chandramouli (moulchan); eman mailing list
>Subject: Re: [eman] = new revision of eman requirements - open issue
>12.3:time series = of energy/power values
>
>Hi John,
>
>We are = currently not discussing optional or mandatory = implementation.
>
>The question is whether or not we have a = requirement for specifying a
>standard for reporting both, energy = time series and power time series, or
>just one of them. What = compliant devices must implement is an issue to be
>discussed = later.
>
>Do I understand right that you would support a = requirement for specifying
>a standard for time series of power = but not for time series of = energy?
>
>Thanks,
>
>    = Juergen
>
>Am 26.07.2011 um 13:08 schrieb John Parello = (jparello):
>
>> Hi Jeurgen,
>>
>> I = tend to agree, for simple devices an energy odometer(s) as = describe
>> from the comments and what I presented from the = ODVA suffices.
>>
>> For time series of data like = historical demand devices such as PDUs very
>> typically store = this. Some our as long as a year's worth of data on the
>> = device. For the very reason that Bill pointed = out.
>>
>> So it would seem that a power value and an = energy odometer could be a
>> required minimum and then time = series of power or demand can be
>> = optional.
>>
>> We specified a power value as required = in the monitoring mib with time
>> series of power and demand = as optional.
>>
>> Jp
>>
>> = -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On = Behalf Of
>> Juergen Quittek
>> Sent: Wednesday, July = 13, 2011 5:53 AM
>> To: Mouli Chandramouli = (moulchan)
>> Cc: eman mailing list
>> Subject: Re: = [eman] new revision of eman requirements - open issue
>> = 12.3:time series of energy/power values
>>
>> Dear = Mouli,
>>
>> Thank you for commenting on this issue. I = would like to have a look at
>> the following point of = view:
>>
>> So far, storing time series of = measurements on managed nodes is rarely
>> standardized and = rarely available as implementation.
>>
>> Typically, = it is the job of a network management system to collect time
>> = series and store them.
>>
>> Take for example byte and = packet counters at line cards. You see many
>> curves showing = time series of traffic rate/volume in the Internet, but
>> = almost all of them were collected at management stations or = data
>> collector modules, but not within MIB modules. (Please = correct me if I'm
>> wrong.)
>>
>> Now the = question is: Is energy management so much different from = other
>> network management tasks, that we need the rarely used = mechanism of
>> storing time series in MIB = modules?
>>
>> If not, it would be sufficient to just = report the number of total energy
>> consumed since the last = re-start as you do it with packet and byte
>> = counters.
>> This would be just a single managed object to be = specified and
>> implemented.
>>
>> = Thanks,
>>
>>    = Juergen
>>



eman mailing =
list
eman@ietf.org
 

<= /div>
= --Apple-Mail-2--930740197-- From ietf@quittek.at Wed Aug 3 09:32:59 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C3721F8686 for ; Wed, 3 Aug 2011 09:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4YWgvteHEoq for ; Wed, 3 Aug 2011 09:32:58 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6FC21F8678 for ; Wed, 3 Aug 2011 09:32:58 -0700 (PDT) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MSYbs-1QyS0M44xg-00SEDT; Wed, 03 Aug 2011 18:33:07 +0200 References: <20110728164503.GA30392@elstar.local> In-Reply-To: <20110728164503.GA30392@elstar.local> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Wed, 3 Aug 2011 18:33:06 +0200 To: eman mailing list X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:CFZNnM3lHoFZjsJrgO7JfpoL0lsh+eIjQyD3AEVEQwF YtK83vZflVLTYzlEK6YKclz0OYqu5L/qeMNjZISBWQcmMoXG4i Jp484fUT29wCc1IfLSdFLyOSK4jaqSGhhJ2wk99J1MMshRvzAv s32KISUGWiGnhIALGid5Wa0Ned9noj/uU07+gtpBj8RYOfCxdm 1lof14dxA9UMgjFE+FD2HN1+ojKEOLNRuAFR+Uw7YU= Subject: Re: [eman] iana powerstate tc proposal X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 16:32:59 -0000 Dear all, There is already a long email thread on this issue. Here is my view on it: The TC that Juergen S. suggested has two definite advantages: - it encodes state series and index in a single value - it needs a single IANA registry only Otherwise, there is no big difference to the other proposal. The single value for set and state is particularly convenient=20 for reading and setting power states. So, I would agree on such a TC.=20 Probably the SYNTAX clause would have to be replaced,=20 because numbers for states and sets would be registered at IANA and not = in the TC. We had several comments on the list suggesting that other values might = be more appropriate. But I assume the values in the TC served rather as examples than as = proposals for the final values to be chosen. Thanks, Juergen Q. would be registered at IANA Am 28.07.2011 um 18:45 schrieb Juergen = Schoenwaelder: > Hi, >=20 > here is a proposal for an IANA maintained power state textual > convention. There are of course other ways of doing this but I thought > a concrete proposal might help the discussion. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > = _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From bnordman@lbl.gov Wed Aug 3 22:21:11 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717D511E80E1 for ; Wed, 3 Aug 2011 22:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eq43HyVfHe64 for ; Wed, 3 Aug 2011 22:21:10 -0700 (PDT) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 76C4111E80A6 for ; Wed, 3 Aug 2011 22:21:09 -0700 (PDT) X-Ironport-SBRS: 4.4 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0AABcsOk5KfVM0kGdsb2JhbAA4BwOCTZU9hzaHN2UIFAEBAQEJCQ0HFAQhgUABAQEBAQEBAQEBDwJaCwUHAgILCwMCAQQBASgHGwcFDQEFAQsJCAYTIodKBKNnCp1CAoMiGoMEBIdaiyGMTDyDfA X-IronPort-AV: E=Sophos;i="4.67,315,1309762800"; d="scan'208";a="47665851" Received: from mail-gw0-f52.google.com ([74.125.83.52]) by ironport4.lbl.gov with ESMTP; 03 Aug 2011 22:21:01 -0700 Received: by gwj15 with SMTP id 15so833270gwj.39 for ; Wed, 03 Aug 2011 22:21:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.163.16 with SMTP id q16mr274701ano.76.1312435261240; Wed, 03 Aug 2011 22:21:01 -0700 (PDT) Received: by 10.100.11.20 with HTTP; Wed, 3 Aug 2011 22:21:01 -0700 (PDT) In-Reply-To: <22B2909DCC2E62418BE369A1F10488994B7ABCD2@ex01.noveda.com> References: <20110728164503.GA30392@elstar.local> <22B2909DCC2E62418BE369A1F10488994B7ABCD2@ex01.noveda.com> Date: Wed, 3 Aug 2011 22:21:01 -0700 Message-ID: From: Bruce Nordman To: Brad Schoening Content-Type: multipart/alternative; boundary=0016e68ee4da8974b004a9a725a4 Cc: "eman@ietf.org" Subject: Re: [eman] iana powerstate tc proposal X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 05:21:11 -0000 --0016e68ee4da8974b004a9a725a4 Content-Type: text/plain; charset=ISO-8859-1 To be clear, Ecma 383 defines a measurement procedure to identify power levels at different points in time. It does not identify power states that are to be exposed to other entities. It also is intended only for personal computers. I offer this observation as someone involved in 383 development. By contrast, IEEE 1621 defines power states of devices as they are to be exposed to other entities (in this case, people). It is also for any electronic device, not just PCs. So, for reporting of power states, and for not being device-specific, IEEE 1621 seems more appropriate for EMAN. If one wants to be PC-specific, and to have more states, then ACPI or DMTF is a good choice, as our drafts already note. --Bruce On Tue, Aug 2, 2011 at 7:01 PM, Brad Schoening wrote: > Hi Juergen, > > Just wondering if it would be more relevant to use ECMA states in IANA > instead of ieee1621? ECMA is newer, with the same basic states as 1621 but > has additional modes that are relevant to contemporary hardware: > > ECMA: > > Off > Sleep > WoL Sleep > ShortIdle > LongIdle > Active > > 1621: > > Off > Sleep > On > > http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-383.pdf > > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder > Sent: Thursday, July 28, 2011 12:45 PM > To: eman@ietf.org > Subject: [eman] iana powerstate tc proposal > > Hi, > > here is a proposal for an IANA maintained power state textual convention. > There are of course other ways of doing this but I thought a concrete > proposal might help the discussion. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > -- *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --0016e68ee4da8974b004a9a725a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable To be clear, Ecma 383 defines a measurement procedure
to identify power = levels at different points in time.=A0 It does
not identify power states= that are to be exposed to other
entities.=A0 It also is intended only f= or personal computers.
I offer this observation as someone involved in 383 development.

By = contrast, IEEE 1621 defines power states of devices as
they are to be ex= posed to other entities (in this case, people).
It is also for any elect= ronic device, not just PCs.

So, for reporting of power states, and for not being device-specific,IEEE 1621 seems more appropriate for EMAN.=A0 If one wants
to be PC-sp= ecific, and to have more states, then ACPI or DMTF
is a good choice, as = our drafts already note.

--Bruce

On Tue, Aug 2, 2011 at 7:01 P= M, Brad Schoening <bschoening@noveda.com> wrote:
Hi Juergen,

Just wondering if it would be more relevant to use ECMA states in IANA inst= ead of ieee1621? =A0ECMA is newer, with the same basic states as 1621 but h= as additional modes that are relevant to contemporary hardware:

ECMA:

=A0 =A0 =A0 =A0Off
=A0 =A0 =A0 =A0Sleep
=A0 =A0 =A0 =A0WoL Sleep
=A0 =A0 =A0 =A0ShortIdle
=A0 =A0 =A0 =A0LongIdle
=A0 =A0 =A0 =A0Active

1621:

=A0 =A0 =A0 =A0Off
=A0 =A0 =A0 =A0Sleep
=A0 =A0 =A0 =A0On

http://www.ecma-international.org/publications= /files/ECMA-ST/ECMA-383.pdf

-----Original Message-----
From: eman-bounces@ietf.org [m= ailto:eman-bounces@ietf.org] O= n Behalf Of Juergen Schoenwaelder
Sent: Thursday, July 28, 2011 12:45 PM
To: eman@ietf.org
Subject: [eman] iana powerstate tc = proposal

Hi,

here is a proposal for an IANA maintained power state textual convention. T= here are of course other ways of doing this but I thought a concrete propos= al might help the discussion.

/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49= 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany
Fax: =A0 += 49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>

_____________________________= __________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman



--
Bruce Nordman
= Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--0016e68ee4da8974b004a9a725a4-- From bclaise@cisco.com Thu Aug 4 01:31:17 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FF321F8B92 for ; Thu, 4 Aug 2011 01:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2p4Pxu7Pg6O for ; Thu, 4 Aug 2011 01:31:16 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2812A21F8B74 for ; Thu, 4 Aug 2011 01:31:16 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p748NuQd006638; Thu, 4 Aug 2011 10:23:56 +0200 (CEST) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p748NtcT026259; Thu, 4 Aug 2011 10:23:56 +0200 (CEST) Message-ID: <4E3A571B.4040105@cisco.com> Date: Thu, 04 Aug 2011 10:23:55 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: eman mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eman] Draft minutes uploaded X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 08:31:17 -0000 Dear all, The draft minutes have been uploaded: http://www.ietf.org/proceedings/81/minutes/eman.txt Thanks a lot to Bill Mielke for the excellent notes. Please review for errors or omissions. Thank you, Bruce and Benoit. From bschoening@noveda.com Thu Aug 4 05:07:05 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D7B21F8B0E for ; Thu, 4 Aug 2011 05:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRjHLf1NhJPg for ; Thu, 4 Aug 2011 05:07:02 -0700 (PDT) Received: from cal3-mh481-a.smtproutes.com (cal3-mh481-a.smtproutes.com [208.70.89.235]) by ietfa.amsl.com (Postfix) with ESMTP id 9151C21F8B03 for ; Thu, 4 Aug 2011 05:06:55 -0700 (PDT) X-Katharion-ID: 1312459603.38771.cal3-mh481 Received: from ex01.noveda.com ([66.198.105.170]) by cal3-mh481.smtproutes.com [(208.70.89.155)] with ESMTP via TCP; 04 Aug 2011 05:06:43 -0700 Received: from EX01.noveda.com ([::1]) by ex01.noveda.com ([::1]) with mapi; Thu, 4 Aug 2011 08:06:43 -0400 From: Brad Schoening To: Bruce Nordman Thread-Topic: [eman] iana powerstate tc proposal Thread-Index: AQHMTUXAYR9DqA881kq9/zpdhjaDOJUKYvIwgAISKYCAACbIcA== Date: Thu, 4 Aug 2011 12:06:42 +0000 Message-ID: <22B2909DCC2E62418BE369A1F10488994B7ADCA6@ex01.noveda.com> References: <20110728164503.GA30392@elstar.local> <22B2909DCC2E62418BE369A1F10488994B7ABCD2@ex01.noveda.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_22B2909DCC2E62418BE369A1F10488994B7ADCA6ex01novedacom_" MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] iana powerstate tc proposal X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 12:07:05 -0000 --_000_22B2909DCC2E62418BE369A1F10488994B7ADCA6ex01novedacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bruce, The reason I see ECMA offering enhanced power states is their notion of Idl= e vs Active. For devices such as a printer, toaster, water heater, or ind= ustrial equipment, a device can be "on" in the IEEE 1621 model, but consumi= ng minimal energy vs on and actively consuming its rated load. As far as exposing these states to management entities, it seems reasonable= that an energy management system would like to know when it reads the kW i= f the device is 'Acitve' or 'Idle' instead of just 'On'. ECMA section 5.2 defines 'Power modes'. It cross references these with man= y ACPI power states ("For products where ACPI standards are applicable, off= mode correlates to ACPI system level S5 state"). As you mention, it does = also discuss power measurements in each of these modes. For example, "5.2.4 The on mode represents the mode the EUT is in when not in the sleep = or off modes. The on mode has several sub-modes that include the long idle = mode, the short idle mode and the active (work) mode." The 6 modes in the ECMA model offer a richer, but yet still concise model t= hat can fill the gap between the rudimentary 1621's 3 states and the propos= ed 12 states in the EMAN model while at the same time harmonizing with thos= e other models. Finally, while ECMA was targeted at desktop and notebook PC's, their modes = seem equally applicable to intelligent devices managed with embedded contro= llers. Regards, Brad From: Bruce Nordman [mailto:bnordman@lbl.gov] Sent: Thursday, August 04, 2011 1:21 AM To: Brad Schoening Cc: eman@ietf.org Subject: Re: [eman] iana powerstate tc proposal To be clear, Ecma 383 defines a measurement procedure to identify power levels at different points in time. It does not identify power states that are to be exposed to other entities. It also is intended only for personal computers. I offer this observation as someone involved in 383 development. By contrast, IEEE 1621 defines power states of devices as they are to be exposed to other entities (in this case, people). It is also for any electronic device, not just PCs. So, for reporting of power states, and for not being device-specific, IEEE 1621 seems more appropriate for EMAN. If one wants to be PC-specific, and to have more states, then ACPI or DMTF is a good choice, as our drafts already note. --Bruce On Tue, Aug 2, 2011 at 7:01 PM, Brad Schoening > wrote: Hi Juergen, Just wondering if it would be more relevant to use ECMA states in IANA inst= ead of ieee1621? ECMA is newer, with the same basic states as 1621 but has= additional modes that are relevant to contemporary hardware: ECMA: Off Sleep WoL Sleep ShortIdle LongIdle Active 1621: Off Sleep On http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-383.pdf -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-boun= ces@ietf.org] On Behalf Of Juergen Schoenwael= der Sent: Thursday, July 28, 2011 12:45 PM To: eman@ietf.org Subject: [eman] iana powerstate tc proposal Hi, here is a proposal for an IANA maintained power state textual convention. T= here are of course other ways of doing this but I thought a concrete propos= al might help the discussion. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1= , 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman -- Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --_000_22B2909DCC2E62418BE369A1F10488994B7ADCA6ex01novedacom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bruce,=

 <= /p>

The reason I see ECMA offering enhanced powe= r states is their notion of Idle vs Active.   For devices such as= a printer, toaster, water heater, or industrial equipment, a device can be= “on” in the IEEE 1621 model, but consuming minimal energy vs o= n and actively consuming its rated load.

 

As f= ar as exposing these states to management entities, it seems reasonable tha= t an energy management system would like to know when it reads the kW if th= e device is ‘Acitve’ or ‘Idle’  instead of jus= t ‘On’.

 

ECMA section 5.2 define= s ‘Power modes’.  It cross references these with many ACPI= power states (“For products where ACPI standards are applicable, off= mode correlates to ACPI system level S5 state”).  As you mentio= n, it does also discuss power measurements in each of these modes.

For example,

 

“5.2.4 The on mode represents the mode the EUT is in when= not in the sleep or off modes. The on mode has several sub-modes that incl= ude the long idle mode, the short idle mode and the active (work) mode.R= 21;

 

The 6 modes in the ECMA model offer a ric= her, but yet still concise model that can fill the gap between the rudiment= ary 1621’s 3 states and the proposed 12 states in the EMAN model whil= e at the same time harmonizing with those other models.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>Finally, while ECMA was targeted at desktop and notebook PC’s, = their modes seem equally applicable to intelligent devices managed with emb= edded controllers.

&n= bsp;

Regards,=

 

Brad

&n= bsp;

From: Bruce Nordman [mai= lto:bnordman@lbl.gov]
Sent: Thursday, August 04, 2011 1:21 AMTo: Brad Schoening
Cc: eman@ietf.org
Subject: R= e: [eman] iana powerstate tc proposal

 

To be clear, Ecma 383 defines a measurement procedure
to iden= tify power levels at different points in time.  It does
not identif= y power states that are to be exposed to other
entities.  It also i= s intended only for personal computers.
I offer this observation as some= one involved in 383 development.

By contrast, IEEE 1621 defines powe= r states of devices as
they are to be exposed to other entities (in this= case, people).
It is also for any electronic device, not just PCs.
<= br>So, for reporting of power states, and for not being device-specific,IEEE 1621 seems more appropriate for EMAN.  If one wants
to be PC-= specific, and to have more states, then ACPI or DMTF
is a good choice, a= s our drafts already note.

--Bruce

On Tue, Aug 2, 2011 at 7:01 PM, Brad Schoening <bschoening@noveda.com> wrote:

=

Hi Juergen,

Just wondering if it would be more = relevant to use ECMA states in IANA instead of ieee1621?  ECMA is newe= r, with the same basic states as 1621 but has additional modes that are rel= evant to contemporary hardware:

ECMA:

      &n= bsp;Off
       Sleep
       W= oL Sleep
       ShortIdle
      &n= bsp;LongIdle
       Active

1621:

 = ;      Off
       Sleep
  &nb= sp;    On

http://www.ecma-int= ernational.org/publications/files/ECMA-ST/ECMA-383.pdf


-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juerg= en Schoenwaelder
Sent: Thursday, July 28, 2011 12:45 PM
To: eman@ietf.org

<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>Subject: [eman] iana pow= erstate tc proposal

Hi,

here is a proposal for an IANA mainta= ined power state textual convention. There are of course other ways of doin= g this but I thought a concrete proposal might help the discussion.

= /js

--
Juergen Schoenwaelder           J= acobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759= Bremen, Germany
Fax:   +4= 9 421 200 3103         <http://www.jacobs-university.de/= >

_____________= __________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/e= man




--
Bruce Nordman
Lawrence= Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
BNordman@LBL.gov510-486-7089
m: 510-501-7943

= --_000_22B2909DCC2E62418BE369A1F10488994B7ADCA6ex01novedacom_-- From j.schoenwaelder@jacobs-university.de Thu Aug 4 11:54:17 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B978B21F8BA7 for ; Thu, 4 Aug 2011 11:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.081 X-Spam-Level: X-Spam-Status: No, score=-103.081 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRO9Ggcz+wa7 for ; Thu, 4 Aug 2011 11:54:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A372A21F8B5A for ; Thu, 4 Aug 2011 11:54:15 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3546C20C26; Thu, 4 Aug 2011 20:54:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7APXD8o+Y6sl; Thu, 4 Aug 2011 20:54:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B51C20C25; Thu, 4 Aug 2011 20:54:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D89DA1A28955; Thu, 4 Aug 2011 20:54:22 +0200 (CEST) Date: Thu, 4 Aug 2011 20:54:22 +0200 From: Juergen Schoenwaelder To: Juergen Quittek Message-ID: <20110804185422.GC2243@elstar.local> Mail-Followup-To: Juergen Quittek , eman mailing list References: <20110728164503.GA30392@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] iana powerstate tc proposal X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 18:54:17 -0000 On Wed, Aug 03, 2011 at 06:33:06PM +0200, Juergen Quittek wrote: > Probably the SYNTAX clause would have to be replaced, > because numbers for states and sets would be registered at IANA and not in the TC. IANA would manage the MIB module with TC and this has been working well for years with other number spaces IANA manages, for example the interface type TC. IANA does any magic needed once specified. I actually find it highly useful to have concrete named-numbers allocated. > We had several comments on the list suggesting that other values might be more appropriate. > But I assume the values in the TC served rather as examples than as proposals > for the final values to be chosen. Exactly. I blindly copied values from draft-claise-energy-monitoring-mib-09.txt from demonstration purposes. The energy management experts need to find out what suitable power state series are - I am just a MIB guy. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jparello@cisco.com Thu Aug 4 15:30:05 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0206A22800E for ; Thu, 4 Aug 2011 15:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HT9uvNCajXlp for ; Thu, 4 Aug 2011 15:30:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF6922800D for ; Thu, 4 Aug 2011 15:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=29518; q=dns/txt; s=iport; t=1312497016; x=1313706616; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=wv0NsGEDIIpxHRwWURP+LdurK7R+6iKkcl6A/McxwoU=; b=lVX5FcGn05JBelxnmqRGFNuDYsy/23jGqqKe5pRFjV9+d3W8/C5XaY4p ++KngSnlORAAJ1NjTrQfFAfBp0wFZej/2DYZJlcLwUyqQe1+WLiEPhrXA Leyj8vC8rpVJZo267pQuUMoAyPPX6aIzACxihpdmhasNJqtroItpZ7tJr E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AAAcdO06rRDoI/2dsb2JhbABDgk2VQY9cd4FAAQEBAQMBAQEPAQkRAz4LDAQCAQgOAwQBAQsGEAcBBgEmHwkIAgQBEggah06iYAGeXoVjXwSHWpAxi3Q X-IronPort-AV: E=Sophos;i="4.67,320,1309737600"; d="scan'208,217";a="9822550" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-5.cisco.com with ESMTP; 04 Aug 2011 22:30:13 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p74MUCmS017119; Thu, 4 Aug 2011 22:30:12 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 15:30:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC52F6.12D6AB65" Date: Thu, 4 Aug 2011 15:28:51 -0700 Message-ID: In-Reply-To: <22B2909DCC2E62418BE369A1F10488994B7ABC78@ex01.noveda.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] new revision of eman requirements - open issue12.3:timeseries of energy/power values Thread-Index: AQHMTGdebe5iwHf9hECy9RtMmcgg7pUCCSPVgAABTtCAAELfkIAHqJwAgABTndCAAwhSwA== References: <9C329342B62B87498B92834DEC9FF51E0D6187D8@fig.raritan.com> <22B2909DCC2E62418BE369A1F10488994B79886F@ex01.noveda.com> <4E381298.2020500@cisco.com> <22B2909DCC2E62418BE369A1F10488994B7ABC78@ex01.noveda.com> From: "John Parello (jparello)" To: "Brad Schoening" , "Benoit Claise (bclaise)" X-OriginalArrivalTime: 04 Aug 2011 22:30:12.0690 (UTC) FILETIME=[13587B20:01CC52F6] Cc: eman mailing list Subject: Re: [eman] new revision of eman requirements - open issue12.3:timeseries of energy/power values X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 22:30:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC52F6.12D6AB65 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 on this. =20 As per our charter we should be investigating existing standards. The standard used by revenue grade meters around the world should be examined. =20 Having time series of power (demand) which matches existing standards used by a preponderance of utility meters should be a requirement. =20 Jp =20 From: Brad Schoening [mailto:bschoening@noveda.com]=20 Sent: Tuesday, August 02, 2011 6:29 PM To: Benoit Claise (bclaise) Cc: Michael Suchoff; John Parello (jparello); Juergen Quittek; Juergen Quittek; eman mailing list Subject: RE: [eman] new revision of eman requirements - open issue12.3:timeseries of energy/power values =20 Energy & demand are an essential measurement of smart meters and similar devices. It's usually computed at the meter by sampling at the millisecond level. Sampling kW by polling and then averaging values will never be close to an actual metered value. The draft-claise-energy-monitoring-mib has such a table based upon IEC 61850's demand measurement table. It can be empty, since device that don't support kWh aren't required to implement it. =20 Existing Building Management Systems and Energy Management Systems already use the IEC 61850 data model, so by leveraging this model our data can be used and shared with these existing management systems. =20 When pmEnergyParametersIntervalMode =3D 'total' the table works as an odometer. =20 Regards, =20 Brad =20 From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Tuesday, August 02, 2011 11:07 AM To: Brad Schoening Cc: Michael Suchoff; John Parello (jparello); Juergen Quittek; Juergen Quittek; eman mailing list Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values =20 Dear all, Trying to combine all the different arguments (discussed on the mailing list and during the meeting), why do we have to have to specify which time series the EMAN standard must support as a pull model?=20 Why not have a generic requirement, such as: The EMAN tandard must not limit time series (for example Power, Energy, Demand) to a pull mechanism; the push mechanism must be considered. Regards, Benoit. An energy time series is can be reported as an odometer reading. I think you'll need to be adaptable to allow either an absolute value like instantaneous kW, kWh over a sample period or odometer sampling for kWh. =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Michael Suchoff Sent: Thursday, July 28, 2011 2:25 PM To: John Parello (jparello); Juergen Quittek; Juergen Quittek Cc: eman mailing list Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values =20 I would add current to the series as well. Most AC devices presently don't have circuitry to report power or energy, they simply report AC current. Also, for capacity planning, current is very useful (it is current that limits how many devices can be placed on an electrical branch circuit or PDU - not power). =20 Ideally, the time series would be structured as a table with the columns being measurements (i.e. column 1 =3D time stamp, 2 =3D power, 3 =3D = energy, 4 =3D current, 5 =3D voltage, etc). The columns could be partitioned into SNMP augmented tables (tables sharing same index). This would allow easy addition of new columns for products that offer more information. =20 I don't see reason for demand as a special table. Demand (watts) is easily computed from the energy readings. For example, if kWh =3D 1000 = at 1PM and kWh =3D 2000 at 1:15PM, then average power over the 15 minute interval is (2000kWh - 1000kWh) * 60minutes/15minutes =3D 4kW. Doesn't = it seem a lot simpler for management program to compute demand based on polled energy readings (i.e. a simple SQL query) - rather than having to write a procedure to configure the power agent to perform demand computations? =20 ________________________________ From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of John Parello (jparello) Sent: Thursday, July 28, 2011 2:06 PM To: Juergen Quittek; Juergen Quittek Cc: eman mailing list Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values =20 =20 I can't vote no when there'sand or and more on the bill. I don't see any reason to restrict to just power. IMO a series of power, energy, and demand is useful if a device can support it. So no don't restrict it to just power and please allow series for power, demand, and energy Jp -----Original Message----- From: Juergen Quittek [mailto:Quittek@neclab.eu] Sent: Wed 7/27/2011 7:13 AM To: John Parello (jparello); Juergen Quittek Cc: eman mailing list Subject: Re: [eman] new revision of eman requirements - open issue 12.3:time series of energy/power values Hi John, my Question was "Do I understand right that you would support a requirement for specifying a standard for time series of power but not for time series of energy?" I take you answer as a no. This would mean we keep both requirements (time series of power and time series of energy). Is this correct? Thanks, Juergen On 26.07.11 18:10, "John Parello (jparello)" wrote: > >Hi Jeurgen, > >We need to express power, energy as a measurement (scalar). > >For time series (vector) IMO having the capability of providing power >over time series (which is demand) or energy over time is valuable and >should not be excluded. Even though for energy an odometer can suffice I >see no need to prevent this for devices that have this capability. > > >Please take a look at the draft-claise-energy-monitoring-mib. I think >they did a good job of providing time series modeling that covers this. > >thanks >Jp > > > > > > > > >-----Original Message----- >From: Juergen Quittek [mailto:ietf@quittek.at] >Sent: Tue 7/26/2011 12:39 PM >To: John Parello (jparello) >Cc: Mouli Chandramouli (moulchan); eman mailing list >Subject: Re: [eman] new revision of eman requirements - open issue >12.3:time series of energy/power values > >Hi John, > >We are currently not discussing optional or mandatory implementation. > >The question is whether or not we have a requirement for specifying a >standard for reporting both, energy time series and power time series, or >just one of them. What compliant devices must implement is an issue to be >discussed later. > >Do I understand right that you would support a requirement for specifying >a standard for time series of power but not for time series of energy? > >Thanks, > > Juergen > >Am 26.07.2011 um 13:08 schrieb John Parello (jparello): > >> Hi Jeurgen, >> >> I tend to agree, for simple devices an energy odometer(s) as describe >> from the comments and what I presented from the ODVA suffices. >> >> For time series of data like historical demand devices such as PDUs very >> typically store this. Some our as long as a year's worth of data on the >> device. For the very reason that Bill pointed out. >> >> So it would seem that a power value and an energy odometer could be a >> required minimum and then time series of power or demand can be >> optional. >> >> We specified a power value as required in the monitoring mib with time >> series of power and demand as optional. >> >> Jp >> >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of >> Juergen Quittek >> Sent: Wednesday, July 13, 2011 5:53 AM >> To: Mouli Chandramouli (moulchan) >> Cc: eman mailing list >> Subject: Re: [eman] new revision of eman requirements - open issue >> 12.3:time series of energy/power values >> >> Dear Mouli, >> >> Thank you for commenting on this issue. I would like to have a look at >> the following point of view: >> >> So far, storing time series of measurements on managed nodes is rarely >> standardized and rarely available as implementation. >> >> Typically, it is the job of a network management system to collect time >> series and store them. >> >> Take for example byte and packet counters at line cards. You see many >> curves showing time series of traffic rate/volume in the Internet, but >> almost all of them were collected at management stations or data >> collector modules, but not within MIB modules. (Please correct me if I'm >> wrong.) >> >> Now the question is: Is energy management so much different from other >> network management tasks, that we need the rarely used mechanism of >> storing time series in MIB modules? >> >> If not, it would be sufficient to just report the number of total energy >> consumed since the last re-start as you do it with packet and byte >> counters. >> This would be just a single managed object to be specified and >> implemented. >> >> Thanks, >> >> Juergen >> _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman =20 ------_=_NextPart_001_01CC52F6.12D6AB65 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [eman] new revision of eman requirements = - open issue 12.3:time series of energy/power values

+1 on this.

 

As per our charter we should be investigating existing standards. The = standard used by revenue grade meters around the world should be = examined.

 

Having time series of power (demand) which matches existing standards = used by a preponderance of utility meters should be a = requirement.

 

Jp

 

From: Brad Schoening [mailto:bschoening@noveda.com]
Sent: = Tuesday, August 02, 2011 6:29 PM
To: Benoit Claise = (bclaise)
Cc: Michael Suchoff; John Parello (jparello); = Juergen Quittek; Juergen Quittek; eman mailing list
Subject: = RE: [eman] new revision of eman requirements - open issue12.3:timeseries = of energy/power values

 

Energy & demand are an essential measurement of smart meters and = similar devices.  It’s usually computed at the meter by = sampling at the millisecond level.  Sampling kW by polling and then = averaging values will never be close to an actual metered value.  = The draft-claise-energy-monitoring-mib has such a table based upon IEC = 61850’s demand measurement table.  It can be empty, since = device that don’t support kWh aren’t required to implement = it.

 

Existing Building Management Systems and Energy Management Systems = already use the IEC 61850 data model, so by leveraging this model our = data can be used and shared with these existing management = systems.

 

When pmEnergyParamete= rsIntervalMode =3D ‘total’ the table works as an = odometer.

 

Regards,

 

Brad

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, = August 02, 2011 11:07 AM
To: Brad Schoening
Cc: = Michael Suchoff; John Parello (jparello); Juergen Quittek; Juergen = Quittek; eman mailing list
Subject: Re: [eman] new revision of = eman requirements - open issue 12.3:timeseries of energy/power = values

 

Dear all,

Trying to combine all = the different arguments (discussed on the mailing list and during the = meeting), why do we have to have to specify which time series the EMAN = standard must support as a pull model?

Why not have a generic = requirement, such as:
The EMAN tandard must not limit time series = (for example Power, Energy, Demand) to a pull mechanism; the push = mechanism must be considered.

Regards, = Benoit.

An energy time series is can be reported as an odometer = reading.  I think you’ll need to be adaptable to allow either = an absolute value like instantaneous kW, kWh over a sample period or = odometer sampling for kWh.

 

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] = On Behalf Of Michael Suchoff
Sent: Thursday, July 28, = 2011 2:25 PM
To: John Parello (jparello); Juergen Quittek; = Juergen Quittek
Cc: eman mailing list
Subject: Re: = [eman] new revision of eman requirements - open issue 12.3:timeseries of = energy/power values

 

I = would add current to the series as well.  Most AC devices presently = don’t have circuitry to report power or energy, they simply report = AC current.  Also, for capacity planning, current is very useful = (it is current that limits how many devices can be placed on an = electrical branch circuit or PDU – not = power).

&n= bsp;

Id= eally, the time series would be structured as a table with the columns = being measurements (i.e. column 1 =3D time stamp, 2 =3D power, 3 =3D = energy, 4 =3D current, 5 =3D voltage, etc).  The columns could be = partitioned into SNMP augmented tables (tables sharing same index). =  This would allow easy addition of new columns for products that = offer more information.

&n= bsp;

I = don’t see reason for demand as a special table.  Demand = (watts) is easily computed from the energy readings.  For example, = if kWh =3D 1000 at 1PM and kWh =3D 2000 at 1:15PM, then average power = over the 15 minute interval is (2000kWh – 1000kWh) * = 60minutes/15minutes =3D 4kW.  Doesn’t it seem a lot simpler = for management program to compute demand based on polled energy readings = (i.e. a simple SQL query) – rather than having to write a = procedure to configure the power agent to perform demand = computations?

&n= bsp;

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] = On Behalf Of John Parello (jparello)
Sent: Thursday, = July 28, 2011 2:06 PM
To: Juergen Quittek; Juergen = Quittek
Cc: eman mailing list
Subject: Re: [eman] = new revision of eman requirements - open issue 12.3:timeseries of = energy/power values

 

 

I can't = vote  no when there'sand or and more on the bill.

I don't = see any reason to restrict to just power. IMO a series of power, energy, = and demand is useful if a device can support it.

So no don't = restrict it to just power and please allow series for power, demand, and = energy

Jp


-----Original Message-----
From: Juergen = Quittek [mailto:Quittek@neclab.eu]
Sent: = Wed 7/27/2011 7:13 AM
To: John Parello (jparello); Juergen = Quittek
Cc: eman mailing list
Subject: Re: [eman] new revision of = eman requirements - open issue 12.3:time series of energy/power = values

Hi John,

my Question was

"Do I = understand right that you would support a requirement for = specifying
a standard for time series of power but not for time = series of energy?"


I take you answer as a no. This would = mean we keep both requirements (time
series of power and time series = of energy). Is this correct?

Thanks,

    = Juergen


On 26.07.11 18:10, "John Parello = (jparello)" <jparello@cisco.com> = wrote:

>
>Hi Jeurgen,
>
>We need to express = power, energy as a measurement (scalar).
>
>For time series = (vector) IMO having the capability of providing power
>over time = series (which is demand) or energy over time is valuable = and
>should not be excluded.  Even though for energy an = odometer can suffice I
>see no need to prevent this for devices = that have this capability.
>
>
>Please take a look at = the draft-claise-energy-monitoring-mib.  I think
>they did a = good job of providing time series modeling that covers = this.
>
>thanks
>Jp
>
>
>
>
= >
>
>
>
>-----Original = Message-----
>From: Juergen Quittek [mailto:ietf@quittek.at]
>Sent: = Tue 7/26/2011 12:39 PM
>To: John Parello (jparello)
>Cc: = Mouli Chandramouli (moulchan); eman mailing list
>Subject: Re: = [eman] new revision of eman requirements - open issue
>12.3:time = series of energy/power values
>
>Hi John,
>
>We = are currently not discussing optional or mandatory = implementation.
>
>The question is whether or not we have a = requirement for specifying a
>standard for reporting both, energy = time series and power time series, or
>just one of them. What = compliant devices must implement is an issue to be
>discussed = later.
>
>Do I understand right that you would support a = requirement for specifying
>a standard for time series of power = but not for time series of = energy?
>
>Thanks,
>
>    = Juergen
>
>Am 26.07.2011 um 13:08 schrieb John Parello = (jparello):
>
>> Hi Jeurgen,
>>
>> I = tend to agree, for simple devices an energy odometer(s) as = describe
>> from the comments and what I presented from the = ODVA suffices.
>>
>> For time series of data like = historical demand devices such as PDUs very
>> typically store = this. Some our as long as a year's worth of data on the
>> = device. For the very reason that Bill pointed = out.
>>
>> So it would seem that a power value and an = energy odometer could be a
>> required minimum and then time = series of power or demand can be
>> = optional.
>>
>> We specified a power value as required = in the monitoring mib with time
>> series of power and demand = as optional.
>>
>> Jp
>>
>> = -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] = On Behalf Of
>> Juergen Quittek
>> Sent: Wednesday, = July 13, 2011 5:53 AM
>> To: Mouli Chandramouli = (moulchan)
>> Cc: eman mailing list
>> Subject: Re: = [eman] new revision of eman requirements - open issue
>> = 12.3:time series of energy/power values
>>
>> Dear = Mouli,
>>
>> Thank you for commenting on this issue. I = would like to have a look at
>> the following point of = view:
>>
>> So far, storing time series of = measurements on managed nodes is rarely
>> standardized and = rarely available as implementation.
>>
>> Typically, = it is the job of a network management system to collect time
>> = series and store them.
>>
>> Take for example byte and = packet counters at line cards. You see many
>> curves showing = time series of traffic rate/volume in the Internet, but
>> = almost all of them were collected at management stations or = data
>> collector modules, but not within MIB modules. (Please = correct me if I'm
>> wrong.)
>>
>> Now the = question is: Is energy management so much different from = other
>> network management tasks, that we need the rarely used = mechanism of
>> storing time series in MIB = modules?
>>
>> If not, it would be sufficient to just = report the number of total energy
>> consumed since the last = re-start as you do it with packet and byte
>> = counters.
>> This would be just a single managed object to be = specified and
>> implemented.
>>
>> = Thanks,
>>
>>    = Juergen
>>



______________=
_________________________________
eman mailing =
list
eman@ietf.org
https://www.ietf.org/=
mailman/listinfo/eman

 

------_=_NextPart_001_01CC52F6.12D6AB65-- From ietf@quittek.at Fri Aug 5 00:29:34 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417BD21F8658 for ; Fri, 5 Aug 2011 00:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5IMT8g9AP7C for ; Fri, 5 Aug 2011 00:29:30 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id CF8D821F865B for ; Fri, 5 Aug 2011 00:29:29 -0700 (PDT) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LqHAa-1RJshs2a0G-00doWd; Fri, 05 Aug 2011 09:29:36 +0200 References: <20110728164503.GA30392@elstar.local> <20110804185422.GC2243@elstar.local> In-Reply-To: <20110804185422.GC2243@elstar.local> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <225ABCBE-9878-4BAA-9C69-4DE58BCC1A14@quittek.at> Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Fri, 5 Aug 2011 09:29:36 +0200 To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:LMEvGl1mBOd8drOUNoqafqq5OPlaNR+nFWyTrskdCof CLRLOUK451REL2USwzA6gt6rSOCFa4fGPMCwLDeZ0GisLO8mDM 19D48/+dCGQrEpkRqOCz9T4qLXkw7ulQDjLWtLykJ/nrYKH+9A HBKC40E1TlmOD6KkvcJSTou6QVkDk3lMSMbHgQSH7EmsQbdqnB CxcLsLBcPIjXfwMJzHx7emzlc5qfiDuQ7ui7VKoqag= Cc: eman mailing list Subject: Re: [eman] iana powerstate tc proposal X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 07:29:34 -0000 On 04.08.2011 at 20:54, Juergen Schoenwaelder wrote: > On Wed, Aug 03, 2011 at 06:33:06PM +0200, Juergen Quittek wrote: >=20 >> Probably the SYNTAX clause would have to be replaced,=20 >> because numbers for states and sets would be registered at IANA and = not in the TC. >=20 > IANA would manage the MIB module with TC and this has been working > well for years with other number spaces IANA manages, for example the > interface type TC. IANA does any magic needed once specified. I > actually find it highly useful to have concrete named-numbers > allocated. I know the procedure. Yes, that's a clean solution. Thanks, Juergen >> We had several comments on the list suggesting that other values = might be more appropriate. >> But I assume the values in the TC served rather as examples than as = proposals >> for the final values to be chosen. >=20 > Exactly. I blindly copied values from = draft-claise-energy-monitoring-mib-09.txt=20 > from demonstration purposes. The energy management experts need to = find out > what suitable power state series are - I am just a MIB guy. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From karagian@cs.utwente.nl Fri Aug 5 11:57:40 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA51421F8B3C for ; Fri, 5 Aug 2011 11:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.021 X-Spam-Level: X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id re-m0-WG-VUx for ; Fri, 5 Aug 2011 11:57:40 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 31EFD21F8B39 for ; Fri, 5 Aug 2011 11:57:39 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p75ItdgM001734; Fri, 5 Aug 2011 20:55:41 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Fri, 05 Aug 2011 18:58:00 +0000 To: "eman mailing list" Date: Fri, 05 Aug 2011 18:58:00 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 05 Aug 2011 20:55:52 +0200 (MEST) Subject: [eman] new applicability related use cases X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 18:57:41 -0000 Hi all During the Quebec eman meeting I have mentioned that I will send some new use cases to the eman mailing list! The above use cases motivate the need of having the requirement of energy management and control for production and consumption of energy! Moreover the neigberhood related use cases motivate the need of supporting aggregation. If you have comments please let me know! Please however, note that in some hours my holidays start. On the 25th of August I will be back to my office! ----------- * Energy neutral building --------------------------- This use case considers the energy management and energy control of a building that can consume energy imported from a grid and it could also generate energy that is exported into the grid. Buildings use the so called domestic technologies for the energy prediction. Some examples of domestic technologies are: Micro-generators, see e.g., [1], that generate electricity at kilowatt level in or nearby houses. Examples of micro-generators are: Photovoltaics (PV), micro wind-turbines and microCHP devices. The microCHP devices are replacements for conventional high efficiency boilers producing both heat and electricity using natural gas. Energy neutral means that there is no net import from or net export into the grid. * Islanded building ------------------ In this case also the energy management and energy control of a building is considered that can however, self produce and consume energy, without importing from or exporting energy into the grid. Islanded means that the building is physically isolated from the grid, so the building can consume all the energy that is producing and no energy is flowing from or into the grid. * Energy neutral neighbourhood ----------------------------- In this use case the energy management and energy control of a group of buildings is considered, that are able to cooperate together in order to optimize their combined and aggregated import from and export into the grid. Optionally, this group of buildings can be combined with larger scale distributed generators. The distributed generators are energy generators that are geographically distributed in a small area. The distributed generation can range from wind turbine parks generating a capacity on a MegaWatt level up to a domestic distributed generator with a killowat level capacity. Energy neutral means that there is no net import from or net export into the grid. * Islanded neighbourhood ------------------------- In this use case also the energy management and energy control of a group of buildings is considered, that are able to cooperate together in order to optimize their combined and aggregated energy that is self produced and also consumed, without importing from or exporting energy into the grid. Islanded means that the neighbourhood is physically isolated from the grid, so the neighbourhood can consume all the energy that is producing and no energy is flowing from or into the grid. [1] A. Molderink, "On the three-step methodology for Smart Grids", Ph. D thesis, University of Twente, the Netherlands, ISBN: 978-90-365-3170-2, CTIT Ph. D thesis Series, No. 11-196, 2011. ---------------------- Best regards, Georgios From Internet-Drafts@ietf.org Tue Aug 9 13:45:02 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158D921F8C7F; Tue, 9 Aug 2011 13:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdz4KiKMSGuG; Tue, 9 Aug 2011 13:45:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5BA21F8C93; Tue, 9 Aug 2011 13:45:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110809204501.30069.8678.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2011 13:45:01 -0700 Cc: eman@ietf.org Subject: [eman] I-D ACTION:draft-ietf-eman-energy-monitoring-mib-00.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 20:45:02 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Energy Management Working Group of the IETF. Title : Power and Energy Monitoring MIB Author(s) : M. Chandramouli, et al Filename : draft-ietf-eman-energy-monitoring-mib-00.txt Pages : 75 Date : 2011-08-05 This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eman-energy-monitoring-mib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-eman-energy-monitoring-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-08-09134426.I-D@ietf.org> --NextPart-- From moulchan@cisco.com Tue Aug 9 23:01:37 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A180F21F86C3 for ; Tue, 9 Aug 2011 23:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.015 X-Spam-Level: X-Spam-Status: No, score=-3.015 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDNyfiVRhURm for ; Tue, 9 Aug 2011 23:01:37 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 14F4D21F86C2 for ; Tue, 9 Aug 2011 23:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=2105; q=dns/txt; s=iport; t=1312956128; x=1314165728; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=SiFsY+jyANaqI16jzSA29i3WGpKdN6lzIcDhzC2HshI=; b=A/74l+KhBfe2zY9miv5X8bz1aDb9JC1gS76Hk1lf1vL0WE+DzotXQ6A2 7sRWtr4omLdApGM1OZrrYKzEOujc/YS8Jvga+na/tzz2uflqrTTTPBHhk yTfxiGP2yvUwW0ERgLFrJ7hky8blVA81NnRr34+p94F2if82zP79wT+Cp M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIBAAAeQk6tJV2c/2dsb2JhbABBl2ZEjxt3gUABAQEBAxIBHQoxGgQCAQgRBAEBCwYXAQYBRQkIAQEEEwgBGYdPnxsBnj6FZ18Eh12QP4t4 X-IronPort-AV: E=Sophos;i="4.67,349,1309737600"; d="scan'208";a="11617824" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 10 Aug 2011 06:02:06 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p7A626je005135 for ; Wed, 10 Aug 2011 06:02:06 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 01:02:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Aug 2011 01:02:01 -0500 Message-ID: In-Reply-To: <20110809204501.30069.8678.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] I-D ACTION:draft-ietf-eman-energy-monitoring-mib-00.txt Thread-Index: AcxW1VjxSNmG4SyhSdORRUtZ7560iAAS2N+A References: <20110809204501.30069.8678.idtracker@ietfa.amsl.com> From: "Mouli Chandramouli (moulchan)" To: X-OriginalArrivalTime: 10 Aug 2011 06:02:06.0099 (UTC) FILETIME=[08431E30:01CC5723] Subject: Re: [eman] I-D ACTION:draft-ietf-eman-energy-monitoring-mib-00.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 06:01:37 -0000 Hello,=20 As you can see from the previous posting, we now have a WG draft on the Monitoring MIB.=20 http://www.ietf.org/id/draft-ietf-eman-energy-monitoring-mib-00.txt It is a revision of draft-claise-energy-monitoring-mib-09.=20 Based on consensus from EMAN WG discussion @ IETF81, the IANA considerations section has been revised and for addition of new Power State Sets - Expert Review has been recommended. Open issues section has been updated. Some of the issues such as TC design for Power State Set, there has been robust discussion on the email list.=20 We would be grateful for proposals on how to solve the remaining open issues listed in Section 14. Changes in this draft-ieft-eman-monitoring-mib-00 are:=20 - IANA considerations section updated=20 - open issues section updated.=20 Your comments welcome.=20 Thanks Brad, Juergen, Thomas, Benoit and Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, August 10, 2011 2:15 AM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D ACTION:draft-ietf-eman-energy-monitoring-mib-00.txt A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Energy Management Working Group of the IETF. Title : Power and Energy Monitoring MIB Author(s) : M. Chandramouli, et al Filename : draft-ietf-eman-energy-monitoring-mib-00.txt Pages : 75 Date : 2011-08-05 =20 This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eman-energy-monitoring-mi b-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From bschoening@noveda.com Wed Aug 10 11:00:04 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EDE21F8AAA for ; Wed, 10 Aug 2011 11:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IjAj0dmh0dc for ; Wed, 10 Aug 2011 11:00:03 -0700 (PDT) Received: from cal3-mh483-a.smtproutes.com (cal3-mh483-a.smtproutes.com [208.70.89.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC0621F8A56 for ; Wed, 10 Aug 2011 11:00:02 -0700 (PDT) X-Katharion-ID: 1312999214.53708.cal3-mh483 Received: from ex01.noveda.com ([66.198.105.170]) by cal3-mh483.smtproutes.com [(208.70.89.157)] with ESMTP via TCP; 10 Aug 2011 11:00:14 -0700 Received: from EX01.noveda.com ([::1]) by ex01.noveda.com ([::1]) with mapi; Wed, 10 Aug 2011 14:00:14 -0400 From: Brad Schoening To: "Mouli Chandramouli (moulchan)" , "eman@ietf.org" Thread-Topic: [eman] I-D ACTION:draft-ietf-eman-energy-monitoring-mib-00.txt Thread-Index: AQHMVtVf/Ums91//t0eUUx00MNEdzJUV222AgAA/FSA= Date: Wed, 10 Aug 2011 18:00:10 +0000 Message-ID: <22B2909DCC2E62418BE369A1F10488994B7B309E@ex01.noveda.com> References: <20110809204501.30069.8678.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] I-D ACTION:draft-ietf-eman-energy-monitoring-mib-00.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 18:00:04 -0000 Mouli, OPEN ISSUE 6: Measurement of AC Power, Voltage, and Current = =20 "AC power is not an RMS measurement, it is an average reading. =20 The term instantaneous AC power can be misleading and power=20 meters do not report it. " =20 The Watt (symbol W) is the derived SI unit of power, and is defined as = one joule per second. Smart meters usually report both kW and kWh. For exa= mple, the Shark 100 meter specification section G & K is an example. http://www.electroind.com/Specs/shark/E141723_Shark100M_GenSpec_RevC.pdf 'instantaneous' refers to the kW reading a meter would report. Usuall= y this is an RMS value, but it can be an average also over an integral numb= er of cycles. =20 OPEN ISSUE 7: In addition to WYE and Delta AC power=20 configurations, 3-Phase hybrid of WYE and Delta should be=20 considered ? =20 Yes, you can make a WYE-Delta connection, but I believe the power measu= rements need to be taken on either the Wye or delta side. OPEN ISSUE 8: Nameplate power consumption should be a fixed=20 value or a range ? =20 This must be a fixed value since its used for capacity planning. =20 "facilities planners used IT equipment nameplate ratings values as a method= to plan power and cooling capacity requirements... The nameplate on a pi= ece of IT equipment is a marking from a third-party agency that indicates t= hat the equipment complies with a set of requirements set forth by a produc= t safety standard such as IEC 60950-1 (Information technology equipment - S= afety - Part 1: General requirements)." From 'Proper Sizing and cooling Loads White Paper' by John Bean, et al. In order to reach closure on the drafts, may I suggest that issues under d= iscussion only become "open issues" once there are valid references to supp= ort a differing opinion. -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Mou= li Chandramouli (moulchan) Sent: Wednesday, August 10, 2011 2:02 AM To: eman@ietf.org Subject: Re: [eman] I-D ACTION:draft-ietf-eman-energy-monitoring-mib-00.txt Hello,=20 As you can see from the previous posting, we now have a WG draft on the Monitoring MIB.=20 http://www.ietf.org/id/draft-ietf-eman-energy-monitoring-mib-00.txt It is a revision of draft-claise-energy-monitoring-mib-09.=20 Based on consensus from EMAN WG discussion @ IETF81, the IANA considerations section has been revised and for addition of new Power State Sets - Expert Review has been recommended. Open issues section has been updated. Some of the issues such as TC design for Power State Set, there has been robust discussion on the email list.=20 We would be grateful for proposals on how to solve the remaining open issues listed in Section 14. Changes in this draft-ieft-eman-monitoring-mib-00 are:=20 - IANA considerations section updated=20 - open issues section updated.=20 Your comments welcome.=20 Thanks Brad, Juergen, Thomas, Benoit and Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, August 10, 2011 2:15 AM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D ACTION:draft-ietf-eman-energy-monitoring-mib-00.txt A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Energy Management Working Group of the IETF. Title : Power and Energy Monitoring MIB Author(s) : M. Chandramouli, et al Filename : draft-ietf-eman-energy-monitoring-mib-00.txt Pages : 75 Date : 2011-08-05 =20 This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eman-energy-monitoring-mi b-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From Michael.Suchoff@raritan.com Wed Aug 10 12:49:31 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C95321F8B88 for ; Wed, 10 Aug 2011 12:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.485 X-Spam-Level: X-Spam-Status: No, score=-1.485 tagged_above=-999 required=5 tests=[AWL=1.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYhd0rSW0g1U for ; Wed, 10 Aug 2011 12:49:30 -0700 (PDT) Received: from fig.raritan.com (fig.raritan.com [12.144.63.197]) by ietfa.amsl.com (Postfix) with ESMTP id 58D3021F8B87 for ; Wed, 10 Aug 2011 12:49:28 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Aug 2011 15:49:54 -0400 Message-ID: <9C329342B62B87498B92834DEC9FF51E0D83C161@fig.raritan.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] I-D ACTION:draft-ietf-eman-energy-monitoring-mib-00.txt Thread-Index: AQHMVtVf/Ums91//t0eUUx00MNEdzJUV222AgAA/FSCAAGBJ0A== References: <20110809204501.30069.8678.idtracker@ietfa.amsl.com> <22B2909DCC2E62418BE369A1F10488994B7B309E@ex01.noveda.com> From: "Michael Suchoff" To: "Brad Schoening" , "Mouli Chandramouli \(moulchan\)" , Subject: Re: [eman] I-D ACTION:draft-ietf-eman-energy-monitoring-mib-00.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 19:49:31 -0000 Brad, Issue 6: Watts are never RMS. For AC, a meter reports the average over an integral number of AC half cycles. Issue 7: In North America (Japan, Taiwan, etc.) common 3-phase line-line voltage is 208 and line-neutral is 120. In 3-phase PDU, all 3 208V line-line and all 3 120V line-neutral configurations are available simultaneously. Example: rack uses 208V for servers (plug into the 208V delta wired outlets of PDU), 120V for lighting and legacy equipment (plug into wye wired 120V outlets). Recommendation: One 3-phase power table Final index component is "line" an enumeration (1) phase A, (2) phase B, (3) phase C. lineLineVoltage - voltage line to line lineNeutralVoltage - voltage line to neutral current - amperes flowing in line watts - active power flowing in line va - apparent power flowing in line Example entries for line =3D 2 (phase B) lineLineVoltage =3D 207.6 // voltage measured phase B to phase C lineNeutral Voltage =3D 120 // voltage measured phase B to neutral Issue 8: UL 60950-1 has a strict format allowing both single, multiple and range values for ratings - so there can be no restrictions made by MIB. However, there is no UL requirement to list power on nameplate (only voltage, current and frequency are required). Power is optional and it is usually given in VA (VA or current is what is used for provisioning). -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Brad Schoening Sent: Wednesday, August 10, 2011 2:00 PM To: Mouli Chandramouli (moulchan); eman@ietf.org Subject: Re: [eman] I-D ACTION:draft-ietf-eman-energy-monitoring-mib-00.txt Mouli, OPEN ISSUE 6: Measurement of AC Power, Voltage, and Current "AC power is not an RMS measurement, it is an average reading. The term instantaneous AC power can be misleading and power=20 meters do not report it. " =20 The Watt (symbol W) is the derived SI unit of power, and is defined as one joule per second. Smart meters usually report both kW and kWh. For example, the Shark 100 meter specification section G & K is an example. =09 http://www.electroind.com/Specs/shark/E141723_Shark100M_GenSpec_RevC.pdf 'instantaneous' refers to the kW reading a meter would report. Usually this is an RMS value, but it can be an average also over an integral number of cycles. =20 OPEN ISSUE 7: In addition to WYE and Delta AC power=20 configurations, 3-Phase hybrid of WYE and Delta should be=20 considered ? =20 Yes, you can make a WYE-Delta connection, but I believe the power measurements need to be taken on either the Wye or delta side. OPEN ISSUE 8: Nameplate power consumption should be a fixed=20 value or a range ? =20 This must be a fixed value since its used for capacity planning. =20 "facilities planners used IT equipment nameplate ratings values as a method to plan power and cooling capacity requirements... The nameplate on a piece of IT equipment is a marking from a third-party agency that indicates that the equipment complies with a set of requirements set forth by a product safety standard such as IEC 60950-1 (Information technology equipment - Safety - Part 1: General requirements)." From 'Proper Sizing and cooling Loads White Paper' by John Bean, et al. In order to reach closure on the drafts, may I suggest that issues under discussion only become "open issues" once there are valid references to support a differing opinion. -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Mouli Chandramouli (moulchan) Sent: Wednesday, August 10, 2011 2:02 AM To: eman@ietf.org Subject: Re: [eman] I-D ACTION:draft-ietf-eman-energy-monitoring-mib-00.txt Hello,=20 As you can see from the previous posting, we now have a WG draft on the Monitoring MIB.=20 http://www.ietf.org/id/draft-ietf-eman-energy-monitoring-mib-00.txt It is a revision of draft-claise-energy-monitoring-mib-09.=20 Based on consensus from EMAN WG discussion @ IETF81, the IANA considerations section has been revised and for addition of new Power State Sets - Expert Review has been recommended. Open issues section has been updated. Some of the issues such as TC design for Power State Set, there has been robust discussion on the email list.=20 We would be grateful for proposals on how to solve the remaining open issues listed in Section 14. Changes in this draft-ieft-eman-monitoring-mib-00 are:=20 - IANA considerations section updated=20 - open issues section updated.=20 Your comments welcome.=20 Thanks Brad, Juergen, Thomas, Benoit and Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, August 10, 2011 2:15 AM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D ACTION:draft-ietf-eman-energy-monitoring-mib-00.txt A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Energy Management Working Group of the IETF. Title : Power and Energy Monitoring MIB Author(s) : M. Chandramouli, et al Filename : draft-ietf-eman-energy-monitoring-mib-00.txt Pages : 75 Date : 2011-08-05 =20 This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eman-energy-monitoring-mi b-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From moulchan@cisco.com Thu Aug 11 00:24:15 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4119821F8531 for ; Thu, 11 Aug 2011 00:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.003 X-Spam-Level: X-Spam-Status: No, score=-3.003 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFCJmViqEDFd for ; Thu, 11 Aug 2011 00:24:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 745F221F851F for ; Thu, 11 Aug 2011 00:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=3622; q=dns/txt; s=iport; t=1313047488; x=1314257088; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=aDWKDW3QbjqIrXDpq2wCiZeDtx/N6Tdz3s1XD3XjuhA=; b=Qcx8QrwI7TdmTcR4RqMHLuZs89NUKjyAWSOdx6nN/OaTPcbaoFwCr+gX MRmv0yLTkZoSrk2wP4OPeob17LFgXyqM9buHLZ1K6+h92Lf5ucj8uTBAd gGYuv4qa53grPO3BLtkKdJd5SmKzdcoBQVFpjsw7cV93kjr7xXj2TTU5+ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQBAGyDQ06tJV2c/2dsb2JhbAA4CYRIkzNEjhdxd4FAAQEBAQMSARANBD4TBAIBCBEEAQEDAgYGFwECAgIBAUQJCAEBBBMIEweHUJ15AY0vkTmBLIF7gg8xXwSHX5BDi3k X-IronPort-AV: E=Sophos;i="4.67,355,1309737600"; d="scan'208";a="12068193" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 11 Aug 2011 07:24:48 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p7B7OmKq032343 for ; Thu, 11 Aug 2011 07:24:48 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Aug 2011 02:24:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 11 Aug 2011 02:24:44 -0500 Message-ID: In-Reply-To: <20110811070707.28475.50612.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version of draft-tychon-eman-applicability-statement-03.txt Thread-Index: AcxX9XZMVA5NbNgPTyyB61zFd1UtUQAAE/dw References: <20110811070707.28475.50612.idtracker@ietfa.amsl.com> From: "Mouli Chandramouli (moulchan)" To: X-OriginalArrivalTime: 11 Aug 2011 07:24:47.0918 (UTC) FILETIME=[C0265CE0:01CC57F7] Subject: Re: [eman] New Version of draft-tychon-eman-applicability-statement-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 07:24:15 -0000 SGksDQoNCkFuIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnQg ZHJhZnQgaGFzIGJlZW4gc3VibWl0dGVkIA0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC10eWNob24tZW1hbi1hcHBsaWNhYmlsaXR5LXN0YXRlbWVudC0wMw0KDQpUaGUgdXBkYXRl IHdhcyBiYXNlZCBvbiBjb21tZW50cyBmcm9tIHRoZSBXRyBtZWV0aW5nIGFuZCBmZWVkYmFjayBm cm9tIHRoZSBlbWFpbCBsaXN0Lg0KDQpUaGUgZGlmZiBjYW4gYmUgc2VlbiBhdCANCg0KaHR0cDov L3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/ZGlmZnR5cGU9LS1od2RpZmYmdXJsMj1kcmFmdC10eWNo b24tZW1hbi1hcHBsaWNhYmlsaXR5LXN0YXRlbWVudC0wMy50eHQNCg0KVGhlIHVwZGF0ZWQgZHJh ZnQgY29udGFpbnMgdGhlIGZvbGxvd2luZyBjaGFuZ2VzOg0KDQotIGFkZGVkIG5ldyB1c2UgY2Fz ZXMgb24gSW5kdXN0cmlhbCBhdXRvbWF0aW9uIG5ldHdvcmtzIChiYXNlZCBvbiBPRFZBJ3MgY29t bWVudCkgYW5kIERlbWFuZC9yZXNwb25zZSAoYSBjb3VwbGUgY29tbWVudHMgIGZyb20gdGhlIGVt YWlsIGxpc3QpIA0KLSBhZGRlZCBzb21lIG1vcmUgdGV4dCB0byB1c2UgY2FzZSAyLjcgaG9tZSBl bmVyZ3kgZ2F0ZXdheSB3aXRoIHRoZSB1c2UgY2FzZSBvbiBlbmVyZ3kgbmV1dHJhbCBob21lcw0K LSB1cGRhdGVkIHRoZSBvcGVuIGlzc3VlcyBzZWN0aW9uIA0KDQpXZSBob3BlIHRvIG1lcmdlIHRo aXMgZHJhZnQgd2l0aCAgZHJhZnQtbm9yZG1hbi1lbWFuLWVuZXJneS1wZXJzcGVjdGl2ZS0wMSBh bmQgc3VibWl0IGEgcmV2aXNlZCBkcmFmdCBzb29uLg0KDQpZb3VyIGNvbW1lbnRzIHdlbGNvbWUu ICANCg0KQXMgbWVudGlvbmVkIGluIHRoZSBXRyBtZWV0aW5nLCB3ZSB3YW50IHRvIGNvbnZlcmdl IG9uIHRoZSB1c2UgY2FzZXMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCBpbiBzY29wZSBmb3Ig RU1BTiBhbmQgYWxzbyB0aGUgZW5lcmd5IHN0YW5kYXJkcyByZWxldmFudCBmb3IgRU1BTi4gDQoN ClRoYW5rcyB2ZXJ5IG11Y2gNCk1vdWxpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSAxMjozNyBQTQ0KVG86IE1v dWxpIENoYW5kcmFtb3VsaSAobW91bGNoYW4pDQpDYzogRW1tYW51ZWwgVHljaG9uIChldHljaG9u KTsgTW91bGkgQ2hhbmRyYW1vdWxpIChtb3VsY2hhbik7IGJyYWRAYnJhZHNjaG9lbmluZy5jb20N ClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3JkcmFmdC10eWNob24tZW1hbi1h cHBsaWNhYmlsaXR5LXN0YXRlbWVudC0wMy50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LXR5Y2hvbi1lbWFuLWFwcGxpY2FiaWxpdHktc3RhdGVtZW50LTAzLnR4dCBoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1vdWxpIENoYW5kcmFtb3VsaSBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtdHljaG9uLWVtYW4tYXBw bGljYWJpbGl0eS1zdGF0ZW1lbnQNClJldmlzaW9uOgkgMDMNClRpdGxlOgkJIEVuZXJneSBNYW5h Z2VtZW50IChFTUFOKSBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudA0KQ3JlYXRpb24gZGF0ZToJIDIw MTEtMDgtMTENCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2Vz OiAyNg0KDQpBYnN0cmFjdDoNCiAgICAgICAgVGhlIG9iamVjdGl2ZSBvZiBFbmVyZ3kgTWFuYWdl bWVudCAoRU1BTikgaXMgdG8gcHJvdmlkZSBhbg0KICAgICAgICBlbmVyZ3kgbWFuYWdlbWVudCBm cmFtZXdvcmsgZm9yIG5ldHdvcmtlZCBkZXZpY2VzLiBJbiB0aGlzDQogICAgICAgIGRvY3VtZW50 IHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBFTUFOIGZyYW1ld29yayBmb3IgYSB2YXJpZXR5DQog ICAgICAgIG9mIG5ldHdvcmsgc2NlbmFyaW9zIGlzIHByZXNlbnRlZC4gVGhpcyBkb2N1bWVudCBs aXN0cyBhIG51bWJlcg0KICAgICAgICBvZiB1c2UgY2FzZXMgYW5kIHRoZSB0YXJnZXQgZGV2aWNl cyB0aGF0IGNhbiBwb3RlbnRpYWxseQ0KICAgICAgICBpbXBsZW1lbnQgdGhlIEVNQU4gZnJhbWV3 b3JrIGFuZCB0aGUgYXNzb2NpYXRlZCBNSUIgbW9kdWxlcy4NCiAgICAgICAgVGh1cywgdGhlc2Ug dXNlIGNhc2VzIGJlIHVzZWZ1bCB0byBpZGVudGl0eSBhZGRpdGlvbmFsDQogICAgICAgIG1vbml0 b3JpbmcgcmVxdWlyZW1lbnRzIHRoYXQgbmVlZCB0byBiZSBjb25zaWRlcmVkIHNvIHRoYXQgRU1B Tg0KICAgICAgICBjYW4gcHJvdmlkZSBhIHNvbHV0aW9uIGZvciB0aG9zZSB1c2UgY2FzZXMuIEZ1 cnRoZXJtb3JlLCB3ZQ0KICAgICAgICBkZXNjcmliZSB0aGUgcmVsYXRpb25zaGlwIG9mIHRoZSBF TUFOIGZyYW1ld29yayB0byBvdGhlciBlbmVyZ3kNCiAgICAgICAgbW9uaXRvcmluZyBzdGFuZGFy ZHMgYW5kIGFyY2hpdGVjdHVyZXMuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From internet-drafts@ietf.org Thu Aug 11 05:20:13 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964F221F8A1A; Thu, 11 Aug 2011 05:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl4O6RGAZitd; Thu, 11 Aug 2011 05:20:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BEC21F8745; Thu, 11 Aug 2011 05:20:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110811122013.31603.16880.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2011 05:20:13 -0700 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-battery-mib-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 12:20:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of th= e IETF. Title : Definition of Managed Objects for Battery Monitoring Author(s) : Juergen Quittek Rolf Winter Thomas Dietz Filename : draft-ietf-eman-battery-mib-03.txt Pages : 26 Date : 2011-08-11 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects that provide information on the status of batteries in managed devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eman-battery-mib-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-eman-battery-mib-03.txt From Rolf.Winter@neclab.eu Thu Aug 11 05:25:12 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6968B21F8A1A for ; Thu, 11 Aug 2011 05:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oldsy2lM-SsS for ; Thu, 11 Aug 2011 05:25:11 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id AA51521F89BE for ; Thu, 11 Aug 2011 05:25:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0E3DD2800031E for ; Thu, 11 Aug 2011 14:25:45 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH-pMyAMITJh for ; Thu, 11 Aug 2011 14:25:44 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id E5C2D2800018F for ; Thu, 11 Aug 2011 14:25:39 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.20]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Thu, 11 Aug 2011 14:25:18 +0200 From: Rolf Winter To: eman mailing list Thread-Topic: New version of the battery MIB Thread-Index: AcxYIbqpaDv1rvUkS/CDnRSDfhBhfg== Date: Thu, 11 Aug 2011 12:25:18 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1D048BFF@DAPHNIS.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [eman] New version of the battery MIB X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 12:25:12 -0000 WG, we have just posted another version of the battery MIB. This version: - addresses the comments raised by Bill Mielke (thanks!) - changes terms a little to either address comments received or to align wi= th the Smart Battery Spec - aligns with changes in the framework document - includes some restructuring of the text - includes the proposed text for re-arming the battery low notification as = presented in the meeting - adds the following open issue:=20 Shall we add managed objects and notifications that are based on the estimated time that the battery will be able to provide power (time- to-empty) or will need until it is fully charged (time-to-full). In general this is useful and desired information. However, this information is not reliable. It is based on the assumption that the actual current will be continuous drawn from the battery or used to charge the battery. Additionally, it is assumed that the battery chemistry works as expected. Both may not be the case. - updates the reference section If you have any comments or further questions, please let us know. Thanks, The authors NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From moulchan@cisco.com Thu Aug 11 05:36:10 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984BF21F88A6 for ; Thu, 11 Aug 2011 05:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.992 X-Spam-Level: X-Spam-Status: No, score=-2.992 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6Zi4LL6Jr3C for ; Thu, 11 Aug 2011 05:36:09 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D70DD21F88A1 for ; Thu, 11 Aug 2011 05:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=1812; q=dns/txt; s=iport; t=1313066204; x=1314275804; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=0w14TvBclojfz4Ws34flfH171J1pubdcQVZZaxazIXY=; b=FQVTsj2+R6FyavKzW/CujMFd4b17Qv3jARbjOTDXsRaIqru1VbOFwXDi SBl/pk1X8/ELZwHJaRORL2vKQSXTPQ5KZWuflNelLN+x6C0T9FRBigK16 vR0gGlKLux27FDzjv6d02WjBbFuENnAPIjxG6HdgfvEwFh+fngbQ4d65N 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8AABPMQ06tJV2Y/2dsb2JhbABBl32PSXeBQAEBAQEDAQEBDwEdCjQXBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIGodRnWUBnwSFaF8Eh1+QQ4t5 X-IronPort-AV: E=Sophos;i="4.67,355,1309737600"; d="scan'208";a="12151338" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 11 Aug 2011 12:36:43 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7BCagT4023903; Thu, 11 Aug 2011 12:36:42 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Aug 2011 07:36:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Aug 2011 07:36:39 -0500 Message-ID: In-Reply-To: <791AD3077F94194BB2BDD13565B6295D1D048BFF@DAPHNIS.office.hd> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] New version of the battery MIB Thread-Index: AcxYIbqpaDv1rvUkS/CDnRSDfhBhfgAAJ5hw References: <791AD3077F94194BB2BDD13565B6295D1D048BFF@DAPHNIS.office.hd> From: "Mouli Chandramouli (moulchan)" To: "Rolf Winter" , "eman mailing list" X-OriginalArrivalTime: 11 Aug 2011 12:36:42.0797 (UTC) FILETIME=[531645D0:01CC5823] Subject: Re: [eman] New version of the battery MIB X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 12:36:10 -0000 Hi Rolf, Reply in line.=20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Rolf Winter Sent: Thursday, August 11, 2011 5:55 PM To: eman mailing list Subject: [eman] New version of the battery MIB WG, we have just posted another version of the battery MIB. This version: - addresses the comments raised by Bill Mielke (thanks!) - changes terms a little to either address comments received or to align with the Smart Battery Spec - aligns with changes in the framework document Mouli>>> Would the battery have a UUID ? There seems to be consensus on a requirement for the use of UUID.=20 - includes some restructuring of the text - includes the proposed text for re-arming the battery low notification as presented in the meeting - adds the following open issue:=20 Shall we add managed objects and notifications that are based on the estimated time that the battery will be able to provide power (time- to-empty) or will need until it is fully charged (time-to-full). In general this is useful and desired information. However, this information is not reliable. It is based on the assumption that the actual current will be continuous drawn from the battery or used to charge the battery. Additionally, it is assumed that the battery chemistry works as expected. Both may not be the case. - updates the reference section If you have any comments or further questions, please let us know. Thanks, The authors NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014=20 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From Rolf.Winter@neclab.eu Fri Aug 12 00:34:08 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C4011E808D for ; Fri, 12 Aug 2011 00:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNWglT4xYbuQ for ; Fri, 12 Aug 2011 00:34:07 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5C53F11E8080 for ; Fri, 12 Aug 2011 00:34:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id AE9372800034C; Fri, 12 Aug 2011 09:33:55 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X57euojSuqfz; Fri, 12 Aug 2011 09:33:55 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 8F2C828000332; Fri, 12 Aug 2011 09:33:45 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.20]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Fri, 12 Aug 2011 09:33:45 +0200 From: Rolf Winter To: "Mouli Chandramouli (moulchan)" , eman mailing list Thread-Topic: [eman] New version of the battery MIB Thread-Index: AcxYIbqpaDv1rvUkS/CDnRSDfhBhfgAAJ5hwACaCiqA= Date: Fri, 12 Aug 2011 07:33:44 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1D0492C5@DAPHNIS.office.hd> References: <791AD3077F94194BB2BDD13565B6295D1D048BFF@DAPHNIS.office.hd> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] New version of the battery MIB X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 07:34:08 -0000 Hi Mouli, This is how Benoit earlier summarized the outcome regarding this: "So, as discussed during the meeting, on based on this dicussion on the lis= t, the battery should be integrated to the framework, with its own UUID, w= ith its own power state set/power state, and on the top of this, it should = support the battery-mib." I haven't seen any objections to his interpretation of the outcome of the d= iscussion. Does this answer your question? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] > Sent: Donnerstag, 11. August 2011 14:37 > To: Rolf Winter; eman mailing list > Subject: RE: [eman] New version of the battery MIB >=20 > Hi Rolf, >=20 > Reply in line. >=20 > Thanks > Mouli >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Rolf Winter > Sent: Thursday, August 11, 2011 5:55 PM > To: eman mailing list > Subject: [eman] New version of the battery MIB >=20 > WG, >=20 > we have just posted another version of the battery MIB. This version: >=20 > - addresses the comments raised by Bill Mielke (thanks!) > - changes terms a little to either address comments received or to > align > with the Smart Battery Spec > - aligns with changes in the framework document >=20 > Mouli>>> Would the battery have a UUID ? There seems to be consensus on > a requirement for the use of UUID. >=20 > - includes some restructuring of the text > - includes the proposed text for re-arming the battery low notification > as presented in the meeting > - adds the following open issue: > Shall we add managed objects and notifications that are based on the > estimated time that the battery will be able to provide power (time- > to-empty) or will need until it is fully charged (time-to-full). In > general this is useful and desired information. However, this > information is not reliable. It is based on the assumption that the > actual current will be continuous drawn from the battery or used to > charge the battery. Additionally, it is assumed that the battery > chemistry works as expected. Both may not be the case. > - updates the reference section >=20 > If you have any comments or further questions, please let us know. >=20 > Thanks, >=20 > The authors >=20 >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From moulchan@cisco.com Fri Aug 12 01:50:54 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC10421F8736 for ; Fri, 12 Aug 2011 01:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.981 X-Spam-Level: X-Spam-Status: No, score=-2.981 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYnvPJsSfwEK for ; Fri, 12 Aug 2011 01:50:54 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF1F21F86FF for ; Fri, 12 Aug 2011 01:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=3271; q=dns/txt; s=iport; t=1313139091; x=1314348691; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=7gHtgMtz+/0q43TSPnsq/IqkCQ5BPxtsE1iA6FPuLtQ=; b=L6A+NA0T0Gi9EI7evs0QLhNiXgRIr8Qi76Vmapr7jWP7R53D4ViDSbmH omvHcspcLtSKKcCHnWApi9w1bP5DrGbVyGwShlKHJ3v4uJK7DuzHl2jEh UJnqzBkU4RgVD1gPC6NBsxScPcuuqbh31cFCpFm44TuYLXiQp0BFxPgiG M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsAADXoRE6tJV2a/2dsb2JhbABBmCCPTXeBQAEBAQEDAQEBDwEdCjQXBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIGodRnTEBnmuFaF8Eh1+QRYt5 X-IronPort-AV: E=Sophos;i="4.67,361,1309737600"; d="scan'208";a="12485272" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 12 Aug 2011 08:48:43 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7C8mhM6006052; Fri, 12 Aug 2011 08:48:43 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Aug 2011 03:48:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Aug 2011 03:48:39 -0500 Message-ID: In-Reply-To: <791AD3077F94194BB2BDD13565B6295D1D0492C5@DAPHNIS.office.hd> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] New version of the battery MIB Thread-Index: AcxYIbqpaDv1rvUkS/CDnRSDfhBhfgAAJ5hwACaCiqAAAkYgwA== References: <791AD3077F94194BB2BDD13565B6295D1D048BFF@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D1D0492C5@DAPHNIS.office.hd> From: "Mouli Chandramouli (moulchan)" To: "Rolf Winter" , "eman mailing list" X-OriginalArrivalTime: 12 Aug 2011 08:48:43.0536 (UTC) FILETIME=[A4067100:01CC58CC] Subject: Re: [eman] New version of the battery MIB X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 08:50:54 -0000 Hi Rolf, Exactly.=20 My question was more on - how does this revision of the battery mib address this point of discussion and the conclusion.=20 IMHO, it would be good to add some text, how this shall be handled.=20 Thanks Mouli -----Original Message----- From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 Sent: Friday, August 12, 2011 1:04 PM To: Mouli Chandramouli (moulchan); eman mailing list Subject: RE: [eman] New version of the battery MIB Hi Mouli, This is how Benoit earlier summarized the outcome regarding this: "So, as discussed during the meeting, on based on this dicussion on the list, the battery should be integrated to the framework, with its own UUID, with its own power state set/power state, and on the top of this, it should support the battery-mib." I haven't seen any objections to his interpretation of the outcome of the discussion. Does this answer your question? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] > Sent: Donnerstag, 11. August 2011 14:37 > To: Rolf Winter; eman mailing list > Subject: RE: [eman] New version of the battery MIB >=20 > Hi Rolf, >=20 > Reply in line. >=20 > Thanks > Mouli >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Rolf Winter > Sent: Thursday, August 11, 2011 5:55 PM > To: eman mailing list > Subject: [eman] New version of the battery MIB >=20 > WG, >=20 > we have just posted another version of the battery MIB. This version: >=20 > - addresses the comments raised by Bill Mielke (thanks!) > - changes terms a little to either address comments received or to > align > with the Smart Battery Spec > - aligns with changes in the framework document >=20 > Mouli>>> Would the battery have a UUID ? There seems to be consensus on > a requirement for the use of UUID. >=20 > - includes some restructuring of the text > - includes the proposed text for re-arming the battery low notification > as presented in the meeting > - adds the following open issue: > Shall we add managed objects and notifications that are based on the > estimated time that the battery will be able to provide power (time- > to-empty) or will need until it is fully charged (time-to-full). In > general this is useful and desired information. However, this > information is not reliable. It is based on the assumption that the > actual current will be continuous drawn from the battery or used to > charge the battery. Additionally, it is assumed that the battery > chemistry works as expected. Both may not be the case. > - updates the reference section >=20 > If you have any comments or further questions, please let us know. >=20 > Thanks, >=20 > The authors >=20 >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From Rolf.Winter@neclab.eu Fri Aug 12 01:53:43 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0F321F8588 for ; Fri, 12 Aug 2011 01:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMiwpKlrFIyX for ; Fri, 12 Aug 2011 01:53:42 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7104D21F8586 for ; Fri, 12 Aug 2011 01:53:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8301028000332; Fri, 12 Aug 2011 10:52:20 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxOONTzk0-m9; Fri, 12 Aug 2011 10:52:20 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 63D80280001AA; Fri, 12 Aug 2011 10:52:10 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.20]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Fri, 12 Aug 2011 10:52:10 +0200 From: Rolf Winter To: "Mouli Chandramouli (moulchan)" , eman mailing list Thread-Topic: [eman] New version of the battery MIB Thread-Index: AcxYIbqpaDv1rvUkS/CDnRSDfhBhfgAAJ5hwACaCiqAAAkYgwAAB21Zg Date: Fri, 12 Aug 2011 08:52:09 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1D04934F@DAPHNIS.office.hd> References: <791AD3077F94194BB2BDD13565B6295D1D048BFF@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D1D0492C5@DAPHNIS.office.hd> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] New version of the battery MIB X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 08:53:43 -0000 Hi Mouli, there is a little bit of text in this direction (when you do a diff you'll = easily spot it) but we will write more once there is a definitive conclusio= n on this issue. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] > Sent: Freitag, 12. August 2011 10:49 > To: Rolf Winter; eman mailing list > Subject: RE: [eman] New version of the battery MIB >=20 > Hi Rolf, >=20 > Exactly. >=20 > My question was more on - how does this revision of the battery mib > address this point of discussion and the conclusion. >=20 > IMHO, it would be good to add some text, how this shall be handled. >=20 > Thanks > Mouli >=20 > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > Sent: Friday, August 12, 2011 1:04 PM > To: Mouli Chandramouli (moulchan); eman mailing list > Subject: RE: [eman] New version of the battery MIB >=20 > Hi Mouli, >=20 > This is how Benoit earlier summarized the outcome regarding this: >=20 > "So, as discussed during the meeting, on based on this dicussion on the > list, the battery should be integrated to the framework, with its own > UUID, with its own power state set/power state, and on the top of this, > it should support the battery-mib." >=20 > I haven't seen any objections to his interpretation of the outcome of > the discussion. >=20 > Does this answer your question? >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] > > Sent: Donnerstag, 11. August 2011 14:37 > > To: Rolf Winter; eman mailing list > > Subject: RE: [eman] New version of the battery MIB > > > > Hi Rolf, > > > > Reply in line. > > > > Thanks > > Mouli > > > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf > Of > > Rolf Winter > > Sent: Thursday, August 11, 2011 5:55 PM > > To: eman mailing list > > Subject: [eman] New version of the battery MIB > > > > WG, > > > > we have just posted another version of the battery MIB. This version: > > > > - addresses the comments raised by Bill Mielke (thanks!) > > - changes terms a little to either address comments received or to > > align > > with the Smart Battery Spec > > - aligns with changes in the framework document > > > > Mouli>>> Would the battery have a UUID ? There seems to be consensus > on > > a requirement for the use of UUID. > > > > - includes some restructuring of the text > > - includes the proposed text for re-arming the battery low > notification > > as presented in the meeting > > - adds the following open issue: > > Shall we add managed objects and notifications that are based on > the > > estimated time that the battery will be able to provide power > (time- > > to-empty) or will need until it is fully charged (time-to-full). > In > > general this is useful and desired information. However, this > > information is not reliable. It is based on the assumption that > the > > actual current will be continuous drawn from the battery or used > to > > charge the battery. Additionally, it is assumed that the battery > > chemistry works as expected. Both may not be the case. > > - updates the reference section > > > > If you have any comments or further questions, please let us know. > > > > Thanks, > > > > The authors > > > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > _______________________________________________ > > eman mailing list > > eman@ietf.org > > https://www.ietf.org/mailman/listinfo/eman From etychon@cisco.com Fri Aug 12 07:20:17 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAB25E8001 for ; Fri, 12 Aug 2011 07:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tk2LWzlyN4ry for ; Fri, 12 Aug 2011 07:20:17 -0700 (PDT) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id BBD375E8005 for ; Fri, 12 Aug 2011 07:20:16 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from bonfire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p7CEKqJo024943 for ; Fri, 12 Aug 2011 07:20:52 -0700 (PDT) Received: from ams-etychon-8916.cisco.com (ams-etychon-8916.cisco.com [10.60.74.7]) by bonfire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p7CEKoN0018893; Fri, 12 Aug 2011 07:20:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Emmanuel Tychon In-Reply-To: Date: Fri, 12 Aug 2011 16:20:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6CE1F354-7B97-402F-898D-9CCA6590332D@cisco.com> References: To: Georgios Karagiannis X-Mailer: Apple Mail (2.1244.3) Cc: eman mailing list Subject: Re: [eman] new applicability related use cases X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 14:20:17 -0000 Hello Georgios, First of all, thank you for the feedback. Here's what I'm thinking: The use cases provided below are definitely very good and interesting, = however I question their applicability to EMAN. They are all related to building energy management where consumers and = producers are not necessarily IT devices (i.e.: boilers and micro = generators).=20 Cases like the one mentioned below are addressed in the applicability = statement in a section called "Gateways to building networks" (section = 2.6). Indeed, we do not expect micro generators or boiler to talk SNMP, = but such a gateway can provide functionality based on specific metering = method outside of the scope of this working group. > Moreover the neigberhood related use cases motivate the need of > supporting aggregation. Aggregation will be supported by the means of so-called "Mid-level = managers=96Aggregation". The applicability statement covers it in = section 2.5. Thanks, Emmanuel > The above use cases motivate the need of having the requirement of = energy > management and control for production and consumption of energy! > Moreover the neigberhood related use cases motivate the need of > supporting aggregation. >=20 > If you have comments please let me know! > Please however, note that in some hours my holidays start. On the 25th = of > August I will be back to my office! >=20 > ----------- >=20 > * Energy neutral building > --------------------------- >=20 > This use case considers the energy management and energy control of a > building that can consume energy imported > from a grid and it could also generate energy that is exported into = the > grid. Buildings use the so called domestic technologies for the energy > prediction. Some examples of domestic technologies are: > Micro-generators, see e.g., [1], that generate electricity at kilowatt > level in or nearby houses. Examples of micro-generators are: > Photovoltaics (PV), micro wind-turbines and microCHP devices. The > microCHP devices are replacements for conventional high efficiency > boilers producing both heat and electricity using natural gas. > Energy neutral means that there is no net import from or net export = into > the grid. >=20 > * Islanded building > ------------------ > In this case also the energy management and energy control of a = building > is considered that can however, self produce and consume energy, > without importing from or exporting energy into the grid. > Islanded means that the building is physically isolated > from the grid, so the building can consume all the energy that is > producing and no energy is flowing from or into the grid. >=20 >=20 > * Energy neutral neighbourhood > ----------------------------- > In this use case the energy management and energy control of a group = of > buildings is considered, that are able to cooperate > together in order to optimize their combined and aggregated import = from > and export > into the grid. Optionally, this group of buildings can be combined = with > larger scale distributed generators. The distributed generators are > energy generators that are geographically distributed in a small area. > The distributed generation can range from wind turbine parks = generating a > capacity on a MegaWatt level up to a domestic distributed generator > with a killowat level capacity. Energy neutral means that there is no = net > import from or net export into the grid. >=20 > * Islanded neighbourhood >=20 > ------------------------- > In this use case also the energy management and energy control of a = group > of buildings is considered, that are able to cooperate > together in order to optimize their combined and aggregated energy = that > is self produced and also consumed, without importing from or = exporting > energy into the grid. > Islanded means that the neighbourhood is physically isolated from the > grid, so the neighbourhood can consume all the energy that is > producing and no energy is flowing from or into the grid. >=20 > [1] A. Molderink, "On the three-step methodology for Smart Grids", Ph. > D thesis, University of Twente, the Netherlands, ISBN: > 978-90-365-3170-2, CTIT Ph. D thesis Series, No. 11-196, 2011. >=20 >=20 > ---------------------- >=20 >=20 > Best regards, > Georgios > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 From ietf@quittek.at Fri Aug 12 21:05:23 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3BA21F85F7 for ; Fri, 12 Aug 2011 21:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIuJ8Ko2wzHv for ; Fri, 12 Aug 2011 21:05:23 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id A1EE621F85A0 for ; Fri, 12 Aug 2011 21:05:21 -0700 (PDT) Received: from [12.235.18.117] ([12.235.18.117]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MIhBo-1QuHLF3btw-002tft; Sat, 13 Aug 2011 06:05:57 +0200 References: <791AD3077F94194BB2BDD13565B6295D1D048BFF@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D1D0492C5@DAPHNIS.office.hd> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Fri, 12 Aug 2011 21:05:46 -0700 To: Mouli Chandramouli (moulchan) X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:sYClFz8g1rpZAcw2qoolEh+PMc92Te12t4lGRcazsQz p/EJCNAZS/DaeszXDt+UCeHs8vRfUOzLgeEJ8r1Nso62VLaTwz Sa6dqJY+oeX7Mt2TbxO442MAQK8VIpsulhc032dbbLLK1lQAz0 eNTC1ZUzKYvEecePj2V2f/nRIMTGhVtBeO04cdGuH/d9rrtyKI FA62327SHUbOg11+EMPAk6oDLbXzadiaSo88nb7Ih0= Cc: eman mailing list Subject: Re: [eman] New version of the battery MIB X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 04:05:24 -0000 Hi Mouli, Maybe all we need is already contained in the document. 1. We have the managed object batteryIdentifier that contains the an ID=20= assigned by the manufacturer and that is somehow stored with the = battery. It's syntax allows representing a UUID, but is not restricted to the 16 = octet length of a UUID as defined in RFC 4122. If the manufacturer has given its battery a universally unique ID, it is = in here. However, it may have a different format than specified in RFC 4122. Would it be a good idea recommending Battery manufacturers to use the UUID defined in RFC 4122?=20 2. I think we agreed that we will try to have the Entity MIB providing = UUIDs. Since the Battery MIB points to the Entity MIB (if present), it does not = need=20 its own managed object to store a UUID. If there is no Entity MIB implementation present, then I would assume = that there is no need to model the battery as separate entity and hence it = does not need its own UUID. Thanks, Juergen Am 12.08.2011 um 01:48 schrieb Mouli Chandramouli (moulchan): > Hi Rolf, >=20 > Exactly.=20 >=20 > My question was more on - how does this revision of the battery mib > address this point of discussion and the conclusion.=20 >=20 > IMHO, it would be good to add some text, how this shall be handled.=20 >=20 > Thanks > Mouli >=20 > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 > Sent: Friday, August 12, 2011 1:04 PM > To: Mouli Chandramouli (moulchan); eman mailing list > Subject: RE: [eman] New version of the battery MIB >=20 > Hi Mouli, >=20 > This is how Benoit earlier summarized the outcome regarding this: >=20 > "So, as discussed during the meeting, on based on this dicussion on = the > list, the battery should be integrated to the framework, with its own > UUID, with its own power state set/power state, and on the top of = this, > it should support the battery-mib." >=20 > I haven't seen any objections to his interpretation of the outcome of > the discussion. >=20 > Does this answer your question? >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014=20 >=20 >=20 >> -----Original Message----- >> From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] >> Sent: Donnerstag, 11. August 2011 14:37 >> To: Rolf Winter; eman mailing list >> Subject: RE: [eman] New version of the battery MIB >>=20 >> Hi Rolf, >>=20 >> Reply in line. >>=20 >> Thanks >> Mouli >>=20 >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf > Of >> Rolf Winter >> Sent: Thursday, August 11, 2011 5:55 PM >> To: eman mailing list >> Subject: [eman] New version of the battery MIB >>=20 >> WG, >>=20 >> we have just posted another version of the battery MIB. This version: >>=20 >> - addresses the comments raised by Bill Mielke (thanks!) >> - changes terms a little to either address comments received or to >> align >> with the Smart Battery Spec >> - aligns with changes in the framework document >>=20 >> Mouli>>> Would the battery have a UUID ? There seems to be consensus > on >> a requirement for the use of UUID. >>=20 >> - includes some restructuring of the text >> - includes the proposed text for re-arming the battery low > notification >> as presented in the meeting >> - adds the following open issue: >> Shall we add managed objects and notifications that are based on > the >> estimated time that the battery will be able to provide power > (time- >> to-empty) or will need until it is fully charged (time-to-full). > In >> general this is useful and desired information. However, this >> information is not reliable. It is based on the assumption that > the >> actual current will be continuous drawn from the battery or used to >> charge the battery. Additionally, it is assumed that the battery >> chemistry works as expected. Both may not be the case. >> - updates the reference section >>=20 >> If you have any comments or further questions, please let us know. >>=20 >> Thanks, >>=20 >> The authors >>=20 >>=20 >>=20 >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >> London W3 6BL | Registered in England 2832014 >>=20 >>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Sat Aug 13 17:31:57 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C9D21F8A4F for ; Sat, 13 Aug 2011 17:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vybu60tTsJ5f for ; Sat, 13 Aug 2011 17:31:56 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFDF21F88A1 for ; Sat, 13 Aug 2011 17:31:55 -0700 (PDT) Received: from [192.168.5.129] ([64.134.234.245]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MAeJn-1R2bta0BSt-00Bx1R; Sun, 14 Aug 2011 02:32:35 +0200 From: Juergen Quittek Content-Type: text/plain; charset=us-ascii Message-Id: <7758B005-2F71-4F35-A07F-F28CC54724C5@quittek.at> Date: Sat, 13 Aug 2011 17:32:27 -0700 To: eman mailing list Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:AWhkCstqgoaO+Zx3Jd2CrG8ypMt54tZupOpOm57O2dc FFwp6hMC8rteqbQTjM620pcotXf+KeZ8u0ZokMorRiEwvaSYrC 2ZAORwvbB43X539XVbvCKDYdWLYDSQ1Yk+bYIb1KCuY5ELcvgn 54gc53k2eKu117fdwkkKgiMc/lA23vCTKoYErGSptlnPDoq0Xf RAF5F1sI+cXILL0i1Vh9uXfTWnRmLBus+o2JkxHwZs= Subject: [eman] Terminology: power states - battery state - power supply state X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 00:31:57 -0000 Dear all, Here are some thoughts on what a power state is and=20 how it relates to the battery state and the power supply state of a = device. So far, there is no document where we clearly define what a power state = is=20 and what it is not. Please find a list of definitions that I collected = from other documents further below. This email mainly serves for sharing some = thoughts=20 on this issue in order to jointly work on a more clear definition of a = power state. My main question is: What is characteristic for a power state? 1. the operational state (Is the device not/fully/partially = operational)? 2. the power consumption in a power state? (min/max/average = power/demand)? 3. the power supply state (running on mains/battery/self-generated = power)? 4. the total power balance (consuming/providing power)? As we have discussed it in the eman WG and as other standards bodies = including=20 DMTF, ACPI, PWG see it, it is just 1. with some implications on 2. Here = is another=20 try on a definition of a power state: "A power state represents one or multiple operational states of a = device. A power state indicates specific properties of a device concerning = its the energy=20 consumption when being in this state." Of course this one cries for definitions of an operational state. Operational state: "An operational state defines the availability of services provided = by a device." We certainly need some more text elaborating on power states beyond the = plain definition, maybe in the framework document. There is one note that I = would=20 definitely like to add there: "Energy consumption of a device is not the only state to be = considered=20 when managing the power supply of a device. If the device contains = batteries or facilities for energy harvesting/generation, also the battery = charging state=20 and the power supply state of a device need to be considered. For = example, a device in a non-operational state such as "off" or "sleep" may = still draw=20 a considerable power for charging its batteries. Or it may be in = state "on" and=20 not draw any mains power at all, because it runs on battery or = supplies itself with a built-in generator." This leads us to the definition of battery state and power supply state: Battery state: The battery state indicates the flow of energy into or out of a battery. Power supply state: The power supply state indicates which power supply is in use at a = device. Examples are: mains power, secondary mains power, battery, built-in = generator We definitely need the battery state for the battery MIB (see object=20 batteryChargingState in draft-ietf-eman-battery-mib-03). I think we also = need=20 something like the power supply state. But my ideas on it are much less = clear=20 than on the battery state that we have been discussing for some months = already. Here are the definitions of power state that we have tried so far: 1. draft-ietf-eman-framework-02 and draft-parello-eman-definitions-0 A Power State is a way to classify a Power setting on an Energy=20 Managed Object (e.g., on, off, or sleep). A Power State can be=20 viewed as a method for Energy Control=20 Comments:=20 - Yes, a power state may be used to classify power setting. But this is a way to use it, not a way define it.=20 - No, a power state is definitely not a method. 2. draft-ietf-eman-requirements-03 Power state of an entity is defined as a specific settings of an entity that influences its power. Examples of power states of an entity are on, off, hibernate, and sleep. Comment:=20 - This is correct, but it neglects the relationship to operational = states 3. draft-quittek-power-mib-02 A power state defines a limitations of services provided by a device and implicitly limits energy consumption. Examples for commonly implemented power states include 'on', 'full power', 'low power', 'sleep', 'stand-by', and 'off'. There is no commonly agreed convention for power states naming and semantics. Therefore power states with the same names may have different semantics and different names may be in use for the same power state. But the actual energy consumption of a device depends on more than just its power state. Also the current load, the kind of load, and many other factors influence energy consumption. Comments:=20 - first line is OK. It explains a power state as an operational state without using the term "operational state" (which might be = desirable). - second line does not seem to be correct. A power state may have=20 power limitations. But this is not a necessary property of it. - rest seems correct, but examples are not a definition and the = following text does not belong into the definition. 4. draft-ietf-eman-energy-monitoring-mib-00 =20 A Power State is defined as a specific power setting for a=20 Power Monitor (e.g., shut, hibernate, sleep, high). Within the=20 context of a Power State Set, the Power State of a device is=20 one of the power saving modes in that Power State Set.=20 Comments:=20 - First sentence correct, but it neglects the relationship to = operational states - The second sentence does not belong to the definition. - Second sentence explains power state as power saving mode. What is a power saving mode? Is "full power" a power saving mode? Thanks, Juergen= From ietf@quittek.at Sun Aug 14 11:30:32 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D57821F877B for ; Sun, 14 Aug 2011 11:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYIQGl3o+Q5v for ; Sun, 14 Aug 2011 11:30:32 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id B5FD421F876A for ; Sun, 14 Aug 2011 11:30:31 -0700 (PDT) Received: from [192.168.168.129] ([12.235.19.143]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0MJIbO-1Qr1pg024A-002mKA; Sun, 14 Aug 2011 20:31:13 +0200 From: Juergen Quittek Content-Type: text/plain; charset=us-ascii Message-Id: <7299E8E1-342F-4C1A-9FCF-11DCF01325B4@quittek.at> Date: Sun, 14 Aug 2011 11:31:02 -0700 To: eman mailing list Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:6RxSx6DBMP1Kad9Im8h9DbZt0atG3CE6N4O2mfb2NaC 32IuFDaXf9eHkSNdDnk8mlQKbJirBw8dRrofJmd651nTQaCeQV o8zAk2Mq5Fd4TpHIWSHJX1CDf65oYPB3UP1eltF1NCd4lJ5Fd+ ICPgSCQFzea74JbziDh12KzC2iZwSzbvH/e4L8sfcDcnYUWQ+E ddbgRN+GHe+mRC2GmhLoSXo0es+Mwh348Vd7fcAank= Subject: [eman] do we really need power quality measurements for energy management? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 18:30:32 -0000 Dear all, In draft-ietf-eman-requirements-04 we have a few requirements on = reporting=20 power quality. They are described in requirements 5.4.6-5.4.9, see copy = at the end of this email. The questions is: do we need these requirements and do we need all of = them? I mentioned the issue briefly in the session at Quebec but since this = was not=20 an urgent issue, we agreed to discuss this on the mailing list. Power quality expresses how good the actual power supply is. Power quality parameters include the actual voltage. Is it exactly = 110/230 Volts?=20 Or is it a bit more or less? It also concerns the actual AC frequency = (deviation=20 from 50/60 Hz), the total harmonic distortion of voltage current and the = impedance=20 of the power supply.=20 There was discussion on the mailing list that these may not be really = needed=20 for energy management without any objections. Do people in the WG think there is a requirement to standardize = reporting=20 these power quality values for energy management?=20 Or, can we drop them from our list of requirements?=20 If so, do you think we should drop just some or all of them? Thanks, Juergen > 5.4.6. Actual voltage and current >=20 > The energy management standard must provide means for reporting the > actual voltage and actual current for each power inlet and each = power > outlet of a powered entity. In case of AC power supply, means must > be provided for reporting the actual voltage and actual current per > phase. >=20 > 5.4.7. Actual AC frequency >=20 > The energy management standard must provide means for reporting the > actual AC frequency for each power inlet and each power outlet of a > powered entity. >=20 > 5.4.8. Total harmonic distortion >=20 > The energy management standard must provide means for reporting the > Total Harmonic Distortion (THD) of voltage and current for each = power > inlet and each power outlet of a powered entity. In case of AC = power > supply, means must be provided for reporting the THD per phase. >=20 > 5.4.9. Power supply impedance >=20 > The energy management standard must provide means for reporting the > impedance of power supply for each power inlet and each power outlet > of a powered entity. In case of AC power supply, means must be > provided for reporting the impedance per phase. From saperia@jdscons.com Sun Aug 14 11:58:38 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BDA21F886A for ; Sun, 14 Aug 2011 11:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qkFzSO0bUno for ; Sun, 14 Aug 2011 11:58:37 -0700 (PDT) Received: from rs69.luxsci.com (rs69.luxsci.com [64.49.254.154]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDC221F87C9 for ; Sun, 14 Aug 2011 11:58:36 -0700 (PDT) Received: from [10.0.1.2] (c-98-229-133-101.hsd1.ma.comcast.net [98.229.133.101]) (authenticated bits=0) by rs69.luxsci.com (8.13.8/8.13.8) with ESMTP id p7EIxFQU003362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Aug 2011 13:59:17 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jon Saperia In-Reply-To: <7299E8E1-342F-4C1A-9FCF-11DCF01325B4@quittek.at> Date: Sun, 14 Aug 2011 14:59:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7299E8E1-342F-4C1A-9FCF-11DCF01325B4@quittek.at> To: Juergen Quittek X-Mailer: Apple Mail (2.1084) Cc: eman mailing list Subject: Re: [eman] do we really need power quality measurements for energy management? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 18:58:38 -0000 I have been mostly following this list so this comment may not be = directly relevant. To the degree one wants to measure delivered power = whether from a utility to a data center for example, a back up source = such as a generator, or anything else, power quality measurements of the = type mentioned are important. If you are thinking mostly of devices = that consume energy only , then it may not matter as much. /jon On Aug 14, 2011, at 2:31 PM, Juergen Quittek wrote: > Dear all, >=20 > In draft-ietf-eman-requirements-04 we have a few requirements on = reporting=20 > power quality. They are described in requirements 5.4.6-5.4.9, see = copy at > the end of this email. >=20 > The questions is: do we need these requirements and do we need all of = them? > I mentioned the issue briefly in the session at Quebec but since this = was not=20 > an urgent issue, we agreed to discuss this on the mailing list. >=20 > Power quality expresses how good the actual power supply is. > Power quality parameters include the actual voltage. Is it exactly = 110/230 Volts?=20 > Or is it a bit more or less? It also concerns the actual AC frequency = (deviation=20 > from 50/60 Hz), the total harmonic distortion of voltage current and = the impedance=20 > of the power supply.=20 >=20 > There was discussion on the mailing list that these may not be really = needed=20 > for energy management without any objections. >=20 > Do people in the WG think there is a requirement to standardize = reporting=20 > these power quality values for energy management?=20 > Or, can we drop them from our list of requirements?=20 > If so, do you think we should drop just some or all of them? >=20 > Thanks, >=20 > Juergen >=20 >=20 >> 5.4.6. Actual voltage and current >>=20 >> The energy management standard must provide means for reporting the >> actual voltage and actual current for each power inlet and each = power >> outlet of a powered entity. In case of AC power supply, means must >> be provided for reporting the actual voltage and actual current per >> phase. >>=20 >> 5.4.7. Actual AC frequency >>=20 >> The energy management standard must provide means for reporting the >> actual AC frequency for each power inlet and each power outlet of a >> powered entity. >>=20 >> 5.4.8. Total harmonic distortion >>=20 >> The energy management standard must provide means for reporting the >> Total Harmonic Distortion (THD) of voltage and current for each = power >> inlet and each power outlet of a powered entity. In case of AC = power >> supply, means must be provided for reporting the THD per phase. >>=20 >> 5.4.9. Power supply impedance >>=20 >> The energy management standard must provide means for reporting the >> impedance of power supply for each power inlet and each power outlet >> of a powered entity. In case of AC power supply, means must be >> provided for reporting the impedance per phase. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 From ietf@quittek.at Sun Aug 14 15:07:48 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE52E21F86FF for ; Sun, 14 Aug 2011 15:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUU3abuz3QiE for ; Sun, 14 Aug 2011 15:07:45 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3038D21F86F6 for ; Sun, 14 Aug 2011 15:07:44 -0700 (PDT) Received: from [192.168.168.129] ([12.235.19.143]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LxYj9-1RMGtm19vH-017HeM; Mon, 15 Aug 2011 00:08:27 +0200 References: <4E2E1729.3070600@cisco.com> <4E2E5C6C.6070502@cisco.com> In-Reply-To: <4E2E5C6C.6070502@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-45053606 Message-Id: <664B5A52-0895-4120-98B6-3C7D0ABA169A@quittek.at> From: Juergen Quittek Date: Sun, 14 Aug 2011 15:08:22 -0700 To: Benoit Claise X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:VR61B/RYiDCbFQIt9vmaPytIMLDi8gdfxze3MUoJ1EL Z1LYnEw1HgawlaFJBLoFync7/qMS2Cz0Pnfxp+lJjrGUvic864 70cT3RPSyO0DX4Fea9CwulWUmTahdj2QG9ELJTn2/g38suo3gx ftcGL8pDW+3dWR2ICecjisataEoOFrK2tCYo20to1bmCN/5etj wOyWFwKikalrMo26RqrhjBwBaw6HADNauGQHoi8gEk= Cc: eman mailing list Subject: Re: [eman] feedback on the eman-ietf-eman-requirements-04 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 22:07:49 -0000 --Apple-Mail-1-45053606 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Benoit, Thanks a lot for all the comments. Please find replies inline. Am 26.07.2011 um 02:19 schrieb Benoit Claise: > Dear all, >=20 > Here is my feedback regarding the EMAN requirement, as a contributor. > Note that some points might have been made on the mailing list = already. >=20 > A couple of big points > - the outlet gang was mentioned by Chris Verges as a requirement. I = don't think I've seen it mentioned. > Note: this could be solved by a specificEnergy Managed Object = Relationships (Metering, Power Source, Proxy, Dependency) Since we do not have text for this requirements, let's list it as an = open issue for now. > - we would need some requirements about producer and/or consumer A lot of the producer requirements are covered by the power outlet = requirements. But I fully agree. There may be specific requirements missing for = generators. Do you have any? Also we need to check the entire text. Many sentences implicitly assume = that we are only dealing with consumers. > - I've been thinking about the following requirement some more > 7.3. Reporting quantities accumulated over multiple powered entities=20= >=20 > For powered entities reporting single values that are accumulated=20= > over multiple powered entities, the energy management standard must=20= > provide means for reporting the list of all powered entities from=20= > which contributions are included in the accumulated value.=20 > And I wonder if we're not trying to make EMAN too complex by adding = this aggregation function. > Note: I've been involved in aggregation scheme (See RFC 5982, RFC = 6183, and http://tools.ietf.org/html/draft-trammell-ipfix-a9n-03) and = this is not straight forward to list all powered entities for which = there is an aggregation. > My point is that there is some debate whether or not a switch should = aggregate all values for children, or if this is a NMS issue. > Feedback? >=20 > See inline >> Network Working Group J. Quittek, = Ed.=20 >> Internet-Draft R. = Winter=20 >> Intended status: Informational T. = Dietz=20 >> Expires: January 12, 2012 NEC Europe = Ltd.=20 >> B. = Claise=20 >> M. = Chandramouli=20 >> Cisco Systems, = Inc.=20 >> July 11, = 2011=20 >>=20 >>=20 >> Requirements for Energy Management=20 >> draft-ietf-eman-requirements-04=20 >>=20 >> Abstract=20 >>=20 >> This document defines requirements for standards specifications = for=20 >> energy management. Defined requirements concern monitoring = functions=20 >> as well as control functions. Covered functions include=20 >> identification of powered entities, monitoring of their power = state,=20 >> power inlets, power outlets, actual power, consumed energy, and=20 >> contained batteries. Further included is control of powered=20 >> entities' power supply and power state. This document does not=20 >> specify the features that must be implemented by compliant=20 >> implementations but rather features that must be supported by=20 >> standards for energy management.=20 > This misses the power quality, or whatever name we want to call it. > For example "power characteristics)" OK. Let's add power quality for now. We can revise it if we have found a better term. Recent statements on the mailing lists questioned the ned for power quality measurements. We should try to reach consensus on this = issue. >>=20 >> Status of this Memo=20 >>=20 =20 [snip] >>=20 >> 1. Introduction=20 >>=20 >> With rising energy cost and with an increasing awareness of the=20 >> ecological impact of running IT and networking equipment, energy=20= >> management is becoming an additional basic requirement for network=20= >> management systems and frameworks.=20 >>=20 >> This document defines requirements for standards specifications = for=20 >> energy management. Defined requirements concern monitoring = functions=20 >> as well as control functions. Covered functions include=20 >> identification of powered entities, monitoring of their power = state,=20 >> power inlets, power outlets, actual power, consumed energy, and=20 >> contained batteries. Further included is control of powered=20 >> entities' power supply and power state. Note that this document = does=20 >> not specify the features that must be implemented by compliant=20 >> implementations but rather features that must be supported by=20 >> standards for energy management.=20 > Same remark about power quality Same reply: Let's add power quality for now. >>=20 >> The main subject of energy management are powered entities that=20 >> consume electric energy. Powered entities include devices that = have=20 >> an IP address and can be addressed directly, such as hosts, = routers,=20 >> and middleboxes, as well as devices indirectly connected to an IP=20= >> network, for which a proxy with an IP address provides a = management=20 >> interface, for example, devices in a building management=20 >> infrastructure using BACNET or MODBUS protocols.=20 >>=20 >> The requirements specified in this document explicitly concern the=20= >> standards specification process and not the implementation of=20 >> specified standards. All requirements in this document must be=20 >> reflected by standards specifications to be developed. But which = of=20 >> the features specified by these standards will be mandatory,=20 >> recommended, or optional for compliant implementations is to be=20 >> defined by the concrete standards track document(s) and not in = this=20 >> document.=20 >>=20 >> This document first discusses general objectives of energy = management=20 >> in Section 3. Requirements for an energy management standard are=20= >> specified in Sections 4 to 8.=20 >>=20 >> 1.1. Conventional requirements for energy management=20 > I don't know what "conventional" is supposed to mean. Conventional in EMAN are requirements of a kind that we use=20 to have for many other network management issues:=20 You measure quantities at a device, make them available in MIB modules,=20= read them from an NMS, send control commands if needed.=20 I will add text on this. Special in EMAN are requirements resulting from the fact that you may=20 have to speak to other devices in order to measure the power for a = device=20 or to control its power supply. I am fine with replacing "conventional" with another term.=20 Are there proposals? "device-centric"? >>=20 >> The specification of requirements for an energy management = standard=20 >> starts with Section 4 addressing the identification of powered=20 >> entities and the granularity of reporting of energy-related=20 >> information.=20 > I don't understand why we have that sentence here and not in the = identifier in section 4. Well this is the introduction explaining the structure of the document. Here the content of Section 4 is explained, below you find the content=20= of sections 5 and 6 summarized. >> A standard must support unique identification of=20 >> powered entities. Furthermore, it must support more than just=20 >> reporting per powered device. Support is required for also = reporting=20 >> energy-related information on individual components of a device or=20= >>=20 >>=20 >>=20 >> Quittek, et al. Expires January 12, 2012 [Page = 4]=20 >>=20 >> Internet-Draft Requirements for Energy Management July = 2011=20 >>=20 >>=20 >> subtended devices. This is why this draft uses the more general = term=20 >> "powered entity" rather than "powered device". A powered entity = may=20 >> be a device or a component of a device.=20 >>=20 >> Section 5 specifies requirements related to monitoring of powered=20= >> entities. This includes general (type, context) information and=20= >> specific information on power states, power inlets, power outlets,=20= >> power, energy, and batteries. Control power state and power = supply=20 >> of powered entities is covered by requirements specified in=20 >> Section 6.=20 >>=20 >> 1.2. Specific requirements for energy management=20 >>=20 >> At first glance the rather conventional requirements summarized = above=20 >> seem to be all that would be needed for energy management. But it=20= >> turns out that there are some significant differences between = energy=20 >> management and most of the well known conventional network = management=20 >> functions. The most significant difference from many other=20 >> management functions is the need for some devices to report on = other=20 >> entities. There are three major reasons for this.=20 >> o For monitoring and controlling a particular powered entity in=20= >> general it is not sufficient to communicate with the powered=20 > "sufficient" is not the right wording. > In some cases, this is just impossible to communicate with the powered = entity. > Example: proxy. This case is covered by the following bullet item. >=20 >> entity only, but in many cases also communication with other=20 >> powered entities along the power distribution path may be=20 >> necessary, for example, with power switches and power meters.=20= >> Indeed, there are situations where a power or energy meter is = not=20 >> located in the powered entity, but in a different physical=20 >> location. For example, a Power Distribution Unit (PDU), which=20= >> supplies power for a server connected to a PDU socket, would = meter=20 >> the power supplied, while the server may not have the = capability=20 >> to measure its power consumption.=20 > new text: In specific cases, the monitoring and controlling of powered = entities must be done by another entity along the power distribution = domain. For example.=20 > And you remove "a second example" below Please check the revision of the first bullet. I don't think the word "must" is appropriate. >> A second example is a Power=20 >> over Ethernet port, which provides power to the attached = device,=20 >> and which can meter how much power/energy it delivers to the=20 >> attached device.=20 >> o Energy management often extends its scope beyond powered = entities=20 >> with IP network interfaces, for example toward non-IP building=20= >> networks, that are accessed via an IP gateway. Requirements in=20= >> this document do not fully cover all these networks, but they=20= >> cover means for opening IP network management towards them.=20 >> o For monitoring of particular powered entities, it is sometimes = not=20 >> a scalable approach to communicate directly with all the = powered=20 >> entities directly from a central energy management system as = the=20 >> number of powered entities keeps increasing.=20 >>=20 >> This specific issue of energy management and a set of further ones=20= >> are covered by requirements specified in Sections 7 and 8.=20 >>=20 >>=20 [snip] >>=20 >> 2.8. Energy management=20 >>=20 >> the definition of the term power is to be agreed on in the EMAN = WG.=20 >>=20 >> 2.9. Energy management standard=20 > This doesn't look like a definition. At least, the first paragraph = should be removed. Right it does not look like a definition.=20 I would suggest removing not the first paragraph,=20 but just the first sentence and keep the rest of the first paragraph: "This term refers to a collections of documents specifying=20 standards for energy-related monitoring and control. The energy=20 management standard specifies means for building energy management=20 systems." This looks a little bit more like a definition. The following two paragraphs are not really part of a definition. =20 They are redundant because similar text is already the introduction.=20 We should remove them. >>=20 >> This document specifies requirements for an energy management=20 >> standard. This term refers to a collections of documents = specifying=20 >> standards for energy-related monitoring and control. The energy=20= >> management standard specifies means for building energy management=20= >> systems.=20 >>=20 >> Requirements specified in this document concern the means that an=20= >> energy management standard must provide. It does not imply that = all=20 >> required means must be implemented in all energy standard = scenarios.=20 >> Which means and features must be implemented by compliant=20 >> implementations is to be specified by the energy management = standard=20 >> itself, not by this requirements document.=20 >>=20 >> Note that for meeting individual requirements specified in this=20 >> document, new standards are not necessarily required. It is=20 >> recommended to rather use existing standards than specify new = ones.=20 >=20 >>=20 >>=20 >>=20 >>=20 >> Quittek, et al. Expires January 12, 2012 [Page = 7]=20 >>=20 >> Internet-Draft Requirements for Energy Management July = 2011=20 >>=20 >>=20 >> 3. General Objectives of Energy Management=20 > Rename to "general considerations related to energy management" Done. >>=20 >> The basic objective of energy management is operating = communication=20 >> networks and other equipment with minimal amount of energy, while=20= >> maintaining a certain level of service. A set of use cases for=20 >> energy management can be found in=20 >> [I-D.tychon-eman-applicability-statement].=20 > It would read better if the content of section about trade-offs was = next in this introduction (without having a specific section) > Then=20 > 3.1. Power States > 3.2 Energy Monitoring versus Energy Savings It is no "Energy Monitoring vs. Energy Savings" but rather=20 "Maintaining service level agreements vs. Energy Savings" But your title is good for renaming section 3.4. > 3.3 Local versus network-wide energy management done. > 3.4. Overview of the energy management requirements Yes. but this is section 3.5 >=20 >>=20 >> 3.1. Power states=20 >>=20 >> One approach to achieve this goal is by setting all powered = entities=20 >> to an operational state that results in lower energy consumption, = but=20 >> still meets the service level performance objectives. The = sufficient=20 >> performance level may vary over time and can depend on several=20 >> factors. In principle, there are four basic types of power states=20= >> for a powered entity or for a whole system:=20 >> o full power state=20 >> o reduced power states (lower clock rate for processor, lower = data=20 >> rate on a link, etc.)=20 >> o sleep state (not functional, but immediately available)=20 >> o off state (may imply requiring significant time for becoming=20 >> operational)=20 >> In actual implementations the number of power states and their=20 >> properties vary a lot. Very simple powered entities may just have=20= >> only the extreme states, full power and off state. Some=20 >> implementations might use IEEE1621 model of three states on, off, = and=20 >> sleep. However, more granular power states can be implemented = with=20 >> many levels of off, sleep, and reduced power states.=20 >>=20 >> 3.2. Trade-offs=20 >>=20 >> While the general objective of energy management is quite clear, = the=20 >> way to attain that goal is often difficult. In many cases there = is=20 >> no way of reducing power consumption without the consequence of a=20= >> potential performance, service, or capacity degradation. Then a=20= >> trade-off needs to be dealt with between service level objectives = and=20 >> energy efficiency. In other cases a reduction of energy = consumption=20 >> can easily be achieved while still maintaining sufficient service=20= >> level performance, for example, by switching powered entities to=20= >> lower power states when higher performance is not needed.=20 >>=20 >> 3.3. Local and network-wide energy management=20 >>=20 >> Many energy saving functions can be executed locally by a powered=20= >> entitiy. The basic principle is that a powered entitiy monitors = its=20 >> usage and dynamically adapts its energy consumption according to = the=20 >> required performance. It may switch to a sleep state when it is = not=20 >> in use at all.=20 > Well, not only when it's not in use. > It could be based on the time of day, or any other energy saving = policies. Right. I extended the sentence accordingly. >> Potential interactions with an energy management=20 >>=20 >>=20 >>=20 >> Quittek, et al. Expires January 12, 2012 [Page = 8]=20 >>=20 >> Internet-Draft Requirements for Energy Management July = 2011=20 >>=20 >>=20 >> system for such an entity include the observation of the entity's=20= >> power state and the configuration of power saving policies, for=20 >> example, by setting thresholds for power state changes.=20 >>=20 >> Energy savings can also be achieved with policies implemented by a=20= >> network management system that controls power states of managed=20 >> entities. In order to make policy decisions properly, information=20= >> about the energy consumption of powered entities in different = power=20 >> states is required. Often this information is acquired best = through=20 >> monitoring.=20 >>=20 >> Both methods, network-wide and local energy management, have=20 >> advantages and disadvantages. Most buildings use both of them. = In=20 >> some cases for example, significant energy savings can be achieved = by=20 >> simply setting all powered entities in a network to sleep, when = the=20 >> network is not needed. However, in general it is dangerous to set=20= >> all powered entities of a group to the same state, because there = is a=20 >> risk that such actions ignore specifics of individual powered=20 >> entities or violate local service level agreements.=20 > Can you please expand the previous sentence. > I'm not sure that I agree. I suggest removing it and polishing the entire paragraph: "Both methods, network-wide and local energy management, have advantages and disadvantages and often it is a good coice=20= to combine them. Central management is often favourable for=20 setting power states of a large number of entities at the same time, for example, at beginning and end of business hours in a=20= building. Local management appears often to be preferable for dynamic power saving measures based on local observations, such=20= as high or low load of an entity." >>=20 >> 3.4. Energy monitoring=20 > rename to "energy monitoring versus energy savings" Done. >>=20 >> It should be noted that only monitoring energy consumption and = power=20 >> states is obviously not a means to reduce the energy consumption = of a=20 >> powered entitiy. In fact, it is likely to increase the power=20 >>=20 [snip] >> 3.5. Overview of energy management requirements=20 >>=20 >> =46rom the considerations described above the following basic=20 >> management functions appear to be required for energy management:=20= >> o monitoring power states=20 >> o monitoring power (energy consumption rate)=20 >> o monitoring (accumulated) energy consumption=20 >> o setting power states=20 >> o setting and enforcing power saving policies=20 > And again the comment about the power quality Added. >>=20 >> It should be noted that active power control is complementary (but=20= > what does the "active" power control mean? I don't know. I suggest removing "active". >> essential) to other energy savings measures such as low power=20 >> electronics, energy saving protocols (for example, IEEE 802.3az),=20= >> energy-efficient device design (for example, sleep and low-power=20= >> modes for individual components of a device), and energy-efficient=20= >> network architectures. Measurement of energy consumption may also=20= >> provide useful input for developing these technologies.=20 >>=20 >>=20 >> 4. Identification of Powered Entities=20 >>=20 >> As already stated Section 1.1, powered entities on which energy-=20= >> related information is provided > add a comma fixed. >> are identified in a sufficiently=20 >> unique way. This holds in particular for powered entities that = are=20 >> components of managed devices and in case that one powered entity=20= >> reports information on another one, see Section 7. For powered=20 >> entities that control other powered entities it is important to=20 >> identify the powered entities they control, see Section 8.=20 >>=20 >> Also stated already in Section 1.1 is the requirement of providing=20= >> means for reporting energy-related information on components of a=20= >> managed device. An entity in this document may be an entire = managed=20 >> device or just a component of it. Examples of components of = interest=20 >> are a hard drive, a battery, or a line card. For controlling=20 >> entities it may be required to be able to address individual=20 >> components in order to save energy. For example, server blades = can=20 >> be switched off when the overall load is low or line cards at=20 >> switches may be powered down at night times.=20 >>=20 >> Instrumentation for measuring energy consumption of a device is=20 >> typically more expensive than instrumentation for retrieving the=20= >> devices power state. It may be a reasonable compromise in many = cases=20 >> to provide power state information for all individually switchable=20= >> components of a device separately, while the energy consumption is=20= >> only measured for the entire device.=20 >>=20 >> Detailed Requirements:=20 >>=20 >>=20 >>=20 >>=20 >> Quittek, et al. Expires January 12, 2012 [Page = 10]=20 >>=20 >> Internet-Draft Requirements for Energy Management July = 2011=20 >>=20 >>=20 >> 4.1. Identifying powered entities=20 >>=20 >> The energy management standard must provide means for uniquely and=20= >> persistently identifying powered entities that are monitored or=20 >> controlled by an energy management system. Uniqueness must be = given=20 >> in a domain that is large enough to avoid collisions of identities = at=20 >> potential receivers of monitored information.=20 > We want to remove "and persistently" from the sentence, as this is = covered in 4.3 Done. > We should have a requirement about a UUID for powered entities. > Let's cover that during the WG. Replaced last sentence with "In order to avoid collisions of identities at potential receivers of=20= monitored information, a univesally unique identifier must be used." >>=20 >> 4.2. Identifying components of powered devices=20 >>=20 >> The energy management standard must provide means for identifying = not=20 >> just entire devices as powered entities, but also individual=20 >> components of powered devices.=20 >>=20 >> 4.3. Persistency of Identifiers=20 >>=20 >> The energy management standard must provide means for indicating=20= >> whether identifiers of powered entities are persistent across a = re-=20 >> start of the powered entitiy that provides the identifiers.=20 >>=20 >>=20 >> 5. Information on Powered Entities=20 >>=20 >> This section describes energy-related information on powered = entities=20 >> for which an energy management standard must provide means for=20 >> retrieving and reporting.=20 >>=20 >> Note that the fact that an energy management standard provides=20 >> required means does not imply that all of them must be implemented = by=20 >> every compliant implementation. The concrete specification of=20 >> standards based on these requirements may label individual = features=20 >> as mandatory, recommended, or optional.=20 > Remove this paragraph above, as this is already covered before, and = this is not specific to this section 5. OK. >>=20 >> Required information on powered entities can be structured into = six=20 >> groups. Section 5.1 specifies requirements for general = information=20 >> on powered entities, such as type of powered entity or context=20 >> information. Section 5.2 covers requirements related to entities'=20= >> power states. Requirements for information on power inlets and = power=20 >> outlets of powered entities are specified in Section 5.3. = Monitoring=20 >> of power and energy is covered by Sections 5.4 and 5.5, = respectively.=20 >> Finally, Section 5.6 specified requirements for monitoring = batteries.=20 >>=20 >> 5.1. General information on powered entities=20 >>=20 >> For energy management it may be required to understand the role = and=20 >> context of a powered entitiy. When monitoring, it may be helpful = to=20 >> group energy consumption per kind of entity. When controlling and=20= >> setting power states it may be helpful to understand the kind and=20= >>=20 >>=20 >>=20 >> Quittek, et al. Expires January 12, 2012 [Page = 11]=20 >>=20 >> Internet-Draft Requirements for Energy Management July = 2011=20 >>=20 >>=20 >> role of a powered entitiy in a network, for example, in order to=20= >> avoid switching off vital network components.=20 >>=20 >> Detailed Requirements:=20 >>=20 >> 5.1.1. Type of powered entity=20 >>=20 >> The energy management standard must provide means to retrieve and=20= >> report the type of powered entities according to a standrdized=20 >> classification scheme.=20 > see the email thread on the mailing list. Yes. It is still an open issue. >>=20 [snip] >> 5.2.1. Actual power state=20 >>=20 >> The energy management standard must provide means for reporting = the=20 >> actual power state of a powered entitiy.=20 >>=20 >> 5.2.2. List of supported power states=20 >>=20 >> The energy management standard must provide means for retrieving = the=20 >> list of all potential power states of a powered entitiy.=20 >>=20 >> 5.2.3. Multiple power state sets=20 >>=20 >> The energy management standard must provide means for supporting=20= >> multiple power state sets simultaneously at a powered entity.=20 >>=20 >> 5.2.4. List of supported power state sets=20 >>=20 >> The energy management standard must provide means for retrieving = the=20 >> list of all power state sets supported by a powered entitiy.=20 >>=20 >> 5.2.5. List of supported power states=20 > 5.2.2 has got the same title. > Proposal for 5.2.5 "List of supported power states within power state = set" Done. >>=20 >> Referring to the "list of supported power state sets" requirement,=20= >> the energy management standard must provide means for retrieving = the=20 >> list of all potential power states of a powered entitiy that = belong=20 >> to a given power state set.=20 > new text. > For the rest of the document, when the Power State term is used, = it implicitly refers to a power state within a power state set. >=20 > Note that this comment might be part of the power State definition Yes, let's rather add this to the definition of power states. Here it seems to bee too late in the draft, because we talk a lot about = power states before. And it should not be just for the rest of the document, it should be for = the full document. >>=20 >> 5.2.6. Maximum and average power per power state=20 >>=20 >> The energy management standard must provide means for retrieving = the=20 >> maximum power and the average power as a typically static property=20= >> for each supported power state.=20 >>=20 >> 5.2.7. Power state statistics=20 >>=20 >> The energy management standard must provide means for monitoring=20= >> statistics per power state including at least the total time spent = in=20 >> a power state, the number of times a state was entered and the = last=20 >> time a state was entered. More power state statistics are = addressed=20 >>=20 >>=20 >>=20 >> Quittek, et al. Expires January 12, 2012 [Page = 13]=20 >>=20 >> Internet-Draft Requirements for Energy Management July = 2011=20 >>=20 >>=20 >> by requirement 5.5.3.=20 >>=20 >> 5.2.8. Power state changes=20 >>=20 >> The energy management standard must provide means for generating a=20= >> notification when the actual power state of a powered entity = changes.=20 >>=20 >> 5.3. Power inlet and power outlet=20 >>=20 >> Powered entities have power inlets at which they are supplied with=20= >> electric power. Most powered entities just have a single power=20 >> inlet, while some have multiple ones. Often different power = inlets=20 >> are connected to separate power distribution trees. For energy=20 >> monitoring, it is important information which power inlets a = powered=20 >> entitiy has, > what do you mean? the type, the number, or something else? This was poorly phrased. Here is another try or the last sentence: "For energy monitoring,=20 it is useful to retrieve information on the number of inlets=20 of a powered entitiy, the availability of power at inlets=20 and which of them are actually in use." >> if power is available at an inlet and which of them are=20 >> actually in use.=20 >>=20 >> Some powered entities have power outlets for supplying other = powered=20 >> entities with electric power. A powered entitiy may have multiple=20= >> power outlets. Examples are Power Distribution Units (PDUs) and=20= >> Power over Ethernet (PoE) Power Sourcing Equipment (PSE).=20 > Remove the previous sentence, as this is already in the terminology = section. Done. >>=20 >> For identifying and potentially controlling the source of power=20 >> received at an inlet, it may be required to identify the power = outlet=20 >> of another powered entity at which the received power is provided.=20= >> Analogously, for each outlet it is of interest to identify the = power=20 >> inlets that receive the power provided at a certain outlet.=20 >>=20 >> Static properties of each power inlet and each power outlet are=20 >> required information for energy management. Static properties=20 >> include the kind of electric current (Alternating Current (AC) or=20= >> Direct Current (DC)), the nominal voltage, the nominal AC = frequency,=20 >> and the number of AC phases.=20 > So "static properties" is what we called "power quality"? I am not sure what was meant when the term power quality was used in = discussions. The current version of the Power Quality MIB contains several dynamic = values that can=20 be used to determine power quality. But it does not contain these static = values. >>=20 >> Detailed Requirements:=20 >>=20 [snip] >> 5.3.8. Nominal AC frequency=20 >>=20 >> The energy management standard must provide means for reporting = the=20 >> nominal AC frequency for each power inlet and each power outlet of = a=20 >> powered entity.=20 >>=20 >> 5.3.9. number of AC phases=20 > number -> Number Fixed. >>=20 >> The energy management standard must provide means for reporting = the=20 >> number of AC phases for each power inlet and each power outlet of = a=20 >> powered entity.=20 >>=20 [snip] >> 5.6. Battery State=20 >>=20 >> Today more and more powered entities contain batteries that supply=20= >> them with power when disconnected from electrical power = distribution=20 >> grids. Common examples are nomadic and mobile devices, such as=20 >> notebook computers, netbooks, and smart phones. The status of=20 >> batteries in such an powered entity, particularly the charging = status=20 >> is typically controlled by automatic functions that act locally on=20= >> the powered entitiy and manually by users of the powered entity. = In=20 >>=20 >>=20 >>=20 >> Quittek, et al. Expires January 12, 2012 [Page = 19]=20 >>=20 >> Internet-Draft Requirements for Energy Management July = 2011=20 >>=20 >>=20 >> addition to this, there is a need to monitor the battery status of=20= >> these entities by network management systems.=20 >>=20 >> The management requirements discussed above in Sections 5.1 to 5.5=20= >> concern energy-related information on powered entities. Powered=20= >> entities may be powered devices or components of powered devices.=20= > I believe that we mentioned that sentence already. removed. >> Devices containing batteries can be modeled in two ways. The = entire=20 >> device can be modeled as a single powered entity on which energy-=20= >> related information is reported or the battery can be modeled as = an=20 >> individual powered entity for which energy-related information is=20= >> monitored individually according to requirements in Sections 5.1 = to=20 >> 5.5.=20 >>=20 >>=20 [snip] >> 5.6.6. Low battery charge notification=20 >>=20 >> The energy management standard must provide means for generating a=20= >> notification when a the charge of a battery decreases below a = given=20 >> threshold.=20 > remove "a" Fixed. >>=20 >> 5.6.7. Battery replacement notification=20 >>=20 >> The energy management standard must provide means for generating a=20= >> notification when the number of charging cycles of battery exceeds = a=20 >> given threshold.=20 >>=20 >>=20 [snip] >>=20 >> 7.3. Reporting quantities accumulated over multiple powered entities=20= >>=20 >> For powered entities reporting single values that are accumulated=20= >> over multiple powered entities, the energy management standard = must=20 >> provide means for reporting the list of all powered entities from=20= >> which contributions are included in the accumulated value.=20 > See my comments at the beginning of the email Yes. We need conclusion on the aggregation issue before finalizing this. >>=20 >> 7.4. List of all powered entities on which is reported=20 >>=20 >> The energy management standard must provide means for a powered=20 >> entitiy to report the list of all other powered entities on which = it=20 >> can report energy-related information.=20 >>=20 [snip] >> 8.2. Controlling power supply of other powered entities=20 >>=20 >> Some powered entities may have control of the power supply of = other=20 >> powered entities, for example, because the other powered entity is=20= >> supplied via a power outlet of the powered entitiy. For this and=20= >> similar cases means are needed to make this control accessible to = the=20 >> energy management system.=20 >>=20 >> In addition to this, it is very required that a powered entitiy = that=20 > very required -> required Fixed. >> has its supply controlled by other powered entities has means to=20= >> report the list of these other powered entities.=20 >>=20 [snip] >> 11. Acknowledgements=20 >>=20 >> The authors would like to thank Ralf Wolter for his first essay on=20= >> this draft. Many thanks to William Mielke, John Parello, Bruce=20 >> Nordman, JinHyeock Choi, Georgios Karagiannis, and Michael Suchoff=20= >> for helpful comments on the draft.=20 >>=20 > I'll address the open issues in separate email threads. >=20 > Regards, Benoit. Thanks a lot, Juergen --Apple-Mail-1-45053606 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Benoit,

Thanks a lot for all the comments. Please = find replies inline.

Am 26.07.2011 um 02:19 = schrieb Benoit Claise:

=20 =20
Dear all,

Here is my feedback regarding the EMAN requirement, as a contributor.
Note that some points might have been made on the mailing list already.

A couple of big points
- the outlet gang was mentioned by Chris Verges as a requirement. I don't think I've seen it mentioned.
    Note: this could be solved by a specificEnergy = Managed Object Relationships  (Metering, Power Source, Proxy, = Dependency)

Since we do not have = text for this requirements, let's list it as an open issue for = now.

- we would need some requirements about producer and/or = consumer

A lot of the = producer requirements are covered by the power outlet = requirements.
But I fully agree. There may be specific = requirements missing for generators.
Do you have = any?

Also we need to check the entire text. = Many sentences implicitly assume that we
are only dealing with = consumers.

- I've been thinking about the following requirement some more
7.3.  Reporting quantities accumulated over = multiple powered entities

   For powered entities reporting single values that are accumulated
   over multiple powered entities, the energy management = standard must
   provide means for reporting the list of all powered = entities from
   which contributions are included in the accumulated = value.
And I wonder if we're not trying to make EMAN too complex by adding this aggregation function.
Note: I've been involved in aggregation scheme (See RFC 5982, RFC 6183, and http://too= ls.ietf.org/html/draft-trammell-ipfix-a9n-03) and this is not straight forward to list all powered entities for which there is an aggregation.
My point is that there is some debate whether or not a switch should aggregate all values for children, or if this is a NMS issue.
Feedback?

See inline
Network Working = Group           &nb= sp;            = ;            J. = Quittek, Ed.
= Internet-Draft          =             &n= bsp;           &nbs= p;            =   R. Winter
Intended status: = Informational          &= nbsp;           &nb= sp;           T. Dietz
Expires: January 12, = 2012           &nbs= p;            =         NEC Europe Ltd.
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p; B. Claise
=             &n= bsp;           &nbs= p;            =             &n= bsp;       M. Chandramouli
=             &n= bsp;           &nbs= p;            =             &n= bsp;   Cisco Systems, Inc.
=             &n= bsp;           &nbs= p;            =             &n= bsp;         July 11, 2011


=             &n= bsp;      Requirements for Energy Management
=             &n= bsp;       draft-ietf-eman-requirements-04

Abstract

   This document defines requirements for standards = specifications for
   energy management.  Defined requirements concern = monitoring functions
   as well as control functions.  Covered functions = include
   identification of powered entities, monitoring of = their power state,
   power inlets, power outlets, actual power, consumed = energy, and
   contained batteries.  Further included is = control of powered
   entities' power supply and power state.  This = document does not
   specify the features that must be implemented by = compliant
   implementations but rather features that must be = supported by
   standards for energy management.
This misses the power quality, or whatever name we want to call = it.
For example "power = characteristics)"

OK. Let's add = power quality for now.
We can revise it if we have found a = better term.
Recent statements on the mailing lists questioned = the ned for
power quality measurements. We should try to reach = consensus on this issue.


Status of this Memo
=
 
[snip]

=

1.  Introduction

   With rising energy cost and with an increasing = awareness of the
   ecological impact of running IT and networking = equipment, energy
   management is becoming an additional basic = requirement for network
   management systems and frameworks.

   This document defines requirements for standards = specifications for
   energy management.  Defined requirements concern = monitoring functions
   as well as control functions.  Covered functions = include
   identification of powered entities, monitoring of = their power state,
   power inlets, power outlets, actual power, consumed = energy, and
   contained batteries.  Further included is = control of powered
   entities' power supply and power state.  Note = that this document does
   not specify the features that must be implemented by = compliant
   implementations but rather features that must be = supported by
   standards for energy management.
Same remark about power = quality

Same reply: Let's add power = quality for now.


   The main subject of energy management are powered = entities that
   consume electric energy.  Powered entities = include devices that have
   an IP address and can be addressed directly, such as = hosts, routers,
   and middleboxes, as well as devices indirectly = connected to an IP
   network, for which a proxy with an IP address = provides a management
   interface, for example, devices in a building = management
   infrastructure using BACNET or MODBUS protocols.

   The requirements specified in this document = explicitly concern the
   standards specification process and not the = implementation of
   specified standards.  All requirements in this = document must be
   reflected by standards specifications to be = developed.  But which of
   the features specified by these standards will be = mandatory,
   recommended, or optional for compliant = implementations is to be
   defined by the concrete standards track document(s) = and not in this
   document.

   This document first discusses general objectives of = energy management
   in Section 3.  Requirements for an energy = management standard are
   specified in Sections 4 to 8.

1.1.  Conventional requirements for energy management
I don't know what "conventional" is supposed to = mean.

Conventional in EMAN are = requirements of a kind that we use 
to have for many = other network management issues: 
You measure quantities = at a device, make them available in MIB modules, 
read = them from an NMS, send control commands if needed. 
I = will add text on this.

Special in EMAN are = requirements resulting from the fact that you may 
have = to speak to other devices in order to measure the power for a = device 
or to control its power = supply.

I am fine with replacing "conventional" = with another term. 
Are there proposals? = "device-centric"?


   The specification of requirements for an energy = management standard
   starts with Section 4 addressing the identification = of powered
   entities and the granularity of reporting of = energy-related
   information. 
I don't understand why we have that sentence here and not in the identifier in section 4.

Well = this is the introduction explaining the structure of the = document.
Here the content of Section 4 is explained, below = you find the content 
of sections 5 and 6 = summarized.

A standard must support unique identification of
   powered entities.  Furthermore, it must support = more than just
   reporting per powered device.  Support is = required for also reporting
   energy-related information on individual components = of a device or



Quittek, et al.         = Expires January 12, = 2012           &nbs= p;    [Page 4]
=0C
Internet-Draft     Requirements for Energy = Management          July 2011


   subtended devices.  This is why this draft uses = the more general term
   "powered entity" rather than "powered device".  = A powered entity may
   be a device or a component of a device.

   Section 5 specifies requirements related to = monitoring of powered
   entities.  This includes general (type, context) = information and
   specific information on power states, power inlets, = power outlets,
   power, energy, and batteries.  Control power = state and power supply
   of powered entities is covered by requirements = specified in
   Section 6.

1.2.  Specific requirements for energy management

   At first glance the rather conventional requirements = summarized above
   seem to be all that would be needed for energy = management.  But it
   turns out that there are some significant differences = between energy
   management and most of the well known conventional = network management
   functions.  The most significant difference from = many other
   management functions is the need for some devices to = report on other
   entities.  There are three major reasons for = this.
   o  For monitoring and controlling a particular = powered entity in
      general it is not sufficient to = communicate with the powered
"sufficient" is not the right wording.
In some cases, this is just impossible to communicate with the powered entity.
Example: proxy.

This case is = covered by the following bullet item.


      entity only, but in many cases also communication with other
      powered entities along the power = distribution path may be
      necessary, for example, with power = switches and power meters.
      Indeed, there are situations where = a power or energy meter is not
      located in the powered entity, but = in a different physical
      location.  For example, a = Power Distribution Unit (PDU), which
      supplies power for a server = connected to a PDU socket, would meter
      the power supplied, while the = server may not have the capability
      to measure its power = consumption. 
new text: In specific cases, the monitoring and controlling of powered entities must be done by another entity along the power distribution domain. For example.
And you remove "a second example" = below

Please check the revision of = the  first bullet.
I don't think the word "must" is = appropriate.

A second example is a Power
      over Ethernet port, which provides = power to the attached device,
      and which can meter how much = power/energy it delivers to the
      attached device.
   o  Energy management often extends its scope = beyond powered entities
      with IP network interfaces, for = example toward non-IP building
      networks, that are accessed via an = IP gateway.  Requirements in
      this document do not fully cover = all these networks, but they
      cover means for opening IP network = management towards them.
   o  For monitoring of particular powered = entities, it is sometimes not
      a scalable approach to communicate = directly with all the powered
      entities directly from a central = energy management system as the
      number of powered entities keeps = increasing.

   This specific issue of energy management and a set of = further ones
   are covered by requirements specified in Sections 7 = and 8.
=


 [snip]
<= div>

2.8.  Energy management

   the definition of the term power is to be agreed on = in the EMAN WG.

2.9.  Energy management standard
This doesn't look like a definition. At least, the first paragraph should be removed.

Right = it does not look like a definition. 
I would suggest = removing not the first paragraph, 
but just the first = sentence and keep the rest of the first = paragraph:
  "This term refers to a collections of = documents specifying 
   standards for = energy-related monitoring and control.  The energy 
  =  management standard specifies means for building energy = management 
   systems."

This = looks a little bit more like a definition.

The = following two paragraphs are not really part of a definition. =  
They are redundant because similar text is already = the introduction. 
We should remove = them.


   This document specifies requirements for an energy = management
   standard.  This term refers to a collections of = documents specifying
   standards for energy-related monitoring and = control.  The energy
   management standard specifies means for building = energy management
   systems.

   Requirements specified in this document concern the = means that an
   energy management standard must provide.  It = does not imply that all
   required means must be implemented in all energy = standard scenarios.
   Which means and features must be implemented by = compliant
   implementations is to be specified by the energy = management standard
   itself, not by this requirements document.

   Note that for meeting individual requirements = specified in this
   document, new standards are not necessarily = required.  It is
   recommended to rather use existing standards than = specify new ones.





Quittek, et al.         = Expires January 12, = 2012           &nbs= p;    [Page 7]
=0C
Internet-Draft     Requirements for Energy = Management          July 2011


3.  General Objectives of Energy Management
Rename to "general considerations related to energy = management"

Done.


   The basic objective of energy management is operating communication
   networks and other equipment with minimal amount of = energy, while
   maintaining a certain level of service.  A set = of use cases for
   energy management can be found in
   [I-D.tychon-eman-applicability-statement].
It would read better if the content of section about trade-offs was next in this introduction (without having a specific section)
Then
    3.1. Power States
    3.2 Energy Monitoring versus Energy = Savings

It is no "Energy Monitoring = vs. Energy Savings" but rather 
"Maintaining service = level agreements vs. Energy Savings"
But your title is good = for renaming section 3.4.

    3.3 Local versus network-wide energy = management

done.

    3.4. Overview of the energy management = requirements

Yes. but this is = section 3.5



3.1.  Power states

   One approach to achieve this goal is by setting all = powered entities
   to an operational state that results in lower energy consumption, but
   still meets the service level performance = objectives.  The sufficient
   performance level may vary over time and can depend = on several
   factors.  In principle, there are four basic = types of power states
   for a powered entity or for a whole system:
   o  full power state
   o  reduced power states (lower clock rate for = processor, lower data
      rate on a link, etc.)
   o  sleep state (not functional, but immediately = available)
   o  off state (may imply requiring significant = time for becoming
      operational)
   In actual implementations the number of power states = and their
   properties vary a lot.  Very simple powered = entities may just have
   only the extreme states, full power and off = state.  Some
   implementations might use IEEE1621 model of three = states on, off, and
   sleep.  However, more granular power states can = be implemented with
   many levels of off, sleep, and reduced power states.

3.2.  Trade-offs

   While the general objective of energy management is = quite clear, the
   way to attain that goal is often difficult.  In = many cases there is
   no way of reducing power consumption without the = consequence of a
   potential performance, service, or capacity = degradation.  Then a
   trade-off needs to be dealt with between service = level objectives and
   energy efficiency.  In other cases a reduction = of energy consumption
   can easily be achieved while still maintaining = sufficient service
   level performance, for example, by switching powered = entities to
   lower power states when higher performance is not = needed.

3.3.  Local and network-wide energy management

   Many energy saving functions can be executed locally = by a powered
   entitiy.  The basic principle is that a powered = entitiy monitors its
   usage and dynamically adapts its energy consumption = according to the
   required performance.  It may switch to a sleep = state when it is not
   in use at all. 
Well, not only when it's not in use.
It could be based on the time of day, or any other energy saving policies.

Right. I extended the = sentence accordingly.

Potential interactions with an energy management



Quittek, et al.         = Expires January 12, = 2012           &nbs= p;    [Page 8]
=0C
Internet-Draft     Requirements for Energy = Management          July 2011


   system for such an entity include the observation of = the entity's
   power state and the configuration of power saving = policies, for
   example, by setting thresholds for power state = changes.

   Energy savings can also be achieved with policies = implemented by a
   network management system that controls power states = of managed
   entities.  In order to make policy decisions = properly, information
   about the energy consumption of powered entities in = different power
   states is required.  Often this information is = acquired best through
   monitoring.

   Both methods, network-wide and local energy = management, have
   advantages and disadvantages.  Most buildings = use both of them.  In
   some cases for example, significant energy savings = can be achieved by
   simply setting all powered entities in a network to = sleep, when the
   network is not needed.  However, in general it = is dangerous to set
   all powered entities of a group to the same state, = because there is a
   risk that such actions ignore specifics of individual = powered
   entities or violate local service level agreements.
Can you please expand the previous sentence.
I'm not sure that I agree.

I = suggest removing it and polishing the entire = paragraph:

        = "Both methods, network-wide and local energy = management,
        have advantages and = disadvantages and often it is a good coice 
    =     to combine them. Central management is often favourable = for 
        setting power states of = a large number of entities at the same
      =   time, for example, at beginning and end of business hours in = a 
        building. Local management = appears often to be preferable for
        = dynamic power saving measures based on local observations, = such 
        as high or low load of = an entity."


3.4.  Energy monitoring
rename to "energy monitoring versus energy = savings"

Done.


   It should be noted that only monitoring energy = consumption and power
   states is obviously not a means to reduce the energy consumption of a
   powered entitiy.  In fact, it is likely to = increase the power =


 [snip]
<= div>
3.5.  Overview of energy management requirements

   =46rom the considerations described above the = following basic
   management functions appear to be required for energy management:
   o  monitoring power states
   o  monitoring power (energy consumption rate)
   o  monitoring (accumulated) energy consumption
   o  setting power states
   o  setting and enforcing power saving policies
And again the comment about the power = quality

Added.


   It should be noted that active power control is = complementary (but
what does the "active" power control = mean?

I don't know. I suggest = removing "active".

   essential) to other energy savings measures such as low power
   electronics, energy saving protocols (for example, = IEEE 802.3az),
   energy-efficient device design (for example, sleep = and low-power
   modes for individual components of a device), and energy-efficient
   network architectures.  Measurement of energy = consumption may also
   provide useful input for developing these = technologies.


4.  Identification of Powered Entities

   As already stated Section 1.1, powered entities on = which energy-
   related information is provided
add a = comma

fixed.

= are identified in a sufficiently
   unique way.  This holds in particular for = powered entities that are
   components of managed devices and in case that one = powered entity
   reports information on another one, see Section = 7.  For powered
   entities that control other powered entities it is = important to
   identify the powered entities they control, see = Section 8.

   Also stated already in Section 1.1 is the requirement = of providing
   means for reporting energy-related information on = components of a
   managed device.  An entity in this document may = be an entire managed
   device or just a component of it.  Examples of = components of interest
   are a hard drive, a battery, or a line card.  = For controlling
   entities it may be required to be able to address = individual
   components in order to save energy.  For = example, server blades can
   be switched off when the overall load is low or line = cards at
   switches may be powered down at night times.

   Instrumentation for measuring energy consumption of a = device is
   typically more expensive than instrumentation for = retrieving the
   devices power state.  It may be a reasonable = compromise in many cases
   to provide power state information for all = individually switchable
   components of a device separately, while the energy = consumption is
   only measured for the entire device.

   Detailed Requirements:




Quittek, et al.         = Expires January 12, = 2012           &nbs= p;   [Page 10]
=0C
Internet-Draft     Requirements for Energy = Management          July 2011


4.1.  Identifying powered entities

   The energy management standard must provide means for = uniquely and
   persistently 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.
We want to remove "and persistently" from the sentence, as this is covered in = 4.3

Done.

=20 We should have a requirement about a UUID for powered entities.
Let's cover that during the = WG.

Replaced last sentence = with
   "In order to avoid collisions of identities = at potential receivers of 
   monitored = information, a univesally unique identifier must be = used."


4.2.  Identifying components of powered devices

   The energy management standard must provide means for identifying not
   just entire devices as powered entities, but also = individual
   components of powered devices.

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 powered entitiy that provides the = identifiers.


5.  Information on Powered Entities

   This section describes energy-related information on = powered entities
   for which an energy management standard must provide = means for
   retrieving and reporting.

   Note that the fact that an energy management standard = provides
   required means does not imply that all of them must = be implemented by
   every compliant implementation.  The concrete = specification of
   standards based on these requirements may label = individual features
   as mandatory, recommended, or optional.
Remove this paragraph above, as this is already covered before, and this is not specific to this section = 5.

OK.


   Required information on powered entities can be = structured into six
   groups.  Section 5.1 specifies requirements for = general information
   on powered entities, such as type of powered entity = or context
   information.  Section 5.2 covers requirements = related to entities'
   power states.  Requirements for information on = power inlets and power
   outlets of powered entities are specified in Section = 5.3.  Monitoring
   of power and energy is covered by Sections 5.4 and = 5.5, respectively.
   Finally, Section 5.6 specified requirements for = monitoring batteries.

5.1.  General information on powered entities

   For energy management it may be required to = understand the role and
   context of a powered entitiy.  When monitoring, = it may be helpful to
   group energy consumption per kind of entity.  = When controlling and
   setting power states it may be helpful to understand = the kind and



Quittek, et al.         = Expires January 12, = 2012           &nbs= p;   [Page 11]
=0C
Internet-Draft     Requirements for Energy = Management          July 2011


   role of a powered entitiy in a network, for example, = in order to
   avoid switching off vital network components.

   Detailed Requirements:

5.1.1.  Type of powered entity

   The energy management standard must provide means to = retrieve and
   report the type of powered entities according to a = standrdized
   classification scheme.
see the email thread on the mailing = list.

Yes. It is still an open = issue.

=

 [snip]

5.2.1.  = Actual power state

   The energy management standard must provide means for = reporting the
   actual power state of a powered entitiy.

5.2.2.  List of supported power states

   The energy management standard must provide means for retrieving the
   list of all potential power states of a powered = entitiy.

5.2.3.  Multiple power state sets

   The energy management standard must provide means for supporting
   multiple power state sets simultaneously at a powered = entity.

5.2.4.  List of supported power state sets

   The energy management standard must provide means for retrieving the
   list of all power state sets supported by a powered = entitiy.

5.2.5.  List of supported power states
5.2.2 has got the same title.
Proposal for 5.2.5 "List of supported power states within power state = set"

Done.


   Referring to the "list of supported power state sets" requirement,
   the energy management standard must provide means for retrieving the
   list of all potential power states of a powered = entitiy that belong
   to a given power state set.
new text.
    For the rest of the document, when the Power = State term is used, it implicitly refers to a power state within a power state set.

Note that this comment might be part of the power State = definition

Yes, let's rather add = this to the definition of power states.
Here it seems to bee = too late in the draft, because we talk a lot about power states = before.
And it should not be just for the rest of the = document, it should be for the full document.


5.2.6.  Maximum and average power per power state

   The energy management standard must provide means for retrieving the
   maximum power and the average power as a typically = static property
   for each supported power state.

5.2.7.  Power state statistics

   The energy management standard must provide means for monitoring
   statistics per power state including at least the = total time spent in
   a power state, the number of times a state was = entered and the last
   time a state was entered.  More power state = statistics are addressed



Quittek, et al.         = Expires January 12, = 2012           &nbs= p;   [Page 13]
=0C
Internet-Draft     Requirements for Energy = Management          July 2011


   by requirement 5.5.3.

5.2.8.  Power state changes

   The energy management standard must provide means for generating a
   notification when the actual power state of a powered = entity changes.

5.3.  Power inlet and power outlet

   Powered entities have power inlets at which they are = supplied with
   electric power.  Most powered entities just have = a single power
   inlet, while some have multiple ones.  Often = different power inlets
   are connected to separate power distribution = trees.  For energy
   monitoring, it is important information which power = inlets a powered
   entitiy has,
what do you mean? the type, the number, or something = else?

This was poorly phrased. Here = is another try or the last = sentence:

        "For = energy monitoring, 
        it is = useful to retrieve information on the number of = inlets 
        of a powered entitiy, = the availability of power at inlets 
      =   and which of them are actually in = use."

if power is available at an inlet and which of them are
   actually in use.

   Some powered entities have power outlets for = supplying other powered
   entities with electric power.  A powered entitiy = may have multiple
   power outlets.  Examples are Power Distribution = Units (PDUs) and
   Power over Ethernet (PoE) Power Sourcing Equipment = (PSE).
Remove the previous sentence, as this is already in the terminology = section.

Done.


   For identifying and potentially controlling the = source of power
   received at an inlet, it may be required to identify = the power outlet
   of another powered 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
   required 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.
So "static properties" is what we called "power = quality"?

I am not sure what = was meant when the term power quality was used in = discussions.
The current version of the Power Quality MIB = contains several dynamic values that can 
be used = to determine power quality. But it does not contain these = static values.


   Detailed Requirements:
=

 [snip]
=
5.3.8.  Nominal AC frequency

   The energy management standard must provide means for = reporting the
   nominal AC frequency for each power inlet and each = power outlet of a
   powered entity.

5.3.9.  number of AC phases
number -> = Number

Fixed.


   The energy management standard must provide means for = reporting the
   number of AC phases for each power inlet and each = power outlet of a
   powered entity.


[snip]

5.6.  Battery State

   Today more and more powered entities contain = batteries that supply
   them with power when disconnected from electrical = power distribution
   grids.  Common examples are nomadic and mobile = devices, such as
   notebook computers, netbooks, and smart phones.  = The status of
   batteries in such an powered entity, particularly the = charging status
   is typically controlled by automatic functions that = act locally on
   the powered entitiy and manually by users of the = powered entity.  In



Quittek, et al.         = Expires January 12, = 2012           &nbs= p;   [Page 19]
=0C
Internet-Draft     Requirements for Energy = Management          July 2011


   addition to this, there is a need to monitor the = battery status of
   these entities by network management systems.

   The management requirements discussed above in = Sections 5.1 to 5.5
   concern energy-related information on powered = entities.  Powered
   entities may be powered devices or components of = powered devices.
I  believe that we mentioned that sentence = already.

removed.

   Devices containing batteries can be modeled in two ways.  The entire
   device can be modeled as a single powered entity on = which energy-
   related information is reported or the battery can be = modeled as an
   individual powered entity for which energy-related = information is
   monitored individually according to requirements in = Sections 5.1 to
   5.5.
=


[snip]
5.6.6.  Low battery charge notification

   The energy management standard must provide means for generating a
   notification when a the charge of a battery decreases = below a given
   threshold.
remove = "a"

Fixed.


5.6.7.  Battery replacement notification

   The energy management standard must provide means for generating a
   notification when the number of charging cycles of = battery exceeds a
   given threshold.
=


 [snip]
<= div>

7.3.  Reporting quantities accumulated over multiple powered entities

   For powered entities reporting single values that are accumulated
   over multiple powered entities, the energy management = standard must
   provide means for reporting the list of all powered = entities from
   which contributions are included in the accumulated = value.
See my comments at the beginning of the = email

Yes. We need conclusion on = the aggregation issue before finalizing this.


7.4.  List of all powered entities on which is reported

   The energy management standard must provide means for = a powered
   entitiy to report the list of all other powered = entities on which it
   can report energy-related information.
=

 [snip]
=
8.2.  Controlling power supply of other powered = entities

   Some powered entities may have control of the power = supply of other
   powered entities, for example, because the other = powered entity is
   supplied via a power outlet of the powered = entitiy.  For this and
   similar cases means are needed to make this control = accessible to the
   energy management system.

   In addition to this, it is very required that a = powered entitiy that
very required -> = required

Fixed.

   has its supply controlled by other powered entities has means to
   report the list of these other powered entities.
=

 [snip]
=
11.  Acknowledgements

   The authors would like to thank Ralf Wolter for his = first essay on
   this draft.  Many thanks to William Mielke, John = Parello, Bruce
   Nordman, JinHyeock Choi, Georgios Karagiannis, and = Michael Suchoff
   for helpful comments on the draft.

I'll address the open issues in separate email threads.

Regards, Benoit.

Thanks a = lot,

    = Juergen


= --Apple-Mail-1-45053606-- From ietf@quittek.at Sun Aug 14 16:15:07 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E79221F893C for ; Sun, 14 Aug 2011 16:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiPKr+2KuS94 for ; Sun, 14 Aug 2011 16:15:06 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6B90D21F85A1 for ; Sun, 14 Aug 2011 16:15:06 -0700 (PDT) Received: from [192.168.168.129] ([12.235.19.143]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LjPoq-1RPsrq3uFU-00bYnW; Mon, 15 Aug 2011 01:15:48 +0200 References: <4E3815B9.6040703@cisco.com> In-Reply-To: <4E3815B9.6040703@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <55F76133-69A9-4CC9-80A1-C193399EB554@quittek.at> Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Sun, 14 Aug 2011 16:15:44 -0700 To: Benoit Claise , eman mailing list X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:T6v7aPG0U36Z4C35RRiGNPs1c7aXa0kp91IhgSdUNJL RHOfRHYnY7JXWYq08uQyZKEgU2mcfGcMRvha8+pFCifnXuYZB3 i1eI+dGFjOlSnFNpxr9gfxdKgBZMz53YW/sXOsWmaRbTVL0F7a GTVJR3kwP7AyPR90K0HzZj8ffCja4Ne8NFVU/YVmAIxaloUqce nliEumsm0Hg5DxFTZJ5G8DrZAMzIfqObPNBvABcdlo= Subject: Re: [eman] new revision of eman requirements - Requirement 7.2 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 23:15:07 -0000 Hi Benoit, Maybe we can argue for a long time what is more logical or less logical = :-) The current logic is: 7.1 - 7.5 are requirements for reporting from = the parent, 7.6 and 7.7 are requirements for reporting from the child. But If you = like I can drop the parent-child logic here.=20 7.1 report on others 7.2 identify the others on which you report 7.3 if you report a single value belonging to multiple other, list all = of them. 7.4 list all you report anything on=20 7.5 list what you can report on others 7.6 identify who reports on you 7.7 state what does who report on you What would be your preferred order? 7.1 report on others 7.2 identify the others on which you report 7.6 identify who reports on you 7.7 state what does who report on you 7.3 if you report a single value belonging to multiple other, list all = of them. 7.4 list all you report anything on=20 7.5 list what you can report on others What I would not like (but could accept) here is the separation of 7.2 = and 7.3 7.2 says if you report a single value on another entity then you should = have means to identify the one you report on. 7.3 says the same thing just for the case that the quantity you report = is=20 accumulated, for example by metering at a PDU socket to which two=20 host are connected. I think these two are closely related, much more than 7.2 and 7.3. By the way, I think we should add a requirement=20 between 7.6 and 7.7: List all others that report on you. I tried to clarify the parent child grouping by rephrasing the = requirements=20 and added the one mentioned above, please see below. It is still in the old order. but I am fine to change it. 7.1. Reports on other powered entities The energy management standard must provide means for a powered entitiy to report energy-related information on another powered entity. 7.2. Identity of other powered entities on which is reported For entities that report on one or more other entities, the energy management standard must provide means for reporting the identity of another powered entity on which energy-related information is reported. 7.3. Reporting quantities accumulated over multiple powered entities For entities that report quantities accumulated over multiple powered entities, the energy management standard must provide means for reporting the list of all powered entities from which contributions are included in an accumulated value. 7.4. List of all powered entities on which is reported For entities that report on one or more other entities, the energy management standard must provide means for reporting the list of all other powered entities on which energy-related information can be reported. 7.5. Content of reports on other powered entities For entities that report on one or more other entities, the energy management standard must provide means for indicating which energy- related information it can report for which other powered entity. 7.6. Indicating source of remote information For entities that have one or more other entities reporting on them, the energy management standard must provide means for indicating the other entities. 7.7. Indicating source of remote information For entities that have one or more other entities reporting on them, the energy management standard must provide means for reporting the list of all other entities that report on them. 7.8. Indicating content of remote information For entities that have one or more other entities reporting on them, the energy management standard must provide means for indicating the content that other entities can report on them. Thanks, Juergen= From bschoening@noveda.com Sun Aug 14 17:46:15 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A08421F8785 for ; Sun, 14 Aug 2011 17:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IaPXN74L3l9 for ; Sun, 14 Aug 2011 17:46:15 -0700 (PDT) Received: from tex1-mh319a.smtpout.com (tex1-mh319a.smtpout.com [208.43.37.159]) by ietfa.amsl.com (Postfix) with ESMTP id E8BA121F8782 for ; Sun, 14 Aug 2011 17:46:14 -0700 (PDT) X-Katharion-ID: 1313369196.19088.tex1-mh319 Received: from ex01.noveda.com ([66.198.105.170]) by tex1-mh319.smtproutes.com [(208.43.37.108)] with ESMTP via TCP; 14 Aug 2011 19:46:36 -0500 Received: from EX01.noveda.com ([::1]) by ex01.noveda.com ([::1]) with mapi; Sun, 14 Aug 2011 20:46:33 -0400 From: Brad Schoening To: Juergen Quittek , eman mailing list Thread-Topic: [eman] do we really need power quality measurements for energy management? Thread-Index: AQHMWuTHxdvSWlFBG0yZ3/W1kaxBxA== Date: Mon, 15 Aug 2011 00:46:35 +0000 Message-ID: <22B2909DCC2E62418BE369A1F10488994B7B49B1@ex01.noveda.com> References: <7299E8E1-342F-4C1A-9FCF-11DCF01325B4@quittek.at> In-Reply-To: <7299E8E1-342F-4C1A-9FCF-11DCF01325B4@quittek.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] do we really need power quality measurements for energy management? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 00:46:15 -0000 Hi Juergen, You ask a very valid question. One issue is smart meters. Smart meters do= measure and report power quality. So in this context, should EMAN be desi= gned with smart meters as a target application? Similarly, for PDU's and U= PS's, is power quality an important measure? =20 Alternatively, we could defer power quality from the initial EMAN MIB and p= lan to add it later. Regards, Brad -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Jue= rgen Quittek Sent: Sunday, August 14, 2011 2:31 PM To: eman mailing list Subject: [eman] do we really need power quality measurements for energy man= agement? Dear all, In draft-ietf-eman-requirements-04 we have a few requirements on reporting= =20 power quality. They are described in requirements 5.4.6-5.4.9, see copy at the end of this email. The questions is: do we need these requirements and do we need all of them? I mentioned the issue briefly in the session at Quebec but since this was n= ot=20 an urgent issue, we agreed to discuss this on the mailing list. Power quality expresses how good the actual power supply is. Power quality parameters include the actual voltage. Is it exactly 110/230 = Volts?=20 Or is it a bit more or less? It also concerns the actual AC frequency (dev= iation=20 from 50/60 Hz), the total harmonic distortion of voltage current and the im= pedance=20 of the power supply.=20 There was discussion on the mailing list that these may not be really neede= d=20 for energy management without any objections. Do people in the WG think there is a requirement to standardize reporting=20 these power quality values for energy management?=20 Or, can we drop them from our list of requirements?=20 If so, do you think we should drop just some or all of them? Thanks, Juergen > 5.4.6. Actual voltage and current >=20 > The energy management standard must provide means for reporting the > actual voltage and actual current for each power inlet and each power > outlet of a powered entity. In case of AC power supply, means must > be provided for reporting the actual voltage and actual current per > phase. >=20 > 5.4.7. Actual AC frequency >=20 > The energy management standard must provide means for reporting the > actual AC frequency for each power inlet and each power outlet of a > powered entity. >=20 > 5.4.8. Total harmonic distortion >=20 > The energy management standard must provide means for reporting the > Total Harmonic Distortion (THD) of voltage and current for each power > inlet and each power outlet of a powered entity. In case of AC power > supply, means must be provided for reporting the THD per phase. >=20 > 5.4.9. Power supply impedance >=20 > The energy management standard must provide means for reporting the > impedance of power supply for each power inlet and each power outlet > of a powered entity. In case of AC power supply, means must be > provided for reporting the impedance per phase. _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From rturner@amalfisystems.com Sun Aug 14 17:49:29 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9A011E809A for ; Sun, 14 Aug 2011 17:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y7O8YxilF5G for ; Sun, 14 Aug 2011 17:49:29 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0414E11E8094 for ; Sun, 14 Aug 2011 17:49:28 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p7F0oAlc014936 for ; Sun, 14 Aug 2011 20:50:10 -0400 Authentication-Results: cm-omr3 smtp.user=rturner@amalfisystems.com; auth=pass (CRAM-MD5) X-Authenticated-UID: rturner@amalfisystems.com Received: from [98.151.18.158] ([98.151.18.158:50661] helo=[192.168.1.109]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id CB/F6-03223-24D684E4; Sun, 14 Aug 2011 20:50:10 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Randy Turner In-Reply-To: <22B2909DCC2E62418BE369A1F10488994B7B49B1@ex01.noveda.com> Date: Sun, 14 Aug 2011 17:50:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <52F5360D-92E8-47CD-BA7D-C68DB549B1F6@amalfisystems.com> References: <7299E8E1-342F-4C1A-9FCF-11DCF01325B4@quittek.at> <22B2909DCC2E62418BE369A1F10488994B7B49B1@ex01.noveda.com> To: Brad Schoening X-Mailer: Apple Mail (2.1244.3) Cc: eman mailing list Subject: Re: [eman] do we really need power quality measurements for energy management? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 00:49:29 -0000 I would pursue an "iterative" approach to this work and prioritize the = "non-power-quality" work first -- it's less contentious and will = probably expedite consensus in the WG on a solution that solves (probably) the majority of use-cases = that will be derived from the participants. Randy On Aug 14, 2011, at 5:46 PM, Brad Schoening wrote: > Hi Juergen, >=20 > You ask a very valid question. One issue is smart meters. Smart = meters do measure and report power quality. So in this context, should = EMAN be designed with smart meters as a target application? Similarly, = for PDU's and UPS's, is power quality an important measure? =20 >=20 > Alternatively, we could defer power quality from the initial EMAN MIB = and plan to add it later. >=20 > Regards, >=20 > Brad >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of Juergen Quittek > Sent: Sunday, August 14, 2011 2:31 PM > To: eman mailing list > Subject: [eman] do we really need power quality measurements for = energy management? >=20 > Dear all, >=20 > In draft-ietf-eman-requirements-04 we have a few requirements on = reporting=20 > power quality. They are described in requirements 5.4.6-5.4.9, see = copy at > the end of this email. >=20 > The questions is: do we need these requirements and do we need all of = them? > I mentioned the issue briefly in the session at Quebec but since this = was not=20 > an urgent issue, we agreed to discuss this on the mailing list. >=20 > Power quality expresses how good the actual power supply is. > Power quality parameters include the actual voltage. Is it exactly = 110/230 Volts?=20 > Or is it a bit more or less? It also concerns the actual AC frequency = (deviation=20 > from 50/60 Hz), the total harmonic distortion of voltage current and = the impedance=20 > of the power supply.=20 >=20 > There was discussion on the mailing list that these may not be really = needed=20 > for energy management without any objections. >=20 > Do people in the WG think there is a requirement to standardize = reporting=20 > these power quality values for energy management?=20 > Or, can we drop them from our list of requirements?=20 > If so, do you think we should drop just some or all of them? >=20 > Thanks, >=20 > Juergen >=20 >=20 >> 5.4.6. Actual voltage and current >>=20 >> The energy management standard must provide means for reporting the >> actual voltage and actual current for each power inlet and each = power >> outlet of a powered entity. In case of AC power supply, means must >> be provided for reporting the actual voltage and actual current per >> phase. >>=20 >> 5.4.7. Actual AC frequency >>=20 >> The energy management standard must provide means for reporting the >> actual AC frequency for each power inlet and each power outlet of a >> powered entity. >>=20 >> 5.4.8. Total harmonic distortion >>=20 >> The energy management standard must provide means for reporting the >> Total Harmonic Distortion (THD) of voltage and current for each = power >> inlet and each power outlet of a powered entity. In case of AC = power >> supply, means must be provided for reporting the THD per phase. >>=20 >> 5.4.9. Power supply impedance >>=20 >> The energy management standard must provide means for reporting the >> impedance of power supply for each power inlet and each power outlet >> of a powered entity. In case of AC power supply, means must be >> provided for reporting the impedance per phase. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 From moulchan@cisco.com Sun Aug 14 20:40:26 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD9921F8B0A for ; Sun, 14 Aug 2011 20:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.97 X-Spam-Level: X-Spam-Status: No, score=-2.97 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pwj2LVtFf32N for ; Sun, 14 Aug 2011 20:40:25 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A351521F8B09 for ; Sun, 14 Aug 2011 20:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=4327; q=dns/txt; s=iport; t=1313379670; x=1314589270; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=LttCWb5VVLl0hlu/yBUSIinsBF9op0d8sZVQsI+mf2Y=; b=jpoY0s0/JEPgP5HrvlOWjnn2O58V44bHWOkGUVgi+xJrsF+L6DyDITzv z1IQrlRAwO8vo5Xz/cIvP+bXaUtzDyAW+vgRJbCwRwTzZh9OqfxfqNCrM McVgfTsayfZxJp5g3xKit1p3ILqxuJDdoZI0xnbrGD7Cgb3ZBAR5iJUI7 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4AAIOUSE6tJXHA/2dsb2JhbABBmC+PTHeBQAEBAQECAQEBAQ8BHQo0EAcEAgEIDgMEAQELBhcBBgEmHwkIAgQBEggah04ElRYBnVeFaF8Eh1+QSIt+ X-IronPort-AV: E=Sophos;i="4.67,371,1309737600"; d="scan'208";a="13093497" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 15 Aug 2011 03:41:09 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p7F3f9on009175; Mon, 15 Aug 2011 03:41:09 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 14 Aug 2011 22:41:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 14 Aug 2011 22:41:04 -0500 Message-ID: In-Reply-To: <22B2909DCC2E62418BE369A1F10488994B7B49B1@ex01.noveda.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] do we really need power quality measurements for energy management? Thread-Index: AQHMWuTHxdvSWlFBG0yZ3/W1kaxBxJUdPoMQ References: <7299E8E1-342F-4C1A-9FCF-11DCF01325B4@quittek.at> <22B2909DCC2E62418BE369A1F10488994B7B49B1@ex01.noveda.com> From: "Mouli Chandramouli (moulchan)" To: "Brad Schoening" , "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 15 Aug 2011 03:41:09.0590 (UTC) FILETIME=[2BDAFF60:01CC5AFD] Subject: Re: [eman] do we really need power quality measurements for energy management? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 03:40:26 -0000 Hi Juergen, There seems reasonable consensus on the basic variables on Power Quality it seems to me - Voltage, Current, Active Power, Reactive Power, Apparent Power and Power Factor.=20 I think these variables would be useful from Smart Meters and PDUs as Brad has also indicated.=20 The discussion is on=20 - what are the other Power quality variables needed ? - power quality measurements by phase=20 - configurations (WYE, Delta or hybrid).=20 There was also discussion saying that requirements draft shall contain the requirements for a Energy standard and the framework and the MIB conformance can indicate what is implemented or not. Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Brad Schoening Sent: Monday, August 15, 2011 6:17 AM To: Juergen Quittek; eman mailing list Subject: Re: [eman] do we really need power quality measurements for energy management? Hi Juergen, You ask a very valid question. One issue is smart meters. Smart meters do measure and report power quality. So in this context, should EMAN be designed with smart meters as a target application? Similarly, for PDU's and UPS's, is power quality an important measure? =20 Alternatively, we could defer power quality from the initial EMAN MIB and plan to add it later. Regards, Brad -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Sunday, August 14, 2011 2:31 PM To: eman mailing list Subject: [eman] do we really need power quality measurements for energy management? Dear all, In draft-ietf-eman-requirements-04 we have a few requirements on reporting=20 power quality. They are described in requirements 5.4.6-5.4.9, see copy at the end of this email. The questions is: do we need these requirements and do we need all of them? I mentioned the issue briefly in the session at Quebec but since this was not=20 an urgent issue, we agreed to discuss this on the mailing list. Power quality expresses how good the actual power supply is. Power quality parameters include the actual voltage. Is it exactly 110/230 Volts?=20 Or is it a bit more or less? It also concerns the actual AC frequency (deviation=20 from 50/60 Hz), the total harmonic distortion of voltage current and the impedance=20 of the power supply.=20 There was discussion on the mailing list that these may not be really needed=20 for energy management without any objections. Do people in the WG think there is a requirement to standardize reporting=20 these power quality values for energy management?=20 Or, can we drop them from our list of requirements?=20 If so, do you think we should drop just some or all of them? Thanks, Juergen > 5.4.6. Actual voltage and current >=20 > The energy management standard must provide means for reporting the > actual voltage and actual current for each power inlet and each power > outlet of a powered entity. In case of AC power supply, means must > be provided for reporting the actual voltage and actual current per > phase. >=20 > 5.4.7. Actual AC frequency >=20 > The energy management standard must provide means for reporting the > actual AC frequency for each power inlet and each power outlet of a > powered entity. >=20 > 5.4.8. Total harmonic distortion >=20 > The energy management standard must provide means for reporting the > Total Harmonic Distortion (THD) of voltage and current for each power > inlet and each power outlet of a powered entity. In case of AC power > supply, means must be provided for reporting the THD per phase. >=20 > 5.4.9. Power supply impedance >=20 > The energy management standard must provide means for reporting the > impedance of power supply for each power inlet and each power outlet > of a powered entity. In case of AC power supply, means must be > provided for reporting the impedance per phase. _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From jparello@cisco.com Sun Aug 14 22:12:39 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C986A11E808A for ; Sun, 14 Aug 2011 22:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.856 X-Spam-Level: X-Spam-Status: No, score=-2.856 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBj0-Pfh3tgj for ; Sun, 14 Aug 2011 22:12:38 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B793611E8083 for ; Sun, 14 Aug 2011 22:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=7430; q=dns/txt; s=iport; t=1313385203; x=1314594803; h=mime-version:subject:date:message-id:references:from:to; bh=V5n0MPIaoUa/lu5toBVDs87Lw3RIkw3tsLoBHYE0wL8=; b=OdlqZP7e4YkwJ35EFh8p7gO8S7579oNMt/72njP+MHbd+WvkaT6vIxrX Q5r0A36ajj0sVSMdnQ7UokyaJPGcTAKS7n2vVNKhdYbw2whdBVTI6/IBu jTxjz0ziBxK2GdMfsuu29TSruaUHtd9TbVFmZASNNjd80lXjaggkrRtwN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEeqSE6rRDoJ/2dsb2JhbABBp3t3gUABAQEBAgEBAQEPAQkRAz4QBwQCAQgOAwQBAQsGGAYBJigIAQEEARIIGodOBJU0AZ1fhWhfBIcwL5BIjAA X-IronPort-AV: E=Sophos;i="4.67,372,1309737600"; d="scan'208,217";a="13100772" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-1.cisco.com with ESMTP; 15 Aug 2011 05:13:23 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7F5DMO1020149; Mon, 15 Aug 2011 05:13:22 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 14 Aug 2011 22:13:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC5B0A.0D90C4E9" Date: Sun, 14 Aug 2011 22:11:45 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] do we really need power quality measurements for energymanagement? Thread-Index: AcxasF0qh2e9jaqQQm2W6yU7dhiCAgAWXbQZ References: <7299E8E1-342F-4C1A-9FCF-11DCF01325B4@quittek.at> From: "John Parello (jparello)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 15 Aug 2011 05:13:22.0409 (UTC) FILETIME=[0DAC2D90:01CC5B0A] Subject: Re: [eman] do we really need power quality measurements for energymanagement? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 05:12:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC5B0A.0D90C4E9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't see any reason to eliminate it. It' susefule for powe rmeters, = pdu's and for industrial devices that generate and provide power. I think it should be optional. Jp -----Original Message----- From: eman-bounces@ietf.org on behalf of Juergen Quittek Sent: Sun 8/14/2011 11:31 AM To: eman mailing list Subject: [eman] do we really need power quality measurements for = energymanagement? =20 Dear all, In draft-ietf-eman-requirements-04 we have a few requirements on = reporting=20 power quality. They are described in requirements 5.4.6-5.4.9, see copy = at the end of this email. The questions is: do we need these requirements and do we need all of = them? I mentioned the issue briefly in the session at Quebec but since this = was not=20 an urgent issue, we agreed to discuss this on the mailing list. Power quality expresses how good the actual power supply is. Power quality parameters include the actual voltage. Is it exactly = 110/230 Volts?=20 Or is it a bit more or less? It also concerns the actual AC frequency = (deviation=20 from 50/60 Hz), the total harmonic distortion of voltage current and the = impedance=20 of the power supply.=20 There was discussion on the mailing list that these may not be really = needed=20 for energy management without any objections. Do people in the WG think there is a requirement to standardize = reporting=20 these power quality values for energy management?=20 Or, can we drop them from our list of requirements?=20 If so, do you think we should drop just some or all of them? Thanks, Juergen > 5.4.6. Actual voltage and current >=20 > The energy management standard must provide means for reporting the > actual voltage and actual current for each power inlet and each = power > outlet of a powered entity. In case of AC power supply, means must > be provided for reporting the actual voltage and actual current per > phase. >=20 > 5.4.7. Actual AC frequency >=20 > The energy management standard must provide means for reporting the > actual AC frequency for each power inlet and each power outlet of a > powered entity. >=20 > 5.4.8. Total harmonic distortion >=20 > The energy management standard must provide means for reporting the > Total Harmonic Distortion (THD) of voltage and current for each = power > inlet and each power outlet of a powered entity. In case of AC = power > supply, means must be provided for reporting the THD per phase. >=20 > 5.4.9. Power supply impedance >=20 > The energy management standard must provide means for reporting the > impedance of power supply for each power inlet and each power outlet > of a powered entity. In case of AC power supply, means must be > provided for reporting the impedance per phase. _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman ------_=_NextPart_001_01CC5B0A.0D90C4E9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eman] do we really need power quality measurements for = energymanagement?

I don't see any reason to eliminate it. It' susefule = for powe rmeters, pdu's and for industrial devices that generate and = provide power.

I think it should be optional.

Jp


-----Original Message-----
From: eman-bounces@ietf.org on behalf of Juergen Quittek
Sent: Sun 8/14/2011 11:31 AM
To: eman mailing list
Subject: [eman] do we really need power quality measurements for = energymanagement?

Dear all,

In draft-ietf-eman-requirements-04 we have a few requirements on = reporting
power quality. They are described in requirements 5.4.6-5.4.9, see copy = at
the end of this email.

The questions is: do we need these requirements and do we need all of = them?
I mentioned the issue briefly in the session at Quebec but since this = was not
an urgent issue, we agreed to discuss this on the mailing list.

Power quality expresses how good the actual power supply is.
Power quality parameters include the actual voltage. Is it exactly = 110/230 Volts?
Or is it a bit more or less?  It also concerns the actual AC = frequency (deviation
from 50/60 Hz), the total harmonic distortion of voltage current and the = impedance
of the power supply.

There was discussion on the mailing list that these may not be really = needed
for energy management without any objections.

Do people in the WG think there is a requirement to standardize = reporting
these power quality values for energy management?
Or, can we drop them from our list of requirements?
If so, do you think we should drop just some or all of them?

Thanks,

   Juergen


> 5.4.6.  Actual voltage and current
>
>   The energy management standard must provide means for = reporting the
>   actual voltage and actual current for each power inlet = and each power
>   outlet of a powered entity.  In case of AC power = supply, means must
>   be provided for reporting the actual voltage and actual = current per
>   phase.
>
> 5.4.7.  Actual AC frequency
>
>   The energy management standard must provide means for = reporting the
>   actual AC frequency for each power inlet and each power = outlet of a
>   powered entity.
>
> 5.4.8.  Total harmonic distortion
>
>   The energy management standard must provide means for = reporting the
>   Total Harmonic Distortion (THD) of voltage and current = for each power
>   inlet and each power outlet of a powered entity.  = In case of AC power
>   supply, means must be provided for reporting the THD = per phase.
>
> 5.4.9.  Power supply impedance
>
>   The energy management standard must provide means for = reporting the
>   impedance of power supply for each power inlet and each = power outlet
>   of a powered entity.  In case of AC power supply, = means must be
>   provided for reporting the impedance per phase.





_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/= mailman/listinfo/eman

------_=_NextPart_001_01CC5B0A.0D90C4E9-- From jparello@cisco.com Mon Aug 15 11:28:23 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D7511E80B6 for ; Mon, 15 Aug 2011 11:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgULKfal1o77 for ; Mon, 15 Aug 2011 11:28:22 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B6AED11E80B4 for ; Mon, 15 Aug 2011 11:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=5986; q=dns/txt; s=iport; t=1313432949; x=1314642549; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=aqvTJhyDPnxoxYt847mc8X+KlsaBGBLs/3DcSmVc/SM=; b=YiCsUEUD43zW0tH47VkD+b1CHH+OPYZnIcO2sTZEJUms3kqoNf+lXs+x wrDLCA41rZQ/oW1AjQ2FBgOgFP/2joJJyufrBDLA6PscXYUEih9XW4v8t Al8lX58YLRpFC3+/zCfc8ygGMKhBPFO3HO8XfRPS60wrH+BL9x7vW7oau c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAAJxkSU6rRDoG/2dsb2JhbABCmEiPTneBQAEBAQEDAQEBCwQBHQorCQQTBAIBCA4DBAEBCwYXAQYBJh8JCAEBBAESCBqHUpleAZ5lhWhfBIdfkEiMAA X-IronPort-AV: E=Sophos;i="4.67,375,1309737600"; d="scan'208";a="13292006" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-1.cisco.com with ESMTP; 15 Aug 2011 18:29:08 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7FIT8BW017675; Mon, 15 Aug 2011 18:29:08 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Aug 2011 11:29:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Aug 2011 11:26:52 -0700 Message-ID: In-Reply-To: <7758B005-2F71-4F35-A07F-F28CC54724C5@quittek.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology: power states - battery state - power supplystate Thread-Index: AcxaGcIFrOwvQlhXSPudor0b7Af4dgBXxAAQ References: <7758B005-2F71-4F35-A07F-F28CC54724C5@quittek.at> From: "John Parello (jparello)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 15 Aug 2011 18:29:08.0079 (UTC) FILETIME=[384F3FF0:01CC5B79] Subject: Re: [eman] Terminology: power states - battery state - power supplystate X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 18:28:23 -0000 Thanks Jeurgen, I'll take a shot at a convergence of the terms with references. Jp -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Saturday, August 13, 2011 5:32 PM To: eman mailing list Subject: [eman] Terminology: power states - battery state - power supplystate Dear all, Here are some thoughts on what a power state is and how it relates to the battery state and the power supply state of a device. So far, there is no document where we clearly define what a power state is and what it is not. Please find a list of definitions that I collected from other documents further below. This email mainly serves for sharing some thoughts on this issue in order to jointly work on a more clear definition of a power state. My main question is: What is characteristic for a power state? 1. the operational state (Is the device not/fully/partially operational)? 2. the power consumption in a power state? (min/max/average power/demand)? 3. the power supply state (running on mains/battery/self-generated power)? 4. the total power balance (consuming/providing power)? As we have discussed it in the eman WG and as other standards bodies including DMTF, ACPI, PWG see it, it is just 1. with some implications on 2. Here is another try on a definition of a power state: "A power state represents one or multiple operational states of a device. A power state indicates specific properties of a device concerning its the energy=20 consumption when being in this state." Of course this one cries for definitions of an operational state. Operational state: "An operational state defines the availability of services provided by a device." We certainly need some more text elaborating on power states beyond the plain definition, maybe in the framework document. There is one note that I would definitely like to add there: "Energy consumption of a device is not the only state to be considered=20 when managing the power supply of a device. If the device contains batteries or facilities for energy harvesting/generation, also the battery charging state=20 and the power supply state of a device need to be considered. For example, a device in a non-operational state such as "off" or "sleep" may still draw=20 a considerable power for charging its batteries. Or it may be in state "on" and=20 not draw any mains power at all, because it runs on battery or supplies itself with a built-in generator." This leads us to the definition of battery state and power supply state: Battery state: The battery state indicates the flow of energy into or out of a battery. Power supply state: The power supply state indicates which power supply is in use at a device. Examples are: mains power, secondary mains power, battery, built-in generator We definitely need the battery state for the battery MIB (see object batteryChargingState in draft-ietf-eman-battery-mib-03). I think we also need something like the power supply state. But my ideas on it are much less clear than on the battery state that we have been discussing for some months already. Here are the definitions of power state that we have tried so far: 1. draft-ietf-eman-framework-02 and draft-parello-eman-definitions-0 A Power State is a way to classify a Power setting on an Energy=20 Managed Object (e.g., on, off, or sleep). A Power State can be=20 viewed as a method for Energy Control=20 Comments:=20 - Yes, a power state may be used to classify power setting. But this is a way to use it, not a way define it.=20 - No, a power state is definitely not a method. 2. draft-ietf-eman-requirements-03 Power state of an entity is defined as a specific settings of an entity that influences its power. Examples of power states of an entity are on, off, hibernate, and sleep. Comment:=20 - This is correct, but it neglects the relationship to operational states 3. draft-quittek-power-mib-02 A power state defines a limitations of services provided by a device and implicitly limits energy consumption. Examples for commonly implemented power states include 'on', 'full power', 'low power', 'sleep', 'stand-by', and 'off'. There is no commonly agreed convention for power states naming and semantics. Therefore power states with the same names may have different semantics and different names may be in use for the same power state. But the actual energy consumption of a device depends on more than just its power state. Also the current load, the kind of load, and many other factors influence energy consumption. Comments:=20 - first line is OK. It explains a power state as an operational state without using the term "operational state" (which might be desirable). - second line does not seem to be correct. A power state may have=20 power limitations. But this is not a necessary property of it. - rest seems correct, but examples are not a definition and the following text does not belong into the definition. 4. draft-ietf-eman-energy-monitoring-mib-00 =20 A Power State is defined as a specific power setting for a=20 Power Monitor (e.g., shut, hibernate, sleep, high). Within the=20 context of a Power State Set, the Power State of a device is=20 one of the power saving modes in that Power State Set.=20 Comments:=20 - First sentence correct, but it neglects the relationship to operational states - The second sentence does not belong to the definition. - Second sentence explains power state as power saving mode. What is a power saving mode? Is "full power" a power saving mode? Thanks, Juergen _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From bill.mielke@alcatel-lucent.com Mon Aug 15 11:40:02 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DF411E80B1 for ; Mon, 15 Aug 2011 11:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVTw2h9cBwDQ for ; Mon, 15 Aug 2011 11:40:02 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id A855211E80A4 for ; Mon, 15 Aug 2011 11:40:01 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p7FIekRB024352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 15 Aug 2011 13:40:47 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7FIekbX029488 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 15 Aug 2011 13:40:46 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 15 Aug 2011 13:40:46 -0500 From: "Mielke, William F (Bill)" To: "eman@ietf.org" Date: Mon, 15 Aug 2011 13:40:12 -0500 Thread-Topic: [eman] iana powerstate tc proposal Thread-Index: AcxRmYra2vvHE8FOQiaXHM9K3ymb2gJ3+qEg Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250A5638FE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <20110728164503.GA30392@elstar.local> <20110728184235.GD30565@elstar.local> <20110728212016.GA31474@elstar.local> <4E38229F.4020504@cisco.com> <20110803045449.GA43357@elstar.local> In-Reply-To: <20110803045449.GA43357@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [eman] iana powerstate tc proposal X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 18:40:02 -0000 > But your design aims at reporting a certain true state of the device > according to different sets concurrently - so you assume there is a > translation which is implementation dependent, that is every device > can translate as it likes to do it. Not sure how this really helps > with interoperability. (And the same goes to proposals where the power > states are expected to be a series with 1000 as percentage increments > as mentioned previously - this looks to me like a fine grained control > knob and not a power state.) >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH >From my perspective allowing for a given device to support multiple power s= tate sets simultaneously we are improving/enabling increased interoperabili= ty by allowing the EnMS interact with the device using it's preferred power= state set. Some EnMS may only support a single power state set, for examp= le, so allowing the device to support multiple power state sets increases t= he number of EnMS which can interoperate with the device. Regarding the "magic" mapping between the power states within the various s= ets supported by a device, the core assumption (perhaps this needs to be ma= de explicit) is that if a device chooses to support multiple power state se= ts that it must do so in such a way that the device operates in a sensible = manner within the individual contexts of each power state set it supports. = It is impossible to define a universally applicable mapping for this but w= ithin the context of a given device a sensible mapping may certainly be pos= sible. If it is, then the device can choose to support that mapping and th= e various EnMS can safely interact with it using any of the available power= state sets. From bill.mielke@alcatel-lucent.com Mon Aug 15 12:34:48 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9ED21F8CBF for ; Mon, 15 Aug 2011 12:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6OVQO4ftekd for ; Mon, 15 Aug 2011 12:34:47 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6FD21F8CBD for ; Mon, 15 Aug 2011 12:34:47 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p7FJZXl5021314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 15 Aug 2011 14:35:33 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7FJZW0j000374 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 15 Aug 2011 14:35:32 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 15 Aug 2011 14:35:32 -0500 From: "Mielke, William F (Bill)" To: eman mailing list Date: Mon, 15 Aug 2011 14:34:55 -0500 Thread-Topic: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values Thread-Index: AQHMUbyLQN8slhq7EUeTtHXmrCW29pUeU8Kw Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250A563954@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4E381298.2020500@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 19:34:48 -0000 > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20 > Behalf Of Juergen Quittek >=20 > ... > > Is there an explicit requirement for having pull or for having push > for time series of power and energy values? I don't see it. >=20 > Thanks, >=20 > Juergen >From my perspective I think that the fundamental requirement is that there = must be a means of reporting time series data for power and/or energy value= s as measured at the device (and perhaps optionally some load and quality m= etrics as well). Either a push or a pull mechanism can be used to satisfy = this requirement. I don't believe that there is a requirement to support s= pecifically either one or both of these mechanisms. I do believe, however,= that there is value in having the framework and the MIBs specifying how ea= ch of these mechanisms (push or pull) should work IF a given device chooses= to support them. For Pull the mechanism is obvious and is nothing more that SNMP applied to = a table of values defined by some MIB that we specify. Push is less obvious given the state of SNMP. IPFIX has been posited as a = possible solution for Push and I don't have a problem with our articulating= that as one possible solution for Push, possibly even the preferred soluti= on, but I would like to keep the door open to alternatives in this case (bu= t that is just my personal preference). William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com 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 jparello@cisco.com Mon Aug 15 12:53:50 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CAC11E80A4 for ; Mon, 15 Aug 2011 12:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.841 X-Spam-Level: X-Spam-Status: No, score=-2.841 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Rr+581MSIzE for ; Mon, 15 Aug 2011 12:53:49 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 654CA11E8080 for ; Mon, 15 Aug 2011 12:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=2413; q=dns/txt; s=iport; t=1313438076; x=1314647676; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=v/sMxw8htcKQm38U2Wme8OAEppPECHsXT8tqCMqUEN0=; b=GN/ORTopL/ixQQvNxf2PDaruH3Rxq74N3enINpW13g0Oe79nDeqDYWBl NLNmKqmlSZBjan8uHHLNL2ukS6qVvFh+ErqdVX+8MBqbksgfRw0FrUbJr Pf+ImzvH0dH0ZQkAU9ZI5Lw2CwPlDr/GYfvTpRr1DmOTMQYkCxAeYl2NR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAADh5SU6rRDoG/2dsb2JhbAA/A5hIj053gUABAQEBAgEBAQEPAR0KNBAHAgQBCBEEAQELBhcBBxoMHwkJAQQBEggTB4dOBJo6AZ8FAoM+gihfBIdfkEiMAA X-IronPort-AV: E=Sophos;i="4.67,375,1309737600"; d="scan'208";a="13318311" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 15 Aug 2011 19:54:35 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7FJsZOD022515; Mon, 15 Aug 2011 19:54:35 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Aug 2011 12:54:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Aug 2011 12:52:16 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values Thread-Index: AcxbhNRqPKdHKPK5TlGjP+tAD2zTMA== From: "John Parello (jparello)" To: "Mielke, William F (Bill)" , "eman mailing list" X-OriginalArrivalTime: 15 Aug 2011 19:54:34.0914 (UTC) FILETIME=[28243020:01CC5B85] Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 19:53:50 -0000 +1 Information should be independent of push/pull protocol. The protocols could be SNMP/IPFIX or HTTP/SMS. IMO the requirement is that any framework or information model should not prevent either push or pull (or both) to be used. JP -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Mielke, William F (Bill) Sent: Monday, August 15, 2011 12:35 PM To: eman mailing list Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf=20 > Of Juergen Quittek >=20 > ... > > Is there an explicit requirement for having pull or for having push=20 > for time series of power and energy values? I don't see it. >=20 > Thanks, >=20 > Juergen >From my perspective I think that the fundamental requirement is that there must be a means of reporting time series data for power and/or energy values as measured at the device (and perhaps optionally some load and quality metrics as well). Either a push or a pull mechanism can be used to satisfy this requirement. I don't believe that there is a requirement to support specifically either one or both of these mechanisms. I do believe, however, that there is value in having the framework and the MIBs specifying how each of these mechanisms (push or pull) should work IF a given device chooses to support them. For Pull the mechanism is obvious and is nothing more that SNMP applied to a table of values defined by some MIB that we specify. Push is less obvious given the state of SNMP. IPFIX has been posited as a possible solution for Push and I don't have a problem with our articulating that as one possible solution for Push, possibly even the preferred solution, but I would like to keep the door open to alternatives in this case (but that is just my personal preference). William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com 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 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Mon Aug 15 13:13:49 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F5C21F8D3E for ; Mon, 15 Aug 2011 13:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyKtbcfJIJXW for ; Mon, 15 Aug 2011 13:13:49 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8E521F8D3B for ; Mon, 15 Aug 2011 13:13:48 -0700 (PDT) Received: from [192.168.168.129] ([12.235.19.143]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MDU2z-1R4oiq0YmL-00GqGC; Mon, 15 Aug 2011 22:14:34 +0200 From: Juergen Quittek Content-Type: text/plain; charset=us-ascii Message-Id: Date: Mon, 15 Aug 2011 13:14:29 -0700 To: eman mailing list Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:wwlCMBdn5LPGES+pjz8Qr/W1OsNk/8k3VQlQOpBljJS 6P+ZLsK0KO/hy77zK1OAcPwfPLwTSef9K8rftzcfPhjvCAj8r2 eL5qVh6Tp2dZzs1jIZoslny+9BeFxe32KyHXIPtyrkejqwKit4 wzjw+Skj8IMFSOX5UoTP3EGzBw8LE/ZmKfbs9qcsR9NDC11Zu6 UtJFDmf82q/eS9FVxoXRcieim/YQMx/auZeZQ2KaqI= Subject: [eman] terminology: power quality X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 20:13:49 -0000 Dear all, Many thanks for the quick replies on the question about power quality. Looking at the answers I might have asked another question first: What is power quality?=20 In past discussions we referred to a lot of quantities when using the = term=20 power quality. For me power quality has always been the "quality of = power=20 that a power provider delivers to consumers". This is separate from=20 the nominal power supply parameters and from the use that consumers=20 make of power offered by the provider. Power quality includes impedance and variation of voltage and frequency=20= from agreed values. Excluded are current, (active/reactive/apparent) = power,=20 and the power factor. Current and power are mainly results of the = consumer's=20 behavior and not mainly driven by the quality of power provided.=20 Of course, badly behaving consumers may deteriorate power quality for=20 themselves and for other consumers connected and poor power quality may influence the current and power at the consumer.=20 Here are three groups of terms we should separate: 1. Nominal power supply (feel free to replace "nominal" with "nameplate" or "design") - type of current (AC or DC) - number of AC phases - nominal voltage (e.g., 100V, 230V) - nominal frequency (e.g. 50Hz, 60Hz) - min and max values for voltage and frequency 2. Power quality - the deviation of actual voltage from nominal voltage (can be realized by reporting the actual voltage and/or min/max = voltage) - the deviation of actual frequency from nominal frequency (can be realized by reporting the actual frequency and/or min/max = frequency) - the total harmonic distortion of voltage In case of AC power, voltage and THD need to be measured per phase Power quality can be measured at power inlets as "received/perceived = quality" or at power outlets as "provided quality". 3. Power usage - actual current - real/active power - power factor - reactive power - apparent power - phase (angle between current and voltage phase) In case of DC power, only the current and real power are applicable In case of AC power, all quantities need to be measured per phase I think there is no question that we need to define a standard for = reporting=20 quantities listed under 1. and 3. (Some of the quantities related to = complex power under 3. are redundant. We may not need all of them.) For me the main question is: Do we need to define a standard for reporting power quality quantities = listed under 2.? Thanks, Juergen From jparello@cisco.com Mon Aug 15 13:24:42 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D6911E8106 for ; Mon, 15 Aug 2011 13:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5NrtqHRj051 for ; Mon, 15 Aug 2011 13:24:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B45CB11E8105 for ; Mon, 15 Aug 2011 13:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=3558; q=dns/txt; s=iport; t=1313439928; x=1314649528; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=0RQUpZcX/4jx2T1p6+Vwwj61YQVLTIkugFwnYEETghk=; b=bsSU7Z82CokDs8JC3gevyipeAfY7ze3+QQNkRo57IL/iM45kPAO3TITl 2R5nz1dgEiP8gTEwR/H+yqp8cMtGr6kqWZ8Vx1tW/F78mvJguTQUyZmaF 0EMZ8nMP98/zLqIPZiPO5GhSfTWMJYTIxWfTOSCIPCh4UBh+moPGoOsJ+ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAAEZ/SU6rRDoI/2dsb2JhbABBmEiPTneBQAEBAQEDAQEBDwEdCjQXBAIBCA4DBAEBCwYXAQYBJh8JCAEBBAESCBqHUppUAZ8EhWhfBIdfkEiMAA X-IronPort-AV: E=Sophos;i="4.67,376,1309737600"; d="scan'208";a="13332327" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-7.cisco.com with ESMTP; 15 Aug 2011 20:25:27 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7FKPRt6014311; Mon, 15 Aug 2011 20:25:27 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Aug 2011 13:25:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Aug 2011 13:23:10 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] terminology: power quality Thread-Index: AcxbiBGXYSGtWg64Rza+2xJRWVLdTAAABOHg References: From: "John Parello (jparello)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 15 Aug 2011 20:25:27.0328 (UTC) FILETIME=[78442200:01CC5B89] Subject: Re: [eman] terminology: power quality X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 20:24:42 -0000 Hi Jeurgen, For the values in Section 2 I think we'll need them. when the endpoints of a communication network are items "less traditional" to this space they become more necessary. For example an enterprise consisting of a communication network with 1 million PC based endpoints would not be concerned with those values. Contrast that to an industrial setup with a communication network with 1 million endpoints of meters, motors, power generating, and non-electrical energy endpoints and it becomes relevant. So I can't see a reason to exclude the information. Allow it just make it optional. Jp -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Monday, August 15, 2011 1:14 PM To: eman mailing list Subject: [eman] terminology: power quality Dear all, Many thanks for the quick replies on the question about power quality. Looking at the answers I might have asked another question first: What is power quality?=20 In past discussions we referred to a lot of quantities when using the term power quality. For me power quality has always been the "quality of power that a power provider delivers to consumers". This is separate from the nominal power supply parameters and from the use that consumers make of power offered by the provider. Power quality includes impedance and variation of voltage and frequency from agreed values. Excluded are current, (active/reactive/apparent) power, and the power factor. Current and power are mainly results of the consumer's behavior and not mainly driven by the quality of power provided.=20 Of course, badly behaving consumers may deteriorate power quality for themselves and for other consumers connected and poor power quality may influence the current and power at the consumer.=20 Here are three groups of terms we should separate: 1. Nominal power supply (feel free to replace "nominal" with "nameplate" or "design") - type of current (AC or DC) - number of AC phases - nominal voltage (e.g., 100V, 230V) - nominal frequency (e.g. 50Hz, 60Hz) - min and max values for voltage and frequency 2. Power quality - the deviation of actual voltage from nominal voltage (can be realized by reporting the actual voltage and/or min/max voltage) - the deviation of actual frequency from nominal frequency (can be realized by reporting the actual frequency and/or min/max frequency) - the total harmonic distortion of voltage In case of AC power, voltage and THD need to be measured per phase Power quality can be measured at power inlets as "received/perceived quality" or at power outlets as "provided quality". 3. Power usage - actual current - real/active power - power factor - reactive power - apparent power - phase (angle between current and voltage phase) In case of DC power, only the current and real power are applicable In case of AC power, all quantities need to be measured per phase I think there is no question that we need to define a standard for reporting quantities listed under 1. and 3. (Some of the quantities related to complex power under 3. are redundant. We may not need all of them.) For me the main question is: Do we need to define a standard for reporting power quality quantities listed under 2.? Thanks, Juergen _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From rturner@amalfisystems.com Mon Aug 15 20:01:59 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85FC21F8C26 for ; Mon, 15 Aug 2011 20:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLjub0DwXtQE for ; Mon, 15 Aug 2011 20:01:59 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2C12521F8C17 for ; Mon, 15 Aug 2011 20:01:59 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p7G32h9x014943 for ; Mon, 15 Aug 2011 23:02:45 -0400 Authentication-Results: cm-omr6 smtp.user=rturner@amalfisystems.com; auth=pass (CRAM-MD5) X-Authenticated-UID: rturner@amalfisystems.com Received: from [64.241.37.151] ([64.241.37.151:20258] helo=[10.0.0.138]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id F3/5D-30405-2DDD94E4; Mon, 15 Aug 2011 23:02:43 -0400 From: Randy Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Aug 2011 20:02:36 -0700 Message-Id: <1F3121E1-7B60-4119-ABF2-60373B27B036@amalfisystems.com> To: eman mailing list Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [eman] Applicability Draft X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 03:01:59 -0000 In section 2.1 of the recently published "EMAN Applicability Statement" = (August 2011), there appears to be a definition of "network devices" as = "routers & switches". In subsequent drafts of EMAN documents, it seems = to me that we would want to broaden the category from it's current = definition. For instance, in an enterprise or large campus network, networked = imaging devices such as multi-function peripherals (high duty-cycle = printer, copier, fax, scanner products) consume an order of magnitude = more power than any switch or router (except maybe a "core" router in a = Tier-1 POP), especially when fully engaged in a full-range of their = functionality. I also noticed that generic computing devices (servers, desktops, = laptops, storage appliances, etc.) were not included as well. Are these = devices considered out of scope? =20 Apologies if I'm re-visiting previously agreed upon info. Thanks! Randy