From etychon@cisco.com Thu Sep 1 00:54: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 8557121F8AF6 for ; Thu, 1 Sep 2011 00:54:26 -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 cycpyK3sCOvn for ; Thu, 1 Sep 2011 00:54:26 -0700 (PDT) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id D480D21F8AF1 for ; Thu, 1 Sep 2011 00:54:25 -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 p817tvBK028881 for ; Thu, 1 Sep 2011 00:55:57 -0700 (PDT) Received: from ams-etychon-8913.cisco.com (ams-etychon-8913.cisco.com [10.60.74.4]) by bonfire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p817ttCC001975; Thu, 1 Sep 2011 00:55:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Emmanuel Tychon In-Reply-To: Date: Thu, 1 Sep 2011 09:55:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <155699C3-5C27-4E2D-A000-19C306B26366@cisco.com> References: To: Juergen Quittek X-Mailer: Apple Mail (2.1244.3) Cc: eman mailing list 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: Thu, 01 Sep 2011 07:54:26 -0000 Hello Juergen - I agree with your definition of power quality and I also agree this is = important as it directly impacts how a system is able to function in its = intended manner. In the section 2. "Power Quality", actual voltage and min/max are = metrics that do not not tell you much as you don't know what's happening = when between "min" and "max".=20 I would add a root mean square (RMS) or anything similar to glimpse the = amplitude and frequency of the variations. The exact metric can be = discussed later. Since the section 4. of the EMAN charter lists explicitly "it will = provide information on electrical power quality", and since this = definition seems to be unclear enough to require clarifications, a = separate document for reporting power quality makes sense at least to = me. Thanks, Emmanuel On 15 Aug 2011, at 22:14, Juergen Quittek wrote: > Dear all, >=20 > Many thanks for the quick replies on the question about power quality. >=20 > Looking at the answers I might have asked another question first: > What is power quality?=20 >=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. >=20 > 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 >=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 >=20 > Here are three groups of terms we should separate: >=20 > 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 >=20 > 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 >=20 > Power quality can be measured at power inlets as "received/perceived = quality" > or at power outlets as "provided quality". >=20 > 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 >=20 > 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.) >=20 > For me the main question is: >=20 > Do we need to define a standard for reporting power quality quantities = listed under 2.? >=20 > Thanks, >=20 > Juergen >=20 >=20 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 From etychon@cisco.com Thu Sep 1 00:56:35 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 098C221F8546 for ; Thu, 1 Sep 2011 00:56:35 -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 IvxzYrcSlceV for ; Thu, 1 Sep 2011 00:56:34 -0700 (PDT) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7232C21F853E for ; Thu, 1 Sep 2011 00:56:34 -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 p817w6Uv029417 for ; Thu, 1 Sep 2011 00:58:07 -0700 (PDT) Received: from ams-etychon-8913.cisco.com (ams-etychon-8913.cisco.com [10.60.74.4]) by bonfire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p817w3KN003731; Thu, 1 Sep 2011 00:58:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Emmanuel Tychon In-Reply-To: <1F3121E1-7B60-4119-ABF2-60373B27B036@amalfisystems.com> Date: Thu, 1 Sep 2011 09:58:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <19857837-90CA-46CB-845D-F3C279118845@cisco.com> References: <1F3121E1-7B60-4119-ABF2-60373B27B036@amalfisystems.com> To: Randy Turner X-Mailer: Apple Mail (2.1244.3) Cc: eman mailing list Subject: Re: [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: Thu, 01 Sep 2011 07:56:35 -0000 This is a good point Randy, thanks for the feedback. We'll make sure this is clarified in the next release. Regards, Emmanuel On 16 Aug 2011, at 05:02, Randy Turner wrote: >=20 > 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. >=20 > 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. >=20 > 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 >=20 > Apologies if I'm re-visiting previously agreed upon info. >=20 > Thanks! > Randy >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 From moulchan@cisco.com Fri Sep 2 00:41: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 C78C321F8F28 for ; Fri, 2 Sep 2011 00:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.961 X-Spam-Level: X-Spam-Status: No, score=-6.961 tagged_above=-999 required=5 tests=[AWL=3.638, 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 AXrm2CFL8X-F for ; Fri, 2 Sep 2011 00:41:50 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3D24F21F8F12 for ; Fri, 2 Sep 2011 00:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=1436; q=dns/txt; s=iport; t=1314949405; x=1316159005; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ZsVQJ74BBelrGApQIzfjiQZopxg0YihfJXLpuVqwz58=; b=gKbD5Ldzka1t7VwVEyeGIdgaZSbsvUC5fGAH/ac3Gu1W0v3qAOcburAe uZvjyqOghLYoUzqrZZk4QYyN5Djs6/zisMGjA9xo+LAAJUEArR3b9tEXY 6MAk5TikQhk89SHhqzngg+AyBtAR4QHnxwGaVaPM5cJ2EmEx+57FtIbNG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAECIYE6Q/khN/2dsb2JhbAA4CqhZeIFGAQEBAQMSAR0KTwIBCCIGGAYBVgEBBBsaoBUBnyaDP4JGYASHaZBajBM X-IronPort-AV: E=Sophos;i="4.68,317,1312156800"; d="scan'208";a="52951521" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 02 Sep 2011 07:43:17 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p827hGFm006870 for ; Fri, 2 Sep 2011 07:43:17 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, 2 Sep 2011 02:43:16 -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, 2 Sep 2011 02:43:13 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Demand/Response Thread-Index: AcxAcisSZRUzanmdsk2o6MS8wxG5wAA6apSACXYG3oA= References: From: "Mouli Chandramouli (moulchan)" To: "eman mailing list" X-OriginalArrivalTime: 02 Sep 2011 07:43:16.0511 (UTC) FILETIME=[FA02BAF0:01CC6943] Subject: Re: [eman] Demand/Response 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, 02 Sep 2011 07:41:50 -0000 Hello, There was a comment during EMAN WG meeting regarding shedding load (as a demand response) if that shall be considered in the scope of EMAN.=20 A description of the scenario is provided and the feedback from the list on this topic is highly appreciated.=20 Demand / Response is an external stimulus in contrast to energy optimization policies implemented in the network.=20 The energy savings policies may be implemented during off-peak hours of the network when the network utilizations are low.=20 Whereas, demand response reduction (brown-out) may occur even during peak hours.=20 The question is do we need additional requirements beyond those to handle this scenario. Currently, there are requirements for configuration of power states of devices 8.1.1. Control of power states of other powered entities.=20 It is also possible to identify the role of entities in the network (pmRoleDescription or pmKeywords) and exclude some of the critical entities in the network and possibly configure the remaining network entities to one of the power saving modes. For the network devices point of view, it is also possible to consider "follow the moon" type of scheduling to move VMs based on energy demand/availability.=20 A description of Demand/Response has been captured in the Applicability statement to indicate that demand/response scenario shall be considered in EMAN.=20 Thanks Mouli From j.schoenwaelder@jacobs-university.de Fri Sep 2 08:41: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 E8E5E21F85B1 for ; Fri, 2 Sep 2011 08:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.097 X-Spam-Level: X-Spam-Status: No, score=-103.097 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 j3b-QHmyd6oI for ; Fri, 2 Sep 2011 08:41:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DD75921F85AB for ; Fri, 2 Sep 2011 08:41:14 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C5FF20CB3; Fri, 2 Sep 2011 17:42:50 +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 CrYGEy1fIc8S; Fri, 2 Sep 2011 17:42:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E09520CAC; Fri, 2 Sep 2011 17:42:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5DEC21A4A22C; Fri, 2 Sep 2011 17:42:40 +0200 (CEST) Date: Fri, 2 Sep 2011 17:42:40 +0200 From: Juergen Schoenwaelder To: "Mielke, William F (Bill)" Message-ID: <20110902154240.GB61202@elstar.local> Mail-Followup-To: "Mielke, William F (Bill)" , "eman@ietf.org" References: <20110728164503.GA30392@elstar.local> <20110728184235.GD30565@elstar.local> <20110728212016.GA31474@elstar.local> <4E38229F.4020504@cisco.com> <20110803045449.GA43357@elstar.local> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250A5638FE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250A5638FE@USNAVSXCHMBSA3.ndc.alcatel-lucent.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: Fri, 02 Sep 2011 15:41:16 -0000 On Mon, Aug 15, 2011 at 01:40:12PM -0500, Mielke, William F (Bill) wrote: > > 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 > > From my perspective allowing for a given device to support multiple power state sets simultaneously we are improving/enabling increased interoperability 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 example, so allowing the device to support multiple power state sets increases the number of EnMS which can interoperate with the device. > > Regarding the "magic" mapping between the power states within the various sets supported by a device, the core assumption (perhaps this needs to be made explicit) is that if a device chooses to support multiple power state sets 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 within the context of a given device a sensible mapping may certainly be possible. If it is, then the device can choose to support that mapping and the various EnMS can safely interact with it using any of the available power state sets. It is kind of interesting to hear that dealing with multiple power state sets is too hard for an EnMS but that this is an easily solvable problem for devices and that relying on an implementation specific "sensible mapping" provided by devices (which can be different for different devices and manufacturers) is sufficient to build robust EnMS. But the question we were discussing here (see the quoted text above) is whether device are expected to report and act according to multiple different power state sets _concurrently_. Are you saying this is the case since devices may need to talk to different EnMS at the same time and these different EnMS all have a simplified view of world where there is only one set of power states? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bschoening@noveda.com Mon Sep 5 09:05:33 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 4BCBE21F8B74 for ; Mon, 5 Sep 2011 09:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=-2.400, BAYES_00=-2.599, GB_SUMOF=5] 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 WCcBeE-4Esrm for ; Mon, 5 Sep 2011 09:05:32 -0700 (PDT) Received: from tex1-mh319a.smtpout.com (tex1-mh319a.smtpout.com [208.43.37.159]) by ietfa.amsl.com (Postfix) with ESMTP id 0011721F8B77 for ; Mon, 5 Sep 2011 09:05:31 -0700 (PDT) X-Katharion-ID: 1315238673.11237.tex1-mh319 Received: from ex01.noveda.com ([66.198.105.170]) by tex1-mh319.smtproutes.com [(208.43.37.108)] with ESMTP via TCP; 05 Sep 2011 11:04:33 -0500 Received: from EX01.noveda.com ([::1]) by ex01.noveda.com ([::1]) with mapi; Mon, 5 Sep 2011 12:04:33 -0400 From: Brad Schoening To: Michael Suchoff , Juergen Quittek , "Mouli Chandramouli (moulchan)" Thread-Topic: [eman] Comments on eman requirements Thread-Index: AcxBXJ8ui2HI0CwAck+Nd3U2fMFfQAAFTl0gCpyZR5A= Date: Mon, 5 Sep 2011 16:04:42 +0000 Message-ID: <22B2909DCC2E62418BE369A1F10488994BA408B7@ex01.noveda.com> References: <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at><9C329342B62B87498B92834DEC9FF51E0D238F6F@fig.raritan.com> <507BECE6-EE1C-4120-8D3C-B2CEEECEC76A@quittek.at> <9C329342B62B87498B92834DEC9FF51E0D38491E@fig.raritan.com> In-Reply-To: <9C329342B62B87498B92834DEC9FF51E0D38491E@fig.raritan.com> 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 mailing list Subject: Re: [eman] Comments on eman requirements 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, 05 Sep 2011 16:05:33 -0000 Hi Michael, IEC 61000-4-30 appears to be a standard for benchmark measurement methods a= nd testing. It does not seem to include a data model for reporting and man= agement over protocols such as IP or SNMP. =20 Thanks, Brad -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Mic= hael Suchoff Sent: Wednesday, July 13, 2011 11:39 AM To: Juergen Quittek; Mouli Chandramouli (moulchan) Cc: eman mailing list Subject: Re: [eman] Comments on eman requirements A root cause for confusion may be WG's selection of IEC 61850 as power quality standard. 61850 is used by power stations and utilities for medium and high voltage systems - this is not appropriate for low voltage AC systems where this group's work will be used. A better choice would be IEC 61000-4-30 "Testing and Measuring Techniques - Power Quality Measurement Methods". An examination of power quality meters will show this is the standard to which they are designed. -----Original Message----- From: Juergen Quittek [mailto:ietf@quittek.at]=20 Sent: Wednesday, July 13, 2011 8:59 AM To: Mouli Chandramouli (moulchan) Cc: Michael Suchoff; eman mailing list Subject: Re: [eman] Comments on eman requirements Hi Mouli, Let's come back to this after we have agreed on a definition for power. Meanwhile I will look up how IEEE and IEC define "instantaneous power", particularly in case of AC. Thanks, Juergen Am 13.07.2011 um 12:09 schrieb Mouli Chandramouli (moulchan): > Hi Juergen, >=20 > I think there is some confusion on measurement - what is meant by > instantaneous power measurement.=20 >=20 > For the sake of clarity, let us assume there is an external meter, which > measures the power of the electrical device at a given time instant and > it is possible to read the meter reading. The reported value is the > power consumed by the device at that time - 100 watts... >=20 > I do not think the intent is to measure Alternating Current at the > granularity of 50 or 60 sinusoidal cycles per second. Not sure if there > are even devices to measure current at that level.=20 >=20 > So, the meter does the averaging internally and reports the power > consumed at a given time. From a energy monitoring or planning > perspective, that would seem to be adequate.=20 >=20 > Any thoughts.=20 >=20 > Thanks > Mouli >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Quittek > Sent: Friday, July 08, 2011 2:17 PM > To: Michael Suchoff > Cc: eman mailing list > Subject: Re: [eman] Comments on eman requirements >=20 > Dear Michael, >=20 > You are absolutely right.=20 > And I wrote the same story already in an earlier message: >=20 > For AC power measurement there is always a reporting interval. >=20 > Thanks, >=20 > Juergen >=20 > Am 07.07.2011 um 17:14 schrieb Michael Suchoff: >=20 >> AC power is not reported as an instantaneous value but as an average - > the minimum averaging time being 1/2 AC cycle. >>=20 >> A plot of the instantaneous AC power is a sinusoidal waveform at 2X > the AC power frequency. For example, assume V =3D 100V RMS, I =3D 1A RMS= , > F=3D60Hz with power factor 1.0. The power waveform would be a 120Hz > sinusoidal with amplitude 200 and average value 100. The average value > is the active (real) power. >>=20 >> The power waveform can be explained mathematically using the product > to sum formula we learned in high school trigonometry class.... >>=20 >> Sin(a) * sin(b) =3D .5 * (cos(a-b) - cos(a+b) >>=20 >> "a" and "b" are frequency (phase term not shown for simplicity) which > are identical. Cos(a-b) =3D 0 which is the real component of power and > whose average value is shown on a watt meter. Cos(a+b) is the 2X > frequency component whose average value is 0. >>=20 >>=20 >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf > Of JinHyeock Choi >> Sent: Wednesday, July 06, 2011 11:09 PM >> To: Juergen Quittek >> Cc: eman mailing list >> Subject: Re: [eman] Comments on eman requirements >>=20 >> Dear Juergen >>=20 >> thanks for kind and thoughtful reply. >>=20 >>>> 1. Clarification of 'Power' and 'Energy' >>>>=20 >>>> Energy management concerns both 'power' and 'energy' and >>>> now the term 'energy consmption' is used for both, >>>> and sometimes brings forth confusion. >>>>=20 >>>> Maybe we can make it more clear >>>> by attaching the unit to be measured (either watt or watthour). >>>> For example such as >>>> "amount of consumed energy measured by joule or watthour." >>>=20 >>> I see your point. The alternative would be adding a clarification to >>> the terminology section. What about appending >>>=20 >>> However, in this document the term "consumed energy" always refers >>> to an energy quantity and not to a power quantity. >>>=20 >>> to section 2.1 Energy? >>=20 >> fine with me. >>=20 >> Sometimes people have trouble distinguishng 'power' and 'energy' >> at least that's the case for me. >> (it has been a long while since I pored over Physics textbook.) >>=20 >> Though 'power' and 'energy' have different meanings >> clearly defined in Physics, >> their everyday usage can be intermingling >> such as 'power efficiency' and 'energy efficiency' >>=20 >>>> 2. Power/ Energy and Time >>>> Both power and energy are time dependent parameter. >>>>=20 >>>> When reporting 'power' or 'energy' value, >>>> i) a specific moment or ii) a time interval >>>> with which the measurement is made also should be provided. >>>=20 >>> Yes, that's a good point. I think for energy measurements this is > covered >>> by requirement 5.5.2. Time intervals, but for power monitoring this > is missing. >>>=20 >>> What about adding the following requirement? >>> 5.4.2. Power measurement interval >>>=20 >>> The energy management standard must provide means for reporting the >>> corresponding time interval for which a power value is reported. A >>> time interval can be very short for reporting approximations of >>> instantaneous power or rather long for reporting demand values. >>=20 >> In principle, >> power itself is an instantateous value >> and measured at a moment (not over interval). >>=20 >> So how about rephrasing >>=20 >> The energy management standard must provide means for reporting the >> corresponding time or time interval for which a power value is > reported. >> The power value can be measured at the corresponding time or > averaged >> over the corresponding time interval. >>=20 >>>> 3. Power state and Energy consumption >>>>=20 >>>>> 5.5.3. Energy per power state >>>>>=20 >>>>> The energy management standard must provide means for reporting the >>>>> consumed energy individually for each power state. >>>>=20 >>>> Energy consumption depends on >>>> not only 'power state' but also 'traffic load'. >>>>=20 >>>> To make sense out of the monitored 'power' or 'energy' value, >>>> energy management system should also take into consideration >>>> corresponding 'traffic rate (measured by bps)' or 'accumulated >>>> traffic (measured by bits)'. >>>>=20 >>>> Otherwise it can't determine >>>> whether high power consumption is from low energy efficiency >>>> or high data traffic. >>>=20 >>> What would be the requirement? >>=20 >> How about >>=20 >> The energy management standard must provide means for reporting the >> consumed energy individually for each power state, >> with which enegy management system can derive an average expected >> energy consumption for each power state. >>=20 >> to clarify the reason behind per-power state reporting >>> A comment on the issue: >>> Proportionality between traffic and energy is a tricky thing. >>> I read reports on measurements at low-end routers that show >>> decreasing energy consumption with increasing traffic. >>=20 >> Interesting. >> Power consumption remaining the same irrespective of traffic load >> is not unusual but power consumption inversely proportional >> to traffic load is a novelty. >> Can you give me a pointer? >>=20 >>>> 4. Power profile of powered entity >>>>=20 >>>> For the above purpose, it would be of help >>>> for energy management system to be aware of >>>> the energy efficiency of each powered device (or entity), >>>> i.e. how much energy (joule) each device consumes per bit. >>>>=20 >>>> Ideally energy efficiency would be provided as >>>> a power profile (or power model), a function >>>> which maps served traffic (bits or bps) into consumed energy (joule/ > watt). >>>>=20 >>>> I recommend >>>> energy efficiency or power profile >>>> to be included to the required information in Sec 5. >>>=20 >>> This would be a requirement for switches, routers, etc. only. >>> For PCs, displays, light bulbs, it would not be applicable. >>=20 >> I see. >>=20 >>> Would it not be sufficient to just report the power and have the > joule/bit >>> be computed by a management system that reads the interface MIB > modules >>> if available? >>=20 >> ok. >>=20 >> For energy management, >> power profile would be needed >> but maybe better be acquired indirectly >> via a kind of resolution scheme. >>=20 >>>>> 4.2. Identifying components of powered devices >>>>>=20 >>>>> The energy management standard must provide means for identifying > not >>>>> just entire devices as powered entities, but also individual >>>>> components of powered devices. >>>>=20 >>>> Shall we also identify (or represent) the (subordinate) relationship >>>> between powered device and its individual components? >>>=20 >>> There are already standards for this available. >>> Shall we still make a requirement out of it in order to clarify that > this is >>> needed for energy management as well? >>=20 >> Such representatin of subordinate relationship would be useful >> but I'm not sure about making it a requirement. >> If WG doesn't have a strong opinion about it, >> let's leave it as it is. :-) >>=20 >>>>> 5.2.6. Maximum and average power per power state >>>>>=20 >>>>> 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. >>>>=20 >>>> Average power in which sense? >>>> Just a arithmetic mean value between maximum and minimum power? >>>=20 >>> I was thinking about the average expected energy consumption in a > particular power state. >>> I admit that this may be difficult to predict. >>=20 >> yes, >> even at the same power state, >> enrgy consumption can vary substantially depending on traffic load. >>=20 >>> But before asking an entity to switch to another >>> power state it would make sense to have information about the chances > of saving power >>> and for avoiding to bring the device into a state that even consumes > more power. >>=20 >> agree. >>=20 >>>>> 5.4. Power >>>>>=20 >>>>> For some network management tasks, it is required to obtain time >>>>> series of power values (or energy consumption values). >>>>=20 >>>> I assume energy consumption value measured by watt. >>>> Am I right? >>>=20 >>> No here it is either or: power or energy time series. But I see this > is confusing. >>> What about removing "(or energy consumption values)"? >>=20 >> ok. thanks for clarificaiton. >>=20 >>>>> 5.5. Energy >>>>>=20 >>>>> In order to monitor energy consumption in different power states, > it >>>>> is useful if entities record their energy consumption per power > state >>>>> and report these quantities. >>>>=20 >>>> Energy consumption varies according to power state and traffic load. >>>> How do you take 'traffic load' into consideration? >>>=20 >>> We do not have any generic term for load. If you can provide one, > please send it. >>=20 >> 'bps' or '(accumulated) bit' would do for network equipments >> such as router or switich. >>=20 >> However, for more generic work load, >> I don't have a good idea. >>=20 >>>> Energy would be measured over time interval. >>>>=20 >>>> Would time series of energy values be measured >>>> over the sequence of time intervals in 5.5.2? >>>=20 >>> Yes. There are different ways to do so. >>>=20 >>> A time series can contain values that give the total energy since the > last re-start >>> up to an indicated measurement time. Alternatively, you can have time > series of energy >>> consumption for consecutive time intervals, one value each. Or you > can have this for >>> overlapping time intervals. 5.5.2 shows all of them. >>=20 >> ok. >>=20 >> Please allow me to split hairs >> cocnerning the terms 'series' and 'sequence' >> which are currently both used in in 5.5.2 and 5.5.4. >>=20 >> Precisely speaking, in mathematics, >> 'series' is the sum of the terms of 'sequence', >> so in our context, 'sequence' is better. >>=20 >> Bets regards >>=20 >> JinHyeock >> _______________________________________________ >> 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 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From moulchan@cisco.com Tue Sep 6 03:37: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 8179421F85A1 for ; Tue, 6 Sep 2011 03:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=-2.955, BAYES_00=-2.599, GB_SUMOF=5] 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 0NOS36L-UIHG for ; Tue, 6 Sep 2011 03:37:19 -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 2B3F721F8586 for ; Tue, 6 Sep 2011 03:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=15157; q=dns/txt; s=iport; t=1315305545; x=1316515145; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=setVWEsuOWT5C3VuL8brGgDZRaxlraPDDeRggGJyuJg=; b=POdJM6U+BV0VU1/A+XqhLHJC46X5YjBp5ds4nC2LLUM3s705tfccKyYH xQqNxcAaG48Lojfkzak1LgFjrT4mcBXWhRzKXUNrVZ4JOrYkAKZuuPnpc ysTckhWDgs50hHCPzUHW/g/LWBQzhyVMw7cXhyIBUKycElMK9Jlw0q859 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMAAH33ZU6tJXG9/2dsb2JhbAA4BAaYWY9JeIFGAQEBAQIBAQEBDwEdCjQCAgcFBwQCAQgOAwQBAQsGFwEGASYfCQgBAQQBEAIIGodRBJsVAZ55g0QLgjtgBIdrkFuMEx4 X-IronPort-AV: E=Sophos;i="4.68,338,1312156800"; d="scan'208";a="19451091" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 06 Sep 2011 10:39:05 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p86Ad5WA001964; Tue, 6 Sep 2011 10:39:05 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); Tue, 6 Sep 2011 05:39: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: Tue, 6 Sep 2011 05:39:00 -0500 Message-ID: In-Reply-To: <22B2909DCC2E62418BE369A1F10488994BA408B7@ex01.noveda.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Comments on eman requirements Thread-Index: AcxBXJ8ui2HI0CwAck+Nd3U2fMFfQAAFTl0gCpyZR5AAJpP9UA== References: <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at><9C329342B62B87498B92834DEC9FF51E0D238F6F@fig.raritan.com><507BECE6-EE1C-4120-8D3C-B2CEEECEC76A@quittek.at> <9C329342B62B87498B92834DEC9FF51E0D38491E@fig.raritan.com> <22B2909DCC2E62418BE369A1F10488994BA408B7@ex01.noveda.com> From: "Mouli Chandramouli (moulchan)" To: "Brad Schoening" , "Michael Suchoff" , "Juergen Quittek" X-OriginalArrivalTime: 06 Sep 2011 10:39:04.0843 (UTC) FILETIME=[32F575B0:01CC6C81] Cc: eman mailing list Subject: Re: [eman] Comments on eman requirements 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, 06 Sep 2011 10:37:20 -0000 Hi Michael, Expanding on Brad's point - IEC 61000-4-30, it seems the standard is focused on defining an standardized approach for instrumentation of measuring devices and devices complying to this standard - " This standard ensures that different PQ instruments use the same definitions, and measurement techniques, for various power quality parameters: sags/dips, swells, frequency, harmonics, ...". The parameters considered in IEC 61000-4-30 include: Power frequency, Magntiude of Supply Voltage, Flicker, Supply Dips/Swells, Voltage Interruptions, Unbalance, Harmonics, Interharmonics, Mains Signaling, Under- and over-deviation, ... The focus of EMAN is on reporting power quality measurements (measured by some device/meter and we trust the values, allowing a margin of measurement error using the concept of accuracy). The question is what are the power quality measurements that are useful ?=20 In that context, a data model that is given in IEC 61850-7-4 LN MMXU (Total active power, Total reactive power, Total apparent power, power factot, ...) has been reused - Page 57 of IEC 61850-7-4 Ed.2.0 Communication networks and systems for power utility automation - Part 7-4: Basic communication structure -Compatible logical node classes and data object classes. Thanks Mouli =20 -----Original Message----- From: Brad Schoening [mailto:bschoening@noveda.com]=20 Sent: Monday, September 05, 2011 9:35 PM To: Michael Suchoff; Juergen Quittek; Mouli Chandramouli (moulchan) Cc: eman mailing list Subject: RE: [eman] Comments on eman requirements Hi Michael, IEC 61000-4-30 appears to be a standard for benchmark measurement methods and testing. It does not seem to include a data model for reporting and management over protocols such as IP or SNMP. =20 Thanks, Brad -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Michael Suchoff Sent: Wednesday, July 13, 2011 11:39 AM To: Juergen Quittek; Mouli Chandramouli (moulchan) Cc: eman mailing list Subject: Re: [eman] Comments on eman requirements A root cause for confusion may be WG's selection of IEC 61850 as power quality standard. 61850 is used by power stations and utilities for medium and high voltage systems - this is not appropriate for low voltage AC systems where this group's work will be used. A better choice would be IEC 61000-4-30 "Testing and Measuring Techniques - Power Quality Measurement Methods". An examination of power quality meters will show this is the standard to which they are designed. -----Original Message----- From: Juergen Quittek [mailto:ietf@quittek.at]=20 Sent: Wednesday, July 13, 2011 8:59 AM To: Mouli Chandramouli (moulchan) Cc: Michael Suchoff; eman mailing list Subject: Re: [eman] Comments on eman requirements Hi Mouli, Let's come back to this after we have agreed on a definition for power. Meanwhile I will look up how IEEE and IEC define "instantaneous power", particularly in case of AC. Thanks, Juergen Am 13.07.2011 um 12:09 schrieb Mouli Chandramouli (moulchan): > Hi Juergen, >=20 > I think there is some confusion on measurement - what is meant by > instantaneous power measurement.=20 >=20 > For the sake of clarity, let us assume there is an external meter, which > measures the power of the electrical device at a given time instant and > it is possible to read the meter reading. The reported value is the > power consumed by the device at that time - 100 watts... >=20 > I do not think the intent is to measure Alternating Current at the > granularity of 50 or 60 sinusoidal cycles per second. Not sure if there > are even devices to measure current at that level.=20 >=20 > So, the meter does the averaging internally and reports the power > consumed at a given time. From a energy monitoring or planning > perspective, that would seem to be adequate.=20 >=20 > Any thoughts.=20 >=20 > Thanks > Mouli >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Quittek > Sent: Friday, July 08, 2011 2:17 PM > To: Michael Suchoff > Cc: eman mailing list > Subject: Re: [eman] Comments on eman requirements >=20 > Dear Michael, >=20 > You are absolutely right.=20 > And I wrote the same story already in an earlier message: >=20 > For AC power measurement there is always a reporting interval. >=20 > Thanks, >=20 > Juergen >=20 > Am 07.07.2011 um 17:14 schrieb Michael Suchoff: >=20 >> AC power is not reported as an instantaneous value but as an average - > the minimum averaging time being 1/2 AC cycle. >>=20 >> A plot of the instantaneous AC power is a sinusoidal waveform at 2X > the AC power frequency. For example, assume V =3D 100V RMS, I =3D 1A = RMS, > F=3D60Hz with power factor 1.0. The power waveform would be a 120Hz > sinusoidal with amplitude 200 and average value 100. The average value > is the active (real) power. >>=20 >> The power waveform can be explained mathematically using the product > to sum formula we learned in high school trigonometry class.... >>=20 >> Sin(a) * sin(b) =3D .5 * (cos(a-b) - cos(a+b) >>=20 >> "a" and "b" are frequency (phase term not shown for simplicity) which > are identical. Cos(a-b) =3D 0 which is the real component of power = and > whose average value is shown on a watt meter. Cos(a+b) is the 2X > frequency component whose average value is 0. >>=20 >>=20 >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf > Of JinHyeock Choi >> Sent: Wednesday, July 06, 2011 11:09 PM >> To: Juergen Quittek >> Cc: eman mailing list >> Subject: Re: [eman] Comments on eman requirements >>=20 >> Dear Juergen >>=20 >> thanks for kind and thoughtful reply. >>=20 >>>> 1. Clarification of 'Power' and 'Energy' >>>>=20 >>>> Energy management concerns both 'power' and 'energy' and >>>> now the term 'energy consmption' is used for both, >>>> and sometimes brings forth confusion. >>>>=20 >>>> Maybe we can make it more clear >>>> by attaching the unit to be measured (either watt or watthour). >>>> For example such as >>>> "amount of consumed energy measured by joule or watthour." >>>=20 >>> I see your point. The alternative would be adding a clarification to >>> the terminology section. What about appending >>>=20 >>> However, in this document the term "consumed energy" always refers >>> to an energy quantity and not to a power quantity. >>>=20 >>> to section 2.1 Energy? >>=20 >> fine with me. >>=20 >> Sometimes people have trouble distinguishng 'power' and 'energy' >> at least that's the case for me. >> (it has been a long while since I pored over Physics textbook.) >>=20 >> Though 'power' and 'energy' have different meanings >> clearly defined in Physics, >> their everyday usage can be intermingling >> such as 'power efficiency' and 'energy efficiency' >>=20 >>>> 2. Power/ Energy and Time >>>> Both power and energy are time dependent parameter. >>>>=20 >>>> When reporting 'power' or 'energy' value, >>>> i) a specific moment or ii) a time interval >>>> with which the measurement is made also should be provided. >>>=20 >>> Yes, that's a good point. I think for energy measurements this is > covered >>> by requirement 5.5.2. Time intervals, but for power monitoring this > is missing. >>>=20 >>> What about adding the following requirement? >>> 5.4.2. Power measurement interval >>>=20 >>> The energy management standard must provide means for reporting the >>> corresponding time interval for which a power value is reported. A >>> time interval can be very short for reporting approximations of >>> instantaneous power or rather long for reporting demand values. >>=20 >> In principle, >> power itself is an instantateous value >> and measured at a moment (not over interval). >>=20 >> So how about rephrasing >>=20 >> The energy management standard must provide means for reporting the >> corresponding time or time interval for which a power value is > reported. >> The power value can be measured at the corresponding time or > averaged >> over the corresponding time interval. >>=20 >>>> 3. Power state and Energy consumption >>>>=20 >>>>> 5.5.3. Energy per power state >>>>>=20 >>>>> The energy management standard must provide means for reporting the >>>>> consumed energy individually for each power state. >>>>=20 >>>> Energy consumption depends on >>>> not only 'power state' but also 'traffic load'. >>>>=20 >>>> To make sense out of the monitored 'power' or 'energy' value, >>>> energy management system should also take into consideration >>>> corresponding 'traffic rate (measured by bps)' or 'accumulated >>>> traffic (measured by bits)'. >>>>=20 >>>> Otherwise it can't determine >>>> whether high power consumption is from low energy efficiency >>>> or high data traffic. >>>=20 >>> What would be the requirement? >>=20 >> How about >>=20 >> The energy management standard must provide means for reporting the >> consumed energy individually for each power state, >> with which enegy management system can derive an average expected >> energy consumption for each power state. >>=20 >> to clarify the reason behind per-power state reporting >>> A comment on the issue: >>> Proportionality between traffic and energy is a tricky thing. >>> I read reports on measurements at low-end routers that show >>> decreasing energy consumption with increasing traffic. >>=20 >> Interesting. >> Power consumption remaining the same irrespective of traffic load >> is not unusual but power consumption inversely proportional >> to traffic load is a novelty. >> Can you give me a pointer? >>=20 >>>> 4. Power profile of powered entity >>>>=20 >>>> For the above purpose, it would be of help >>>> for energy management system to be aware of >>>> the energy efficiency of each powered device (or entity), >>>> i.e. how much energy (joule) each device consumes per bit. >>>>=20 >>>> Ideally energy efficiency would be provided as >>>> a power profile (or power model), a function >>>> which maps served traffic (bits or bps) into consumed energy (joule/ > watt). >>>>=20 >>>> I recommend >>>> energy efficiency or power profile >>>> to be included to the required information in Sec 5. >>>=20 >>> This would be a requirement for switches, routers, etc. only. >>> For PCs, displays, light bulbs, it would not be applicable. >>=20 >> I see. >>=20 >>> Would it not be sufficient to just report the power and have the > joule/bit >>> be computed by a management system that reads the interface MIB > modules >>> if available? >>=20 >> ok. >>=20 >> For energy management, >> power profile would be needed >> but maybe better be acquired indirectly >> via a kind of resolution scheme. >>=20 >>>>> 4.2. Identifying components of powered devices >>>>>=20 >>>>> The energy management standard must provide means for identifying > not >>>>> just entire devices as powered entities, but also individual >>>>> components of powered devices. >>>>=20 >>>> Shall we also identify (or represent) the (subordinate) relationship >>>> between powered device and its individual components? >>>=20 >>> There are already standards for this available. >>> Shall we still make a requirement out of it in order to clarify that > this is >>> needed for energy management as well? >>=20 >> Such representatin of subordinate relationship would be useful >> but I'm not sure about making it a requirement. >> If WG doesn't have a strong opinion about it, >> let's leave it as it is. :-) >>=20 >>>>> 5.2.6. Maximum and average power per power state >>>>>=20 >>>>> 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. >>>>=20 >>>> Average power in which sense? >>>> Just a arithmetic mean value between maximum and minimum power? >>>=20 >>> I was thinking about the average expected energy consumption in a > particular power state. >>> I admit that this may be difficult to predict. >>=20 >> yes, >> even at the same power state, >> enrgy consumption can vary substantially depending on traffic load. >>=20 >>> But before asking an entity to switch to another >>> power state it would make sense to have information about the chances > of saving power >>> and for avoiding to bring the device into a state that even consumes > more power. >>=20 >> agree. >>=20 >>>>> 5.4. Power >>>>>=20 >>>>> For some network management tasks, it is required to obtain time >>>>> series of power values (or energy consumption values). >>>>=20 >>>> I assume energy consumption value measured by watt. >>>> Am I right? >>>=20 >>> No here it is either or: power or energy time series. But I see this > is confusing. >>> What about removing "(or energy consumption values)"? >>=20 >> ok. thanks for clarificaiton. >>=20 >>>>> 5.5. Energy >>>>>=20 >>>>> In order to monitor energy consumption in different power states, > it >>>>> is useful if entities record their energy consumption per power > state >>>>> and report these quantities. >>>>=20 >>>> Energy consumption varies according to power state and traffic load. >>>> How do you take 'traffic load' into consideration? >>>=20 >>> We do not have any generic term for load. If you can provide one, > please send it. >>=20 >> 'bps' or '(accumulated) bit' would do for network equipments >> such as router or switich. >>=20 >> However, for more generic work load, >> I don't have a good idea. >>=20 >>>> Energy would be measured over time interval. >>>>=20 >>>> Would time series of energy values be measured >>>> over the sequence of time intervals in 5.5.2? >>>=20 >>> Yes. There are different ways to do so. >>>=20 >>> A time series can contain values that give the total energy since the > last re-start >>> up to an indicated measurement time. Alternatively, you can have time > series of energy >>> consumption for consecutive time intervals, one value each. Or you > can have this for >>> overlapping time intervals. 5.5.2 shows all of them. >>=20 >> ok. >>=20 >> Please allow me to split hairs >> cocnerning the terms 'series' and 'sequence' >> which are currently both used in in 5.5.2 and 5.5.4. >>=20 >> Precisely speaking, in mathematics, >> 'series' is the sum of the terms of 'sequence', >> so in our context, 'sequence' is better. >>=20 >> Bets regards >>=20 >> JinHyeock >> _______________________________________________ >> 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 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From jparello@cisco.com Thu Sep 15 13: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 4D67011E8096 for ; Thu, 15 Sep 2011 13:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-0.229, 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 u4wAd5dY66tY for ; Thu, 15 Sep 2011 13:31:55 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 96B7511E8086 for ; Thu, 15 Sep 2011 13:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=10979; q=dns/txt; s=iport; t=1316118848; x=1317328448; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=TS/LxiLbpx/6ZhZg3PBltEK28dZEgILs9KI69YKeo3A=; b=NwfeUOrdbCveltTFJTtQHipDcE6ol/EpTVN57jVdtKQq+QCl6EWKRBAq 7j4jKRt3f4znG9/xkoZj+AleMNkcoQpMLR4XxUrb8WgXGL+CouDXauW90 4RuOMkJr+68lJobk18WW3ncP8raQ+8dd6OBHkIatcwFWJAEw+Si5WMKg+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYAAPpfck6rRDoJ/2dsb2JhbABCgk2WBo8EeIFTAQEBAQMSAQkRAz4bAgEIDgMEAQELBgUOBAEGAUUJCAEBBAESCBqgDAGeIYNggjRgBIdvkH2MJQ X-IronPort-AV: E=Sophos;i="4.68,389,1312156800"; d="scan'208,217";a="2397824" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 15 Sep 2011 20:34:08 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8FKY8CJ004116; Thu, 15 Sep 2011 20:34:08 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, 15 Sep 2011 13:34:08 -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_01CC73E6.D14E5848" Date: Thu, 15 Sep 2011 13:31:53 -0700 Message-ID: In-Reply-To: <0E1278EA-66B1-4299-AAF6-C75B45F09BC8@quittek.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology: energy management system (was: Re: comments ondraft-parello-eman-definitions-00) Thread-Index: AcxL6tzxdHdAMTsxT1yqlZLv5LiVNgn+3Reg References: <0E1278EA-66B1-4299-AAF6-C75B45F09BC8@quittek.at> From: "John Parello (jparello)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 15 Sep 2011 20:34:08.0007 (UTC) FILETIME=[D16BB170:01CC73E6] Subject: Re: [eman] Terminology: energy management system (was: Re: comments ondraft-parello-eman-definitions-00) 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, 15 Sep 2011 20:31:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC73E6.D14E5848 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 I've combined these and clarified it. I preserved the fact that that the term Energy Management System is overload from ISO in case anyone comes to our standards from that track. =20 Thanks! Jp =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Tuesday, July 26, 2011 4:22 PM To: eman mailing list Subject: [eman] Terminology: energy management system (was: Re: comments ondraft-parello-eman-definitions-00) =20 Hi John, =20 In draft-parello-eman-definitions-00 you define an energy management system twice: =20 Energy Management System (EnMS)=20 =20 An EnMS is a set of systems or procedures upon which=20 organizations can develop and implement an energy policy, set=20 targets, action plans and take into account legal requirements=20 related to energy use. An EnMS allows organizations to improve=20 energy performance and demonstrate conformity to requirements,=20 standards and/or legal requirements. =20 Example: =20 A set of workflow procedures setup by an organization to track=20 and archive utility billing records to ensure an auditable=20 history of targets.=20 Reference:=20 [ISO50001]=20 =20 and =20 Energy Management Systems =20 =20 An Energy Management System (EMS) is congruent to a Network=20 Management System (NMS) and is a combination of hardware and=20 software used to administer a network with the primarily purpose=20 being Energy Management.=20 Example:=20 Reference:=20 Derived from [1037C]=20 =20 We cannot go with two definitions.=20 Shall we merge them or drop one of them? =20 For the acronym: I would prefer using EnMS, because it avoids confusion with an=20 element management system which is typically referred to as EMS. =20 Thanks, =20 Juergen =20 =20 =20 ------_=_NextPart_001_01CC73E6.D14E5848 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve combined these and clarified it. I preserved the fact that = that the term Energy Management System is overload from ISO in case = anyone comes to our standards from that track.

 

Thanks!

Jp

 

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Juergen Quittek
Sent: Tuesday, July 26, 2011 4:22 = PM
To: eman mailing list
Subject: [eman] = Terminology: energy management system (was: Re: comments = ondraft-parello-eman-definitions-00)

 

Hi = John,

 

In draft-parello-eman-definitions-00 you define = an energy management system twice:

 

     Energy = Management System (EnMS) 

 

      =  An EnMS is a set of systems or procedures upon = which 

       organizations can = develop and implement an energy policy, = set 

       targets, action plans = and take into account legal = requirements 

      =  related to energy use.  An EnMS allows organizations to = improve 

       energy performance and = demonstrate conformity to = requirements, 

      =  standards and/or legal requirements. =   

       Example: =  

       A set of workflow = procedures setup by an organization to = track 

       and archive utility = billing records to ensure an = auditable 

      =  history of targets. 

      =  Reference: 

      =  [ISO50001] 

 

and

 

     Energy = Management Systems  

 

      =  An Energy Management System (EMS) is congruent to a = Network 

       Management System (NMS) = and is a combination of hardware = and 

       software used to = administer a network with the primarily = purpose 

       being Energy = Management. 

      =  Example: 

      =  Reference: 

      =  Derived from = [1037C] 

 

We cannot go with two = definitions. 

Shall = we merge them or drop one of them?

 

For the acronym: I would prefer using EnMS, because it = avoids confusion with an 

element management system which is typically referred = to as EMS.

 

Thanks,

 

    Juergen

 

 

 

------_=_NextPart_001_01CC73E6.D14E5848-- From jparello@cisco.com Thu Sep 15 13:36:47 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 013CE21F8AF8 for ; Thu, 15 Sep 2011 13:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 KwogSB2w5YNY for ; Thu, 15 Sep 2011 13:36:45 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8F47921F8AF4 for ; Thu, 15 Sep 2011 13:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=8042; q=dns/txt; s=iport; t=1316119138; x=1317328738; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=9JhKc8gQJtBoF4WI4oXLH8DOmtcUUcxDnT+FKGAy1z4=; b=Pwt7dkMvi8AtysKj6JXkcNBAY4KLAPMX3lMPC9o+0UthE/hDVtIPH+6z ATW5YZhITr0frLcXfD9s8g01FTOoZBrPH4bmgwPwAFmJHWCksLVmRNqdX yrMcvn+cO3vft1BxzystGjxQeKcT6liMXpO1kSeuKA+F/aOfkH611zS5g U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYAAJxhck6rRDoH/2dsb2JhbABCgk2WBo8EeIFTAQEBAQMSAQkRAz4bAgEIDgMEAQELBhcBBgFFCQgBAQQBEggaoA8BniCGFGAEh2+QfYwl X-IronPort-AV: E=Sophos;i="4.68,389,1312156800"; d="scan'208,217";a="2391311" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 15 Sep 2011 20:38:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8FKctmu031042; Thu, 15 Sep 2011 20:38:55 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); Thu, 15 Sep 2011 13:38:55 -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_01CC73E7.7C7C3D98" Date: Thu, 15 Sep 2011 13:36:35 -0700 Message-ID: In-Reply-To: <40A7C674-CDAA-4643-959A-D0C71FFC5735@quittek.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Termiology: Thread-Index: AcxL7HmMoCleiQhaSrqlt7WUL4/mfAn+mPAA References: <40A7C674-CDAA-4643-959A-D0C71FFC5735@quittek.at> From: "John Parello (jparello)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 15 Sep 2011 20:38:55.0352 (UTC) FILETIME=[7CB10F80:01CC73E7] Subject: Re: [eman] Termiology: 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, 15 Sep 2011 20:36:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC73E7.7C7C3D98 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 We discussed this at IETF81 so the consensus form the meeting was to remove the term Managed and go with Electrical =20 I've use the terms Energy Object with "sub-class" Electrical Energy Object, Non-Electrical Energy Object which is all rooted from in the IEEE100 definition of Electrical Equipment. =20 =20 Jp =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Tuesday, July 26, 2011 4:34 PM To: eman mailing list Subject: [eman] Termiology: =20 Hi John, =20 In draft-parello-eman-definitions-00 you define 'energy managed object' as: =20 Energy Managed Object =20 =20 An Energy Managed Object (EMO) is a device that is part of or=20 attached to a communications network that is monitored,=20 controlled, or aids in the management of another device for=20 Energy Management.=20 =20 I have two issues here: =20 1. the term "managed object" is already in common use for the objects defined in a MIB module. Since we are also defining MIB modules, we will run into ambiguities and risk confusion of readers if we re-use the term here. =20 2. The attribute "managed" is confusing, because the term refers also to "unmanaged" objects that are neither monitored or controlled, but just "aid" in the management of other devices. These seem to be rather "managing" objects than "managed" objects. =20 Thanks, =20 Juergen ------_=_NextPart_001_01CC73E7.7C7C3D98 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

 

We discussed this at IETF81 so the consensus form the meeting was to = remove the term Managed and go with Electrical

 

I’ve use the terms Energy Object with “sub-class” = Electrical Energy Object, Non-Electrical Energy Object which is all = rooted from in the IEEE100 definition of Electrical = Equipment.

 

 

Jp

 

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Juergen Quittek
Sent: Tuesday, July 26, 2011 4:34 = PM
To: eman mailing list
Subject: [eman] = Termiology:

 

Hi = John,

 

In draft-parello-eman-definitions-00 you define = 'energy managed object' as:

 

     Energy = Managed Object  

 

      =   An Energy Managed Object (EMO) is a device that is part of = or 

        attached to a = communications network that is = monitored, 

      =   controlled, or aids in the management of another device = for 

        Energy = Management. 

 

I have two issues here:

 

1. the term "managed object" is already in = common use for the objects defined in a MIB module. Since we are also = defining MIB modules, we will run into ambiguities and risk confusion of = readers if we re-use the term here.

 

2. The attribute "managed" is confusing, = because the term refers also to "unmanaged" objects that are = neither monitored or controlled, but just "aid" in the = management of other devices. These seem to be rather = "managing" objects than "managed" = objects.

 

Thanks,

 

    = Juergen

------_=_NextPart_001_01CC73E7.7C7C3D98-- From jparello@cisco.com Thu Sep 15 13:37:35 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 C609411E80A1 for ; Thu, 15 Sep 2011 13:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 tagged_above=-999 required=5 tests=[AWL=-0.216, 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 jcelCYA6Yqus for ; Thu, 15 Sep 2011 13:37:34 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id EA7FA21F8BDC for ; Thu, 15 Sep 2011 13:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=7172; q=dns/txt; s=iport; t=1316119187; x=1317328787; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=UUIEzFVRrgg/pAGMrl7kWYmOeqKPojhyt4LtSkO9SCE=; b=bxFeNBlqX5KLPhAOMvNlJjnkZ2Bu3VTHL04MkpG+zTm3iAzctEgEDfQo kQKOBY4vUtLFDvT1rYhS8d7TrZ6Ljmit4QBVHJtFznsb49iqza3tbfx1M jMutgPD4FZd7ACN8afRCg+fHZaYIGQvTYEIjh0TE+wGpHi29krFzrpkwY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYAAD9ick6rRDoJ/2dsb2JhbABCgk2WBo8EeIFTAQEBAQMSAQkRAz4bAgEIDgMEAQELBhcBBgFFCQgBAQQBEggaoA8BniCGFGAEh2+QfYwl X-IronPort-AV: E=Sophos;i="4.68,389,1312156800"; d="scan'208,217";a="2397633" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 15 Sep 2011 20:39:46 +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 p8FKdhdG008116; Thu, 15 Sep 2011 20:39:45 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); Thu, 15 Sep 2011 13:39:44 -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_01CC73E7.9A0234D0" Date: Thu, 15 Sep 2011 13:37:22 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology: energy control Thread-Index: AcxL7ka+bIkTwM9CSsyeTJ12zN6S8wn+O5SA References: From: "John Parello (jparello)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 15 Sep 2011 20:39:44.0788 (UTC) FILETIME=[9A286540:01CC73E7] Subject: Re: [eman] Terminology: energy control 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, 15 Sep 2011 20:37:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC73E7.9A0234D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable HI, =20 I moved the contentious phrase to a note and re-phrased. =20 Jp =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Tuesday, July 26, 2011 4:47 PM To: eman mailing list Subject: [eman] Terminology: energy control =20 Hi John, =20 In draft-parello-eman-definitions-00 you define 'energy control' as: =20 Energy Control=20 =20 Energy Control is a part of Energy Management that deals with=20 modifying or setting the state of an Energy Managed Object in=20 order to optimize or ensure its efficiency.=20 =20 I disagree. Energy Control is not limited to optimization of efficiency. "in order to optimize or ensure its efficiency" should be removed. A function that increases energy consumption needs also to be covered by the term energy control. =20 What woud be the difference between "modifying" and "setting" a state? =20 What about the following?: =20 Energy Control is a part of Energy Management that deals wit influencing the consumption of energy in a network of energy consuming devices. =20 Thanks, =20 Juergen =20 =20 ------_=_NextPart_001_01CC73E7.9A0234D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

HI,

 

I moved the contentious phrase to a note and = re-phrased.

 

Jp

 

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Juergen Quittek
Sent: Tuesday, July 26, 2011 4:47 = PM
To: eman mailing list
Subject: [eman] = Terminology: energy control

 

Hi = John,

 

In draft-parello-eman-definitions-00 you define = 'energy control' as:

 

     Energy = Control 

 

      =  Energy Control is a part of Energy Management that deals = with 

       modifying or setting = the state of an Energy Managed Object = in 

       order to optimize or = ensure its = efficiency. 

 

I disagree. Energy Control is not limited to = optimization of efficiency. "in order to optimize or ensure its = efficiency" should be removed. A function that increases energy = consumption needs also to be covered by the term energy = control.

 

What woud be the difference between = "modifying" and "setting" a = state?

 

What about the following?:

 

    Energy Control is a part of Energy = Management that deals wit influencing = the

    = consumption of energy in a network of energy consuming = devices.

 

Thanks,

 

    Juergen

 

 

------_=_NextPart_001_01CC73E7.9A0234D0-- From jparello@cisco.com Thu Sep 15 13: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 A0A1C11E8096 for ; Thu, 15 Sep 2011 13:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[AWL=-0.211, 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 8LToOAXSroUQ for ; Thu, 15 Sep 2011 13:38:03 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1884621F8BD7 for ; Thu, 15 Sep 2011 13:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=8455; q=dns/txt; s=iport; t=1316119216; x=1317328816; h=mime-version:subject:date:message-id:references:from:to; bh=lrKOgqn7G48YVmv1FKnjKgNYgsmlKippKzm81ar74To=; b=Uo/B1Hpo/FOt468Dkksaj8A81q7D5DKQTw/P9aVkx0ybsqSoJTyQPgCq 2fA8TzGqY0NE2DUyZIdE11Cb4EdWo1oCmsABAo19zSdcfOAzhqp5+tckJ Kg650nnXnIJ5T6c3Jz7X8RljfTdEdo89wmYqwsL6B54gfVxQCCYE8tOqE o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYAAD9ick6rRDoI/2dsb2JhbABCgk2WBo8EeIFTAQEBAQMSAQkRAz4bAgEIDgMEAQELBhcBBgFFCQgBAQQBEggaoA8BniCGFGAEh2+QfYwl X-IronPort-AV: E=Sophos;i="4.68,389,1312156800"; d="scan'208,217";a="2397800" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 15 Sep 2011 20:40:15 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8FKeFk1009221; Thu, 15 Sep 2011 20:40:15 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); Thu, 15 Sep 2011 13:40:15 -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_01CC73E7.AC72F460" Date: Thu, 15 Sep 2011 13:38:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology: power Thread-Index: AcxL63VFcAR0s3/0QfCgDp17TSACwQn+1pTQAAAhp7A= References: From: "John Parello (jparello)" To: "Juergen Quittek" , X-OriginalArrivalTime: 15 Sep 2011 20:40:15.0631 (UTC) FILETIME=[AC8AA9F0:01CC73E7] Subject: Re: [eman] Terminology: power 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, 15 Sep 2011 20:38:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC73E7.AC72F460 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable ACK =20 IEEE 100=20 =20 Jp =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Tuesday, July 26, 2011 4:26 PM To: eman mailing list Subject: [eman] Terminology: power =20 Hi John, =20 In draft-parello-eman-definitions-00 you define power as: =20 Power=20 =20 Power is a rate of energy conversion. As the unit of time=20 approaches zero a power measurement is called an instantaneous=20 power reading. Typically when implementing Power monitoring in=20 hardware, a measuring device may have to compute an average=20 value per some unit of time to express a reading to approximate=20 an instantaneous power measurement. =20 Example:=20 Reference:=20 Derived from [ISO50001]=20 =20 This contradicts the definition of instantaneous power in the IEEE dictionary of standards terms where active power is "The time average of the instantaneous power over one period of the wave." This implies that the instantaneous power changes from zero to a maximum and back two times of a period, i.e. 100 or 120 times a second for common AC power. Typical meter implementations measure power over at least half a period. The result of their approximation is not called instantaneous power. It is the power over a (short) interval of time. =20 Again, I propose taking text from the IEE dictionary or a similar source. =20 Juergen ------_=_NextPart_001_01CC73E7.AC72F460 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

ACK

 

IEEE 100

 

Jp

 

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Juergen Quittek
Sent: Tuesday, July 26, 2011 4:26 = PM
To: eman mailing list
Subject: [eman] = Terminology: power

 

Hi = John,

 

In draft-parello-eman-definitions-00 you define = power as:

 

    =  Power 

 

      =  Power is a rate of energy conversion.  As the unit of = time 

       approaches zero a power = measurement is called an = instantaneous 

      =  power reading.  Typically when implementing Power monitoring = in 

       hardware, a measuring = device may have to compute an = average 

       value per some unit of = time to express a reading to = approximate 

      =  an instantaneous power measurement. =  

      =  Example: 

      =  Reference: 

      =  Derived from = [ISO50001] 

=

 

This contradicts the definition of instantaneous power = in the IEEE dictionary of standards terms where active power is = "The time average of the instantaneous power over one period of the = wave." This implies that the instantaneous power changes from zero = to a maximum and back two times of a period, i.e. 100 or 120 times a = second for common AC power. Typical meter implementations measure power = over at least half a period. The result of their approximation is not = called instantaneous power. It is the power over a (short) interval of = time.

 

Again, I propose taking text from the IEE dictionary = or a similar source.

 

    = Juergen

------_=_NextPart_001_01CC73E7.AC72F460-- From jparello@cisco.com Thu Sep 15 13:38: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 819FD21F8BD8 for ; Thu, 15 Sep 2011 13:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=-0.205, 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 S+Ypr0KiRXVf for ; Thu, 15 Sep 2011 13:38:37 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6B49321F8BD7 for ; Thu, 15 Sep 2011 13:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=8681; q=dns/txt; s=iport; t=1316119250; x=1317328850; h=mime-version:subject:date:message-id:references:from:to; bh=8DEY4buEkEMjAV343SWMbiCdkTF2ZtsMwBFItpNf17E=; b=MKdzzlsZKC1vpNvl3sKzBp3uhSuUCQFrfjy5WUiGVzLTp7EeLKjaTYBx 1UPPOcgPdpx6lqx1yCmwwOqbOndyuC4f5lh1rwXt5gbj15rigBEO7fkgY SpwlS/TD+AL0D3c7t6GjcHhHbTePGsTU6uaV6BkPV9pHryQjkoHTI68YO Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYAAD9ick6rRDoG/2dsb2JhbABCgk2WBo8EeIFTAQEBAQMSAQkRAz4bAgEIDgMEAQELBhcBBgFFCQgBAQQBEggaoA8BniCGFGAEh2+QfYwl X-IronPort-AV: E=Sophos;i="4.68,389,1312156800"; d="scan'208,217";a="2398982" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 15 Sep 2011 20:40:50 +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 p8FKeo7I017954; Thu, 15 Sep 2011 20:40:50 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); Thu, 15 Sep 2011 13:40:50 -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_01CC73E7.C0F9C470" Date: Thu, 15 Sep 2011 13:38:38 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology: energy Thread-Index: AcxL6u+z+6YGwQFMR5CNZlHeAIGZwwn+5MEwAAA4PzA= References: <0F0F2CC7-42B9-44E3-93A3-5ADFC48091BD@quittek.at> <688494E6-FFE4-43AD-8075-FD2D894B4C41@quittek.at> From: "John Parello (jparello)" To: "Juergen Quittek" , X-OriginalArrivalTime: 15 Sep 2011 20:40:50.0037 (UTC) FILETIME=[C10C9A50:01CC73E7] Subject: Re: [eman] Terminology: energy 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, 15 Sep 2011 20:38:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC73E7.C0F9C470 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 HI, =20 That definition was taken from ISO. After getting feedback from the various standards I have a definition from IEEE and IEC in there. Bear with me that was a strawman please do see the new version. =20 We can certainly restrict our work and implementation to electrical energy if that's the charter/consensus but the non-electrical will still need to be defined. This is a definition draft not an implementation draft. =20 Jp =20 =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Tuesday, July 26, 2011 4:22 PM To: eman mailing list Subject: [eman] Terminology: energy =20 Hi John, =20 In draft-parello-eman-definitions-00 you define energy as: =20 Energy =20 =20 Energy is the capacity of a system to produce external activity=20 or perform work and can be electricity, fuels, steam, heat,=20 compressed air, and other like media. Energy is typically expressed in watt hours or joules. =20 Example:=20 Reference:=20 [ISO50001]=20 =20 This is certainly not taken from an IEEE or IEC dictionary:=20 Energy is not steam, it is not fuel, it is not compressed air. Let's take reasonable text from a dictionary. =20 Would it be OK if we restricted our work to electrical energy? =20 Juergen ------_=_NextPart_001_01CC73E7.C0F9C470 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

HI,

 

That definition was taken from ISO. After getting feedback from the various standards I have a = definition from IEEE and IEC in there. Bear with me that was a strawman = please do see the new version.

 

We can certainly restrict our work and implementation to electrical = energy if that’s the charter/consensus but the non-electrical will = still need to be defined. This is a definition draft not an = implementation draft.

 

Jp

 

 

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Juergen Quittek
Sent: Tuesday, July 26, 2011 4:22 = PM
To: eman mailing list
Subject: [eman] = Terminology: energy

 

Hi = John,

 

In draft-parello-eman-definitions-00 you define = energy as:

 

     Energy =  

 

      =  Energy is the capacity of a system to produce external = activity 

      =  or perform work and can be electricity, fuels, steam, = heat, 

       compressed air, and = other like media. Energy is = typically 

      =  expressed in watt hours or joules. =  

      =  Example: 

      =  Reference: 

      =  [ISO50001] 

 

This is certainly not taken from an IEEE or IEC = dictionary: 

Energy = is not steam, it is not fuel, it is not compressed = air.

Let's take reasonable = text from a dictionary.

 

Would it be OK if we restricted our work to electrical = energy?

 

    = Juergen

------_=_NextPart_001_01CC73E7.C0F9C470-- From jparello@cisco.com Thu Sep 15 13:42: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 A036311E80A0 for ; Thu, 15 Sep 2011 13:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 8KHaoXt8Lrum for ; Thu, 15 Sep 2011 13:42:34 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 397AB11E807F for ; Thu, 15 Sep 2011 13:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=16588; q=dns/txt; s=iport; t=1316119487; x=1317329087; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=Fg0wxoSoC+nM1NUXOv0N1TkX+BeIq+UsqTJaywlPye4=; b=HRxTiy33rtLbdU6gIqALAiitRSjDN2wuUf9AWuElvjtExBOJgz511sDG MmA7SoFnPkoEJ/lcLfDhxz/FhRlDaHN55XTfMe5pr9L5Po7pOBaoZkRvZ 6BZpVzBcdnLcaaRYlWtS34NHo64T4SvdYm0204nmLdReRkW/cQQY9QwsY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscAAJVjck6rRDoI/2dsb2JhbAA5BgOCTZYGh1UBhy54gVMBAQEBAxIBCREDPgQXAgEIDgMEAQELBhcBBgFFCQgBAQQBEggBGYdZmDABniGDThmCLWAEh2+QfYwl X-IronPort-AV: E=Sophos;i="4.68,389,1312156800"; d="scan'208,217";a="2398493" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 15 Sep 2011 20:44:41 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8FKieh9011966; Thu, 15 Sep 2011 20:44:41 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); Thu, 15 Sep 2011 13:44:40 -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_01CC73E8.4A69A5BC" Date: Thu, 15 Sep 2011 13:42:18 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology comments Thread-Index: AcxMGghILmynbfGBTsCl3Abo8iVhTAnzUKDQ References: From: "John Parello (jparello)" To: "Bruce Nordman" , "eman mailing list" X-OriginalArrivalTime: 15 Sep 2011 20:44:40.0718 (UTC) FILETIME=[4A8BBAE0:01CC73E8] Subject: Re: [eman] Terminology comments 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, 15 Sep 2011 20:42:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC73E8.4A69A5BC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Bruce, =20 First I have to thank you very much for the references and comments. These were really helpful in getting bearings on the various standards and definitions. So wow thanks! =20 I think I have addressed all your items. The two I have to add and would like to discuss with you are: =20 Simple Device Classification =20 Take a look at the definition I used for electrical equipment and the derivations in the draft. Given the lexicon I have there what you like for Simple Device? Simple Energy Object etc? =20 For Classification I think I have that covered under the context definition. Please let me know if that will suffice. =20 The rest should be covered. =20 Thanks again for the really great guidance! Jp =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Bruce Nordman Sent: Tuesday, July 26, 2011 10:00 PM To: eman mailing list Subject: [eman] Terminology comments =20 John-- Thanks much for putting together the Terminology draft. General --Separate a definition from commentary on a definition. I am all in favor of including comments. A separate paragraph for each suffices to separate the definition and comments. Energy Monitoring=20 --Add "Classification," before context (this to speak to the topic of=20 "Identity" I have raised previously but which seems to be an overloaded term). Energy and Power --http://www.ietf.org/mail-archive/web/eman/current/msg00562.html I posted some IEEE definitions in this message. IEEE seems closer to energy than ISO. IEC is also an alternative. The IEC conveniently provides: http://www.electropedia.org/iev/iev.nsf/welcome?openform Unfortunately, the "energy" and "power definitions from this are not particularly useful, so I would stick with IEEE. It does define: "(electrical) energy" as "the magnitude of an electricity supply,=20 expressed in kilowatthours" Energy Control --"in order to optimize or ensure its efficiency" - this is one important reason for control but not the only one. I would move this to a comment and include other reasons, such as basic functionality, emergency conditions, etc. Energy Managed Object=20 --Change to "Powered Device". The definition says it is a device (and not a component). We care about it because it is powered. Energy Managed Object Identification --Move classification into its own term, separate from identity. As the definition notes, identity is unique (or at least ideally so) parameters. Classification is about membership in a group of devices. Energy Management Domain --Change to "Power Domain". Change definition to "An Power Domain is a=20 name or name space that groups Powered Devices according to common power delivery infrastructure so that they share a common fate and their consumption is aggregated." --A note should observe that devices with multiple power inlets will not have a defined Power Domain, but that each power interface will be labeled with the Power Domain that it is part of. --The example is consistent as-is with the above edits. Dependency Relationship --This definition says that an EMO may be a component, whereas the EMO definition says it is a device. Some EMAN capabilities apply to devices, some to components, and many to both. The term "entity" is suitable for referring to the combination of devices and components. We need to be clear about which we are covering when any of these terms are use. Power State --"A Power State can be viewed as" to "Setting a Power State is". --Or better yet, adopt the first sentence from IEEE 1621: 3.1.7 power state: A condition or mode of a device that broadly=20 characterizes its capabilities, power consumption, power indicator=20 coding, and responsiveness to input.=20 For reference, the rest of the definition is: Basic power states are on, sleep, and off. Devices may have multiple instances of one or more of the basic states (e.g. light sleep, deep sleep), and need not have any sleep states. All devices have at least=20 one on state, and at least one off state (unplugged). The term "power=20 mode" may be substituted and has identical meaning. Nameplate Power --In my line of work, this refers literally to the power level put on the nameplate on the back of the products, sometimes specified in W, and sometimes only in amps. I have often been told that this is sometimes the safety rating of the chassis, sometimes the safety rating of the power supply, or something else. I would go with some text saying it is the maximum power level declared by the manufacturer, leaving it open as to where to find it (since some products do not have nameplates). --The definition offered may be a useful value to have, but I would choose a different name. I assume that we will end up with a bunch more definitions. Following is one: Simple Device --A network-connected Powered Device with a single power inlet and no=20 power outlets. (The point of adding this definition is that the vast majority of energy use will be from devices like this but most complexity in EMAN is from non-simple devices). --=20 Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 ------_=_NextPart_001_01CC73E8.4A69A5BC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Bruce,

 

First I have to thank you very much for the references and comments. = These were really helpful in getting bearings on the various standards = and definitions. So wow thanks!

 

I think I have addressed all your items. The two I have to add and = would like to discuss with you are:

 

Simple Device

Classification

 

Take a look at the definition I used for electrical equipment and the = derivations in the draft. Given the lexicon I have there what you like = for Simple Device? Simple Energy Object etc?

 

For Classification I think I have that covered under the context = definition. Please let me know if that will = suffice.

 

The rest should be covered.

 

Thanks again for the really great guidance!

Jp

 

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Bruce Nordman
Sent: Tuesday, July 26, 2011 10:00 = PM
To: eman mailing list
Subject: [eman] Terminology = comments

 

John--

   Thanks much = for putting together the Terminology draft.

General
--Separate = a definition from commentary on a definition.  I am all in = favor
of including comments.  A separate paragraph for each = suffices to separate
the definition and comments.

Energy = Monitoring
--Add "Classification," before context (this to = speak to the topic of
"Identity" I have raised previously = but which seems to be an overloaded term).

Energy and = Power
--= http://www.ietf.org/mail-archive/web/eman/current/msg00562.html
I = posted some IEEE definitions in this message.  IEEE seems closer = to
energy than ISO.  IEC is also an alternative.  The IEC = conveniently provides:
  http://= www.electropedia.org/iev/iev.nsf/welcome?openform
Unfortunately, = the "energy" and "power definitions from this are = not
particularly useful, so I would stick with IEEE.  It does = define:
"(electrical) energy" as "the magnitude of an = electricity supply,
expressed in kilowatthours"

Energy = Control
--"in order to optimize or ensure its efficiency" - = this is one important reason
for control but not the only one.  = I would move this to a comment and include
other reasons, such as = basic functionality, emergency conditions, etc.

Energy Managed = Object
--Change to "Powered Device".  The definition = says it is a device (and not a
component).  We care about it = because it is powered.

Energy Managed Object = Identification
--Move classification into its own term, separate from = identity.  As the
definition notes, identity is unique (or at = least ideally so) parameters.
Classification is about membership in a = group of devices.

Energy Management Domain
--Change to = "Power Domain".  Change definition to "An Power = Domain is a
name or name space that groups Powered Devices according = to common
power delivery infrastructure so that they share a common = fate and
their consumption is aggregated."
--A note should = observe that devices with multiple power inlets will not
have a = defined Power Domain, but that each power interface will be = labeled
with the Power Domain that it is part of.
--The example is = consistent as-is with the above edits.

Dependency = Relationship
--This definition says that an EMO may be a component, = whereas the EMO
definition says it is a device.  Some EMAN = capabilities apply to devices,
some to components, and many to = both.  The term "entity" is suitable for
referring to = the combination of devices and components.  We need to be = clear
about which we are covering when any of these terms are = use.

Power State
--"A Power State can be viewed as" = to "Setting a Power State is".
--Or better yet, adopt the = first sentence from IEEE 1621:
    3.1.7 power state: = A condition or mode of a device that broadly
    = characterizes its capabilities, power consumption, power indicator =
    coding, and responsiveness to input.
For = reference, the rest of the definition is:
    Basic = power states are on, sleep, and off. Devices may have multiple =
    instances of one or more of the basic states = (e.g. light sleep, deep
    sleep), and need not have = any sleep states. All devices have at least
    one = on state, and at least one off state (unplugged). The term “power =
    mode” may be substituted and has identical = meaning.

Nameplate Power
--In my line of work, this refers = literally to the power level put on the
nameplate on the back of the = products, sometimes specified in W, and sometimes
only in amps.  = I have often been told that this is sometimes the safety
rating of = the chassis, sometimes the safety rating of the power supply,
or = something else.  I would go with some text saying it is the = maximum
power level declared by the manufacturer, leaving it open as = to where to
find it (since some products do not have = nameplates).
--The definition offered may be a useful value to have, = but I would
choose a different name.

I assume that we will end = up with a bunch more definitions.  Following
is = one:

Simple Device
--A network-connected Powered Device with a = single power inlet and no
power outlets.
(The point of adding = this definition is that the vast majority of energy
use will be from = devices like this but most complexity in EMAN is from = non-simple
devices).


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

------_=_NextPart_001_01CC73E8.4A69A5BC-- From jparello@cisco.com Thu Sep 15 13:46: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 B68CA11E80BA for ; Thu, 15 Sep 2011 13:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.793 X-Spam-Level: X-Spam-Status: No, score=-2.793 tagged_above=-999 required=5 tests=[AWL=-0.195, 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 D+4hznin00Nz for ; Thu, 15 Sep 2011 13:46:00 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8BB11E807F for ; Thu, 15 Sep 2011 13:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=9770; q=dns/txt; s=iport; t=1316119693; x=1317329293; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=5Fy5FC+WdjLHXDP/gqOaOYba30IcqLZsGq7xBFCaS1w=; b=INbgKQ3G8uMcxyVRs/39ausm6HIi+Onp9dydBwL/BKXopV19eyjWD7LL 0f9Ns5qJfnP83+v2eucL8fg3mY6wNWIpBJKIC3leo2yxaKiHXbUl9cDrb VeNKBQNl8fakhOeuxgRfk0/8JAFmcIXAAMeewz6Bo4KvHl/QjzFoqSPiX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYAAJVjck6rRDoI/2dsb2JhbABCgk2WBo8EeIFTAQEBAQMSAQkLBgM+GwIBCA4DBAEBCwYXAQYBRQkIAQEEARIIGqAJAZ4hhhRgBIdvkH2MJQ X-IronPort-AV: E=Sophos;i="4.68,389,1312156800"; d="scan'208,217";a="2399173" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 15 Sep 2011 20:48:13 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8FKmCdb014353; Thu, 15 Sep 2011 20:48:12 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); Thu, 15 Sep 2011 13:48: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_01CC73E8.C8BAC5F0" Date: Thu, 15 Sep 2011 13:46:03 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology: demand Thread-Index: AcxMbu8CnM7NyDNjS9y9GY47taA7vAneRXFg References: From: "John Parello (jparello)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 15 Sep 2011 20:48:12.0603 (UTC) FILETIME=[C8D6D0B0:01CC73E8] Subject: Re: [eman] Terminology: demand 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, 15 Sep 2011 20:46:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC73E8.C8BAC5F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 Demand is now taken from IEEE100. =20 =20 I was not trying to falsely or otherwise restrict an implementation. For version 1 I was more concerned about making sure I had captured all the items from the draft - the things to define. Cleaning up the definitions is this exercise. Nothing malicious intended. Ever. =20 There are various definitions and finding the right one took a new revision. That was there from the usage in the framework and charter etc. =20 Please do see the approach listed in the draft and the definition. =20 Thanks! Jp=20 =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Wednesday, July 27, 2011 8:07 AM To: eman mailing list Subject: [eman] Terminology: demand =20 Hi John, =20 In draft-parello-eman-definitions-00 you define demand as: =20 Demand=20 =20 Demand is an average of Power measurements over an interval(s)=20 =20 I disagree. Demand is a power measurement over a long time interval. There is no need for having multiple power measurements and averaging them. Of course I agree that this would be a way to implement demand measurements. But the definition of a term should not falsely restrict it to a certain implementation. Please let's take IEEE or other bodies dictionary terms. =20 "an interval(s)" --> "an interval" of time and typically expressed in kilowatt hours. This=20 measurement is significant because some utilities or energy=20 =20 remove "This measurement is significant because" =20 providers bill by Demand measurements as well as for maximum=20 Demand per billing periods. Power values may spike during=20 short-terms by devices, but Demand measurements recognize that=20 maximum Demand does not equal maximum Power during an interval.=20 =20 Thanks, =20 Juergen ------_=_NextPart_001_01CC73E8.C8BAC5F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

 

Demand is now taken from IEEE100. 

 

I was not trying to falsely or otherwise restrict an implementation. = For version 1 I was more concerned about making sure I had captured all = the items from the draft – the things to define. Cleaning up the = definitions is this exercise. Nothing malicious intended. = Ever.

 

There are various definitions and finding the right one took a new = revision. That was there from the usage in the framework and charter = etc.

 

Please do see the approach listed in the draft and the = definition.

 

Thanks!

Jp

 

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Juergen Quittek
Sent: Wednesday, July 27, 2011 8:07 = AM
To: eman mailing list
Subject: [eman] = Terminology: demand

 

Hi = John,

 

In draft-parello-eman-definitions-00 you define = demand as:

 

    =  Demand 

 

       Demand is an average of = Power measurements over an = interval(s) 

 

I = disagree. Demand is a power measurement over a long time interval. There = is no need for having multiple power measurements and averaging them. Of = course I agree that this would be a way to implement demand = measurements. But the definition of a term should not falsely restrict = it to a certain implementation.

Please let's take IEEE or other bodies dictionary = terms.

 

"an interval(s)" --> "an = interval"



       of time and typically = expressed in kilowatt hours. =  This 

  =      measurement is significant because some utilities or = energy 

 

remove "This measurement is significant = because"

 

       providers bill by Demand = measurements as well as for maximum 

       Demand per billing periods. =  Power values may spike during 

       short-terms by devices, but = Demand measurements recognize that 

       maximum Demand does not = equal maximum Power during an = interval. 

 

Thanks,

 

    = Juergen

------_=_NextPart_001_01CC73E8.C8BAC5F0-- From jparello@cisco.com Thu Sep 15 13:47:27 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 08A4C11E80C2 for ; Thu, 15 Sep 2011 13:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=-0.191, 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 z28xnqa8slnV for ; Thu, 15 Sep 2011 13:47:26 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5975511E80C1 for ; Thu, 15 Sep 2011 13:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=10093; q=dns/txt; s=iport; t=1316119779; x=1317329379; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=3/sedozDdDC+pDslkl0QbyjFFSSxFxYBjrmUxUAXGCk=; b=ZA4ciqMSCIJjBVz3AcdloCYXpB00G7MNtYLSuUcn731pVXjiR/EDJNv2 nKMvjTD0XuvWJ+LgT7dQCV6b+BoWBC5RnsTlpZckhKq2/SX3ydKDTE9dj RpavDl2lf39v702M+4OF1kjJUDe0MKP1vmN8Oir4VQGoA+xz5AAJiS7G7 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYAAK9kck6rRDoH/2dsb2JhbABCgk2WBo8EeIFTAQEBAQMBAQEPAQkRAz4XBAIBCA4DBAEBCwYXAQYBJh8JCAEBBAESCAEZh1mYJQGeHIYUYASHb5B9jCU X-IronPort-AV: E=Sophos;i="4.68,389,1312156800"; d="scan'208,217";a="2399525" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 15 Sep 2011 20:49:39 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8FKnd9R004507; Thu, 15 Sep 2011 20:49:39 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); Thu, 15 Sep 2011 13:49:38 -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_01CC73E8.FC2D2F20" Date: Thu, 15 Sep 2011 13:47:16 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] terminology and monitoring devices that generate energy Thread-Index: AcxNTs/cyrRL19JoTxagwmTdACzU1QAAHSmaCaZV1UA= References: From: "John Parello (jparello)" To: "Georgios Karagiannis" , "eman mailing list" X-OriginalArrivalTime: 15 Sep 2011 20:49:38.0976 (UTC) FILETIME=[FC524A00:01CC73E8] Subject: Re: [eman] terminology and monitoring devices that generate energy 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, 15 Sep 2011 20:47:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC73E8.FC2D2F20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable HI, =20 Please do let me know if I accurately covered your feedback =20 Thanks! Jp =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of John Parello (jparello) Sent: Thursday, July 28, 2011 10:54 AM To: Georgios Karagiannis; eman mailing list Subject: Re: [eman] terminology and monitoring devices that generate energy =20 =20 Thanks! I'll add that to the terminology draft and then back in the framework. Are you ok with the term Energy Managed Object? Jp -----Original Message----- From: eman-bounces@ietf.org on behalf of Georgios Karagiannis Sent: Thu 7/28/2011 10:50 AM To: eman mailing list Subject: [eman] terminology and monitoring devices that generate energy Hi all, I read the terminology provided in the following draft and I have one generic comment: http://www.ietf.org/id/draft-ietf-eman-framework-02.txt In almost all listed terms, energy monitoring & control refers only to monitoring the energy consumption. In my opinion it is also needed to also emphasize that energy monitoring & control is accomplished for energy consumption and/or energy generation. This addition will be needed in most of the provided terms, for example, this terminology modification is needed in the following terms: "Energy Management System (EnMS)", "Energy Management", "Energy Control", "Energy Managed Object", "Energy Aware Object", "Energy Management Domain". For example the modification on the definition of the "Energy Management Domain" could change from: Energy Management Domain An Energy Management Domain is a name or name space that logically groups Energy Managed Objects into a zone of Energy Management. Typically, this zone will have as members all Energy Managed Objects that are powered from the same electrical panel(s) for which there is a meter or sub meter. Into something like: Energy Management Domain An Energy Management Domain is a name or name space that logically groups Energy Managed Objects into a zone of Energy Management. Typically, this zone will have as members all Energy Managed Objects that are powered from the same electrical panel(s) and/or are supplying power to the same electrical panel(s) for which there is a meter or sub meter. Best regards, Georgios _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman ------_=_NextPart_001_01CC73E8.FC2D2F20 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [eman] terminology and monitoring devices = that generate energy

HI,

 

Please do let me know if I accurately covered your = feedback

 

Thanks!

Jp

 

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = John Parello (jparello)
Sent: Thursday, July 28, 2011 = 10:54 AM
To: Georgios Karagiannis; eman mailing = list
Subject: Re: [eman] terminology and monitoring devices = that generate energy

 

 

Thanks!

I'll add that to the = terminology draft and then back in the framework.

Are you ok with = the term Energy Managed Object?

Jp

-----Original = Message-----
From: eman-bounces@ietf.org on behalf of Georgios = Karagiannis
Sent: Thu 7/28/2011 10:50 AM
To: eman mailing = list
Subject: [eman] terminology and monitoring devices that generate = energy

Hi all,

I read the terminology provided in the = following  draft and I have one
generic comment:

http://w= ww.ietf.org/id/draft-ietf-eman-framework-02.txt


In almost = all listed terms, energy monitoring & control refers only = to
monitoring the energy consumption.

In my opinion it is also = needed to also emphasize that energy monitoring
& control is = accomplished for energy consumption and/or = energy
generation.

This addition will be needed in most of the = provided terms, for example,
this terminology modification is needed = in the following terms:

"Energy Management System = (EnMS)", "Energy Management", = "Energy
Control", "Energy Managed Object", = "Energy Aware Object", "Energy
Management = Domain".

For example the modification on the definition of = the "Energy Management
Domain" could change = from:

  Energy Management = Domain

        An Energy = Management Domain is a name or name space = that
        logically groups = Energy Managed Objects into a zone of = Energy
        Management.  = Typically, this zone will have as members = all
        Energy Managed Objects = that are powered from the same = electrical
        panel(s) for = which there is a meter or sub meter.

Into something = like:


  Energy Management = Domain

        An Energy = Management Domain is a name or name space = that
        logically groups = Energy Managed Objects into a zone of = Energy
        Management.  = Typically, this zone will have as members = all
        Energy Managed Objects = that are powered from the same = electrical
        panel(s) and/or = are supplying power to the same = electrical
panel(s)
        for = which there is a meter or sub meter.


Best = regards,
Georgios
_______________________________________________eman mailing list
eman@ietf.org
https://www.ietf.org/= mailman/listinfo/eman

------_=_NextPart_001_01CC73E8.FC2D2F20-- From jparello@cisco.com Thu Sep 15 13:49: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 5672D11E80C3 for ; Thu, 15 Sep 2011 13:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[AWL=-0.186, 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 OdQFYdhywjzV for ; Thu, 15 Sep 2011 13:49:39 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 835E011E80C2 for ; Thu, 15 Sep 2011 13:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=6330; q=dns/txt; s=iport; t=1316119912; x=1317329512; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=SS1/bfzOIcdbmYXT4gpHp7sqMsny5hipXd0NCJtjUZY=; b=iuji3Ec4uTv1ktmP0Sc1dc3zeiSHjai/FJ19bNekPOGe4SDWddww4U6u t0eA6XsnakGNBh6kS9wk+gy1opho7x2eFJEn1jK+gqJ0wFzaFZpavHFon AeAv5qPnO8rz3FsE4m/RhfMVsklYSU5Nm14f7+hjQKDPyc0CgkDDVXEOH 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYAAK9kck6rRDoI/2dsb2JhbABCmFOPBHiBUwEBAQEDAQEBCwQBHQorCQQTBAIBCA4DBAEBCwYXAQYBJh8JCAEBBAESCBqHWZglAZ4chhRgBIdvkH2MJQ X-IronPort-AV: E=Sophos;i="4.68,389,1312156800"; d="scan'208";a="2401019" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 15 Sep 2011 20:51:52 +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 p8FKpqEl016726; Thu, 15 Sep 2011 20:51:52 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, 15 Sep 2011 13:51:51 -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: Thu, 15 Sep 2011 13:49:35 -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: AcxaGcIFrOwvQlhXSPudor0b7Af4dgZzuy9g References: <7758B005-2F71-4F35-A07F-F28CC54724C5@quittek.at> From: "John Parello (jparello)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 15 Sep 2011 20:51:51.0879 (UTC) FILETIME=[4B89AD70:01CC73E9] 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: Thu, 15 Sep 2011 20:49:40 -0000 Hi, For states I put the terms Power State and Power Series to reflect what we discussed at the last two meetings. I don't see a distinction between the state as they refer to a battery or a simple device. As we discussed at IETF81 (I think Juergen S brought it up) why not keep the same information for the battery. I kept it simple in the definition and if there's new terms from this thread please do let me know. 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 jparello@cisco.com Thu Sep 15 13:51:06 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 5399B11E80C1 for ; Thu, 15 Sep 2011 13:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.781 X-Spam-Level: X-Spam-Status: No, score=-2.781 tagged_above=-999 required=5 tests=[AWL=-0.182, 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 Qb5qsjalRm86 for ; Thu, 15 Sep 2011 13:51:05 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B257311E807F for ; Thu, 15 Sep 2011 13:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=4281; q=dns/txt; s=iport; t=1316119998; x=1317329598; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=sjlDa68JvVDDSvcGK23EbIFFPcGhlCt7ULHY1jo70/A=; b=hvpHiFcE85n73IyDCLDMEpzeS9MV4QNUtSb43ljodOgUIrdUmkXQmmkm G9RJAkl7CKEeL4JB9GblzuYNeRMBK381Iyks2Ky0P/n2DSyz/slaGRo82 O3vrm91aqFB4Dp56oCZC283QoU81mAXndcBKYwjoqzs/ljZCubtWo+VuX g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYAABhlck6rRDoH/2dsb2JhbABCmFOPBHiBUwEBAQEDAQEBDwEdCjQXBAIBCA4DBAEBCwYXAQYBJh8JCAEBBAESCBqHWZgmAZ4chhRgBIdvkH2MJQ X-IronPort-AV: E=Sophos;i="4.68,389,1312156800"; d="scan'208";a="2393921" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 15 Sep 2011 20:53:18 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8FKrIsT007093; Thu, 15 Sep 2011 20:53:18 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); Thu, 15 Sep 2011 13:53:18 -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: Thu, 15 Sep 2011 13:51:02 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] terminology: power quality Thread-Index: AcxbiBGXYSGtWg64Rza+2xJRWVLdTAAABOHgBhg3a3A= References: From: "John Parello (jparello)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 15 Sep 2011 20:53:18.0377 (UTC) FILETIME=[7F183990:01CC73E9] 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: Thu, 15 Sep 2011 20:51:06 -0000 For Terminology I defined Power Quality but left the items and attributes of power quality out. This is in line with the referenced definition. I think the ODVA CIP spec has a wonderful list of power quality attributes and given that groups experience I think that's a great list of attributes to use or at least start with. Jp -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of John Parello (jparello) Sent: Monday, August 15, 2011 1:23 PM To: Juergen Quittek; eman mailing list Subject: Re: [eman] terminology: power quality 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 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From jparello@cisco.com Thu Sep 15 13:51: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 4B84321F8634 for ; Thu, 15 Sep 2011 13:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=-0.178, 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 tGlC08qg4Dm2 for ; Thu, 15 Sep 2011 13:51:42 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6280821F8568 for ; Thu, 15 Sep 2011 13:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=2616; q=dns/txt; s=iport; t=1316120034; x=1317329634; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=QFoK45ZLm12tK/rDqyge6Km1CrqRxTS6BDoCTRS5ry0=; b=W7F/AxiLXi7HUdD55uG4627R4DtTM3eSRRaXYhkXgnEM52LMw6nhaNG1 u6Q4omPVOzf3h4cghyDSoynEi0OZEbByLrAFk6i54nYOBCekyMpFt/p61 So3Podb1dXJgKFFDA9GO30c6YCbPr2V8avDVQkt04wTVkmNYT/bwZfJGZ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEBAK9kck6rRDoJ/2dsb2JhbABChFWTfkONNYEMeIFTAQEBAQMSARANBEMOBAIBGQQBAQMCBgYXAQICAgEBRAkIAQEEEwgan34BjDmRY4EshDcxYASHb5B9jCU X-IronPort-AV: E=Sophos;i="4.68,389,1312156800"; d="scan'208";a="2401385" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 15 Sep 2011 20:53:54 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8FKrqvA015832 for ; Thu, 15 Sep 2011 20:53:54 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); Thu, 15 Sep 2011 13:53:53 -0700 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, 15 Sep 2011 13:51:38 -0700 Message-ID: In-Reply-To: <20110915165320.10444.23015.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-parello-eman-definitions-01.txt Thread-Index: AcxzyFM87dec1B7BQx2Yfbmb75tyMAAHVbiw References: <20110915165320.10444.23015.idtracker@ietfa.amsl.com> From: "John Parello (jparello)" To: X-OriginalArrivalTime: 15 Sep 2011 20:53:53.0954 (UTC) FILETIME=[944CD820:01CC73E9] Subject: [eman] New Version Notification for draft-parello-eman-definitions-01.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, 15 Sep 2011 20:51:43 -0000 SGksDQoNClBsZWFzZSBmaW5kIHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgZGVmaW5pdGlvbnMgZHJh ZnQuIEFwb2xvZ2llcyBhcyB0aGUgdGl0bGUgaXMgbGlzdGVkIGluY29ycmVjdGx5Lg0KDQpJIHVw ZGF0ZWQgaXQgYmFzZWQgb24gYWxsIHlvdXIgZmVlZGJhY2suIFRoZSBnZW5lcmFsIGFwcHJvYWNo IHdhcyB0byB1c2UgZGVmaW5pdGlvbnMgZnJvbSBJRUVFLCBJRUMgYW5kIHRoZSBJU08gaW4gdGhh dCBvcmRlci4gV2hlcmUgdGVybXMgaGFkIGR1YWwgbWVhbmluZyBpbiB0aGUgc3RhbmRhcmRzIEkg aW5jbHVkZWQgYm90aCB3aXRoIGNvbW1lbnRzIHNheWluZyB0aGUgcHJlZmVycmVkIGV0Yy4gDQoN ClBsZWFzZSBub3QgaWYgYSBkZWZpbml0aW9uIGlzIHRha2VuIHZlcmJhdGltIGZyb20gYSByZWZl cmVuY2UgYW55IGRpc2N1c3Npb24gb24gdGhhdCB3b3JkaW5nIHNob3VsZCBiZSBrZXB0IHRvIHVz aW5nIGFuIGFsdGVybmF0ZSBkZWZpbml0aW9uLiBJdGVtcyB3ZSBkZWZpbmUgaW4gRU1BTiBhcmUg d2lkZSBvcGVuIG9mIGNvdXJzZSBidXQgc3RhbmRhcmRzIGJhc2VkIHRlcm1zIHNob3VsZCByZW1h aW4gYXMgc3VjaC4NCg0KUGxlYXNlIGRvIGdpdmUgZmVlZGJhY2sgYW5kIGZlZWwgZnJlZSB0byB0 b3NzIG92ZXIgYW55IHRlcm1zIGZyb20geW91ciBkcmFmdHMgdGhhdCB5b3UgdGhpbmsgbmVlZCB0 byBiZSBpbmNsdWRlZC4gSGFwcHkgdG8gYWRkIHRoZW0uDQoNClRoYW5rcyENCkpwDQoNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBTZXB0 ZW1iZXIgMTUsIDIwMTEgOTo1MyBBTQ0KVG86IEpvaG4gUGFyZWxsbyAoanBhcmVsbG8pDQpDYzog Sm9obiBQYXJlbGxvIChqcGFyZWxsbykNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtcGFyZWxsby1lbWFuLWRlZmluaXRpb25zLTAxLnR4dA0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtcGFyZWxsby1lbWFuLWRlZmluaXRpb25zLTAxLnR4dCBoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEpvaG4gUGFyZWxsbyBhbmQgcG9zdGVkIHRvIHRo ZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtcGFyZWxsby1lbWFuLWRlZmlu aXRpb25zDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBFbmVyZ3kgTWFuYWdlbWVudCBGcmFtZXdv cmsNCkNyZWF0aW9uIGRhdGU6CSAyMDExLTA5LTE1DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1p c3Npb24NCk51bWJlciBvZiBwYWdlczogMTQNCg0KQWJzdHJhY3Q6DQogICAgICAgIFRoaXMgZG9j dW1lbnQgY29udGFpbnMgZGVmaW5pdGlvbnMgYW5kIHRlcm1zIHVzZWQgaW4gdGhlIEVuZXJneQ0K ICAgICAgICBNYW5hZ2VtZW50IFdvcmtpbmcgR3JvdXAuIEVhY2ggdGVybSBjb250YWlucyBhIGRl ZmluaXRpb24ocyksDQogICAgICAgIGV4YW1wbGUsIGFuZCByZWZlcmVuY2UgdG8gYSBub3JtYXRp dmUsIGluZm9ybWF0aXZlIG9yIHdlbGwga25vdw0KICAgICAgICBzb3VyY2UuIFRlcm1zIG9yaWdp bmF0aW5nIGluIHRoaXMgZHJhZnQgc2hvdWxkIGJlIGVpdGhlcg0KICAgICAgICBjb21wb3NlZCBv ZiBvciBhZGFwdGVkIGZyb20gb3RoZXIgdGVybXMgaW4gdGhlIGRyYWZ0IHdpdGggYQ0KICAgICAg ICBzb3VyY2UuIFRoZSBkZWZpbmVkIHRlcm1zIHdpbGwgdGhlbiBiZSB1c2VkIGluIG90aGVyIGRy YWZ0cyBhcw0KICAgICAgICBkZWZpbmVkIGhlcmUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From bclaise@cisco.com Mon Sep 19 06:22: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 7565F21F8B92 for ; Mon, 19 Sep 2011 06:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 vDAuM8cKppLU for ; Mon, 19 Sep 2011 06:22: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 8F8A721F8B90 for ; Mon, 19 Sep 2011 06:22: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 p8JDOZ4V024732 for ; Mon, 19 Sep 2011 15:24:35 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8JDOYQO023706 for ; Mon, 19 Sep 2011 15:24:34 +0200 (CEST) Message-ID: <4E774296.507@cisco.com> Date: Mon, 19 Sep 2011 15:24:38 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: eman mailing list References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------020605030705050402010402" Subject: [eman] Fwd: FW: Nomcom 2011-2012: Second Call for Nominations 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, 19 Sep 2011 13:22:17 -0000 This is a multi-part message in MIME format. --------------020605030705050402010402 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI. Regards, Benoit. -------- Original Message -------- Hi OPS chairs, Please distribute this further to your working groups. Proposing the best candidates for the open positions in the IETF leadership and supporting NomCom with your comments about the candidates and proposals is of great importance for the IETF. Thanks and Regards, Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Sunday, September 18, 2011 5:06 AM To: IETF Announcement list Cc: ietf@ietf.org Subject: Nomcom 2011-2012: Second Call for Nominations Hi All, We are halfway through the nomination period (it ends on October 2, 2011) and we need more nominees than we have received so far. We appreciate the folks that have taken the time to nominate people and those who have accepted so far. But the fact remains that the number of nominations have been below average and the acceptance rates of those nominated has also been low. We need **YOUR** input and participation! We cannot properly execute the task of selecting the best candidates for these positions with so few nominations and acceptances. So, please consider making nominations for the open positions, in particular those for which we have so few nominations it takes just a few minutes of your time. Right now, we just need the names/email addresses. Why do we need more nominations? Well, even if you think a willing incumbent is doing a very good job and should be returned, his or her ability to serve again might be impacted by unforeseen circumstances between now and March. NomCom needs to consider multiple nominees to be prepared in the event one or more candidates is unable to serve come next March and to ensure we have chosen the best candidate. There are several ways you can help the Nomcom - You can nominate yourself. - You can nominate someone you know whom you think would do a good job. Don't worry about whether they might already be nominated. We would much prefer to receive the same nomination several times rather than miss a good person we should consider. How to submit Nominations: -------------------------- The list of positions we need to fill, and the provided Job Descriptions, and forms for nominations, can be found in the call for nominations at: https://datatracker.ietf.org/ann/nomcom/3049/ You can enter a nomination by going to the following URL: https://www.ietf.org/group/nomcom/2011/nominate You can also nominate someone by sending an email to nomcom11@ietf.org and giving us their name, email address and the open position you are nominating them for. We will take care of the rest. If you are asked for a user name and password, use an existing ietf login and password. If you need a login and password, request one from the following URL: https://datatracker.ietf.org/accounts/create/ Open List: ---------- As you already know, NomCom 2011-2012 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. Feedback Collection: -------------------- The open list is currently available on the Nomcom page and the entire community is invited to provide feedback on all nominees. You can provide your comments on all willing nominees at the following URL: https://www.ietf.org/group/nomcom/2011/input/ Suresh Krishnan Chair, NomCom 2011-2012 nomcom-chair@ietf.org suresh.krishnan@ericsson.com --------------020605030705050402010402 Content-Type: text/plain; name="ATT6759294.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ATT6759294.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklFVEYt QW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2UNCg== --------------020605030705050402010402--