From moulchan@cisco.com Fri Nov 2 04:13:05 2012 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 4A98921F99AD for ; Fri, 2 Nov 2012 04:13:05 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maECWB6dS-cf for ; Fri, 2 Nov 2012 04:13:04 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4529721F99AB for ; Fri, 2 Nov 2012 04:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5011; q=dns/txt; s=iport; t=1351854784; x=1353064384; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qsjxm68cOnhaYE/P4bRqCjYNTr7HePZAKpm7XuwspQk=; b=dZji9ldYRb8rV4v57uyQokXTbA4oS8ji45+4OoU0H4Ml/A0xczEePZxY TAXuYov/3nwQkOcJFKlOgpg2a48f4Hglzwh5BWyyU9iX+XDZZ0dGfZE74 +Ax+UXMPJPXB1xncihUeb+XfzwaEsmRSLFAjm6gNOH4eHBJfImmOXweVD U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACWqk1CtJXG8/2dsb2JhbABBA8M4gQiCHgEBAQQSASc/DAICAgEIDgIBBAEBAQoUCQcbFxQJCAIEAQ0FCBqHaJtsoAsEi30agniCSGEDpFKBa4JvgWQXHg X-IronPort-AV: E=Sophos;i="4.80,699,1344211200"; d="scan'208";a="138099445" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 02 Nov 2012 11:13:03 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA2BD3sw016758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 11:13:03 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.234]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 06:13:03 -0500 From: "Mouli Chandramouli (moulchan)" To: Juergen Schoenwaelder , "Minoru.Teraoka@jp.yokogawa.com" Thread-Topic: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt Thread-Index: AQHNX0MUsD8/DD8mNE6B4Tg4arITD5cjx/sQgCNv8lGAbqwo4IAUdw2ggABXWACAABjqAIAAB70AgAxAvmA= Date: Fri, 2 Nov 2012 11:13:02 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237EA32A@xmb-rcd-x08.cisco.com> References: <20120711085632.3934.80262.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA402D2E6@xmb-rcd-x08.cisco.com> <92A5C8A0221B31479EB7913C528ACC59017DA2DC1FD5@EXMAIL01.jp.ykgw.net> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237DA2B6@xmb-rcd-x08.cisco.com> <92A5C8A0221B31479EB7913C528ACC59017DA7A04462@EXMAIL01.jp.ykgw.net> <20121025085616.GB85599@elstar.local> <92A5C8A0221B31479EB7913C528ACC59017DA7A044BA@EXMAIL01.jp.ykgw.net> <20121025105307.GA85900@elstar.local> In-Reply-To: <20121025105307.GA85900@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.140] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--73.687600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 11:13:05 -0000 Juergen, Agreed, Thanks this is really a TimeStamp object - TimeTicks measures the t= ime between epochs (which would be the window length). =20 sysUpTime shall be reset when the device is rebooted, the table is also des= troyed and a new table shall be created when the device is rebooted. Thanks Mouli -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, October 25, 2012 4:23 PM To: Minoru.Teraoka@jp.yokogawa.com Cc: Mouli Chandramouli (moulchan); eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.tx= t My point here was that TimeTicks does not imply sysUpTime. I did not look at the object in question. Now that I do that, I read: eoEnergyCollectionStartTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of seconds" MAX-ACCESS not-accessible STATUS current DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized, as specified in the sysUpTime [RFC3418]. This object is useful for reference of interval periods for which the energy is measured." ::=3D { eoEnergyEntry 1 } This really seems to be a TimeStamp object. I do agree that using sysUpTime as an epoch needs to be carefully thought through since any discontinuity that resets sysUpTime makes the value of this object meaningless. I am also not sure I understand the meaning of "for reference of interval periods". /js On Thu, Oct 25, 2012 at 07:25:26PM +0900, Minoru.Teraoka@jp.yokogawa.com wr= ote: > Hello Juergen, >=20 > I see I did not understand correctly about TimeTicks. > In EoEnergyCollectionStartTime, it begins from 0 at the time of an > observation start. What I just wanted to say is that if there is an entr= y > that updated maximum 16 months ago in the table, old and new index may ex= ist. > Is it too strict? >=20 > Best regards, > Minoru > -- > Minoru Teraoka > Yokogawa Electric Corporation >=20 >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, October 25, 2012 5:56 PM > > To: Teraoka, Minoru (Minoru.Teraoka@jp.yokogawa.com) > > Cc: moulchan@cisco.com; eman@ietf.org > > Subject: Re: [eman] I-D Action: > > draft-ietf-eman-energy-monitoring-mib-03.txt > > > > On Thu, Oct 25, 2012 at 05:49:43PM +0900, Minoru.Teraoka@jp.yokogawa.co= m > > wrote: > > > Hello Mouli, > > > > > > Thank you for your comments. I understood the operation of the table= . > > > By the way, I'm concerned about using eoEnergyCollectionStartTime > > > (SYNTAX TimeTicks) as an index of eoEnergyTable. > > > Description of the eoEnergyParametersIntervalNumber object says that > > > when the eoEnergyMaxConsumed and/or eoEnergyMaxProduced are in (one > > > of) the two oldest measurement(s), they are left untouched and the > > > next oldest measurement is replaced. When sysUpTime wraps, it may be > > > possible that a value of eoEnergyCollectionStartTime repeats. > > > I'm sorry if I have not been clear. > > > > > > > RFC 2578: > > > > 7.1.8. TimeTicks > > > > The TimeTicks type represents a non-negative integer which represent= s > > the time, modulo 2^32 (4294967296 decimal), in hundredths of a secon= d > > between two epochs. When objects are defined which use this ASN.1 > > type, the description of the object identifies both of the reference > > epochs. > > > > For example, [3] defines the TimeStamp textual convention which is > > based on the TimeTicks type. With a TimeStamp, the first reference > > epoch is defined as the time when sysUpTime [5] was zero, and the > > second reference epoch is defined as the current value of sysUpTime. > > > > Note that TimeTicks itself is not linked to sysUpTime. TimeStamp is but > > TimeTicks is not. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 >=20 > ----- > CONFIDENTIAL: This e-mail may contain information that is confidential or= otherwise protected from disclosure and intended only for the party to who= m it is addressed. If you are not the intended recipient, please notify the= sender by return and delete this e-mail. You are hereby formally advised t= hat any unauthorized use, disclosure or copying of this email is strictly p= rohibited and may be unlawful. --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Nov 2 15:09:25 2012 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 D12171F0C8C for ; Fri, 2 Nov 2012 15:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9s+qwwx1yQ2 for ; Fri, 2 Nov 2012 15:09:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 194E71F0C80 for ; Fri, 2 Nov 2012 15:09:25 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CDD5320DC8; Fri, 2 Nov 2012 23:09:23 +0100 (CET) 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 xktCLT4IraJW; Fri, 2 Nov 2012 23:09:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A39FC20DBC; Fri, 2 Nov 2012 23:09:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8AFD22296CA2; Fri, 2 Nov 2012 23:09:23 +0100 (CET) Date: Fri, 2 Nov 2012 23:09:23 +0100 From: Juergen Schoenwaelder To: "Mouli Chandramouli (moulchan)" Message-ID: <20121102220922.GA5118@elstar.local> Mail-Followup-To: "Mouli Chandramouli (moulchan)" , "Minoru.Teraoka@jp.yokogawa.com" , "eman@ietf.org" References: <20120711085632.3934.80262.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA402D2E6@xmb-rcd-x08.cisco.com> <92A5C8A0221B31479EB7913C528ACC59017DA2DC1FD5@EXMAIL01.jp.ykgw.net> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237DA2B6@xmb-rcd-x08.cisco.com> <92A5C8A0221B31479EB7913C528ACC59017DA7A04462@EXMAIL01.jp.ykgw.net> <20121025085616.GB85599@elstar.local> <92A5C8A0221B31479EB7913C528ACC59017DA7A044BA@EXMAIL01.jp.ykgw.net> <20121025105307.GA85900@elstar.local> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237EA32A@xmb-rcd-x08.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237EA32A@xmb-rcd-x08.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "eman@ietf.org" Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt 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 Nov 2012 22:09:25 -0000 On Fri, Nov 02, 2012 at 11:13:02AM +0000, Mouli Chandramouli (moulchan) wrote: > Juergen, > > Agreed, Thanks this is really a TimeStamp object - TimeTicks measures the time between epochs (which would be the window length). > > sysUpTime shall be reset when the device is rebooted, the table is also destroyed and a new table shall be created when the device is rebooted. > Note that sysUpTime may be reset at other occasions as well. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From karagian@cs.utwente.nl Sun Nov 4 12:45:52 2012 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 9984721F88C7 for ; Sun, 4 Nov 2012 12:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qs8AypSgApxS for ; Sun, 4 Nov 2012 12:45:52 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id B8C1121F88C1 for ; Sun, 4 Nov 2012 12:45:51 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 4 Nov 2012 21:45:53 +0100 Received: from EXMBX01.ad.utwente.nl ([169.254.1.130]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0318.004; Sun, 4 Nov 2012 21:45:49 +0100 From: To: , , Thread-Topic: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? Thread-Index: AQHNm5gxMY4OvKo9wEWkT7oEBiVGLZfJXYkAgBEEkyg= Date: Sun, 4 Nov 2012 20:45:48 +0000 Message-ID: References: <064.e0edb6f25a043000c8d23b23fb4ed6cf@trac.tools.ietf.org>, <079.bcac537536af509ab30e5d720bdf398d@trac.tools.ietf.org> In-Reply-To: <079.bcac537536af509ab30e5d720bdf398d@trac.tools.ietf.org> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.67.215] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman@ietf.org Subject: Re: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:45:52 -0000 Hi all, I assume that this comment refers to the situation where bidirectional powe= r interfaces are used? I agre that this the parent/child energy object relationship needs to be de= fined for the situation that bidirectional power interfaces are used! Best regards, Georgios ________________________________________ Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens eman issue tracke= r [trac+eman@grenache.tools.ietf.org] Verzonden: donderdag 25 oktober 2012 4:47 To: n.brownlee@auckland.ac.nz; brads@coraid.com Cc: eman@ietf.org Onderwerp: Re: [eman] #16: c. What does parent/child mean when the directio= n of power flow between two devices can reverse? #16: c. What does parent/child mean when the direction of power flow betwe= en two devices can reverse? Comment (by brads@=85): I presume the the question regards when a child uses its battery to power a parent. This seems a limited duration use case that doesn't change the normal flow of power from parent to child. -- --------------------------+------------------------- Reporter: n.brownlee@=85 | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman= From karagian@cs.utwente.nl Sun Nov 4 13:23:19 2012 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 E807321F84D2 for ; Sun, 4 Nov 2012 13:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QkZtkxepGgE for ; Sun, 4 Nov 2012 13:23:19 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id E6BB021F84C8 for ; Sun, 4 Nov 2012 13:23:18 -0800 (PST) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 4 Nov 2012 22:23:10 +0100 Received: from EXMBX01.ad.utwente.nl ([169.254.1.130]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0318.004; Sun, 4 Nov 2012 22:23:09 +0100 From: To: , Thread-Topic: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt Thread-Index: AQHNrfwHOIdDW3o/RUm4TZcvAYNrkpfEtbEAgBWRPWY= Date: Sun, 4 Nov 2012 21:23:08 +0000 Message-ID: References: <20121019131631.23306.94125.idtracker@ietfa.amsl.com>, <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237E2F03@xmb-rcd-x08.cisco.com> In-Reply-To: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237E2F03@xmb-rcd-x08.cisco.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.67.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.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: Sun, 04 Nov 2012 21:23:20 -0000 Hi all, >From what I remember, during the IETF in Vancouver, it was acceptable to th= e WG to integrate the new use case that focusses on "Neighborhood Energy Ga= teways", see the description of this use case in the email that I sent to t= he list on the 24th of June 2012 with the Home Energy Gateways use case (Se= ction 2.7). Mouli, is it possible to add the following (or a modified version of this) = paragraph in Section 2.7: "This use case can also be applied in neighborhoods, where the eman target = devices are neighborhood energy gateways. These neighborhood energy gateway= s can collect power consumption of a home via the home energy gateway and p= ossibly report the metering reading to the utility. " Best regards, Georgios ________________________________________ Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens Mouli Chandramoul= i (moulchan) [moulchan@cisco.com] Verzonden: maandag 22 oktober 2012 7:53 To: eman@ietf.org Onderwerp: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-0= 2.txt Hello all, An updated version of the applicability statement has been submitted. Several editorial changes to improve the readability of the draft and also = consolidating the section on the related standards from the requirements to= applicability statement http://www.ietf.org/mail-archive/web/eman/current/msg01595.html The only remaining open issue is - the applicability of ASHRAE 201P standa= rds to EMAN. Are any concepts that can be reused ? which we hope address after the WG meeting. Please send your comments. Thanks Brad, Bruce and Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Friday, October 19, 2012 6:47 PM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Energy Management (EMAN) Applicability Statement Author(s) : Brad Schoening Mouli Chandramouli Bruce Nordman Filename : draft-ietf-eman-applicability-statement-02.txt Pages : 30 Date : 2012-10-19 Abstract: The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN framework to a variety of scenarios. This document lists use cases and target devices that can potentially implement the EMAN framework and associated SNMP MIB modules. These use cases are useful for identifying requirements for the framework and MIBs. Further, we describe the relationship of the EMAN framework to relevant other energy monitoring standards and architectures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-applicability-statement-= 02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 karagian@cs.utwente.nl Sun Nov 4 13:52:46 2012 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 4731F21F8667 for ; Sun, 4 Nov 2012 13:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.461 X-Spam-Level: X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk+lyzKsc86P for ; Sun, 4 Nov 2012 13:52:40 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6360021F85FD for ; Sun, 4 Nov 2012 13:52:40 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 4 Nov 2012 22:52:41 +0100 Received: from EXMBX01.ad.utwente.nl ([169.254.1.130]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0318.004; Sun, 4 Nov 2012 22:52:39 +0100 From: To: Thread-Topic: [eman] comments on draft-ietf-eman-requirements-08.txt Thread-Index: AQHNb3t8cLxl7ZurrkC784Qyz3NiY5dECFaAgAE7m1CAlYlCaQ== Date: Sun, 4 Nov 2012 21:52:39 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.67.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] comments on draft-ietf-eman-requirements-08.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: Sun, 04 Nov 2012 21:52:46 -0000 Hi all, I promissed to send more details on synchrophasors, see below! Synchronized phasor measurements are used mainly for power system model val= idation, postevent analysis, real-time display, and other similar activities. They are however= , increasingly contributing to the reliable and economical operation of power systems as real-time control and= protection schemes. =20 This is in line with IEC standardization, since the applicability of synchr= ophasors is currently included into IEC 61850. More details on synchrophasors can be found via: http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.111.1663&rep=3Dr= ep1&type=3Dpdf Best regards, Georgios ________________________________________ Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens karagian@cs.utwen= te.nl [karagian@cs.utwente.nl] Verzonden: woensdag 1 augustus 2012 20:17 To: brads@coraid.com; Quittek@neclab.eu; eman@ietf.org Onderwerp: Re: [eman] comments on draft-ietf-eman-requirements-08.txt Hi Brad, The IEEE C37.118 standard specifies the monitoring and the communication of= the synchrophasor measurements from Phasor Measurement Units (PMUs) towards the= phasor data concentrators (PDCs). By using the received synchrophasor measurement data and information (via t= he PDCs) the grid operators will be able to have better visibility of power= grid operations and respond to grid disturbances earlier to prevent major = blackouts. >From IEEE C37.118 we could use the specification related to monitoring. Best regards, Georgios ________________________________________ Van: Brad Schoening [brads@coraid.com] Verzonden: woensdag 1 augustus 2012 3:24 Aan: Karagiannis, G. (EWI); Quittek@neclab.eu; eman@ietf.org Onderwerp: Re: [eman] comments on draft-ietf-eman-requirements-08.txt Hi Georgios, The standard you reference, IEEE 37.118, appears to involve a special communications protocol with phasor measurement units (PMUs). Could you provide a little more background on this standard and how it would be applicable in a SNMP management environment? Most importantly, could not synchrophasor data simply roll up and be reported as an aggregate in EMAN? In EMAN, we have tried to provide general use case that cover many different underlying technologies for acquiring the data. By encapsulating the specifics of the underlying protocols, we simplify the reporting and control. Regarding bi-directional power, I believe we cover that by allowing meters to report consumed, exported, and net energy. Best Regards, Brad Schoening On 7/31/12 5:34 PM, "karagian@cs.utwente.nl" wrote: >Hi Juergen, Hi all, > >I have read the last version of the requirements draft and I have two >main comments! > >Comment_1: Section 5.3, page 14, specifies that: >"Power monitoring should be in line with existing standards, such as >[IEC.61850-7-4]." > >What I miss is a reference to IEEE 37.118-2005 [IEEE37118], which is a >monitoring standard based on synchrophasors, like Phasor Measurement >Units (PMUs). >Please note that an ongoing IEC standardization activity was defined that >is focusing on the integration of this type of monitoring into IEC 61850, >see reference [Mar11] below. >Note also that a reference to IEEE37118 is not included in the >Applicability statement draft. I will be happy to provide input on this >standard. > >[IEEE37118] IEEE 37.118-2005, "IEEE Standard for Synchrophasors for Power >System", IEEE standard, 2005. > >[Mart11] K. E. Martin, "Synchrophasor Standards Development - IEEE >C37.118 & IEC 61850", Proc. of 44th Hawaii International Conference on >System Sciences (ICSS'2011), pp. 1-8, 2011. > >Comment_2: The requirements draft is not mentioning bidirectional power >interfaces, which I think is needed. For motivation of this argument, >please see section 4.1.4 of the eman framework draft. > >Best regards, >Georgios > > >________________________________________ >Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens Juergen Quittek >[Quittek@neclab.eu] >Verzonden: maandag 16 juli 2012 15:50 >Aan: eman mailing list >Onderwerp: [eman] FW: New Version Notification for >draft-ietf-eman-requirements-08.txt > >Dear all, > >This update only brings a small change in terminology. >We found that the term "Powered Entity" is not appropriate, >because it is also used for devices providing power to others. > >The solution in this draft is to just use "entity" instead. > >Thanks, > Juergen > >On 16.07.12 15:27, "internet-drafts@ietf.org" >wrote: > >> >>A new version of I-D, draft-ietf-eman-requirements-08.txt >>has been successfully submitted by Juergen Quittek and posted to the >>IETF repository. >> >>Filename: draft-ietf-eman-requirements >>Revision: 08 >>Title: Requirements for Energy Management >>Creation date: 2012-07-16 >>WG ID: eman >>Number of pages: 32 >>URL: >>http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-08.txt >>Status: >>http://datatracker.ietf.org/doc/draft-ietf-eman-requirements >>Htmlized: >>http://tools.ietf.org/html/draft-ietf-eman-requirements-08 >>Diff: >>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-requirements-08 >> >>Abstract: >> This document defines requirements for standards specifications for >> energy management. The requirements defined in this document concern >> monitoring functions as well as control functions. In detail, the >> focus of the requirements is on the following features: >> identification of energy-managed devices and their components, >> monitoring of their Power State, power inlets, power outlets, actual >> power, power properties, received energy, provided energy, and >> contained batteries. Further requirements are included to enable >> control of their power supply and Power State. This document does >> not specify the features that must be implemented by compliant >> implementations but rather features that must be supported by >> standards for energy management. >> >> >> >> >> >>The IETF Secretariat > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman= From jparello@cisco.com Sun Nov 4 20:14:38 2012 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 EB23921F89C3 for ; Sun, 4 Nov 2012 20:14:38 -0800 (PST) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vU2TdLVCJht1 for ; Sun, 4 Nov 2012 20:14:38 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D4ADB21F8996 for ; Sun, 4 Nov 2012 20:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2362; q=dns/txt; s=iport; t=1352088877; x=1353298477; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kM5wVelSN89ihP5XY8cxjVBikJxxPe4kNKxeG64WCzE=; b=LXOGcoLbxpuAFYyaV47kEOZAPmRvreceA6FkfXAyy2CdzAiZBnF6OnT1 rn1twz3zFcJ4EgpCrrU+PuDRH1Ox2nxIZgrlf2KcCcjmDchyHjEMINfPM f4yNr7kY2E7H15Ww7I+6OhvYtjpohRWCzKG9k/uBj3sME56UPaH0NgSWT g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANk8l1CtJXG9/2dsb2JhbABEwzuBCIIeAQEBAwEBAQEPAVsEBwULAgEINQYLJwslAgQOBSKHYgYLmVSfGIwBBQ8HCYU3YQOVe4EcihqDI4Frgm+BWyA X-IronPort-AV: E=Sophos;i="4.80,712,1344211200"; d="scan'208";a="138740198" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 05 Nov 2012 04:14:37 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA54Eace026069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 04:14:36 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.95]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 22:14:36 -0600 From: "John Parello (jparello)" To: "karagian@cs.utwente.nl" Thread-Topic: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? Thread-Index: AQHNslsgbGd4WxYd7EmQBUf18o2wJJfampsAgAAY0FY= Date: Mon, 5 Nov 2012 04:14:35 +0000 Message-ID: References: <064.e0edb6f25a043000c8d23b23fb4ed6cf@trac.tools.ietf.org>, <079.bcac537536af509ab30e5d720bdf398d@trac.tools.ietf.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004 x-tm-as-result: No--44.225000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "eman@ietf.org" , "trac+eman@grenache.tools.ietf.org" Subject: Re: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? 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 Nov 2012 04:14:39 -0000 Hi All, In the draft we defined parent child as a generic relationship between two = entities. Then we define specific relationships: power by, metered by etc. The direction of energy expressed by the sign of the power is orthogonal to= the relationships so I think this is covered and not an issue. Jp Sent from my iPad=20 (expect ridiculous spelling mistakes)=20 On Nov 4, 2012, at 12:45 PM, "karagian@cs.utwente.nl" wrote: > Hi all, >=20 > I assume that this comment refers to the situation where bidirectional po= wer interfaces are used? > I agre that this the parent/child energy object relationship needs to be = defined for the situation that bidirectional power interfaces are used! >=20 > Best regards, > Georgios >=20 > ________________________________________ > Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens eman issue trac= ker [trac+eman@grenache.tools.ietf.org] > Verzonden: donderdag 25 oktober 2012 4:47 > To: n.brownlee@auckland.ac.nz; brads@coraid.com > Cc: eman@ietf.org > Onderwerp: Re: [eman] #16: c. What does parent/child mean when the direct= ion of power flow between two devices can reverse? >=20 > #16: c. What does parent/child mean when the direction of power flow bet= ween > two devices can reverse? >=20 >=20 > Comment (by brads@=85): >=20 > I presume the the question regards when a child uses its battery to power > a parent. This seems a limited duration use case that doesn't change the > normal flow of power from parent to child. >=20 > -- > --------------------------+------------------------- > Reporter: n.brownlee@=85 | Owner: all > Type: defect | Status: new > Priority: minor | Milestone: milestone1 > Component: framework | Version: 1.0 > Severity: - | Resolution: > Keywords: | > --------------------------+------------------------- >=20 > Ticket URL: > 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 karagian@cs.utwente.nl Mon Nov 5 03:58:33 2012 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 7302A21F845B for ; Mon, 5 Nov 2012 03:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqhdj8Nn2RcK for ; Mon, 5 Nov 2012 03:58:33 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 81AE821F8458 for ; Mon, 5 Nov 2012 03:58:31 -0800 (PST) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 5 Nov 2012 12:58:33 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.76]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0318.004; Mon, 5 Nov 2012 12:58:30 +0100 From: To: Thread-Topic: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? Thread-Index: AQHNm5gxMY4OvKo9wEWkT7oEBiVGLZfJXYkAgBEEkyiAAG4QgIAAkj4O Date: Mon, 5 Nov 2012 11:58:30 +0000 Message-ID: References: <064.e0edb6f25a043000c8d23b23fb4ed6cf@trac.tools.ietf.org>, <079.bcac537536af509ab30e5d720bdf398d@trac.tools.ietf.org>, , In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.67.215] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman@ietf.org, trac+eman@grenache.tools.ietf.org Subject: Re: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? 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 Nov 2012 11:58:33 -0000 Hi John, Thank you for the clarification! Best regards, Georgios ________________________________________ Van: John Parello (jparello) [jparello@cisco.com] Verzonden: maandag 5 november 2012 5:14 To: Karagiannis, G. (EWI) Cc: trac+eman@grenache.tools.ietf.org; n.brownlee@auckland.ac.nz; brads@cor= aid.com; eman@ietf.org Onderwerp: Re: [eman] #16: c. What does parent/child mean when the directio= n of power flow between two devices can reverse? Hi All, In the draft we defined parent child as a generic relationship between two = entities. Then we define specific relationships: power by, metered by etc. The direction of energy expressed by the sign of the power is orthogonal to= the relationships so I think this is covered and not an issue. Jp Sent from my iPad (expect ridiculous spelling mistakes) On Nov 4, 2012, at 12:45 PM, "karagian@cs.utwente.nl" wrote: > Hi all, > > I assume that this comment refers to the situation where bidirectional po= wer interfaces are used? > I agre that this the parent/child energy object relationship needs to be = defined for the situation that bidirectional power interfaces are used! > > Best regards, > Georgios > > ________________________________________ > Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens eman issue trac= ker [trac+eman@grenache.tools.ietf.org] > Verzonden: donderdag 25 oktober 2012 4:47 > To: n.brownlee@auckland.ac.nz; brads@coraid.com > Cc: eman@ietf.org > Onderwerp: Re: [eman] #16: c. What does parent/child mean when the direct= ion of power flow between two devices can reverse? > > #16: c. What does parent/child mean when the direction of power flow bet= ween > two devices can reverse? > > > Comment (by brads@=85): > > I presume the the question regards when a child uses its battery to power > a parent. This seems a limited duration use case that doesn't change the > normal flow of power from parent to child. > > -- > --------------------------+------------------------- > Reporter: n.brownlee@=85 | Owner: all > Type: defect | Status: new > Priority: minor | Milestone: milestone1 > Component: framework | Version: 1.0 > Severity: - | Resolution: > Keywords: | > --------------------------+------------------------- > > Ticket URL: > eman > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman= From Quittek@neclab.eu Mon Nov 5 19:46:52 2012 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 2380021F8685 for ; Mon, 5 Nov 2012 19:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idBaKKKrEkm1 for ; Mon, 5 Nov 2012 19:46:51 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E57A921F867B for ; Mon, 5 Nov 2012 19:46:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 176D810242F for ; Tue, 6 Nov 2012 04:46:50 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV4BQre6ebBR for ; Tue, 6 Nov 2012 04:46:50 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id E8D4210240C for ; Tue, 6 Nov 2012 04:46:44 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 6 Nov 2012 04:46:23 +0100 From: Juergen Quittek To: eman mailing list Thread-Topic: simplifying the support of multiple power state sets Thread-Index: AQHNu9E4f9uXSpc1t0+uko1ImjG4XA== Date: Tue, 6 Nov 2012 03:45:53 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <56CC4D7973DE8D4DB11B0E1EDCD02CF6@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [eman] simplifying the support of multiple power state sets 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 Nov 2012 03:46:52 -0000 Dear all, I would like to re-open a closed issue: the concurrent support of multiple power sets. Curently our requirements documents states in section 5.4: "In order to support multiple management systems possibly using different Power State sets, while simultaneously interfacing with a particular entity, the energy management standard must provide means for supporting multiple Power State sets used simultaneously at an entity." When trying to design such a system at NEC, we ran into several problems that made us doubt whether this requirements is wisely chosen. The problem arises from the issue that not for all states in a power state set A there is necessarily a corresponding state in power set B and/or vice versa. The problem is which power state to report for set B if the device is set to a power state of set A that cannot be mapped to any state of set B? Fortunately, the DMTF has all of its state more or less mappable to ACPI states, but as soon as we include ASHRAE states, this is gone. One solution would be extending each set by a generic power state that is called "non-supported-by-this-set". Another solution would be to give up supporting multiple state sets concurrently. I would like to make a simple proposal that would still allow a device to support multiple sets, just not at the same time. It implies de-regulating power set support and gives a bit more freedom to implementers. The proposal is - Having all power states registered at IANA with a unique number The membership of a power state set can be indicated by just an attribute in the IANA registration. - Allowing devices to implement any subset of IANA registered power states (independent of power state sets). - Requiring a device to provide a list of all power states it implemens. - Requiring a device to be in exactly one power state at a time (I don't claim the proposal is new. Probably it has already been made already on the list in earlier discussions by someone else.) This would support the following options: 1. We can still have power state sets. They would consist of all power states registered at IANA with the same power state set attribute. 2. We can have a device implementing exactly one set by implementing all power states that are registered at IANA with the same power state set attribute. 3. We can extend power sets if needed, by just adding one more state with the same power state set attribute to the IANA registry. 4. We can have devices supporting only a subset of a single power state set. The device would indicate to any management system which states it supports. 5. We can have a device supproting two or more power state sets. It would just implement all or a subset of all states in multiple power sets. Management systems that can operate on just a single set would use only power states belonging to the set that they know. 6. We can even have manfacturers creating private extensions of standard power state sets by supporting all states of a set and additional states that are in the standard set, but have been registered individually by the manufacturer. This provides extensibility to device types we did not consider today or to new power saving technologies that lead to new power states. 7. If we want we can further allow proprietary power states that are not registered at IANA. For these we would have to reserve a number space. 8. We can still make recommendations that certain devices types should implement certain power state sets. The only drawback I see compared to the current solution occurs in the situation of multiple management systems managing the device using different power states. If one management system wants the device to be in a certain state of a cretain set and another managament system want to have it in another state of a different set, then the device may be permanently swapping power states. What do people on this list think about the proposed simplification? Dear all, I would like to re-open a closed issue: the concurrent support of multiple power sets. Curently our requirements documents states in section 5.4: "In order to support multiple management systems possibly using different Power State sets, while simultaneously interfacing with a particular entity, the energy management standard must provide means for supporting multiple Power State sets used simultaneously at an entity." When trying to design such a system at NEC, we ran into several problems that made us doubt whether this requirements is wisely chosen. The problem arises from the issue that not for all states in a power state set A there is necessarily a corresponding state in power set B and/or vice versa. The problem is which power state to report for set B if the device is set to a power state of set A that cannot be mapped to any state of set B? Fortunately, the DMTF has all of its state more or less mappable to ACPI states, but as soon as we include ASHRAE states, this is gone. One solution would be adding a generic power state to each set that is called "non-supported-by-this-set". Another solution would be to give up supporting multiple state sets concurrently. I would like to make a simple proposal that still allows a device to support multiple sets, just not at the same time. It implies de-regulating power set support and gives a bit more freedom to implementers. The proposal is - Having all power states registered at IANA with a unique number The membership of a power state set can be indicated by just an attribute in the IANA registration. - Allowing devices to implement any subset of IANA registered power states (independent of power state sets). - Requiring a device to provide a list of all power states it implemens. - Requiring a device to be in exactly one power state at a time (I don't claim the proposal is new. Probably it has already been made already on the list in earlier discussions by someone else.) This would support the following options: 1. We can still have power state sets. They would consist of all power states registered at IANA with the same power state set attribute. 2. We can have a device implementing exactly one set by implementing all power states that are registered at IANA with the same power state set attribute. 3. We can extend power sets if needed, by just adding one more state with the same power state set attribute to the IANA registry. 4. We can have devices supporting only a subset of a single power state set. The device would indicate to any management system which states it supports. 5. We can have a device supproting two or more power state sets. It would just implement all or a subset of all states in multiple power sets. Management systems that can operate on just a single set would use only power states belonging to the set that they know. 6. We can even have manfacturers creating private extensions of standard power state sets by supporting all states of a set and additional states that are in the standard set, but have been registered individually by the manufacturer. This provides extensibility to device types we did not consider today or to new power saving technologies that lead to new power states. 7. If we want we can further allow proprietary power states that are not registered at IANA. For these we would have to reserve a number space. 8. We can still make recommendations that certain devices types should implement certain power state sets. The only drawback I see compared to the current solution occurs in the situation of multiple management systems managing the device using different power states. If one management system wants the device to be in a certain state of a cretain set and another managament system want to have it in another state of a different set, then the device may be permanently swapping power states. Implied changes in the requirements draft would be: Section 5.4 Power State OLD "In order to support multiple management systems possibly using different Power State sets, while simultaneously interfacing with a particular entity, the energy management standard must provide means for supporting multiple Power State sets used simultaneously at an entity." NEW "In order to support multiple management systems possibly using different Power State sets, the energy management standard must provide means for supporting multiple Power State sets at an entity." 5.4.3. Multiple Power State sets OLD "The standard must provide means for supporting multiple Power State sets simultaneously at an entity." NEW "The standard must provide means for supporting multiple Power State sets at an entity." 5.4.4. List of supported Power State sets Delete requirement, because it is implicitly covered by requirement 5.4.2 (List of supported Power States) 5.4.5. List of supported Power States within a set Delete requirement, because it is implicitly covered by requirement 5.4.2 (List of supported Power States) What do people on this list think about the proposed simplification? Thanks, Juergen From Quittek@neclab.eu Mon Nov 5 19:54:42 2012 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 6CC9811E80C5 for ; Mon, 5 Nov 2012 19:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KInQHym-lRVN for ; Mon, 5 Nov 2012 19:54:41 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9016711E80BA for ; Mon, 5 Nov 2012 19:54:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D39AD102433; Tue, 6 Nov 2012 04:54:40 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksh5CGFG7o1s; Tue, 6 Nov 2012 04:54:40 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id B071410240C; Tue, 6 Nov 2012 04:54:20 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 6 Nov 2012 04:53:59 +0100 From: Juergen Quittek To: "John Parello (jparello)" , "karagian@cs.utwente.nl" Thread-Topic: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? Thread-Index: AQHNu9JIQSUSUpJHTUWCYhfKfXYbow== Date: Tue, 6 Nov 2012 03:53:29 +0000 Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list , "trac+eman@grenache.tools.ietf.org" Subject: Re: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? 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 Nov 2012 03:54:42 -0000 Hi John, I do not understand why the "powered-by" relationship would be independent of the direction of energy. Wouldn't it change somehow if the direction of energy changes at a device? Thanks, Juergen On 04.11.12 23:14, "John Parello (jparello)" wrote: >Hi All, > >In the draft we defined parent child as a generic relationship between >two entities. Then we define specific relationships: power by, metered by >etc. > >The direction of energy expressed by the sign of the power is orthogonal >to the relationships so I think this is covered and not an issue. > >Jp > > > >Sent from my iPad=20 >(expect ridiculous spelling mistakes) > >On Nov 4, 2012, at 12:45 PM, "karagian@cs.utwente.nl" > wrote: > >> Hi all, >>=20 >> I assume that this comment refers to the situation where bidirectional >>power interfaces are used? >> I agre that this the parent/child energy object relationship needs to >>be defined for the situation that bidirectional power interfaces are >>used! >>=20 >> Best regards, >> Georgios >>=20 >> ________________________________________ >> Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens eman issue >>tracker [trac+eman@grenache.tools.ietf.org] >> Verzonden: donderdag 25 oktober 2012 4:47 >> To: n.brownlee@auckland.ac.nz; brads@coraid.com >> Cc: eman@ietf.org >> Onderwerp: Re: [eman] #16: c. What does parent/child mean when the >>direction of power flow between two devices can reverse? >>=20 >> #16: c. What does parent/child mean when the direction of power flow >>between >> two devices can reverse? >>=20 >>=20 >> Comment (by brads@=8A): >>=20 >> I presume the the question regards when a child uses its battery to >>power >> a parent. This seems a limited duration use case that doesn't change >>the >> normal flow of power from parent to child. >>=20 >> -- >> --------------------------+------------------------- >> Reporter: n.brownlee@=8A | Owner: all >> Type: defect | Status: new >> Priority: minor | Milestone: milestone1 >> Component: framework | Version: 1.0 >> Severity: - | Resolution: >> Keywords: | >> --------------------------+------------------------- >>=20 >> Ticket URL:=20 >> >> 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 >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman From bnordman@lbl.gov Tue Nov 6 05:45:39 2012 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 7C69521F88FF for ; Tue, 6 Nov 2012 05:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tVPknC1Vzwm for ; Tue, 6 Nov 2012 05:45:38 -0800 (PST) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id 67E1E21F88FD for ; Tue, 6 Nov 2012 05:45:38 -0800 (PST) X-Ironport-SBRS: 2.6 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwGADsUmVDRVdzGfmdsb2JhbABBA4JJt34BiF8IIwEBCwkMCBQngh4BAQEDAQEBAWsEBwUHBAsLBgQBASgHIgUNAQUBCwkIGQgBh3sGC50Hjh6QTowDGgGDEIMqA4hajSGBHI1HFimEL4FGFw X-IronPort-AV: E=Sophos;i="4.80,722,1344236400"; d="scan'208";a="1864456" Received: from mail-vc0-f198.google.com ([209.85.220.198]) by fe1.lbl.gov with ESMTP; 06 Nov 2012 05:45:36 -0800 Received: by mail-vc0-f198.google.com with SMTP id d16so716318vcd.1 for ; Tue, 06 Nov 2012 05:45:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=LUzyka2CsMCODulyLI6s2OHwBA0LAIbAlwDvZDbK7yQ=; b=VygeJkcJzPVjUrc1vB85ozz380ug3cmwIavWtwSBCBJhjiW6tZzTU3zSbkUbS/NYxA EMJxTf7OjTQsJXDeRo7NXKAlbsp9el3Y0TQrmzfg5AnqVOS34MudSEhQ/n1a374Oq65L KSSTtXPgte1XtDlR5/xqKkiq/z0erDMc45KQVi+DyWu8l4b68PTkWLzMtedNkgCMFuJX eHZgJ6LWqkFL2OqfXBjhsZVCCUW1fVEEGh2c9vhDm961b5+bRBQVlQ2OK9Jsv+wIka2e FbGeDxiqHYygZij3/AEnmK/yv9vWqSBby5HHpPH6rMn01KmBKuAU/UBhR7HjB+RIrI1U W4cQ== Received: by 10.52.179.2 with SMTP id dc2mr764429vdc.50.1352209536596; Tue, 06 Nov 2012 05:45:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.179.2 with SMTP id dc2mr764427vdc.50.1352209536485; Tue, 06 Nov 2012 05:45:36 -0800 (PST) Received: by 10.58.15.234 with HTTP; Tue, 6 Nov 2012 05:45:36 -0800 (PST) In-Reply-To: References: <20121019131631.23306.94125.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237E2F03@xmb-rcd-x08.cisco.com> Date: Tue, 6 Nov 2012 08:45:36 -0500 Message-ID: From: Bruce Nordman To: karagian@cs.utwente.nl Content-Type: multipart/alternative; boundary=bcaec5014a4315878c04cdd3d1b9 X-Gm-Message-State: ALoCoQkhhTNrw8aY+TarAWh2vYC/loiqX31lUFiPXlrbwate+Isb4D+NsLFyaXCCJ+Eh0p1p3URq0gHbopnD4f2zpozItAG+0DgB1YcejzbVpbrgx1EAyn3v68EX1vHC+n0GweyEwfLs Cc: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 13:45:39 -0000 --bcaec5014a4315878c04cdd3d1b9 Content-Type: text/plain; charset=ISO-8859-1 Giorgios-- I think some text could be added on this to 2.7 as you suggest, but I have two questions/concerns about the text you propose. First is that I am not familiar with the term 'neighborhood energy gateway' (NEG). Is it a grid entity, or a meter at the edge of a grid (as a ordinary building meter is) with the downstream infrastructure not part of the utility grid? Some clarity would be needed so that readers can be sure to understand correctly what you mean. The second concern is on reporting to the utility. Nowhere in the current draft do we speak to sending EMAN data to a utility. Many standards organizations are active in utility/grid issues and there are many considerations that do nor arise within buildings. I am not active in this area, but know people who are, and there are many considerations we have not addressed. Utility meters are used for billing purposes and there are standards that address what "revenue grade" meters must do. I don't think that EMAN should tread into this area. If a NEG Is part of the grid, I also don't think we should address it. If not part of the grid, then fine to do so. All that said, someone could use EMAN data and pass it to a utility, but they then have the burden of considering what the utility needs or wants for data. That applies to any EMAN data, NEG and otherwise. Might you be able to propose alternate text which brings the NEG concept in but addresses these concerns? Thanks, --Bruce On Sun, Nov 4, 2012 at 4:23 PM, wrote: > Hi all, > > From what I remember, during the IETF in Vancouver, it was acceptable to > the WG to integrate the new use case that focusses on "Neighborhood Energy > Gateways", see the description of this use case in the email that I sent to > the list on the 24th of June 2012 with the Home Energy Gateways use case > (Section 2.7). > > Mouli, is it possible to add the following (or a modified version of this) > paragraph in Section 2.7: > > "This use case can also be applied in neighborhoods, where the eman target > devices are neighborhood energy gateways. These neighborhood energy > gateways can collect power consumption of a home via the home energy > gateway and possibly report the metering reading to the utility. " > > Best regards, > Georgios > > > ________________________________________ > Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens Mouli > Chandramouli (moulchan) [moulchan@cisco.com] > Verzonden: maandag 22 oktober 2012 7:53 > To: eman@ietf.org > Onderwerp: Re: [eman] I-D Action: > draft-ietf-eman-applicability-statement-02.txt > > Hello all, > > An updated version of the applicability statement has been submitted. > > Several editorial changes to improve the readability of the draft and also > consolidating the section on the related standards from the requirements to > applicability statement > > http://www.ietf.org/mail-archive/web/eman/current/msg01595.html > > The only remaining open issue is - the applicability of ASHRAE 201P > standards to EMAN. Are any concepts that can be reused ? > > which we hope address after the WG meeting. > > Please send your comments. > > Thanks > Brad, Bruce and Mouli > > > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, October 19, 2012 6:47 PM > To: i-d-announce@ietf.org > Cc: eman@ietf.org > Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Energy Management Working Group of the > IETF. > > Title : Energy Management (EMAN) Applicability Statement > Author(s) : Brad Schoening > Mouli Chandramouli > Bruce Nordman > Filename : draft-ietf-eman-applicability-statement-02.txt > Pages : 30 > Date : 2012-10-19 > > Abstract: > The objective of Energy Management (EMAN) is to provide an > energy management framework for networked devices. This > document presents the applicability of the EMAN framework to a > variety of scenarios. This document lists use cases and target > devices that can potentially implement the EMAN framework and > associated SNMP MIB modules. These use cases are useful for > identifying requirements for the framework and MIBs. Further, > we describe the relationship of the EMAN framework to relevant > other energy monitoring standards and architectures. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-eman-applicability-statement-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --bcaec5014a4315878c04cdd3d1b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Giorgios--

=A0I think some text could be added on this to 2.7 as you= suggest,
but I have two questions/concerns about the text you propose.<= br>
=A0 First is that I am not familiar with the term 'neighborhood = energy
gateway' (NEG).=A0 Is it a grid entity, or a meter at the edge of a gri= d (as
a ordinary building meter is) with the downstream infrastructurenot part of the utility grid?=A0 Some clarity would be needed so that
readers can be sure to understand correctly what you mean.

=A0 The s= econd concern is on reporting to the utility.=A0 Nowhere in
the current = draft do we speak to sending EMAN data to a utility.
Many standards orga= nizations are active in utility/grid issues and
there are many considerations that do nor arise within
buildings.=A0 I a= m not active in this area, but know people
who are, and there are many considerations we have not
addressed.=A0 Uti= lity meters are used for billing purposes and
there are standards that a= ddress what "revenue grade" meters
must do.=A0 I don't thi= nk that EMAN should tread into this area.
If a NEG Is part of the grid, I also don't think we should address
i= t.=A0 If not part of the grid, then fine to do so.

All that said, so= meone could use EMAN data and pass it to a
utility, but they then have the burden of considering what the
utility n= eeds or wants for data.=A0 That applies to any EMAN data,
NEG and otherw= ise.

Might you be able to propose alternate text which brings the NEG concept in but addresses these concerns?
Thanks,

--Bruce
<= br>

On Sun, Nov 4, 2012 at 4:23 PM, <karagian@cs.utwente.nl> wrote:
Hi all,

>From what I remember, during the IETF in Vancouver, it was acceptable to th= e WG to integrate the new use case that focusses on "Neighborhood Ener= gy Gateways", see the description of this use case in the email that I= sent to the list on the 24th of June 2012 with the Home Energy Gateways us= e case (Section 2.7).

Mouli, is it possible to add the following (or a modified version of this) = paragraph in Section 2.7:

"This use case can also be applied in neighborhoods, where the eman ta= rget devices are neighborhood energy gateways. These neighborhood energy ga= teways can collect power consumption of a home via the home energy gateway = and possibly report the metering reading to the utility. "

Best regards,
Georgios


________________________________________
Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens Mo= uli Chandramouli (moulchan) [moulchan= @cisco.com]
Verzonden: maandag 22 oktober 2012 7:53
To: eman@ietf.org
Onderwerp: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-0= 2.txt

Hello all,

An updated version of the applicability statement has been submitted.

Several editorial changes to improve the readability of the draft and also = consolidating the section on the related standards from the requirements to= applicability statement

http://www.ietf.org/mail-archive/web/eman/current/msg015= 95.html

The only remaining open issue is - =A0the applicability of ASHRAE 201P stan= dards to EMAN. =A0Are any concepts that can be reused ?

which we hope address after the WG meeting.

Please send your comments.

Thanks
Brad, Bruce and Mouli


-----Original Message-----
From: eman-bounces@ietf.org [m= ailto:eman-bounces@ietf.org] O= n Behalf Of internet-drafts@iet= f.org
Sent: Friday, October 19, 2012 6:47 PM
To: i-d-announce@ietf.org
Cc: eman@ietf.org
Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Energy Management Working Group of the = IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Energy Management (EMAN) Applic= ability Statement
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Brad Schoening
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mouli Chandramouli
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bruce Nordman
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-eman-applicability-sta= tement-02.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 30
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-19

Abstract:
=A0 =A0 =A0 =A0 The objective of Energy Management (EMAN) is to provide an<= br> =A0 =A0 =A0 =A0 energy management framework for networked devices. =A0This<= br> =A0 =A0 =A0 =A0 document presents the applicability of the EMAN framework t= o a
=A0 =A0 =A0 =A0 variety of scenarios. =A0This document lists use cases and = target
=A0 =A0 =A0 =A0 devices that can potentially implement the EMAN framework a= nd
=A0 =A0 =A0 =A0 associated SNMP MIB modules. =A0These use cases are useful = for
=A0 =A0 =A0 =A0 identifying requirements for the framework and MIBs. =A0Fur= ther,
=A0 =A0 =A0 =A0 we describe the relationship of the EMAN framework to relev= ant
=A0 =A0 =A0 =A0 other energy monitoring standards and architectures.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ema= n-applicability-statement

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-applica= bility-statement-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-i= etf-eman-applicability-statement-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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



--
Bruce Nordman
La= wrence Berkeley National Laboratory
nordman.lbl.g= ov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--bcaec5014a4315878c04cdd3d1b9-- From brads@coraid.com Tue Nov 6 06:25:07 2012 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 560A921F87E0 for ; Tue, 6 Nov 2012 06:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdIPSrlr8wnQ for ; Tue, 6 Nov 2012 06:25:06 -0800 (PST) Received: from server505.appriver.com (server505g.appriver.com [98.129.35.12]) by ietfa.amsl.com (Postfix) with ESMTP id D9E1421F8721 for ; Tue, 6 Nov 2012 06:25:05 -0800 (PST) X-Note-AR-ScanTimeLocal: 11/6/2012 8:25:04 AM X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Primary: brads@coraid.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @coraid.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: smtp.exg5.exghost.com X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G329 G330 G331 G332 G336 G337 G348 G444 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 334283034; Tue, 06 Nov 2012 08:25:03 -0600 Received: from MBX22.exg5.exghost.com ([169.254.2.182]) by HT09-e5.exg5.exghost.com ([98.129.23.242]) with mapi; Tue, 6 Nov 2012 08:25:03 -0600 From: Brad Schoening To: Bruce Nordman , "karagian@cs.utwente.nl" Date: Tue, 6 Nov 2012 08:25:02 -0600 Thread-Topic: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt Thread-Index: Ac28KoKQmJ5zwv8jS3K+rEbfsLBdeQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CCBE5BDC6AEFEbradscoraidcom_" MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 14:25:07 -0000 --_000_CCBE5BDC6AEFEbradscoraidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Bruce here that I am unfamiliar with this terminology. When I= search this term on Google ("neighborhood energy gateway"), I see only 8 r= esults; 5 related to our EMAN mailing list discussion with Giorgios, and 3 = related to an iOS game called Shadow Cities. If this term is not in common= use, including it in the Applicability statement would likely confuse read= ers. You text proposes "where the eman target devices are neighborhood energy ga= teways.". Can you provide us some examples of companies that produce and s= ell products known as NEGs? Regards, Brad From: Bruce Nordman > Date: Tue, 6 Nov 2012 07:45:36 -0600 To: "karagian@cs.utwente.nl" > Cc: "eman@ietf.org" > Subject: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.= txt Giorgios-- I think some text could be added on this to 2.7 as you suggest, but I have two questions/concerns about the text you propose. First is that I am not familiar with the term 'neighborhood energy gateway' (NEG). Is it a grid entity, or a meter at the edge of a grid (as a ordinary building meter is) with the downstream infrastructure not part of the utility grid? Some clarity would be needed so that readers can be sure to understand correctly what you mean. The second concern is on reporting to the utility. Nowhere in the current draft do we speak to sending EMAN data to a utility. Many standards organizations are active in utility/grid issues and there are many considerations that do nor arise within buildings. I am not active in this area, but know people who are, and there are many considerations we have not addressed. Utility meters are used for billing purposes and there are standards that address what "revenue grade" meters must do. I don't think that EMAN should tread into this area. If a NEG Is part of the grid, I also don't think we should address it. If not part of the grid, then fine to do so. All that said, someone could use EMAN data and pass it to a utility, but they then have the burden of considering what the utility needs or wants for data. That applies to any EMAN data, NEG and otherwise. Might you be able to propose alternate text which brings the NEG concept in but addresses these concerns? Thanks, --Bruce On Sun, Nov 4, 2012 at 4:23 PM, > wrote: Hi all, >From what I remember, during the IETF in Vancouver, it was acceptable to th= e WG to integrate the new use case that focusses on "Neighborhood Energy Ga= teways", see the description of this use case in the email that I sent to t= he list on the 24th of June 2012 with the Home Energy Gateways use case (Se= ction 2.7). Mouli, is it possible to add the following (or a modified version of this) = paragraph in Section 2.7: "This use case can also be applied in neighborhoods, where the eman target = devices are neighborhood energy gateways. These neighborhood energy gateway= s can collect power consumption of a home via the home energy gateway and p= ossibly report the metering reading to the utility. " Best regards, Georgios ________________________________________ Van: eman-bounces@ietf.org [eman-bounces@ietf= .org] namens Mouli Chandramouli (moulchan) [m= oulchan@cisco.com] Verzonden: maandag 22 oktober 2012 7:53 To: eman@ietf.org Onderwerp: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-0= 2.txt Hello all, An updated version of the applicability statement has been submitted. Several editorial changes to improve the readability of the draft and also = consolidating the section on the related standards from the requirements to= applicability statement http://www.ietf.org/mail-archive/web/eman/current/msg01595.html The only remaining open issue is - the applicability of ASHRAE 201P standa= rds to EMAN. Are any concepts that can be reused ? which we hope address after the WG meeting. Please send your comments. Thanks Brad, Bruce and Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-boun= ces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Friday, October 19, 2012 6:47 PM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Energy Management (EMAN) Applicability Statement Author(s) : Brad Schoening Mouli Chandramouli Bruce Nordman Filename : draft-ietf-eman-applicability-statement-02.txt Pages : 30 Date : 2012-10-19 Abstract: The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN framework to a variety of scenarios. This document lists use cases and target devices that can potentially implement the EMAN framework and associated SNMP MIB modules. These use cases are useful for identifying requirements for the framework and MIBs. Further, we describe the relationship of the EMAN framework to relevant other energy monitoring standards and architectures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-applicability-statement-= 02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --_000_CCBE5BDC6AEFEbradscoraidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Bruce here that I am unfamiliar with this terminology.  = When I search this term on Google ("neighborhood energy gateway"), I see on= ly 8 results; 5 related to our EMAN mailing list discussion with Giorgios, = and 3 related to an iOS game called Shadow Cities.  If this term is no= t in common use, including it in the Applicability statement would likely c= onfuse readers.

You text proposes "where the eman = target devices are neighborhood energy gateways.".  Can you provide us= some examples of companies that produce and sell products known as NE= Gs?

Regards,

Brad

From: Bruce Nordman <bnordman@lbl.gov>
Date: Tue, 6 Nov 2012 07:= 45:36 -0600
To: "karagian@cs.utwente.nl" <karagian@cs.utwente.nl>
Cc: "eman@ietf.= org" <eman@ietf.org>
Subject: Re: [eman] I-D Action: draft-= ietf-eman-applicability-statement-02.txt

Giorgios--=

 I think some text could be added on this to 2.7 as you sugges= t,
but I have two questions/concerns about the text you propose.

=   First is that I am not familiar with the term 'neighborhood energy gateway' (NEG).  Is it a grid entity, or a meter at the edge of a grid= (as
a ordinary building meter is) with the downstream infrastructurenot part of the utility grid?  Some clarity would be needed so thatreaders can be sure to understand correctly what you mean.

  = The second concern is on reporting to the utility.  Nowhere in
the = current draft do we speak to sending EMAN data to a utility.
Many standa= rds organizations are active in utility/grid issues and
there are many considerations that do nor arise within
buildings.  = I am not active in this area, but know people
who are, and there are many considerations we have not
addressed.  = Utility meters are used for billing purposes and
there are standards tha= t address what "revenue grade" meters
must do.  I don't think that = EMAN should tread into this area.
If a NEG Is part of the grid, I also don't think we should address
it.&n= bsp; If not part of the grid, then fine to do so.

All that said, som= eone could use EMAN data and pass it to a
utility, but they then have the burden of considering what the
utility n= eeds or wants for data.  That applies to any EMAN data,
NEG and oth= erwise.

Might you be able to propose alternate text which brings the=
NEG concept in but addresses these concerns?
Thanks,

--Bruce
<= br>

On Sun, Nov 4, 2012 at 4:23 PM, <karagian@cs.utwente.nl> wrote:
Hi all,

>From what I remember, during the IETF in Vancouver, it was acceptable to th= e WG to integrate the new use case that focusses on "Neighborhood Energy Ga= teways", see the description of this use case in the email that I sent to t= he list on the 24th of June 2012 with the Home Energy Gateways use case (Se= ction 2.7).

Mouli, is it possible to add the following (or a modified version of this) = paragraph in Section 2.7:

"This use case can also be applied in neighborhoods, where the eman target = devices are neighborhood energy gateways. These neighborhood energy gateway= s can collect power consumption of a home via the home energy gateway and p= ossibly report the metering reading to the utility. "

Best regards,
Georgios


________________________________________
Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens Mo= uli Chandramouli (moulchan) [moulchan= @cisco.com]
Verzonden: maandag 22 oktober 2012 7:53
To: eman@ietf.org
Onderwerp: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-0= 2.txt

Hello all,

An updated version of the applicability statement has been submitted.
Several editorial changes to improve the readability of the draft and also = consolidating the section on the related standards from the requirements to= applicability statement

http://www.ietf.org/mail= -archive/web/eman/current/msg01595.html

The only remaining open issue is -  the applicability of ASHRAE 201P s= tandards to EMAN.  Are any concepts that can be reused ?

which we hope address after the WG meeting.

Please send your comments.

Thanks
Brad, Bruce and Mouli


-----Original Message-----
From: eman-bounces@ietf.org [m= ailto:eman-bounces@ietf.org] O= n Behalf Of internet-drafts@iet= f.org
Sent: Friday, October 19, 2012 6:47 PM
To: i-d-announce@ietf.org
Cc: eman@ietf.org
Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 This draft is a work item of the Energy Management Working Group of t= he IETF.

        Title           : Ener= gy Management (EMAN) Applicability Statement
        Author(s)       : Brad Schoening=
                     = ;     Mouli Chandramouli
                     = ;     Bruce Nordman
        Filename        : draft-iet= f-eman-applicability-statement-02.txt
        Pages           : 30         Date            := 2012-10-19

Abstract:
        The objective of Energy Management (EMAN) is to= provide an
        energy management framework for networked devic= es.  This
        document presents the applicability of the EMAN= framework to a
        variety of scenarios.  This document lists= use cases and target
        devices that can potentially implement the EMAN= framework and
        associated SNMP MIB modules.  These use ca= ses are useful for
        identifying requirements for the framework and = MIBs.  Further,
        we describe the relationship of the EMAN framew= ork to relevant
        other energy monitoring standards and architect= ures.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-eman-applicability-stat= ement

There's also a htmlized version available at:
h= ttp://tools.ietf.org/html/draft-ietf-eman-applicability-statement-02
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-applicabilit= y-statement-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/intern= et-drafts/

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



--
Bruce Nordman<= /font>
Lawrence Berkeley National Lab= oratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089m: 510-501-7943

--_000_CCBE5BDC6AEFEbradscoraidcom_-- From karagian@cs.utwente.nl Tue Nov 6 08:11:43 2012 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 7335421F8A48 for ; Tue, 6 Nov 2012 08:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.476 X-Spam-Level: X-Spam-Status: No, score=-0.476 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyX49h7xM8-A for ; Tue, 6 Nov 2012 08:11:42 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 537DF21F8A43 for ; Tue, 6 Nov 2012 08:11:41 -0800 (PST) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 6 Nov 2012 17:11:38 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.76]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0318.004; Tue, 6 Nov 2012 17:11:38 +0100 From: To: , Thread-Topic: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt Thread-Index: AQHNrfwHOIdDW3o/RUm4TZcvAYNrkpfEtbEAgBWRPWaAApZWAIAACwQAgAArxSU= Date: Tue, 6 Nov 2012 16:11:37 +0000 Message-ID: References: , In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.64.192] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CC1AD2AEXMBX04adutwent_" MIME-Version: 1.0 Cc: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:11:43 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CC1AD2AEXMBX04adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Brad, Hi Bruce, You are right, the term Neighborhood Energy Gateways is not a typically use= d term. I was actually refering to "Collectors" used in neighborhoods, as e= xample see: https://www.ieso.ca/imoweb/siteshared/smart_meter_information_loop.asp?sid= =3Dic Note however, that this "Collectors", are used in the current power grid an= d are not only used to collect data that will be used for billing! Bruce, what about the following text that could be included in Section 2.7 = of the applicability draft: "This use case can also be applied in neighborhoods, where the eman target = devices are energy "collector" gateways. These energy "collector" gateways = can collect power consumption of a home via the home energy gateway and pos= sibly report the metering reading to the smart meter data repository. " Best regards, Georgios ________________________________ Van: Brad Schoening [brads@coraid.com] Verzonden: dinsdag 6 november 2012 15:25 To: Bruce Nordman; Karagiannis, G. (EWI) Cc: eman@ietf.org Onderwerp: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-0= 2.txt I agree with Bruce here that I am unfamiliar with this terminology. When I= search this term on Google ("neighborhood energy gateway"), I see only 8 r= esults; 5 related to our EMAN mailing list discussion with Giorgios, and 3 = related to an iOS game called Shadow Cities. If this term is not in common= use, including it in the Applicability statement would likely confuse read= ers. You text proposes "where the eman target devices are neighborhood energy ga= teways.". Can you provide us some examples of companies that produce and s= ell products known as NEGs? Regards, Brad From: Bruce Nordman > Date: Tue, 6 Nov 2012 07:45:36 -0600 To: "karagian@cs.utwente.nl" > Cc: "eman@ietf.org" > Subject: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.= txt Giorgios-- I think some text could be added on this to 2.7 as you suggest, but I have two questions/concerns about the text you propose. First is that I am not familiar with the term 'neighborhood energy gateway' (NEG). Is it a grid entity, or a meter at the edge of a grid (as a ordinary building meter is) with the downstream infrastructure not part of the utility grid? Some clarity would be needed so that readers can be sure to understand correctly what you mean. The second concern is on reporting to the utility. Nowhere in the current draft do we speak to sending EMAN data to a utility. Many standards organizations are active in utility/grid issues and there are many considerations that do nor arise within buildings. I am not active in this area, but know people who are, and there are many considerations we have not addressed. Utility meters are used for billing purposes and there are standards that address what "revenue grade" meters must do. I don't think that EMAN should tread into this area. If a NEG Is part of the grid, I also don't think we should address it. If not part of the grid, then fine to do so. All that said, someone could use EMAN data and pass it to a utility, but they then have the burden of considering what the utility needs or wants for data. That applies to any EMAN data, NEG and otherwise. Might you be able to propose alternate text which brings the NEG concept in but addresses these concerns? Thanks, --Bruce On Sun, Nov 4, 2012 at 4:23 PM, > wrote: Hi all, >From what I remember, during the IETF in Vancouver, it was acceptable to th= e WG to integrate the new use case that focusses on "Neighborhood Energy Ga= teways", see the description of this use case in the email that I sent to t= he list on the 24th of June 2012 with the Home Energy Gateways use case (Se= ction 2.7). Mouli, is it possible to add the following (or a modified version of this) = paragraph in Section 2.7: "This use case can also be applied in neighborhoods, where the eman target = devices are neighborhood energy gateways. These neighborhood energy gateway= s can collect power consumption of a home via the home energy gateway and p= ossibly report the metering reading to the utility. " Best regards, Georgios ________________________________________ Van: eman-bounces@ietf.org [eman-bounces@ietf= .org] namens Mouli Chandramouli (moulchan) [m= oulchan@cisco.com] Verzonden: maandag 22 oktober 2012 7:53 To: eman@ietf.org Onderwerp: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-0= 2.txt Hello all, An updated version of the applicability statement has been submitted. Several editorial changes to improve the readability of the draft and also = consolidating the section on the related standards from the requirements to= applicability statement http://www.ietf.org/mail-archive/web/eman/current/msg01595.html The only remaining open issue is - the applicability of ASHRAE 201P standa= rds to EMAN. Are any concepts that can be reused ? which we hope address after the WG meeting. Please send your comments. Thanks Brad, Bruce and Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-boun= ces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Friday, October 19, 2012 6:47 PM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Energy Management (EMAN) Applicability Statement Author(s) : Brad Schoening Mouli Chandramouli Bruce Nordman Filename : draft-ietf-eman-applicability-statement-02.txt Pages : 30 Date : 2012-10-19 Abstract: The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN framework to a variety of scenarios. This document lists use cases and target devices that can potentially implement the EMAN framework and associated SNMP MIB modules. These use cases are useful for identifying requirements for the framework and MIBs. Further, we describe the relationship of the EMAN framework to relevant other energy monitoring standards and architectures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-applicability-statement-= 02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CC1AD2AEXMBX04adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Brad, Hi Bruce,

 

You are right, the term Neighborhood Energy Gateways is not a typically = used term. I was actually refering to "Collectors" used in neighb= orhoods, as example see:

 

https://www.ieso.ca/imoweb/siteshared/smart_met= er_information_loop.asp?sid=3Dic

 

Note however, that this "Collectors", are used in the current = power grid and are not only used to collect data that will be used for bill= ing!

 

Bruce, what about the following text that could be included in Section 2= .7 of the applicability draft:

 

"This use case can also be applied in neighborhoods, where the eman= target devices are energy "collector" gateways. These energy &qu= ot;collector" gateways can collect power consumption of a home via the= home energy gateway and possibly report the metering reading to the smart meter data repository. "

 

Best regards,

Georgios

 

Van: Brad Schoening [brads@coraid.com]
Verzonden: dinsdag 6 november 2012 15:25
To: Bruce Nordman; Karagiannis, G. (EWI)
Cc: eman@ietf.org
Onderwerp: Re: [eman] I-D Action: draft-ietf-eman-applicability-stat= ement-02.txt


I agree with Bruce here that I am unfamiliar with this terminology. &n= bsp;When I search this term on Google ("neighborhood energy gateway&qu= ot;), I see only 8 results; 5 related to our EMAN mailing list discussion w= ith Giorgios, and 3 related to an iOS game called Shadow Cities.  If this term is not in common use, including it in th= e Applicability statement would likely confuse readers.

You text proposes "where the eman target devices are neighborhood= energy gateways.".  Can you provide us some examples of com= panies that produce and sell products known as NEGs?

Regards,

Brad

From: Bruce Nordman <bnordman@lbl.gov>
Date: Tue, 6 Nov 2012 07:45:36 -06= 00
To: "karagian@cs.utwente.nl" <karagian@cs.utwen= te.nl>
Cc: "eman@ietf.org" <eman@ietf.org>
Subject: Re: [eman] I-D Action: dr= aft-ietf-eman-applicability-statement-02.txt

Giorgios--

 I think some text could be added on this to 2.7 as you suggest,
but I have two questions/concerns about the text you propose.

  First is that I am not familiar with the term 'neighborhood energy gateway' (NEG).  Is it a grid entity, or a meter at the edge of a grid= (as
a ordinary building meter is) with the downstream infrastructure
not part of the utility grid?  Some clarity would be needed so that readers can be sure to understand correctly what you mean.

  The second concern is on reporting to the utility.  Nowhere in<= br> the current draft do we speak to sending EMAN data to a utility.
Many standards organizations are active in utility/grid issues and
there are many considerations that do nor arise within
buildings.  I am not active in this area, but know people
who are, and there are many considerations we have not
addressed.  Utility meters are used for billing purposes and
there are standards that address what "revenue grade" meters
must do.  I don't think that EMAN should tread into this area.
If a NEG Is part of the grid, I also don't think we should address
it.  If not part of the grid, then fine to do so.

All that said, someone could use EMAN data and pass it to a
utility, but they then have the burden of considering what the
utility needs or wants for data.  That applies to any EMAN data,
NEG and otherwise.

Might you be able to propose alternate text which brings the
NEG concept in but addresses these concerns?
Thanks,

--Bruce



On Sun, Nov 4, 2012 at 4:23 PM, <karagian@= cs.utwente.nl> wrote:
Hi all,

>From what I remember, during the IETF in Vancouver, it was acceptable to th= e WG to integrate the new use case that focusses on "Neighborhood Ener= gy Gateways", see the description of this use case in the email that I= sent to the list on the 24th of June 2012 with the Home Energy Gateways use case (Section 2.7).

Mouli, is it possible to add the following (or a modified version of this) = paragraph in Section 2.7:

"This use case can also be applied in neighborhoods, where the eman ta= rget devices are neighborhood energy gateways. These neighborhood energy ga= teways can collect power consumption of a home via the home energy gateway = and possibly report the metering reading to the utility. "

Best regards,
Georgios


________________________________________
Van: eman-bounce= s@ietf.org [= eman-bounces@ietf.org] namens Mouli Chandramouli (moulchan) [moulchan@cisco.com]
Verzonden: maandag 22 oktober 2012 7:53
To: eman@ietf.org Onderwerp: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-0= 2.txt

Hello all,

An updated version of the applicability statement has been submitted.

Several editorial changes to improve the readability of the draft and also = consolidating the section on the related standards from the requirements to= applicability statement

http://www.ietf.org/mail-archive/web/eman/current/msg015= 95.html

The only remaining open issue is -  the applicability of ASHRAE 201P s= tandards to EMAN.  Are any concepts that can be reused ?

which we hope address after the WG meeting.

Please send your comments.

Thanks
Brad, Bruce and Mouli


-----Original Message-----
From: eman-bounc= es@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of internet-draf= ts@ietf.org
Sent: Friday, October 19, 2012 6:47 PM
To: i-d-announce= @ietf.org
Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 This draft is a work item of the Energy Management Working Group of t= he IETF.

        Title           : Ener= gy Management (EMAN) Applicability Statement
        Author(s)       : Brad Schoening=
                     = ;     Mouli Chandramouli
                     = ;     Bruce Nordman
        Filename        : draft-iet= f-eman-applicability-statement-02.txt
        Pages           : 30         Date            := 2012-10-19

Abstract:
        The objective of Energy Management (EMAN) is to= provide an
        energy management framework for networked devic= es.  This
        document presents the applicability of the EMAN= framework to a
        variety of scenarios.  This document lists= use cases and target
        devices that can potentially implement the EMAN= framework and
        associated SNMP MIB modules.  These use ca= ses are useful for
        identifying requirements for the framework and = MIBs.  Further,
        we describe the relationship of the EMAN framew= ork to relevant
        other energy monitoring standards and architect= ures.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ema= n-applicability-statement

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-applica= bility-statement-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-i= etf-eman-applicability-statement-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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



--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov<= br> 510-486-7089
m: 510-501-7943

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CC1AD2AEXMBX04adutwent_-- From n.brownlee@auckland.ac.nz Tue Nov 6 08:24:22 2012 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 BFC8121F88A9 for ; Tue, 6 Nov 2012 08:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmzWU3Wo0oes for ; Tue, 6 Nov 2012 08:24:21 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4CB21F86C1 for ; Tue, 6 Nov 2012 08:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1352219061; x=1383755061; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=7AQ53FMgtPk/CywNoq0FPjmgu9nkCBfo5JxK5t3BFUU=; b=gitT7CtF4HhH14KiSPatA018nSEQilt2kMge+QB5NoUA33JnXv+gMu29 CV2NV3rFzQ5KklEPPWij4AbyqEFWUADv4sgXIFN7qLgNOhvBTIx+dnWzH Ccd11uVU3fTqyNZ5BjjKyZ14XHrpCevS2aouA5bm0MpOoGmlsVEmlf6ap M=; X-IronPort-AV: E=Sophos;i="4.80,723,1344168000"; d="scan'208";a="155386391" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.20.231 - Outgoing - Outgoing-SSL Received: from dhcp-14e7.meeting.ietf.org (HELO [130.129.20.231]) ([130.129.20.231]) by mx2-int.auckland.ac.nz with ESMTP; 07 Nov 2012 05:24:19 +1300 Message-ID: <509939B0.3070308@auckland.ac.nz> Date: Wed, 07 Nov 2012 05:24:16 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: eman@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eman] Slides for EMAN meeting 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 Nov 2012 16:24:22 -0000 Hi draft authors: We need to get the slides for Wednesday's meeting onto the Meeting Materials page. Please send your slide, as .pdf files, to me and to Bruce. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From jparello@cisco.com Tue Nov 6 09:16:32 2012 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 4FBAF21F88A5 for ; Tue, 6 Nov 2012 09:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu+JbfCTLv6f for ; Tue, 6 Nov 2012 09:16:31 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E7C6221F88A3 for ; Tue, 6 Nov 2012 09:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12539; q=dns/txt; s=iport; t=1352222191; x=1353431791; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xQpnOEfWDyquRQYoyjGIKcMjjzKwohVFM18zFjiQZB0=; b=m536veyNbtQb/9PnTLjasCwTppwDvm04nGupzPS3fF5YdWaqxs/bbosX UnwxHEALn5DqnZxVEqaOF3opg2rKugGhq4XoVVmdszXNGT8JroxEKpEGG CihqZeq2uQ0Sq1zP3Y1MsHdP9GqySXMN0UUpXy/xySvi+6dMqe8iXpo0X Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAFFmVCtJXG+/2dsb2JhbABEwy+BCIIeAQEBAwEBAQEPASc0AwgFCwIBCDYQJwslAgQOBRsHh2IGC5wGj2SQTYwDCgsGhVlhA5JJgzKOWYFrgm+BXA X-IronPort-AV: E=Sophos;i="4.80,722,1344211200"; d="scan'208";a="139381984" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 06 Nov 2012 17:16:29 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA6HGTbg016335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 17:16:29 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.95]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 11:16:28 -0600 From: "John Parello (jparello)" To: Juergen Quittek Thread-Topic: [eman] simplifying the support of multiple power state sets Thread-Index: AQHNvEJ1uQR9Z2pvrkOJoZ8IipkJAQ== Date: Tue, 6 Nov 2012 17:16:28 +0000 Message-ID: <2D99DB04-D708-4EB3-AD1D-7C3A655B589A@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--63.014200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] simplifying the support of multiple power state sets 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 Nov 2012 17:16:32 -0000 Hi Juergen, Sorry you've had problems designing such a system. At Cisco and with the En= ergyWise program and partner system we have designs and deployments that d= o not have this problem. We support multiple concurrent sets of power level= s (this group is calling them states now) with various vendors. Our partners and device manufacturers have had no problems mapping the DMTF= , ACPI, Poe, PWG, Cisco, and manufacturer specific states. (see Cisco,Leno= vo, Xerox, Schneider APC, Raritan etc..) simultaneously. In fact it's been very usable by our management partners who have implement= ed EnMS' on such a scheme. (see Joulex, Cisco Prime, Verdiem, CA Nimsoft, I= BM Tivoli) Your premise that you do not have corresponding states between sets of stat= es is one that can be loosened when you look at overlapping ranges of state= . Again we've been doing this for four with years now with about 85 partne= rs now and thousands of devices deployed under management. So if you make a requirement that we can't do multiple states at the same t= ime you'd be negating our work and design. The requirement doc should not dictate implementation. I think by stating t= hat a device should be able to support multiple power state sets that is en= ough. The fact that they are simultaneous or not is a limitation of some de= vice but please don't limit it in the requirements for those of us who can. The proposal you have is more relevant as an implementation discussion not = a requirements discussion. In that light thanks for the impementation proposal below, can you provide= an example much like the tables we showed in our work in the framework ove= r the past two years on this issue that shows your proposal.=20 =20 I'd like to make sure that for those of us who can and are doing this mapp= ing as a matter of course can still be able to without a long cumbersome li= st.=20 Without that example I feel we are just thrashing an issue which we've show= n in running code and stated in nearly two years of discussion here.=20 Jp Design references http://www.cisco.com/en/US/docs/solutions/Enterprise/Borderless_Networks/En= ergy_Management/energywisedg.html Manufacturers and EnMS references http://www.cisco.com/en/US/prod/switches/ps5718/ps10195/energywise_partner_= ecosystem.html =20 Sent from my iPad=20 (expect ridiculous spelling mistakes)=20 On Nov 5, 2012, at 7:46 PM, "Juergen Quittek" wrote: > Dear all, >=20 > I would like to re-open a closed issue: the concurrent support of > multiple power sets. Curently our requirements documents states > in section 5.4: > "In order to support multiple management > systems possibly using different Power State sets, while > simultaneously interfacing with a particular entity, the energy > management standard must provide means for supporting multiple Power > State sets used simultaneously at an entity." >=20 > When trying to design such a system at NEC, we ran into several > problems that made us doubt whether this requirements is wisely > chosen. >=20 > The problem arises from the issue that not for all states in a > power state set A there is necessarily a corresponding state in > power set B and/or vice versa. >=20 > The problem is which power state to report for set B if the device > is set to a power state of set A that cannot be mapped to any state > of set B? Fortunately, the DMTF has all of its state more or less > mappable to ACPI states, but as soon as we include ASHRAE states, > this is gone. >=20 > One solution would be extending each set by a generic power state > that is called "non-supported-by-this-set". >=20 > Another solution would be to give up supporting multiple state sets > concurrently. >=20 >=20 > I would like to make a simple proposal that would still allow a > device to support multiple sets, just not at the same time. > It implies de-regulating power set support and gives a bit more > freedom to implementers. >=20 > The proposal is > - Having all power states registered at IANA with a unique number > The membership of a power state set can be indicated by just an > attribute in the IANA registration. > - Allowing devices to implement any subset of IANA registered > power states (independent of power state sets). > - Requiring a device to provide a list of all power states it > implemens. > - Requiring a device to be in exactly one power state at a time > (I don't claim the proposal is new. Probably it has already been > made already on the list in earlier discussions by someone else.) >=20 > This would support the following options: >=20 > 1. We can still have power state sets. They would consist of all > power states registered at IANA with the same power state set > attribute. >=20 > 2. We can have a device implementing exactly one set by implementing > all power states that are registered at IANA with the same power > state set attribute. >=20 > 3. We can extend power sets if needed, by just adding one more state > with the same power state set attribute to the IANA registry. >=20 > 4. We can have devices supporting only a subset of a single power > state set. The device would indicate to any management system > which states it supports. >=20 > 5. We can have a device supproting two or more power state sets. > It would just implement all or a subset of all states in multiple > power sets. Management systems that can operate on just a single > set would use only power states belonging to the set that they know. >=20 > 6. We can even have manfacturers creating private extensions of > standard power state sets by supporting all states of a set and > additional states that are in the standard set, but have been > registered individually by the manufacturer. This provides > extensibility to device types we did not consider today or to new > power saving technologies that lead to new power states. >=20 > 7. If we want we can further allow proprietary power states that > are not registered at IANA. For these we would have to reserve a > number space. >=20 > 8. We can still make recommendations that certain devices types > should implement certain power state sets. >=20 > The only drawback I see compared to the current solution occurs in > the situation of multiple management systems managing the device > using different power states. If one management system wants the > device to be in a certain state of a cretain set and another > managament system want to have it in another state of a different > set, then the device may be permanently swapping power states. >=20 > What do people on this list think about the proposed simplification? >=20 > Dear all, >=20 > I would like to re-open a closed issue: the concurrent support of > multiple power sets. Curently our requirements documents states > in section 5.4: > "In order to support multiple management > systems possibly using different Power State sets, while > simultaneously interfacing with a particular entity, the energy > management standard must provide means for supporting multiple Power > State sets used simultaneously at an entity." >=20 > When trying to design such a system at NEC, we ran into several > problems that made us doubt whether this requirements is wisely > chosen. >=20 > The problem arises from the issue that not for all states in a > power state set A there is necessarily a corresponding state in > power set B and/or vice versa. >=20 > The problem is which power state to report for set B if the device > is set to a power state of set A that cannot be mapped to any state > of set B? Fortunately, the DMTF has all of its state more or less > mappable to ACPI states, but as soon as we include ASHRAE states, > this is gone. >=20 > One solution would be adding a generic power state to each set that > is called "non-supported-by-this-set". >=20 > Another solution would be to give up supporting multiple state sets > concurrently. >=20 >=20 > I would like to make a simple proposal that still allows a > device to support multiple sets, just not at the same time. > It implies de-regulating power set support and gives a bit more > freedom to implementers. >=20 > The proposal is > - Having all power states registered at IANA with a unique number > The membership of a power state set can be indicated by just an > attribute in the IANA registration. > - Allowing devices to implement any subset of IANA registered > power states (independent of power state sets). > - Requiring a device to provide a list of all power states it > implemens. > - Requiring a device to be in exactly one power state at a time > (I don't claim the proposal is new. Probably it has already been > made already on the list in earlier discussions by someone else.) >=20 > This would support the following options: >=20 > 1. We can still have power state sets. They would consist of all > power states registered at IANA with the same power state set > attribute. >=20 > 2. We can have a device implementing exactly one set by implementing > all power states that are registered at IANA with the same power > state set attribute. >=20 > 3. We can extend power sets if needed, by just adding one more state > with the same power state set attribute to the IANA registry. >=20 > 4. We can have devices supporting only a subset of a single power > state set. The device would indicate to any management system > which states it supports. >=20 > 5. We can have a device supproting two or more power state sets. > It would just implement all or a subset of all states in multiple > power sets. Management systems that can operate on just a single > set would use only power states belonging to the set that they know. >=20 > 6. We can even have manfacturers creating private extensions of > standard power state sets by supporting all states of a set and > additional states that are in the standard set, but have been > registered individually by the manufacturer. This provides > extensibility to device types we did not consider today or to new > power saving technologies that lead to new power states. >=20 > 7. If we want we can further allow proprietary power states that > are not registered at IANA. For these we would have to reserve a > number space. >=20 > 8. We can still make recommendations that certain devices types > should implement certain power state sets. >=20 > The only drawback I see compared to the current solution occurs in > the situation of multiple management systems managing the device > using different power states. If one management system wants the > device to be in a certain state of a cretain set and another > managament system want to have it in another state of a different > set, then the device may be permanently swapping power states. >=20 >=20 > Implied changes in the requirements draft would be: > Section 5.4 Power State > OLD > "In order to support multiple management > systems possibly using different Power State sets, while > simultaneously interfacing with a particular entity, the energy > management standard must provide means for supporting multiple Power > State sets used simultaneously at an entity." > NEW > "In order to support multiple management > systems possibly using different Power State sets, the energy > management standard must provide means for supporting multiple Power > State sets at an entity." >=20 > 5.4.3. Multiple Power State sets > OLD > "The standard must provide means for supporting multiple Power State > sets simultaneously at an entity." > NEW > "The standard must provide means for supporting multiple Power State > sets at an entity." >=20 > 5.4.4. List of supported Power State sets > Delete requirement, because it is implicitly covered by > requirement 5.4.2 (List of supported Power States) >=20 > 5.4.5. List of supported Power States within a set > Delete requirement, because it is implicitly covered by > requirement 5.4.2 (List of supported Power States) >=20 >=20 > What do people on this list think about the proposed simplification? >=20 > Thanks, > Juergen >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From jparello@cisco.com Tue Nov 6 09:25:41 2012 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 27B0121F8925 for ; Tue, 6 Nov 2012 09:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbBGk4qk5m3L for ; Tue, 6 Nov 2012 09:25:40 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3B64B21F8916 for ; Tue, 6 Nov 2012 09:25:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4390; q=dns/txt; s=iport; t=1352222740; x=1353432340; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+XAqgvzcIKEU/otsYBsF7bgvP0CrJdG6/vmc8MH2dtY=; b=a1AxTdslTetfIfRT7vMhoimqaSGsmBTAH4YI8gmomXcaN+UlwrXuJE/s MmoOWaaCNtm+BhJoafH82AeuFhDbgDDJphxFBzQPL007wqA3IIaY7IoMw wH1bdNE/Sz37QOeKe+l0TyAnbmVssBwktvrOQQuicKlk8vIpwudGIv8lV g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGpHmVCtJXHA/2dsb2JhbABEwy+BCIIeAQEBAwEBAQEPAVsEBwULAgEIGCMLJwslAgQOBSKHYgYLnAiPZJBNjAMFDwcJhVBhA5V7gRyKGoMjgWuCb4FbIA X-IronPort-AV: E=Sophos;i="4.80,722,1344211200"; d="scan'208";a="139382380" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 06 Nov 2012 17:25:38 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA6HPbK1009962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 17:25:37 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.95]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 11:25:37 -0600 From: "John Parello (jparello)" To: Juergen Quittek Thread-Topic: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? Thread-Index: AQHNslsgbGd4WxYd7EmQBUf18o2wJJfampsAgAAY0FaAAfEEgIAAflOy Date: Tue, 6 Nov 2012 17:25:37 +0000 Message-ID: <3D26F57F-8198-4408-B02F-977C321BEB6E@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--48.208000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list , "trac+eman@grenache.tools.ietf.org" Subject: Re: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? 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 Nov 2012 17:25:41 -0000 Yes in that specific relationship one could change but not required (the si= gn of power could change and the relationship remain and indicate and error= condition. Etc) That aside the question and issue here was about parent child and the conce= pt. I'm referring to the definition of parent and child as generic terms an= d concept for a relationship. That has nothing to with power and direction. Energy Object Parent=20 An Energy Object Parent is an Energy Object that=20 participates in an Energy Object Relationships=20 and is considered as providing the capabilities=20 in the relationship. =20 =20 Example: in a Metering Relationship, the Energy=20 Object that is metering is called the Energy=20 Object Parent, while the Energy Object that is=20 metered is called the Energy Object Child. =20 =20 =20 Energy Object Child=20 An Energy Object Child is an Energy Object that=20 participates in an Energy Object Relationships=20 and is considered as receiving the capabilities=20 in the relationship.=20 =20 Sent from my iPad=20 (expect ridiculous spelling mistakes)=20 On Nov 5, 2012, at 7:54 PM, "Juergen Quittek" wrote: > Hi John, >=20 > I do not understand why the "powered-by" relationship would be independen= t > of the direction of energy. Wouldn't it change somehow if the direction > of energy changes at a device? >=20 > Thanks, > Juergen >=20 >=20 > On 04.11.12 23:14, "John Parello (jparello)" wrote: >=20 >> Hi All, >>=20 >> In the draft we defined parent child as a generic relationship between >> two entities. Then we define specific relationships: power by, metered b= y >> etc. >>=20 >> The direction of energy expressed by the sign of the power is orthogonal >> to the relationships so I think this is covered and not an issue. >>=20 >> Jp >>=20 >>=20 >>=20 >> Sent from my iPad=20 >> (expect ridiculous spelling mistakes) >>=20 >> On Nov 4, 2012, at 12:45 PM, "karagian@cs.utwente.nl" >> wrote: >>=20 >>> Hi all, >>>=20 >>> I assume that this comment refers to the situation where bidirectional >>> power interfaces are used? >>> I agre that this the parent/child energy object relationship needs to >>> be defined for the situation that bidirectional power interfaces are >>> used! >>>=20 >>> Best regards, >>> Georgios >>>=20 >>> ________________________________________ >>> Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens eman issue >>> tracker [trac+eman@grenache.tools.ietf.org] >>> Verzonden: donderdag 25 oktober 2012 4:47 >>> To: n.brownlee@auckland.ac.nz; brads@coraid.com >>> Cc: eman@ietf.org >>> Onderwerp: Re: [eman] #16: c. What does parent/child mean when the >>> direction of power flow between two devices can reverse? >>>=20 >>> #16: c. What does parent/child mean when the direction of power flow >>> between >>> two devices can reverse? >>>=20 >>>=20 >>> Comment (by brads@=8A): >>>=20 >>> I presume the the question regards when a child uses its battery to >>> power >>> a parent. This seems a limited duration use case that doesn't change >>> the >>> normal flow of power from parent to child. >>>=20 >>> -- >>> --------------------------+------------------------- >>> Reporter: n.brownlee@=8A | Owner: all >>> Type: defect | Status: new >>> Priority: minor | Milestone: milestone1 >>> Component: framework | Version: 1.0 >>> Severity: - | Resolution: >>> Keywords: | >>> --------------------------+------------------------- >>>=20 >>> Ticket URL:=20 >>> >>> 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 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >=20 From Quittek@neclab.eu Tue Nov 6 11:48:48 2012 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 CB98321F8AB1 for ; Tue, 6 Nov 2012 11:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQhmlhcfyKHO for ; Tue, 6 Nov 2012 11:48:48 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A3F0221F8AB3 for ; Tue, 6 Nov 2012 11:48:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 9F1DF102454; Tue, 6 Nov 2012 20:48:46 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lltov3Cjigle; Tue, 6 Nov 2012 20:48:46 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 7CAB410244C; Tue, 6 Nov 2012 20:48:26 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 6 Nov 2012 20:48:05 +0100 From: Juergen Quittek To: "John Parello (jparello)" Thread-Topic: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? Thread-Index: AQHNvFeUQSUSUpJHTUWCYhfKfXYbow== Date: Tue, 6 Nov 2012 19:47:40 +0000 Message-ID: In-Reply-To: <3D26F57F-8198-4408-B02F-977C321BEB6E@cisco.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list , "trac+eman@grenache.tools.ietf.org" Subject: Re: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? 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 Nov 2012 19:48:49 -0000 Hi John, On 06.11.12 12:25, "John Parello (jparello)" wrote: >Yes in that specific relationship one could change but not required (the >sign of power could change and the relationship remain and indicate and >error condition. Etc) I am not sure I fully understand this: Do you mean that a changed power direction would be an error condition? > >That aside the question and issue here was about parent child and the >concept. I'm referring to the definition of parent and child as generic >terms and concept for a relationship. That has nothing to with power and >direction. Indeed it was. If you go down the email thread below you'll find the question: "What does parent/child mean when the direction of power flow between two devices can reverse?" And I would answer: Yes, the parent child relationship between two devices can reverse over time. Thanks, Juergen > > > Energy Object Parent > > An Energy Object Parent is an Energy Object that > participates in an Energy Object Relationships > and is considered as providing the capabilities > in the relationship. > =20 > Example: in a Metering Relationship, the Energy > Object that is metering is called the Energy > Object Parent, while the Energy Object that is > metered is called the Energy Object Child. > =20 > =20 > Energy Object Child > > An Energy Object Child is an Energy Object that > participates in an Energy Object Relationships > and is considered as receiving the capabilities > in the relationship. > > >=20 > >Sent from my iPad=20 >(expect ridiculous spelling mistakes) > >On Nov 5, 2012, at 7:54 PM, "Juergen Quittek" wrote: > >> Hi John, >>=20 >> I do not understand why the "powered-by" relationship would be >>independent >> of the direction of energy. Wouldn't it change somehow if the direction >> of energy changes at a device? >>=20 >> Thanks, >> Juergen >>=20 >>=20 >> On 04.11.12 23:14, "John Parello (jparello)" wrote: >>=20 >>> Hi All, >>>=20 >>> In the draft we defined parent child as a generic relationship between >>> two entities. Then we define specific relationships: power by, metered >>>by >>> etc. >>>=20 >>> The direction of energy expressed by the sign of the power is >>>orthogonal >>> to the relationships so I think this is covered and not an issue. >>>=20 >>> Jp >>>=20 >>>=20 >>>=20 >>> Sent from my iPad >>> (expect ridiculous spelling mistakes) >>>=20 >>> On Nov 4, 2012, at 12:45 PM, "karagian@cs.utwente.nl" >>> wrote: >>>=20 >>>> Hi all, >>>>=20 >>>> I assume that this comment refers to the situation where bidirectional >>>> power interfaces are used? >>>> I agre that this the parent/child energy object relationship needs to >>>> be defined for the situation that bidirectional power interfaces are >>>> used! >>>>=20 >>>> Best regards, >>>> Georgios >>>>=20 >>>> ________________________________________ >>>> Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens eman issue >>>> tracker [trac+eman@grenache.tools.ietf.org] >>>> Verzonden: donderdag 25 oktober 2012 4:47 >>>> To: n.brownlee@auckland.ac.nz; brads@coraid.com >>>> Cc: eman@ietf.org >>>> Onderwerp: Re: [eman] #16: c. What does parent/child mean when the >>>> direction of power flow between two devices can reverse? >>>>=20 >>>> #16: c. What does parent/child mean when the direction of power flow >>>> between >>>> two devices can reverse? >>>>=20 >>>>=20 >>>> Comment (by brads@=A9): >>>>=20 >>>> I presume the the question regards when a child uses its battery to >>>> power >>>> a parent. This seems a limited duration use case that doesn't change >>>> the >>>> normal flow of power from parent to child. >>>>=20 >>>> -- >>>> --------------------------+------------------------- >>>> Reporter: n.brownlee@=A9 | Owner: all >>>> Type: defect | Status: new >>>> Priority: minor | Milestone: milestone1 >>>> Component: framework | Version: 1.0 >>>> Severity: - | Resolution: >>>> Keywords: | >>>> --------------------------+------------------------- >>>>=20 >>>> Ticket URL:=20 >>>> >>>> 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 >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman >>=20 From jparello@cisco.com Tue Nov 6 12:54:47 2012 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 3090021F85D8 for ; Tue, 6 Nov 2012 12:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZ0R6+AwWs5b for ; Tue, 6 Nov 2012 12:54:46 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDF621F85C7 for ; Tue, 6 Nov 2012 12:54:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5738; q=dns/txt; s=iport; t=1352235286; x=1353444886; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r+gDmDR9ZC7KN8pRK0qVp3a/Hqq11ybBW2S3YgE7MTo=; b=kQN4olUfiUT2QVJWrkwESJ1oUwPW3gkVkjx9HslYrOPFoWaQqtI3VvsJ Ehy8e2KzBCkiCzZoW7N5dQH0apohnLUSRbc8ek1CgXKSyLzc2LNErLxZM z0qn347WeNw8kdHok7QbvRJk7uaF+FuyF/Vom+47Vl3dj/qVGGCYajuib g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIV4mVCtJV2b/2dsb2JhbABEwz6BCIIeAQEBAwEBAQEPAVsEBwULAgEIGCMLJwslAgQOBSKHYgYLm2yPYpAxjAMFDwcJhjEDlXuBHIoagyOBa4JvgVsJFw X-IronPort-AV: E=Sophos;i="4.80,723,1344211200"; d="scan'208";a="139458509" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 06 Nov 2012 20:54:45 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA6KsjX6012917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 20:54:45 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.95]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 14:54:45 -0600 From: "John Parello (jparello)" To: Juergen Quittek Thread-Topic: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? Thread-Index: AQHNslsgbGd4WxYd7EmQBUf18o2wJJfampsAgAAY0FaAAfEEgIAAflOygACMRQD//64pbg== Date: Tue, 6 Nov 2012 20:54:45 +0000 Message-ID: <5B4BFC22-39A9-4FCB-A3E8-5554886590AC@cisco.com> References: <3D26F57F-8198-4408-B02F-977C321BEB6E@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--49.861300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list , "trac+eman@grenache.tools.ietf.org" Subject: Re: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? 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 Nov 2012 20:54:47 -0000 Sent from my iPad=20 (expect ridiculous spelling mistakes)=20 On Nov 6, 2012, at 2:48 PM, "Juergen Quittek" wrote: > Hi John, >=20 > On 06.11.12 12:25, "John Parello (jparello)" wrote: >=20 >> Yes in that specific relationship one could change but not required (the >> sign of power could change and the relationship remain and indicate and >> error condition. Etc) >=20 > I am not sure I fully understand this: Do you mean that a changed power > direction would be an error condition? >=20 You can have a condition where the power source is fixed and the power sign= changes. In that case it could be used as a way of indicating to an EnMS o= f an anomalous condition. It's not a data modeling error it's a condition = that can be interpreted as an problem. >>=20 >> That aside the question and issue here was about parent child and the >> concept. I'm referring to the definition of parent and child as generic >> terms and concept for a relationship. That has nothing to with power and >> direction. >=20 > Indeed it was. If you go down the email thread below you'll find the > question: >=20 > "What does parent/child mean when the direction of power flow between two > devices can reverse?" >=20 >=20 > And I would answer: Yes, the parent child relationship between two device= s > can reverse over time. >=20 Ack on that - it can - but doesn't have to if the direction changes. Depend= s on the devices in question > Thanks, > Juergen >=20 >>=20 >>=20 >> Energy Object Parent >>=20 >> An Energy Object Parent is an Energy Object that >> participates in an Energy Object Relationships >> and is considered as providing the capabilities >> in the relationship. >>=20 >> Example: in a Metering Relationship, the Energy >> Object that is metering is called the Energy >> Object Parent, while the Energy Object that is >> metered is called the Energy Object Child. >>=20 >>=20 >> Energy Object Child >>=20 >> An Energy Object Child is an Energy Object that >> participates in an Energy Object Relationships >> and is considered as receiving the capabilities >> in the relationship. >>=20 >>=20 >>=20 >>=20 >> Sent from my iPad=20 >> (expect ridiculous spelling mistakes) >>=20 >> On Nov 5, 2012, at 7:54 PM, "Juergen Quittek" wrote: >>=20 >>> Hi John, >>>=20 >>> I do not understand why the "powered-by" relationship would be >>> independent >>> of the direction of energy. Wouldn't it change somehow if the directio= n >>> of energy changes at a device? >>>=20 >>> Thanks, >>> Juergen >>>=20 >>>=20 >>> On 04.11.12 23:14, "John Parello (jparello)" wrote= : >>>=20 >>>> Hi All, >>>>=20 >>>> In the draft we defined parent child as a generic relationship between >>>> two entities. Then we define specific relationships: power by, metered >>>> by >>>> etc. >>>>=20 >>>> The direction of energy expressed by the sign of the power is >>>> orthogonal >>>> to the relationships so I think this is covered and not an issue. >>>>=20 >>>> Jp >>>>=20 >>>>=20 >>>>=20 >>>> Sent from my iPad >>>> (expect ridiculous spelling mistakes) >>>>=20 >>>> On Nov 4, 2012, at 12:45 PM, "karagian@cs.utwente.nl" >>>> wrote: >>>>=20 >>>>> Hi all, >>>>>=20 >>>>> I assume that this comment refers to the situation where bidirectiona= l >>>>> power interfaces are used? >>>>> I agre that this the parent/child energy object relationship needs to >>>>> be defined for the situation that bidirectional power interfaces are >>>>> used! >>>>>=20 >>>>> Best regards, >>>>> Georgios >>>>>=20 >>>>> ________________________________________ >>>>> Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens eman issue >>>>> tracker [trac+eman@grenache.tools.ietf.org] >>>>> Verzonden: donderdag 25 oktober 2012 4:47 >>>>> To: n.brownlee@auckland.ac.nz; brads@coraid.com >>>>> Cc: eman@ietf.org >>>>> Onderwerp: Re: [eman] #16: c. What does parent/child mean when the >>>>> direction of power flow between two devices can reverse? >>>>>=20 >>>>> #16: c. What does parent/child mean when the direction of power flow >>>>> between >>>>> two devices can reverse? >>>>>=20 >>>>>=20 >>>>> Comment (by brads@=8A): >>>>>=20 >>>>> I presume the the question regards when a child uses its battery to >>>>> power >>>>> a parent. This seems a limited duration use case that doesn't change >>>>> the >>>>> normal flow of power from parent to child. >>>>>=20 >>>>> -- >>>>> --------------------------+------------------------- >>>>> Reporter: n.brownlee@=8A | Owner: all >>>>> Type: defect | Status: new >>>>> Priority: minor | Milestone: milestone1 >>>>> Component: framework | Version: 1.0 >>>>> Severity: - | Resolution: >>>>> Keywords: | >>>>> --------------------------+------------------------- >>>>>=20 >>>>> Ticket URL:=20 >>>>> >>>>> 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 >>>> _______________________________________________ >>>> eman mailing list >>>> eman@ietf.org >>>> https://www.ietf.org/mailman/listinfo/eman >>>=20 >=20 From bnordman@lbl.gov Tue Nov 6 14:28:11 2012 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 D74CE21F8B6E for ; Tue, 6 Nov 2012 14:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+82xjbxi5od for ; Tue, 6 Nov 2012 14:28:08 -0800 (PST) Received: from fe2.lbl.gov (fe2.lbl.gov [128.3.41.134]) by ietfa.amsl.com (Postfix) with ESMTP id 1447421F8BB1 for ; Tue, 6 Nov 2012 14:28:01 -0800 (PST) X-Ironport-SBRS: 2.2 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigEACWOmVDRVdXGemdsb2JhbABBA4JJuBoBiF8IIwEBCwkMCBQEI4IeAQEBAwEBAQFrBAcFBwQLCwYDAQEBAScHIgUNAQUBCwkIGQmHewYLnH+OHZAvjAMaAYMQgyoDiFqNIYEcjUcWKYQvgUYX X-IronPort-AV: E=Sophos;i="4.80,724,1344236400"; d="scan'208";a="1944413" Received: from mail-ye0-f198.google.com ([209.85.213.198]) by fe2.lbl.gov with ESMTP; 06 Nov 2012 14:27:55 -0800 Received: by mail-ye0-f198.google.com with SMTP id q10so1747729yen.1 for ; Tue, 06 Nov 2012 14:27:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=L+M+AF2oJRIr2Uz52qvFlbXzzHH/D83ZE5y4hlI//l8=; b=WqHH93btOBEJLpolB9DNE3B7C9jlFKb/2ALHJCzXVsVSo5tmJqFsfA8lzLUKMeNHN1 WugLqtepRIOjRPiROBzzDp4iIkl71K2BGp56moJAhBY+9SGoplJmE5bV/rXxIxfF3Ael SSor7ibwxqjMRV2o6hDDWvD/w5kQWyiOd7CSehLgU/v9qdC7LFYNSl01Pf/ap87pDmpo FJvCOrdDIFJ3rCzErabakuTLgNoIv4QwAItqA/hoyxPt1GRBZhzpkqhFZvYeAT8YzEZ9 60JkyIzFH/RGBGOU/OQSnwiwX9BatDwUKNIFvO+/8GGVjcbru33+hrnM3KwC3tEDs4Dn RRpQ== Received: by 10.52.179.2 with SMTP id dc2mr2055042vdc.50.1352240874982; Tue, 06 Nov 2012 14:27:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.179.2 with SMTP id dc2mr2055037vdc.50.1352240874840; Tue, 06 Nov 2012 14:27:54 -0800 (PST) Received: by 10.58.15.234 with HTTP; Tue, 6 Nov 2012 14:27:54 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Nov 2012 17:27:54 -0500 Message-ID: From: Bruce Nordman To: karagian@cs.utwente.nl Content-Type: multipart/alternative; boundary=bcaec5014a43fee25d04cddb1c04 X-Gm-Message-State: ALoCoQksNKy8pQ+zmVa9L9hwcCx3KFaFmKvJTHEMnV/GQynUSej0R+mR2RSrThGhIAIx3MTqs3qa/BD9IJSZ5igxxpcfr+VABw8JPmITVsXeWNoIl7dm5oN+WFu8hAYIypSwa0avB98N Cc: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 22:28:12 -0000 --bcaec5014a43fee25d04cddb1c04 Content-Type: text/plain; charset=ISO-8859-1 Georgios-- Thanks much for the clarification. The example you point to is about utility meter data for billing. I am not familiar with the technology issues around revenue meters and with protocols for moving that data to the utility. However, since large amounts of money are at stake with revenue meters, and there are existing standards for accuracy and other characteristics for such devices (none of which we reference), I think this is outside of territory that EMAN should tread into. If data are not to be used for billing then I think existing EMAN use cases cover this. I agree that collecting data across multiple meters (generic meters, not utility meters in their utility role) is useful and part of our scope. --Bruce On Tue, Nov 6, 2012 at 11:11 AM, wrote: > Hi Brad, Hi Bruce, > > > > You are right, the term Neighborhood Energy Gateways is not a typically > used term. I was actually refering to "Collectors" used in neighborhoods, > as example see: > > > > * > https://www.ieso.ca/imoweb/siteshared/smart_meter_information_loop.asp?sid=ic > * > > ** > > Note however, that this "Collectors", are used in the current power grid > and are not only used to collect data that will be used for billing! > > > > Bruce, what about the following text that could be included in Section 2.7 > of the applicability draft: > > ** > > "This use case can also be applied in neighborhoods, where the eman target > devices are energy "collector" gateways. These energy "collector" gateways > can collect power consumption of a home via the home energy gateway and > possibly report the metering reading to the smart meter data repository. " > > ** > > Best regards, > > Georgios > > ** > ------------------------------ > *Van:* Brad Schoening [brads@coraid.com] > *Verzonden:* dinsdag 6 november 2012 15:25 > *To:* Bruce Nordman; Karagiannis, G. (EWI) > *Cc:* eman@ietf.org > > *Onderwerp:* Re: [eman] I-D Action: > draft-ietf-eman-applicability-statement-02.txt > > > I agree with Bruce here that I am unfamiliar with this terminology. > When I search this term on Google ("neighborhood energy gateway"), I see > only 8 results; 5 related to our EMAN mailing list discussion with > Giorgios, and 3 related to an iOS game called Shadow Cities. If this term > is not in common use, including it in the Applicability statement would > likely confuse readers. > > You text proposes "where the eman target devices are neighborhood energy > gateways.". Can you provide us some examples of companies that produce and > sell products known as NEGs? > > Regards, > > Brad > > From: Bruce Nordman > Date: Tue, 6 Nov 2012 07:45:36 -0600 > To: "karagian@cs.utwente.nl" > Cc: "eman@ietf.org" > Subject: Re: [eman] I-D Action: > draft-ietf-eman-applicability-statement-02.txt > > Giorgios-- > > I think some text could be added on this to 2.7 as you suggest, > but I have two questions/concerns about the text you propose. > > First is that I am not familiar with the term 'neighborhood energy > gateway' (NEG). Is it a grid entity, or a meter at the edge of a grid (as > a ordinary building meter is) with the downstream infrastructure > not part of the utility grid? Some clarity would be needed so that > readers can be sure to understand correctly what you mean. > > The second concern is on reporting to the utility. Nowhere in > the current draft do we speak to sending EMAN data to a utility. > Many standards organizations are active in utility/grid issues and > there are many considerations that do nor arise within > buildings. I am not active in this area, but know people > who are, and there are many considerations we have not > addressed. Utility meters are used for billing purposes and > there are standards that address what "revenue grade" meters > must do. I don't think that EMAN should tread into this area. > If a NEG Is part of the grid, I also don't think we should address > it. If not part of the grid, then fine to do so. > > All that said, someone could use EMAN data and pass it to a > utility, but they then have the burden of considering what the > utility needs or wants for data. That applies to any EMAN data, > NEG and otherwise. > > Might you be able to propose alternate text which brings the > NEG concept in but addresses these concerns? > Thanks, > > --Bruce > > > > On Sun, Nov 4, 2012 at 4:23 PM, wrote: > >> Hi all, >> >> From what I remember, during the IETF in Vancouver, it was acceptable to >> the WG to integrate the new use case that focusses on "Neighborhood Energy >> Gateways", see the description of this use case in the email that I sent to >> the list on the 24th of June 2012 with the Home Energy Gateways use case >> (Section 2.7). >> >> Mouli, is it possible to add the following (or a modified version of >> this) paragraph in Section 2.7: >> >> "This use case can also be applied in neighborhoods, where the eman >> target devices are neighborhood energy gateways. These neighborhood energy >> gateways can collect power consumption of a home via the home energy >> gateway and possibly report the metering reading to the utility. " >> >> Best regards, >> Georgios >> >> >> ________________________________________ >> Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens Mouli >> Chandramouli (moulchan) [moulchan@cisco.com] >> Verzonden: maandag 22 oktober 2012 7:53 >> To: eman@ietf.org >> Onderwerp: Re: [eman] I-D Action: >> draft-ietf-eman-applicability-statement-02.txt >> >> Hello all, >> >> An updated version of the applicability statement has been submitted. >> >> Several editorial changes to improve the readability of the draft and >> also consolidating the section on the related standards from the >> requirements to applicability statement >> >> http://www.ietf.org/mail-archive/web/eman/current/msg01595.html >> >> The only remaining open issue is - the applicability of ASHRAE 201P >> standards to EMAN. Are any concepts that can be reused ? >> >> which we hope address after the WG meeting. >> >> Please send your comments. >> >> Thanks >> Brad, Bruce and Mouli >> >> >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Friday, October 19, 2012 6:47 PM >> To: i-d-announce@ietf.org >> Cc: eman@ietf.org >> Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Energy Management Working Group of the >> IETF. >> >> Title : Energy Management (EMAN) Applicability Statement >> Author(s) : Brad Schoening >> Mouli Chandramouli >> Bruce Nordman >> Filename : draft-ietf-eman-applicability-statement-02.txt >> Pages : 30 >> Date : 2012-10-19 >> >> Abstract: >> The objective of Energy Management (EMAN) is to provide an >> energy management framework for networked devices. This >> document presents the applicability of the EMAN framework to a >> variety of scenarios. This document lists use cases and target >> devices that can potentially implement the EMAN framework and >> associated SNMP MIB modules. These use cases are useful for >> identifying requirements for the framework and MIBs. Further, >> we describe the relationship of the EMAN framework to relevant >> other energy monitoring standards and architectures. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-02 >> >> A diff from the previous version is available at: >> >> http://www.ietf.org/rfcdiff?url2=draft-ietf-eman-applicability-statement-02 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >> > > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > *nordman.lbl.gov* > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --bcaec5014a43fee25d04cddb1c04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Georgios--

=A0 Thanks much for the clarification.
=A0 The example= you point to is about utility meter data for billing.
I am not familiar= with the technology issues around revenue meters
and with protocols for= moving that data to the utility.=A0 However, since
large amounts of money are at stake with revenue meters, and there
are e= xisting standards for accuracy and other characteristics for such
device= s (none of which we reference), I think this is outside of territory
that EMAN should tread into.
=A0 If data are not to be used for billing = then I think existing EMAN use
cases cover this.=A0 I agree that collect= ing data across multiple meters
(generic meters, not utility meters in t= heir utility role) is useful and part
of our scope.

--Bruce

On Tue, Nov = 6, 2012 at 11:11 AM, <karagian@cs.utwente.nl> wrote:

Hi Brad, Hi Bruce,

=A0

You are right, the term Neighborhood Energy Gateways is not a typically = used term. I was actually refering to "Collectors" used in neighb= orhoods, as example see:

=A0

https://www.ieso.ca/imoweb/sitesha= red/smart_meter_information_loop.asp?sid=3Dic

=A0

Note however, that this "Collectors", are used in the current = power grid and are not only used to collect data that will be used for bill= ing!

=A0

Bruce, what about the following text that could be included in Section 2= .7 of the applicability draft:

=A0

"This use case can also be applied in neighborhoods, where the eman= target devices are energy "collector" gateways. These energy &qu= ot;collector" gateways can collect power consumption of a home via the= home energy gateway and possibly report the metering reading to the smart meter data repository. "

=A0

Best regards,

Georgios

=A0

Van= : Brad Schoening [brads@coraid.com]
Verzonden: dinsdag 6 november 2012 15:25
To: Bruce Nordman; Karagiannis, G. (EWI)
Cc: eman@ietf.org=

Onderwerp: Re: [eman] I-D Action: draft-ietf-eman-applicability-stat= ement-02.txt


I agree with Bruce here that I am unfamiliar with this terminology. = =A0When I search this term on Google ("neighborhood energy gateway&quo= t;), I see only 8 results; 5 related to our EMAN mailing list discussion wi= th Giorgios, and 3 related to an iOS game called Shadow Cities. =A0If this term is not in common use, including it in the A= pplicability statement would likely confuse readers.

You text proposes "where the eman target devices are neighborhood= energy gateways.". =A0Can you provide us some=A0examples of companies= that produce and sell products known as NEGs?

Regards,

Brad

From: Bruce Nordman <bnordman@lbl.gov>
Date: Tue, 6 Nov 2012 07:45:36 -060= 0
To: "karagian@cs.utwente.nl" <karagian@cs.utwent= e.nl>
Cc: "eman@ietf.org" <eman@ietf.org>
Subject: Re: [eman] I-D Action: dra= ft-ietf-eman-applicability-statement-02.txt

Giorgios--

=A0I think some text could be added on this to 2.7 as you suggest,
but I have two questions/concerns about the text you propose.

=A0 First is that I am not familiar with the term 'neighborhood energy<= br> gateway' (NEG).=A0 Is it a grid entity, or a meter at the edge of a gri= d (as
a ordinary building meter is) with the downstream infrastructure
not part of the utility grid?=A0 Some clarity would be needed so that
readers can be sure to understand correctly what you mean.

=A0 The second concern is on reporting to the utility.=A0 Nowhere in
the current draft do we speak to sending EMAN data to a utility.
Many standards organizations are active in utility/grid issues and
there are many considerations that do nor arise within
buildings.=A0 I am not active in this area, but know people
who are, and there are many considerations we have not
addressed.=A0 Utility meters are used for billing purposes and
there are standards that address what "revenue grade" meters
must do.=A0 I don't think that EMAN should tread into this area.
If a NEG Is part of the grid, I also don't think we should address
it.=A0 If not part of the grid, then fine to do so.

All that said, someone could use EMAN data and pass it to a
utility, but they then have the burden of considering what the
utility needs or wants for data.=A0 That applies to any EMAN data,
NEG and otherwise.

Might you be able to propose alternate text which brings the
NEG concept in but addresses these concerns?
Thanks,

--Bruce



On Sun, Nov 4, 2012 at 4:23 PM, <karagian@= cs.utwente.nl> wrote:
Hi all,

>From what I remember, during the IETF in Vancouver, it was acceptable to th= e WG to integrate the new use case that focusses on "Neighborhood Ener= gy Gateways", see the description of this use case in the email that I= sent to the list on the 24th of June 2012 with the Home Energy Gateways use case (Section 2.7).

Mouli, is it possible to add the following (or a modified version of this) = paragraph in Section 2.7:

"This use case can also be applied in neighborhoods, where the eman ta= rget devices are neighborhood energy gateways. These neighborhood energy ga= teways can collect power consumption of a home via the home energy gateway = and possibly report the metering reading to the utility. "

Best regards,
Georgios


________________________________________
Van: eman-bounce= s@ietf.org [= eman-bounces@ietf.org] namens Mouli Chandramouli (moulchan) [moulchan@cisco.com]
Verzonden: maandag 22 oktober 2012 7:53
To: eman@ietf.org Onderwerp: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-0= 2.txt

Hello all,

An updated version of the applicability statement has been submitted.

Several editorial changes to improve the readability of the draft and also = consolidating the section on the related standards from the requirements to= applicability statement

http://www.ietf.org/mail-archive/web/eman/current/msg015= 95.html

The only remaining open issue is - =A0the applicability of ASHRAE 201P stan= dards to EMAN. =A0Are any concepts that can be reused ?

which we hope address after the WG meeting.

Please send your comments.

Thanks
Brad, Bruce and Mouli


-----Original Message-----
From: eman-bounc= es@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of internet-draf= ts@ietf.org
Sent: Friday, October 19, 2012 6:47 PM
To: i-d-announce= @ietf.org
Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Energy Management Working Group of the = IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Energy Management (EMAN) Applic= ability Statement
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Brad Schoening
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mouli Chandramouli
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bruce Nordman
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-eman-applicability-sta= tement-02.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 30
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-19

Abstract:
=A0 =A0 =A0 =A0 The objective of Energy Management (EMAN) is to provide an<= br> =A0 =A0 =A0 =A0 energy management framework for networked devices. =A0This<= br> =A0 =A0 =A0 =A0 document presents the applicability of the EMAN framework t= o a
=A0 =A0 =A0 =A0 variety of scenarios. =A0This document lists use cases and = target
=A0 =A0 =A0 =A0 devices that can potentially implement the EMAN framework a= nd
=A0 =A0 =A0 =A0 associated SNMP MIB modules. =A0These use cases are useful = for
=A0 =A0 =A0 =A0 identifying requirements for the framework and MIBs. =A0Fur= ther,
=A0 =A0 =A0 =A0 we describe the relationship of the EMAN framework to relev= ant
=A0 =A0 =A0 =A0 other energy monitoring standards and architectures.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ema= n-applicability-statement

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-applica= bility-statement-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-i= etf-eman-applicability-statement-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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



--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov<= br> 510-4= 86-7089
m: 51= 0-501-7943




--
Bru= ce Nordman
Lawrence Berkel= ey National Laboratory
nordman.lbl.gov=
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--bcaec5014a43fee25d04cddb1c04-- From jparello@cisco.com Tue Nov 6 14:42:47 2012 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 0DB1F21F8BB5 for ; Tue, 6 Nov 2012 14:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9YUs+66n1W8 for ; Tue, 6 Nov 2012 14:42:45 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8C19721F8B8C for ; Tue, 6 Nov 2012 14:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26563; q=dns/txt; s=iport; t=1352241764; x=1353451364; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7Y5q2nyZ76xdawK4ALN1fS+86T5e+9l77KOxliBFIjQ=; b=gkz/YELq8FriZdy9HBnu81SUc1oyXFglMfEzX4I/TtnUQqggHohsnc6x sHhrUpFlXVSlDb32ZxS+u6cPgghm9AbedikzhnvEfMs+ctoHLDXf4sScK eJUnzv/XDyAi98OlshITtaUYzTY1ib5vZQLRTsO+PDw3Vmh98mT2f3ewB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFAO2RmVCtJXG9/2dsb2JhbABBA4JJuCUBiGeBCIIeAQEBBAEBAQ8BWwQHDAQCAQgOAwMBAQEhBwcnCxQJCAIEDgUJGYdoC5szj2KQL4wDGgGDEIJJYQOVe4EcjT2Ba4JvgWQX X-IronPort-AV: E=Sophos;i="4.80,724,1344211200"; d="scan'208,217";a="139473217" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 06 Nov 2012 22:42:40 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA6MgeWY006780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 22:42:40 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.95]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 16:42:40 -0600 From: "John Parello (jparello)" To: Bruce Nordman Thread-Topic: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt Thread-Index: AQHNvG4sveHv0OlKw0mQFaT7Q1+O/ZfdZzCF Date: Tue, 6 Nov 2012 22:42:39 +0000 Message-ID: <94DAAA1A-E584-4762-96EC-78C05E811471@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--65.213100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_94DAAA1AE584476296EC78C05E811471ciscocom_" MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 22:42:47 -0000 --_000_94DAAA1AE584476296EC78C05E811471ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So are we saying that a utility grade meter that connects a network would r= eport its data in a different format? Why preclude a revenue grade meter from participating and exposing informat= ion this way? I've seen/worked with SNMP capable utility meters on cogen units. Why would= n't it be applicable to report the energy the same way as the devices conne= cted to them? Jp Sent from my iPad (expect ridiculous spelling mistakes) On Nov 6, 2012, at 5:29 PM, "Bruce Nordman" > wrote: Georgios-- Thanks much for the clarification. The example you point to is about utility meter data for billing. I am not familiar with the technology issues around revenue meters and with protocols for moving that data to the utility. However, since large amounts of money are at stake with revenue meters, and there are existing standards for accuracy and other characteristics for such devices (none of which we reference), I think this is outside of territory that EMAN should tread into. If data are not to be used for billing then I think existing EMAN use cases cover this. I agree that collecting data across multiple meters (generic meters, not utility meters in their utility role) is useful and pa= rt of our scope. --Bruce On Tue, Nov 6, 2012 at 11:11 AM, > wrote: Hi Brad, Hi Bruce, You are right, the term Neighborhood Energy Gateways is not a typically use= d term. I was actually refering to "Collectors" used in neighborhoods, as e= xample see: https://www.ieso.ca/imoweb/siteshared/smart_meter_information_loop.asp?sid= =3Dic Note however, that this "Collectors", are used in the current power grid an= d are not only used to collect data that will be used for billing! Bruce, what about the following text that could be included in Section 2.7 = of the applicability draft: "This use case can also be applied in neighborhoods, where the eman target = devices are energy "collector" gateways. These energy "collector" gateways = can collect power consumption of a home via the home energy gateway and pos= sibly report the metering reading to the smart meter data repository. " Best regards, Georgios ________________________________ Van: Brad Schoening [brads@coraid.com] Verzonden: dinsdag 6 november 2012 15:25 To: Bruce Nordman; Karagiannis, G. (EWI) Cc: eman@ietf.org Onderwerp: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-0= 2.txt I agree with Bruce here that I am unfamiliar with this terminology. When I= search this term on Google ("neighborhood energy gateway"), I see only 8 r= esults; 5 related to our EMAN mailing list discussion with Giorgios, and 3 = related to an iOS game called Shadow Cities. If this term is not in common= use, including it in the Applicability statement would likely confuse read= ers. You text proposes "where the eman target devices are neighborhood energy ga= teways.". Can you provide us some examples of companies that produce and s= ell products known as NEGs? Regards, Brad From: Bruce Nordman > Date: Tue, 6 Nov 2012 07:45:36 -0600 To: "karagian@cs.utwente.nl" > Cc: "eman@ietf.org" > Subject: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.= txt Giorgios-- I think some text could be added on this to 2.7 as you suggest, but I have two questions/concerns about the text you propose. First is that I am not familiar with the term 'neighborhood energy gateway' (NEG). Is it a grid entity, or a meter at the edge of a grid (as a ordinary building meter is) with the downstream infrastructure not part of the utility grid? Some clarity would be needed so that readers can be sure to understand correctly what you mean. The second concern is on reporting to the utility. Nowhere in the current draft do we speak to sending EMAN data to a utility. Many standards organizations are active in utility/grid issues and there are many considerations that do nor arise within buildings. I am not active in this area, but know people who are, and there are many considerations we have not addressed. Utility meters are used for billing purposes and there are standards that address what "revenue grade" meters must do. I don't think that EMAN should tread into this area. If a NEG Is part of the grid, I also don't think we should address it. If not part of the grid, then fine to do so. All that said, someone could use EMAN data and pass it to a utility, but they then have the burden of considering what the utility needs or wants for data. That applies to any EMAN data, NEG and otherwise. Might you be able to propose alternate text which brings the NEG concept in but addresses these concerns? Thanks, --Bruce On Sun, Nov 4, 2012 at 4:23 PM, > wrote: Hi all, >From what I remember, during the IETF in Vancouver, it was acceptable to th= e WG to integrate the new use case that focusses on "Neighborhood Energy Ga= teways", see the description of this use case in the email that I sent to t= he list on the 24th of June 2012 with the Home Energy Gateways use case (Se= ction 2.7). Mouli, is it possible to add the following (or a modified version of this) = paragraph in Section 2.7: "This use case can also be applied in neighborhoods, where the eman target = devices are neighborhood energy gateways. These neighborhood energy gateway= s can collect power consumption of a home via the home energy gateway and p= ossibly report the metering reading to the utility. " Best regards, Georgios ________________________________________ Van: eman-bounces@ietf.org [eman-bounces@ietf= .org] namens Mouli Chandramouli (moulchan) [m= oulchan@cisco.com] Verzonden: maandag 22 oktober 2012 7:53 To: eman@ietf.org Onderwerp: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-0= 2.txt Hello all, An updated version of the applicability statement has been submitted. Several editorial changes to improve the readability of the draft and also = consolidating the section on the related standards from the requirements to= applicability statement http://www.ietf.org/mail-archive/web/eman/current/msg01595.html The only remaining open issue is - the applicability of ASHRAE 201P standa= rds to EMAN. Are any concepts that can be reused ? which we hope address after the WG meeting. Please send your comments. Thanks Brad, Bruce and Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-boun= ces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Friday, October 19, 2012 6:47 PM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Energy Management (EMAN) Applicability Statement Author(s) : Brad Schoening Mouli Chandramouli Bruce Nordman Filename : draft-ietf-eman-applicability-statement-02.txt Pages : 30 Date : 2012-10-19 Abstract: The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN framework to a variety of scenarios. This document lists use cases and target devices that can potentially implement the EMAN framework and associated SNMP MIB modules. These use cases are useful for identifying requirements for the framework and MIBs. Further, we describe the relationship of the EMAN framework to relevant other energy monitoring standards and architectures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-applicability-statement-= 02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman --_000_94DAAA1AE584476296EC78C05E811471ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
So are we saying that a utility grade meter that connects a network wo= uld report its data in a different format?

Why preclude a revenue grade meter from participating and exposing inf= ormation this way?

I've seen/worked with SNMP capable utility meters on cogen units. Why = wouldn't it be applicable to report the energy the same way as the devices = connected to them?


Jp

Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Nov 6, 2012, at 5:29 PM, "Bruce Nordman" <bnordman@lbl.gov> wrote:

Georgios--

  Thanks much for the clarification.
  The example you point to is about utility meter data for billing. I am not familiar with the technology issues around revenue meters
and with protocols for moving that data to the utility.  However, sinc= e
large amounts of money are at stake with revenue meters, and there
are existing standards for accuracy and other characteristics for such
devices (none of which we reference), I think this is outside of territory<= br> that EMAN should tread into.
  If data are not to be used for billing then I think existing EMAN us= e
cases cover this.  I agree that collecting data across multiple meters=
(generic meters, not utility meters in their utility role) is useful and pa= rt
of our scope.

--Bruce

On Tue, Nov 6, 2012 at 11:11 AM, <karagian= @cs.utwente.nl> wrote:

Hi Brad, Hi Bruce,

 

You are right, the term Neighborhood Energy Gateways is not a typically = used term. I was actually refering to "Collectors" used in neighb= orhoods, as example see:

 

https://www.ieso.ca/imoweb/sitesha= red/smart_meter_information_loop.asp?sid=3Dic

 

Note however, that this "Collectors", are used in the current = power grid and are not only used to collect data that will be used for bill= ing!

 

Bruce, what about the following text that could be included in Section 2= .7 of the applicability draft:

 

"This use case can also be applied in neighborhoods, where the eman= target devices are energy "collector" gateways. These energy &qu= ot;collector" gateways can collect power consumption of a home via the= home energy gateway and possibly report the metering reading to the smart meter data repository. "

 

Best regards,

Georgios

 

Van= : Brad Schoening [brads@coraid.com]
Verzonden: dinsdag 6 november 2012 15:25
To: Bruce Nordman; Karagiannis, G. (EWI)
Cc: eman@ietf.org=

Onderwerp: Re: [eman] I-D Action: draft-ietf-eman-applicability-stat= ement-02.txt


I agree with Bruce here that I am unfamiliar with this terminology. &n= bsp;When I search this term on Google ("neighborhood energy gateway&qu= ot;), I see only 8 results; 5 related to our EMAN mailing list discussion w= ith Giorgios, and 3 related to an iOS game called Shadow Cities.  If this term is not in common use, including it in th= e Applicability statement would likely confuse readers.

You text proposes "where the eman target devices are neighborhood= energy gateways.".  Can you provide us some examples of com= panies that produce and sell products known as NEGs?

Regards,

Brad

From: Bruce Nordman <bnordman@lbl.gov>
Date: Tue, 6 Nov 2012 07:45:36 -060= 0
To: "karagian@cs.utwente.nl" <karagian@cs.utwent= e.nl>
Cc: "eman@ietf.org" <eman@ietf.org>
Subject: Re: [eman] I-D Action: dra= ft-ietf-eman-applicability-statement-02.txt

Giorgios--

 I think some text could be added on this to 2.7 as you suggest,
but I have two questions/concerns about the text you propose.

  First is that I am not familiar with the term 'neighborhood energy gateway' (NEG).  Is it a grid entity, or a meter at the edge of a grid= (as
a ordinary building meter is) with the downstream infrastructure
not part of the utility grid?  Some clarity would be needed so that readers can be sure to understand correctly what you mean.

  The second concern is on reporting to the utility.  Nowhere in<= br> the current draft do we speak to sending EMAN data to a utility.
Many standards organizations are active in utility/grid issues and
there are many considerations that do nor arise within
buildings.  I am not active in this area, but know people
who are, and there are many considerations we have not
addressed.  Utility meters are used for billing purposes and
there are standards that address what "revenue grade" meters
must do.  I don't think that EMAN should tread into this area.
If a NEG Is part of the grid, I also don't think we should address
it.  If not part of the grid, then fine to do so.

All that said, someone could use EMAN data and pass it to a
utility, but they then have the burden of considering what the
utility needs or wants for data.  That applies to any EMAN data,
NEG and otherwise.

Might you be able to propose alternate text which brings the
NEG concept in but addresses these concerns?
Thanks,

--Bruce



On Sun, Nov 4, 2012 at 4:23 PM, <karagian@= cs.utwente.nl> wrote:
Hi all,

>From what I remember, during the IETF in Vancouver, it was acceptable to th= e WG to integrate the new use case that focusses on "Neighborhood Ener= gy Gateways", see the description of this use case in the email that I= sent to the list on the 24th of June 2012 with the Home Energy Gateways use case (Section 2.7).

Mouli, is it possible to add the following (or a modified version of this) = paragraph in Section 2.7:

"This use case can also be applied in neighborhoods, where the eman ta= rget devices are neighborhood energy gateways. These neighborhood energy ga= teways can collect power consumption of a home via the home energy gateway = and possibly report the metering reading to the utility. "

Best regards,
Georgios


________________________________________
Van: eman-bounce= s@ietf.org [= eman-bounces@ietf.org] namens Mouli Chandramouli (moulchan) [moulchan@cisco.com]
Verzonden: maandag 22 oktober 2012 7:53
To: eman@ietf.org Onderwerp: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-0= 2.txt

Hello all,

An updated version of the applicability statement has been submitted.

Several editorial changes to improve the readability of the draft and also = consolidating the section on the related standards from the requirements to= applicability statement

http://www.ietf.org/mail-archive/web/eman/current/msg015= 95.html

The only remaining open issue is -  the applicability of ASHRAE 201P s= tandards to EMAN.  Are any concepts that can be reused ?

which we hope address after the WG meeting.

Please send your comments.

Thanks
Brad, Bruce and Mouli


-----Original Message-----
From: eman-bounc= es@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of internet-draf= ts@ietf.org
Sent: Friday, October 19, 2012 6:47 PM
To: i-d-announce= @ietf.org
Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 This draft is a work item of the Energy Management Working Group of t= he IETF.

        Title           : Ener= gy Management (EMAN) Applicability Statement
        Author(s)       : Brad Schoening=
                     = ;     Mouli Chandramouli
                     = ;     Bruce Nordman
        Filename        : draft-iet= f-eman-applicability-statement-02.txt
        Pages           : 30         Date            := 2012-10-19

Abstract:
        The objective of Energy Management (EMAN) is to= provide an
        energy management framework for networked devic= es.  This
        document presents the applicability of the EMAN= framework to a
        variety of scenarios.  This document lists= use cases and target
        devices that can potentially implement the EMAN= framework and
        associated SNMP MIB modules.  These use ca= ses are useful for
        identifying requirements for the framework and = MIBs.  Further,
        we describe the relationship of the EMAN framew= ork to relevant
        other energy monitoring standards and architect= ures.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ema= n-applicability-statement

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-applica= bility-statement-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-i= etf-eman-applicability-statement-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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



--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov<= br> 5= 10-486-7089
m: 510-501-7943




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

_______________________________________________
eman mailing list
eman@ietf.org
https://www.ie= tf.org/mailman/listinfo/eman
--_000_94DAAA1AE584476296EC78C05E811471ciscocom_-- From Quittek@neclab.eu Tue Nov 6 14:51:56 2012 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 7360621F8B8C for ; Tue, 6 Nov 2012 14:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.064 X-Spam-Level: X-Spam-Status: No, score=-103.064 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SXLIFE=1.07, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QSFeJwMOfI5 for ; Tue, 6 Nov 2012 14:51:55 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E8EB421F8B69 for ; Tue, 6 Nov 2012 14:51:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5C070102456; Tue, 6 Nov 2012 23:51:54 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7t9KHva-gCx; Tue, 6 Nov 2012 23:51:54 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 3815610245C; Tue, 6 Nov 2012 23:51:44 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 6 Nov 2012 23:51:23 +0100 From: Juergen Quittek To: "John Parello (jparello)" Thread-Topic: [eman] simplifying the support of multiple power state sets Thread-Index: AQHNvHEviJ3sCv7Pj0+PFAxzxDx2yw== Date: Tue, 6 Nov 2012 22:50:58 +0000 Message-ID: In-Reply-To: <2D99DB04-D708-4EB3-AD1D-7C3A655B589A@cisco.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] simplifying the support of multiple power state sets 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 Nov 2012 22:51:56 -0000 Hi John, On 06.11.12 12:16, "John Parello (jparello)" wrote: >Hi Juergen, > >Sorry you've had problems designing such a system. At Cisco and with the >EnergyWise program and partner system we have designs and deployments >that do not have this problem. We support multiple concurrent sets of >power levels (this group is calling them states now) with various vendors. > >Our partners and device manufacturers have had no problems mapping the >DMTF, ACPI, Poe, PWG, Cisco, and manufacturer specific states. (see >Cisco,Lenovo, Xerox, Schneider APC, Raritan etc..) simultaneously. I explicitly wrote that we did not have a problem mapping DMTF and ACPI states, but we ran into problems mapping (1) ASHRAE states and (2) states not covered by these sets. It looks like this is a problem that you and your partners have not addressed yet. >In fact it's been very usable by our management partners who have >implemented EnMS' on such a scheme. (see Joulex, Cisco Prime, Verdiem, CA >Nimsoft, IBM Tivoli) > >Your premise that you do not have corresponding states between sets of >states is one that can be loosened when you look at overlapping ranges of >state. Again we've been doing this for four with years now with about 85 >partners now and thousands of devices deployed under management. Can you explain how you solved the problem by "looking at overlapping ranges"?. >So if you make a requirement that we can't do multiple states at the same >time you'd be negating our work and design. Not at all. I just say that I cannot do it in my case. I have no doubt that your case is fully working. And again, we had no problems mapping state sets that fit well to each other, such as ACPI and DMTF. And I do not make new requirement, I just claim that I have problems with meeting a requirement. I'll gladly take your advice on any solution. >The requirement doc should not dictate implementation. I fully agree. But the tighter the requirement, the stronger the 'dictate'. I argue about relaxing the requirement and having less 'dictated'. Thus you should be glad I'm doing so, if you care about implementation flexibility. >I think by stating that a device should be able to support multiple power >state sets that is enough. Yes, this is what I suggested. Thanks. >The fact that they are simultaneous or not is a limitation of some device >but please don't limit it in the requirements for those of us who can. Yes. The requirements are I suggested are less limiting, not more limiting. >The proposal you have is more relevant as an implementation discussion >not a requirements discussion. Fully agreed. > In that light thanks for the impementation proposal below, can you >provide an example much like the tables we showed in our work in the >framework over the past two years on this issue that shows your proposal. >=20 >I'd like to make sure that for those of us who can and are doing this >mapping as a matter of course can still be able to without a long >cumbersome list. Yes, I will send you the cases. I think I your funny term "those of us who can" does not make the point. I said that I can do the mappings you did. My problem occurred with mappings you did not do.=20 >Without that example I feel we are just thrashing an issue which we've >shown in running code and stated in nearly two years of discussion here. I don't want to trash anything. However, if I have a technical concern, I will speak up, independent of the number of customers that you have. Let's continue the discussion in a separate email where I will elaborate the case. I hope you can help me solving it and then there will be no issue anymore. Thanks, Juergen >Jp > >Design references > >http://www.cisco.com/en/US/docs/solutions/Enterprise/Borderless_Networks/E >nergy_Management/energywisedg.html > >Manufacturers and EnMS references > >http://www.cisco.com/en/US/prod/switches/ps5718/ps10195/energywise_partner >_ecosystem.html > > > =20 >Sent from my iPad=20 >(expect ridiculous spelling mistakes) > >On Nov 5, 2012, at 7:46 PM, "Juergen Quittek" wrote: > >> Dear all, >>=20 >> I would like to re-open a closed issue: the concurrent support of >> multiple power sets. Curently our requirements documents states >> in section 5.4: >> "In order to support multiple management >> systems possibly using different Power State sets, while >> simultaneously interfacing with a particular entity, the energy >> management standard must provide means for supporting multiple Power >> State sets used simultaneously at an entity." >>=20 >> When trying to design such a system at NEC, we ran into several >> problems that made us doubt whether this requirements is wisely >> chosen. >>=20 >> The problem arises from the issue that not for all states in a >> power state set A there is necessarily a corresponding state in >> power set B and/or vice versa. >>=20 >> The problem is which power state to report for set B if the device >> is set to a power state of set A that cannot be mapped to any state >> of set B? Fortunately, the DMTF has all of its state more or less >> mappable to ACPI states, but as soon as we include ASHRAE states, >> this is gone. >>=20 >> One solution would be extending each set by a generic power state >> that is called "non-supported-by-this-set". >>=20 >> Another solution would be to give up supporting multiple state sets >> concurrently. >>=20 >>=20 >> I would like to make a simple proposal that would still allow a >> device to support multiple sets, just not at the same time. >> It implies de-regulating power set support and gives a bit more >> freedom to implementers. >>=20 >> The proposal is >> - Having all power states registered at IANA with a unique number >> The membership of a power state set can be indicated by just an >> attribute in the IANA registration. >> - Allowing devices to implement any subset of IANA registered >> power states (independent of power state sets). >> - Requiring a device to provide a list of all power states it >> implemens. >> - Requiring a device to be in exactly one power state at a time >> (I don't claim the proposal is new. Probably it has already been >> made already on the list in earlier discussions by someone else.) >>=20 >> This would support the following options: >>=20 >> 1. We can still have power state sets. They would consist of all >> power states registered at IANA with the same power state set >> attribute. >>=20 >> 2. We can have a device implementing exactly one set by implementing >> all power states that are registered at IANA with the same power >> state set attribute. >>=20 >> 3. We can extend power sets if needed, by just adding one more state >> with the same power state set attribute to the IANA registry. >>=20 >> 4. We can have devices supporting only a subset of a single power >> state set. The device would indicate to any management system >> which states it supports. >>=20 >> 5. We can have a device supproting two or more power state sets. >> It would just implement all or a subset of all states in multiple >> power sets. Management systems that can operate on just a single >> set would use only power states belonging to the set that they know. >>=20 >> 6. We can even have manfacturers creating private extensions of >> standard power state sets by supporting all states of a set and >> additional states that are in the standard set, but have been >> registered individually by the manufacturer. This provides >> extensibility to device types we did not consider today or to new >> power saving technologies that lead to new power states. >>=20 >> 7. If we want we can further allow proprietary power states that >> are not registered at IANA. For these we would have to reserve a >> number space. >>=20 >> 8. We can still make recommendations that certain devices types >> should implement certain power state sets. >>=20 >> The only drawback I see compared to the current solution occurs in >> the situation of multiple management systems managing the device >> using different power states. If one management system wants the >> device to be in a certain state of a cretain set and another >> managament system want to have it in another state of a different >> set, then the device may be permanently swapping power states. >>=20 >> What do people on this list think about the proposed simplification? >>=20 >> Dear all, >>=20 >> I would like to re-open a closed issue: the concurrent support of >> multiple power sets. Curently our requirements documents states >> in section 5.4: >> "In order to support multiple management >> systems possibly using different Power State sets, while >> simultaneously interfacing with a particular entity, the energy >> management standard must provide means for supporting multiple Power >> State sets used simultaneously at an entity." >>=20 >> When trying to design such a system at NEC, we ran into several >> problems that made us doubt whether this requirements is wisely >> chosen. >>=20 >> The problem arises from the issue that not for all states in a >> power state set A there is necessarily a corresponding state in >> power set B and/or vice versa. >>=20 >> The problem is which power state to report for set B if the device >> is set to a power state of set A that cannot be mapped to any state >> of set B? Fortunately, the DMTF has all of its state more or less >> mappable to ACPI states, but as soon as we include ASHRAE states, >> this is gone. >>=20 >> One solution would be adding a generic power state to each set that >> is called "non-supported-by-this-set". >>=20 >> Another solution would be to give up supporting multiple state sets >> concurrently. >>=20 >>=20 >> I would like to make a simple proposal that still allows a >> device to support multiple sets, just not at the same time. >> It implies de-regulating power set support and gives a bit more >> freedom to implementers. >>=20 >> The proposal is >> - Having all power states registered at IANA with a unique number >> The membership of a power state set can be indicated by just an >> attribute in the IANA registration. >> - Allowing devices to implement any subset of IANA registered >> power states (independent of power state sets). >> - Requiring a device to provide a list of all power states it >> implemens. >> - Requiring a device to be in exactly one power state at a time >> (I don't claim the proposal is new. Probably it has already been >> made already on the list in earlier discussions by someone else.) >>=20 >> This would support the following options: >>=20 >> 1. We can still have power state sets. They would consist of all >> power states registered at IANA with the same power state set >> attribute. >>=20 >> 2. We can have a device implementing exactly one set by implementing >> all power states that are registered at IANA with the same power >> state set attribute. >>=20 >> 3. We can extend power sets if needed, by just adding one more state >> with the same power state set attribute to the IANA registry. >>=20 >> 4. We can have devices supporting only a subset of a single power >> state set. The device would indicate to any management system >> which states it supports. >>=20 >> 5. We can have a device supproting two or more power state sets. >> It would just implement all or a subset of all states in multiple >> power sets. Management systems that can operate on just a single >> set would use only power states belonging to the set that they know. >>=20 >> 6. We can even have manfacturers creating private extensions of >> standard power state sets by supporting all states of a set and >> additional states that are in the standard set, but have been >> registered individually by the manufacturer. This provides >> extensibility to device types we did not consider today or to new >> power saving technologies that lead to new power states. >>=20 >> 7. If we want we can further allow proprietary power states that >> are not registered at IANA. For these we would have to reserve a >> number space. >>=20 >> 8. We can still make recommendations that certain devices types >> should implement certain power state sets. >>=20 >> The only drawback I see compared to the current solution occurs in >> the situation of multiple management systems managing the device >> using different power states. If one management system wants the >> device to be in a certain state of a cretain set and another >> managament system want to have it in another state of a different >> set, then the device may be permanently swapping power states. >>=20 >>=20 >> Implied changes in the requirements draft would be: >> Section 5.4 Power State >> OLD >> "In order to support multiple management >> systems possibly using different Power State sets, while >> simultaneously interfacing with a particular entity, the energy >> management standard must provide means for supporting multiple Power >> State sets used simultaneously at an entity." >> NEW >> "In order to support multiple management >> systems possibly using different Power State sets, the energy >> management standard must provide means for supporting multiple Power >> State sets at an entity." >>=20 >> 5.4.3. Multiple Power State sets >> OLD >> "The standard must provide means for supporting multiple Power State >> sets simultaneously at an entity." >> NEW >> "The standard must provide means for supporting multiple Power State >> sets at an entity." >>=20 >> 5.4.4. List of supported Power State sets >> Delete requirement, because it is implicitly covered by >> requirement 5.4.2 (List of supported Power States) >>=20 >> 5.4.5. List of supported Power States within a set >> Delete requirement, because it is implicitly covered by >> requirement 5.4.2 (List of supported Power States) >>=20 >>=20 >> What do people on this list think about the proposed simplification? >>=20 >> Thanks, >> Juergen >>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman From bnordman@lbl.gov Tue Nov 6 15:05:20 2012 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 CC49B21F8B77 for ; Tue, 6 Nov 2012 15:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsBROPvYXyDL for ; Tue, 6 Nov 2012 15:05:20 -0800 (PST) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC4921F8ACC for ; Tue, 6 Nov 2012 15:05:20 -0800 (PST) X-Ironport-SBRS: 2.2 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYEAGaWmVDRVdhGemdsb2JhbABBA4JJuCYBiF8IIwEBCwkMCBQEI4IeAQEEAXkFCwsEAQY7IhIBBQEcBhMIh3wGnQuOHZAsjAODK4MqA4hajSGBHI1HFimELw X-IronPort-AV: E=Sophos;i="4.80,724,1344236400"; d="scan'208";a="1947643" Received: from mail-qa0-f70.google.com ([209.85.216.70]) by fe1.lbl.gov with ESMTP; 06 Nov 2012 15:05:19 -0800 Received: by mail-qa0-f70.google.com with SMTP id s11so340436qaa.1 for ; Tue, 06 Nov 2012 15:05:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/owlqa6UxuEIFKz6waZHdKsqdgTxAoFaMx8KcbBlsno=; b=jG+ODMNpG4z0sQVlzdhKlHR99Ik4z+nxP4VTPa2MHuXjFD6m/17qFwqAXDdQdkYS1z BftyF10wbEBEq24H+22atPN+qjtW0/XpJRGP0fSNEvUoutVAyWPMS9lonlFwoFyh/qhf oGggaX0YQvyQp1QpnTnRs2WnxJ3wIqYHeOMgNmctvuS9JdPNzX2HqUCbrQ71ObRBxI3U iP0o8Wcqal7PQ9b+ndG4DuLbIqRPWK/zEuh0WM67+5QO8xkF4TR01pu4v3rxDmGN8jy6 y9WnJJUjKKoQUdtmwt+FuvaekBu00HBYjdkQJDnd1BEs8ifGh6RYZK2qv/XBg6Wbi+GS LbRQ== Received: by 10.52.179.2 with SMTP id dc2mr2123709vdc.50.1352243119282; Tue, 06 Nov 2012 15:05:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.179.2 with SMTP id dc2mr2123704vdc.50.1352243119210; Tue, 06 Nov 2012 15:05:19 -0800 (PST) Received: by 10.58.15.234 with HTTP; Tue, 6 Nov 2012 15:05:19 -0800 (PST) In-Reply-To: <94DAAA1A-E584-4762-96EC-78C05E811471@cisco.com> References: <94DAAA1A-E584-4762-96EC-78C05E811471@cisco.com> Date: Tue, 6 Nov 2012 18:05:19 -0500 Message-ID: From: Bruce Nordman To: "John Parello (jparello)" Content-Type: multipart/alternative; boundary=bcaec5014a43c542cd04cddba263 X-Gm-Message-State: ALoCoQkO7+V61AwRkoDuxTz06PFAdcgZ829jnS6mM09KhPmuesQ7dhLeIuk2YiIhAyZ+ePoX9LjAcW4qwwlpLIHE4X35zuY/03XWzgp0P0a57svrxXUcAvFExqFpsG+KLVU1tnXOWM6V Cc: "eman@ietf.org" Subject: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 23:05:20 -0000 --bcaec5014a43c542cd04cddba263 Content-Type: text/plain; charset=ISO-8859-1 My concern is not with utility grade meters. Rather, my concern is reporting to utilities and for revenue purposes. Having an actual utility meter reporting to the building for local purposes seems fine to me, so I think we agree. --Bruce On Tue, Nov 6, 2012 at 5:42 PM, John Parello (jparello) wrote: > So are we saying that a utility grade meter that connects a network > would report its data in a different format? > > Why preclude a revenue grade meter from participating and exposing > information this way? > > I've seen/worked with SNMP capable utility meters on cogen units. Why > wouldn't it be applicable to report the energy the same way as the devices > connected to them? > > > Jp > ... > -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --bcaec5014a43c542cd04cddba263 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My concern is not with utility grade meters.
Rather, my concern is repor= ting to utilities and for revenue purposes.
Having an actual utility met= er reporting to the building for local
purposes seems fine to me, so I t= hink we agree.
--Bruce

On Tue, Nov 6, 2012 at 5:42 PM, J= ohn Parello (jparello) <jparello@cisco.com> wrote:
So are we saying that a utility grade meter that connects a network wo= uld report its data in a different format?

Why preclude a revenue grade meter from participating and exposing inf= ormation this way?

I've seen/worked with SNMP capable utility meters on cogen units. = Why wouldn't it be applicable to report the energy the same way as the = devices connected to them?


Jp
...


--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordma= n.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--bcaec5014a43c542cd04cddba263-- From jparello@cisco.com Tue Nov 6 15:40:15 2012 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 8F71221F8BD4 for ; Tue, 6 Nov 2012 15:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYHpXS6R13V3 for ; Tue, 6 Nov 2012 15:40:14 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AF93021F8BB9 for ; Tue, 6 Nov 2012 15:40:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3729; q=dns/txt; s=iport; t=1352245214; x=1353454814; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3t25nS29Eu+qrW4G+FCD0VUCpTpsgZjb1bdJmT9jJ4o=; b=Kha8qmktyRaJkNfyw9BgHb34ckjjk3Z4BN1VhjSMjcPxjUnwzG5r2G9z F/q/AoEArimpPPzyEZszqcLwREoxw888vy0+jhzd2OTIHY2lLKSjYRBr8 Fgg5mFmOt0Db5dl6RPWehz0G62sGJOnCBIKvcE9nV77Hg3yuL84f0X6H5 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsFAG+fmVCtJXG//2dsb2JhbABBA4JJuDABiGeBCIIfAQEEEgFmEAIBCAQKMQcyFBECBA4FIodomzqPYpArjAODK4JJYQOVe4EcjT2Ba4Jv X-IronPort-AV: E=Sophos;i="4.80,725,1344211200"; d="scan'208,217";a="139543109" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 06 Nov 2012 23:40:14 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA6NeEIM000906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 23:40:14 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.95]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 17:40:13 -0600 From: "John Parello (jparello)" To: Bruce Nordman Thread-Topic: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt Thread-Index: AQHNvHM1nUsm1YYWhEaniGMeTfPZOpfddztq Date: Tue, 6 Nov 2012 23:40:13 +0000 Message-ID: <28E73130-D7E6-44C6-A313-7245A4E87EEA@cisco.com> References: <94DAAA1A-E584-4762-96EC-78C05E811471@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--42.401900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_28E73130D7E644C6A3137245A4E87EEAciscocom_" MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 23:40:15 -0000 --_000_28E73130D7E644C6A3137245A4E87EEAciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cool we agree. Sent from my iPad (expect ridiculous spelling mistakes) On Nov 6, 2012, at 6:05 PM, "Bruce Nordman" > wrote: My concern is not with utility grade meters. Rather, my concern is reporting to utilities and for revenue purposes. Yes Having an actual utility meter reporting to the building for local purposes seems fine to me, so I think we agree. Yes --Bruce On Tue, Nov 6, 2012 at 5:42 PM, John Parello (jparello) > wrote: So are we saying that a utility grade meter that connects a network would r= eport its data in a different format? Why preclude a revenue grade meter from participating and exposing informat= ion this way? I've seen/worked with SNMP capable utility meters on cogen units. Why would= n't it be applicable to report the energy the same way as the devices conne= cted to them? Jp ... -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --_000_28E73130D7E644C6A3137245A4E87EEAciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Cool we agree.

Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Nov 6, 2012, at 6:05 PM, "Bruce Nordman" <bnordman@lbl.gov> wrote:

My concern is not with utility grade meters.
Rather, my concern is reporting to utilities and for revenue purposes.
Yes

Having an actual utility meter reporting to the building for local
purposes seems fine to me, so I think we agree.
Yes 

--Bruce

On Tue, Nov 6, 2012 at 5:42 PM, John Parello (jp= arello) <jparello@cisco.= com> wrote:
So are we saying that a utility grade meter that connects a network wo= uld report its data in a different format?

Why preclude a revenue grade meter from participating and exposing inf= ormation this way?

I've seen/worked with SNMP capable utility meters on cogen units. Why = wouldn't it be applicable to report the energy the same way as the devices = connected to them?


Jp
...


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

--_000_28E73130D7E644C6A3137245A4E87EEAciscocom_-- From trac+eman@trac.tools.ietf.org Wed Nov 7 06:40:05 2012 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 8DC8D21F8B55 for ; Wed, 7 Nov 2012 06:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaepjVV6wXMm for ; Wed, 7 Nov 2012 06:40:03 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 45C7F21F8B4A for ; Wed, 7 Nov 2012 06:40:03 -0800 (PST) Received: from localhost ([127.0.0.1]:39924 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TW6n8-0007Fc-Ju; Wed, 07 Nov 2012 15:39:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: quittek@neclab.eu, bclaise@cisco.com, jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 07 Nov 2012 14:39:42 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/6#comment:5 Message-ID: <079.48477dc3f59763ae89e4f8dbac32ebf6@trac.tools.ietf.org> References: <064.3a9e930207302af0939a4d9d1c602749@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <064.3a9e930207302af0939a4d9d1c602749@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: quittek@neclab.eu, bclaise@cisco.com, jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #6: States and ASHRAE Curtailment levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:40:05 -0000 #6: States and ASHRAE Curtailment levels Comment (by n.brownlee@…): JQ: If you have two management systems, how to handle interlocking between them? In particular, what happens if they are using different sets of power states? (set A and set B) IANA 'power states' registry needs at least one 'unregistered' set of power states. BN: Also need an 'open' set so that users can create (and use) a locally- defined set of states. JQ will write some new text. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: quittek@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 7 06:45:08 2012 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 C75D521F8B5D for ; Wed, 7 Nov 2012 06:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tde9y4gr2Qia for ; Wed, 7 Nov 2012 06:45:08 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3427521F8B19 for ; Wed, 7 Nov 2012 06:45:08 -0800 (PST) Received: from localhost ([127.0.0.1]:40377 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TW6s5-0001K4-Ik; Wed, 07 Nov 2012 15:44:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz, quittek@neclab.eu, jparello@cisco.com X-Trac-Project: eman Date: Wed, 07 Nov 2012 14:44:49 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/7#comment:4 Message-ID: <079.30217aa3f6fccb956062082eea481101@trac.tools.ietf.org> References: <064.0286cc8ffe2a823c965c5977746402d8@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <064.0286cc8ffe2a823c965c5977746402d8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, quittek@neclab.eu, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #7: Clarify power interfaces X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:45:08 -0000 #7: Clarify power interfaces Changes (by n.brownlee@…): * status: new => closed * resolution: => fixed Comment: Agreed to use 4 (above). -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: bclaise Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 7 06:51:06 2012 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 5CDA521F8BAE for ; Wed, 7 Nov 2012 06:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rq0Zdz5jSTVh for ; Wed, 7 Nov 2012 06:51:06 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id C874621F8B35 for ; Wed, 7 Nov 2012 06:51:05 -0800 (PST) Received: from localhost ([127.0.0.1]:41023 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TW6y3-0004EQ-0z; Wed, 07 Nov 2012 15:50:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz, quittek@neclab.eu, jparello@cisco.com X-Trac-Project: eman Date: Wed, 07 Nov 2012 14:50:59 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/7#comment:5 Message-ID: <079.1ef6a0288b8b8dea64118b691d37376c@trac.tools.ietf.org> References: <064.0286cc8ffe2a823c965c5977746402d8@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <064.0286cc8ffe2a823c965c5977746402d8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, quittek@neclab.eu, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #7: Clarify power interfaces X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:51:06 -0000 #7: Clarify power interfaces Comment (by n.brownlee@…): Correction, use 4, but also mention 2. JQ will revise the text. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: bclaise Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 7 07:27:06 2012 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 029BA21F8BF4 for ; Wed, 7 Nov 2012 07:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npeBX0XsOAia for ; Wed, 7 Nov 2012 07:27:05 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 15AB121F8BF0 for ; Wed, 7 Nov 2012 07:27:05 -0800 (PST) Received: from localhost ([127.0.0.1]:44879 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TW7WU-00075n-Li; Wed, 07 Nov 2012 16:26:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: quittek@neclab.eu, jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 07 Nov 2012 15:26:34 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/8#comment:4 Message-ID: <079.8eb9f12bf45ecfdebb4291337222a329@trac.tools.ietf.org> References: <064.cbeb4b04599adc4564503ec585a112d7@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <064.cbeb4b04599adc4564503ec585a112d7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: quittek@neclab.eu, jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #8: List EMAN curtailment levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:27:06 -0000 #8: List EMAN curtailment levels Comment (by n.brownlee@…): Add an item on power states / curtailment levels for routers (eman has max levels for each power state). Need more discussion in the text about states vs curtailment levels, Options: 1. as is - power states (with max power levels) power state series 2. power level, power level set 3. power set, power set element <- neutral (avoids 'state' and 'level') 4. some other, better, name - but what? Open issue for meeting/list -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: quittek@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 7 07:42:38 2012 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 AB4EE21F8C11 for ; Wed, 7 Nov 2012 07:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL0OwP9I250S for ; Wed, 7 Nov 2012 07:42:37 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA8621F8C25 for ; Wed, 7 Nov 2012 07:42:37 -0800 (PST) Received: from localhost ([127.0.0.1]:45816 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TW7lg-00062N-UQ; Wed, 07 Nov 2012 16:42:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz, brads@coraid.com X-Trac-Project: eman Date: Wed, 07 Nov 2012 15:42:16 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/16#comment:3 Message-ID: <079.41c5e714fd5daa7acd741ba5817bd506@trac.tools.ietf.org> References: <064.e0edb6f25a043000c8d23b23fb4ed6cf@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <064.e0edb6f25a043000c8d23b23fb4ed6cf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, brads@coraid.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:42:38 -0000 #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? Changes (by n.brownlee@…): * status: new => closed * resolution: => fixed -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 7 08:17:37 2012 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 CA3B921F8C18 for ; Wed, 7 Nov 2012 08:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVyBHqcMjSOw for ; Wed, 7 Nov 2012 08:17:37 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4266F21F8BF7 for ; Wed, 7 Nov 2012 08:17:37 -0800 (PST) Received: from localhost ([127.0.0.1]:49767 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TW8Jf-0005yh-FN; Wed, 07 Nov 2012 17:17:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 07 Nov 2012 16:17:23 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/19#comment:2 Message-ID: <079.dd2afb024e2010e10234f7feca781660@trac.tools.ietf.org> References: <064.df6b3e9b9b553a88f83bed1f3bf4f52e@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <064.df6b3e9b9b553a88f83bed1f3bf4f52e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #19: f. Possibility to merge some keyword variables? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:17:37 -0000 #19: f. Possibility to merge some keyword variables? Changes (by n.brownlee@…): * status: new => closed * resolution: => fixed Comment: Fields broadly defineable, use with with care for interoperability. JP to add text. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 7 08:23:25 2012 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 F2FC221F8B71 for ; Wed, 7 Nov 2012 08:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npPUJHnYwj+L for ; Wed, 7 Nov 2012 08:23:24 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id F0F1B21F8ACD for ; Wed, 7 Nov 2012 08:23:23 -0800 (PST) Received: from localhost ([127.0.0.1]:50090 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TW8PH-0004do-N4; Wed, 07 Nov 2012 17:23:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: brads@coraid.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 07 Nov 2012 16:23:11 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/25#comment:4 Message-ID: <079.2ab69068bb36f08d3449b2c7872735c1@trac.tools.ietf.org> References: <064.63adb5d03338921086f8490c4f50a27b@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <064.63adb5d03338921086f8490c4f50a27b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brads@coraid.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #25: l. Figure 7 seems unnecessary to include? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:23:25 -0000 #25: l. Figure 7 seems unnecessary to include? Changes (by n.brownlee@…): * status: new => closed * resolution: => fixed Comment: Table has been removed, material moved to figure 16. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: brads@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 7 09:20:58 2012 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 58AAF21F8BF1 for ; Wed, 7 Nov 2012 09:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcBd6NwoC8G8 for ; Wed, 7 Nov 2012 09:20:56 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id B9F0321F8853 for ; Wed, 7 Nov 2012 09:20:56 -0800 (PST) Received: from localhost ([127.0.0.1]:55483 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TW9Is-00058E-7L; Wed, 07 Nov 2012 18:20:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: brad@coraid.com, n.brownlee@auckland.ac.nz, brads@coraid.com, quittek@neclab.eu X-Trac-Project: eman Date: Wed, 07 Nov 2012 17:20:38 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/26#comment:4 Message-ID: <070.45c5776f68acda55bf83e93771fdba63@trac.tools.ietf.org> References: <055.1ebf9c4bc8a3a981d504d2e1cfb60986@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <055.1ebf9c4bc8a3a981d504d2e1cfb60986@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brad@coraid.com, n.brownlee@auckland.ac.nz, brads@coraid.com, quittek@neclab.eu, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #26: ASHRAE 201P Power Quality X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:20:58 -0000 #26: ASHRAE 201P Power Quality Comment (by quittek@…): ASHRAE power quality parameters are a subset of what we call power characteristics. We chose "power characteristics", because it contains some measured values that are typically not used for quality assessment. Also there is a concern that values such as measured voltage may be used for quality assessment, but do not express quality by themselves (without a reference). However, the term power chartacteristics is in conflict a common use of the term for specifying the power that a deveice draws when operational. Proposal: replace "power characteristics" with "power attributes" and rename section "6.5.2 Optional Power Quality" to "6.5.2 Optional Power Attributes" -- -----------------------+------------------------- Reporter: brads@… | Owner: brad@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | -----------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 7 09:24:12 2012 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 3B0E221F8C17 for ; Wed, 7 Nov 2012 09:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1Fj7inz5IYW for ; Wed, 7 Nov 2012 09:24:11 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4661221F8C09 for ; Wed, 7 Nov 2012 09:24:11 -0800 (PST) Received: from localhost ([127.0.0.1]:55846 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TW9MD-0007AP-PG; Wed, 07 Nov 2012 18:24:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: brad@coraid.com, n.brownlee@auckland.ac.nz, brads@coraid.com, quittek@neclab.eu X-Trac-Project: eman Date: Wed, 07 Nov 2012 17:24:05 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/26#comment:5 Message-ID: <070.9ee099ea060816947a2bce68f12e8e01@trac.tools.ietf.org> References: <055.1ebf9c4bc8a3a981d504d2e1cfb60986@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <055.1ebf9c4bc8a3a981d504d2e1cfb60986@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brad@coraid.com, n.brownlee@auckland.ac.nz, brads@coraid.com, quittek@neclab.eu, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #26: ASHRAE 201P Power Quality X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:24:12 -0000 #26: ASHRAE 201P Power Quality Comment (by quittek@…): Some power attributes are commonly used for assessing power quality. -- -----------------------+------------------------- Reporter: brads@… | Owner: brad@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | -----------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Thu Nov 8 05:50:48 2012 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 EC41721F8B68 for ; Thu, 8 Nov 2012 05:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYvL4vUt3s0O for ; Thu, 8 Nov 2012 05:50:48 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 5106721F8B6A for ; Thu, 8 Nov 2012 05:50:48 -0800 (PST) Received: from localhost ([127.0.0.1]:53554 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWSVE-0007Mf-Cm; Thu, 08 Nov 2012 14:50:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: bnordman@lbl.gov, jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Thu, 08 Nov 2012 13:50:40 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/12#comment:4 Message-ID: <079.e0c94c326f6afca9cb32b8dd5a33c476@trac.tools.ietf.org> References: <064.9a8404aa8b8749382a7ecb93a3197acb@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <064.9a8404aa8b8749382a7ecb93a3197acb@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bnordman@lbl.gov, jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #12: how summation occurs X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 13:50:49 -0000 #12: how summation occurs Comment (by bnordman@…): When summation occurs across a set of entities, some of the values may be missing. EMAN does not specify how these should be treated, as different implementations may have good reason to take different approaches. One common treatment is to define the sum as missing if any of the constituent elements are missing (useful to be most precise). Another is to treat the missing value as zero (useful to have continuous data streams). [ This addresses the 'missing' issue; I still need to check for consistency in use of the term "aggregation" ] -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: bnordman@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Thu Nov 8 09:19:39 2012 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 8F6DD21F8456 for ; Thu, 8 Nov 2012 09:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf-p+8JjH6qY for ; Thu, 8 Nov 2012 09:19:38 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 8762521F8438 for ; Thu, 8 Nov 2012 09:19:38 -0800 (PST) Received: from localhost ([127.0.0.1]:45393 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWVl7-0008Nl-O0; Thu, 08 Nov 2012 18:19:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: quittek@neclab.eu, jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Thu, 08 Nov 2012 17:19:17 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/8#comment:5 Message-ID: <079.edef09fa8495b4a6a0e84c002a92dbc6@trac.tools.ietf.org> References: <064.cbeb4b04599adc4564503ec585a112d7@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <064.cbeb4b04599adc4564503ec585a112d7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: quittek@neclab.eu, jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #8: List EMAN curtailment levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 17:19:39 -0000 #8: List EMAN curtailment levels Comment (by jparello@…): Per ietf 85 meeting Agreed to keep power states and power states set and to pursue with the wg 1) addition of current curtailment on a device 2) possible registry of curtailments -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: quittek@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From bnordman@lbl.gov Thu Nov 8 11:40:48 2012 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 139FE21F8755 for ; Thu, 8 Nov 2012 11:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaUWF+5e--+L for ; Thu, 8 Nov 2012 11:40:47 -0800 (PST) Received: from fe2.lbl.gov (fe2.lbl.gov [128.3.41.134]) by ietfa.amsl.com (Postfix) with ESMTP id EB29421F85B1 for ; Thu, 8 Nov 2012 11:40:46 -0800 (PST) X-Ironport-SBRS: 2.6 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAFAFQKnFDRVdzGfmdsb2JhbABBA4JJuCkBiGkIIwEBCwkMCBQngh4BAQMCgQkWBgMBAi8iEgEFARICCAYTCRKHbwudP55xjBKDHYMqA4hajSGBHI1GFimEL4FG X-IronPort-AV: E=Sophos;i="4.80,739,1344236400"; d="scan'208";a="2167213" Received: from mail-vc0-f198.google.com ([209.85.220.198]) by fe2.lbl.gov with ESMTP; 08 Nov 2012 11:40:42 -0800 Received: by mail-vc0-f198.google.com with SMTP id d16so5409535vcd.1 for ; Thu, 08 Nov 2012 11:40:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=uMmqlv05jtmaV76x6K3pCbjz6M2VtVX4l6eBf/1f4XE=; b=fLkYpfCBVN0vKiuFQQIKMd48vWqeq6yWa/XDqFR/rUbKuP8bZkMn2yQZIhl9pve8kg EL0FXGkUW6GoY3QY9vUSSP4B8gWKTkfiBMB3AIcVUAWFoiOxOOZReRWygUTiTOGcsk3k GxpMBzLtadRlJ1RDSmg0eoxbz4RhSkLrfFfHOfSeWOtYZkyrzTSauZYT16FzpRwisn9H mF3qQjd9IFHuTS07K9dRTt87hUY+AUU+s7Rwz8nOoqyIsBmusLULKS+GKIV4IJKGy/7C IcyBSsmjNh0RLBsKlMUNrkFfslUxxs6lVnKYCTM8/EfGPt8QR2Q98C9N5EYcnc8BZhOT BTQw== Received: by 10.52.88.14 with SMTP id bc14mr7145325vdb.110.1352403642358; Thu, 08 Nov 2012 11:40:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.88.14 with SMTP id bc14mr7145321vdb.110.1352403642206; Thu, 08 Nov 2012 11:40:42 -0800 (PST) Received: by 10.58.15.234 with HTTP; Thu, 8 Nov 2012 11:40:42 -0800 (PST) In-Reply-To: <1FA3CA46-1C9F-4FCC-90B0-41B1C89A9E7F@amsl.com> References: <1FA3CA46-1C9F-4FCC-90B0-41B1C89A9E7F@amsl.com> Date: Thu, 8 Nov 2012 14:40:42 -0500 Message-ID: From: Bruce Nordman To: eman mailing list Content-Type: multipart/alternative; boundary=bcaec5016613afc81804ce010231 X-Gm-Message-State: ALoCoQn4Ek5iaVtwFCgS9lPQgiBZ7iHFIHs4i0OLwBylysz7O3IjDd1zv1Rr7aDVbeSFacfEFkLDTQnTK+A9b9RgA5GxtnhgTSCzWDLZ+bbZV3rtsug3rxEwYuGlKCjXa0oUvN9om+Lb Subject: [eman] Fwd: EMAN WebEx Session for IETF 85 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, 08 Nov 2012 19:40:48 -0000 --bcaec5016613afc81804ce010231 Content-Type: text/plain; charset=ISO-8859-1 Apologies for not sending this out earlier. --Bruce ---------- Forwarded message ---------- From: Cindy Morgan Date: Mon, Oct 22, 2012 at 12:55 PM Subject: EMAN WebEx Session for IETF 85 To: Bruce Nordman , Nevil Brownlee < n.brownlee@auckland.ac.nz> Dear Bruce and Nevil, Your WebEx session for IETF 85 has been scheduled. You should have just received an invitation in your email for this meeting; you should forward this information to your participants. Participants may also join from http://www.ietf.org/meeting/85/remote-participation.html. Note that remote participants will need to listen to the audio stream (linked from both http://www.ietf.org/meeting/85/remote-participation.htmland http://tools.ietf.org/agenda/85/) to follow the discussion. To claim the host role for your meeting, first join as a regular participant. Then, go to the participant menu at the top of the screen and choose "Claim Host Role." You will be prompted for the host key. Host Key: 600702 More information about WebEx may be found at http://www.ietf.org/wg/webex.html and http://www.ietf.org/wg/webex-hosting.pdf. Information about claiming the host role and running your WebEx meeting will also be found on the chairs' table at the front of the meeting room, and the host keys can be found at: http://www.ietf.org/private/webex-host-keys.html Best regards, Cindy Cindy Morgan / Project Manager / IETF 48377 Fremont Blvd., Suite 117 / Fremont CA 94358 T: +1.510.492.4085 / F: +1.510.492.4001 / http://www.ietf.org ---------- Managed by Association Management Solutions (AMS); Forum Management, Meeting and Event Planning Website: http://www.amsl.com -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --bcaec5016613afc81804ce010231 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Apologies for not sending this out earlier.
--Bruce

---------- Forwarded message ----------
From: Cindy Morgan <cmorgan@amsl.com>
Date: Mon, Oct 22, 2012 at 12:55 PM
Subject: EMAN WebEx Session for IETF= 85
To: Bruce Nordman <bnordman@l= bl.gov>, Nevil Brownlee <n.brownlee@auckland.ac.nz>


Dear Bruce and Nevil,

Your WebEx session for IETF 85 has been scheduled. You should have just rec= eived an invitation in your email for this meeting; you should forward this= information to your participants. =A0Participants may also join from http://www.ietf.org/meeting/85/remote-participation.html.

Note that remote participants will need to listen to the audio stream (link= ed from both http://www.ietf.org/meeting/85/remote-participatio= n.html and http://tools.ietf.org/agenda/85/) to follow the discussion.

To claim the host role for your meeting, first join as a regular participan= t. Then, go to the participant menu at the top of the screen and choose &qu= ot;Claim Host Role." You will be prompted for the host key.

=A0 =A0 Host Key: 600702

More information about WebEx may be found at
http://www.= ietf.org/wg/webex.html and
http= ://www.ietf.org/wg/webex-hosting.pdf.

Information about claiming the host role and running your WebEx meeting wil= l also be found on the chairs' table at the front of the meeting room, = and the host keys can be found at: http://www.ietf.org/private/webex-ho= st-keys.html

Best regards,
Cindy


Cindy Morgan / Project Manager / IETF
48377 Fremont Blvd., Suite 117 / Fremont CA 94358
T: +1.510.492.4085= / F: +1.510.4= 92.4001 / http://www.= ietf.org
----------
Managed by Association Management Solutions (AMS);
Forum Management, Meeting and Event Planning
Website: http://www.amsl.= com






--
Bruce Nordman
Lawrence Berkeley National L= aboratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--bcaec5016613afc81804ce010231-- From trac+eman@trac.tools.ietf.org Wed Nov 14 10:11:28 2012 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 0420721F86E3 for ; Wed, 14 Nov 2012 10:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTfVwBszhoiz for ; Wed, 14 Nov 2012 10:11:27 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 73C9421F86A8 for ; Wed, 14 Nov 2012 10:11:27 -0800 (PST) Received: from localhost ([127.0.0.1]:37088 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TYhQT-0002Qb-Uw; Wed, 14 Nov 2012 19:11:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: quittek@neclab.eu, bclaise@cisco.com, jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 14 Nov 2012 18:11:01 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/eman/trac/ticket/6#comment:6 Message-ID: <079.258a3b75541262cad1e44fa9a0e1ecc8@trac.tools.ietf.org> References: <064.3a9e930207302af0939a4d9d1c602749@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <064.3a9e930207302af0939a4d9d1c602749@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: quittek@neclab.eu, bclaise@cisco.com, jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #6: States and ASHRAE Curtailment levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 18:11:28 -0000 #6: States and ASHRAE Curtailment levels Changes (by n.brownlee@…): * status: new => closed * resolution: => fixed Comment: Closed as per IET% 85 -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: quittek@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 14 10:12:31 2012 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 E2A7E21F8715 for ; Wed, 14 Nov 2012 10:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0y4XcjLTHoH for ; Wed, 14 Nov 2012 10:12:31 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 6337421F8758 for ; Wed, 14 Nov 2012 10:12:31 -0800 (PST) Received: from localhost ([127.0.0.1]:37098 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TYhRf-00088x-Ti; Wed, 14 Nov 2012 19:12:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: quittek@neclab.eu, jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 14 Nov 2012 18:12:15 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/8#comment:6 Message-ID: <079.7016a1d40a455d9c7779dff2f30d53e7@trac.tools.ietf.org> References: <064.cbeb4b04599adc4564503ec585a112d7@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <064.cbeb4b04599adc4564503ec585a112d7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: quittek@neclab.eu, jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #8: List EMAN curtailment levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 18:12:32 -0000 #8: List EMAN curtailment levels Changes (by n.brownlee@…): * status: new => closed * resolution: => fixed Comment: Closed as per IETF 85 -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: quittek@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 14 10:13:35 2012 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 4A2CE21F8778 for ; Wed, 14 Nov 2012 10:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzIJskc1O1U6 for ; Wed, 14 Nov 2012 10:13:34 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAD821F8758 for ; Wed, 14 Nov 2012 10:13:34 -0800 (PST) Received: from localhost ([127.0.0.1]:37221 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TYhSp-0005N9-2g; Wed, 14 Nov 2012 19:13:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: brad@coraid.com, n.brownlee@auckland.ac.nz, brads@coraid.com, quittek@neclab.eu X-Trac-Project: eman Date: Wed, 14 Nov 2012 18:13:27 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/26#comment:6 Message-ID: <070.5609d1d07bcc3dad9506eef424ab3ef8@trac.tools.ietf.org> References: <055.1ebf9c4bc8a3a981d504d2e1cfb60986@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <055.1ebf9c4bc8a3a981d504d2e1cfb60986@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brad@coraid.com, n.brownlee@auckland.ac.nz, brads@coraid.com, quittek@neclab.eu, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #26: ASHRAE 201P Power Quality X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 18:13:35 -0000 #26: ASHRAE 201P Power Quality Changes (by n.brownlee@…): * status: new => closed * resolution: => fixed Comment: Cloased as per IETF 85 -- -----------------------+------------------------- Reporter: brads@… | Owner: brad@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | -----------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 14 10:35:30 2012 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 3309721F8518 for ; Wed, 14 Nov 2012 10:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7dxvdkab4F8 for ; Wed, 14 Nov 2012 10:35:29 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 6447621F84C6 for ; Wed, 14 Nov 2012 10:35:29 -0800 (PST) Received: from localhost ([127.0.0.1]:38938 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TYhnv-0003Ov-3F; Wed, 14 Nov 2012 19:35:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz, jparello@cisco.com X-Trac-Project: eman Date: Wed, 14 Nov 2012 18:35:15 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/4#comment:6 Message-ID: <079.c218ff86aff56c279e5933c48c3b7466@trac.tools.ietf.org> References: <064.7a9d450cca2046de189ad1ffa76f63de@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <064.7a9d450cca2046de189ad1ffa76f63de@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #4: Reorganise sections X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 18:35:30 -0000 #4: Reorganise sections Comment (by jparello@…): jparello - For next week move all examples and notes to other sections and one intro move. Have a draft with changes from IETF 85 and these moves. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 14 10:39:23 2012 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 2E53921F8522 for ; Wed, 14 Nov 2012 10:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hz+VDqQ-TRJi for ; Wed, 14 Nov 2012 10:39:22 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 37CE321F8521 for ; Wed, 14 Nov 2012 10:39:22 -0800 (PST) Received: from localhost ([127.0.0.1]:39122 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TYhrj-00008A-DL; Wed, 14 Nov 2012 19:39:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz, jparello@cisco.com X-Trac-Project: eman Date: Wed, 14 Nov 2012 18:39:11 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/eman/trac/ticket/21#comment:3 Message-ID: <079.3078cefc2c52492b730c3b5373675b7a@trac.tools.ietf.org> References: <064.71cdaa9804b4d5542ef8cf6433ee0054@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <064.71cdaa9804b4d5542ef8cf6433ee0054@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #21: h. Clarify the intended application of the Domain concept? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 18:39:23 -0000 #21: h. Clarify the intended application of the Domain concept? Comment (by jparello@…): Bruce to make changes in the doc and then we'll review at next meeting. Domain should be in line with the definition in all places in the doc. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 14 10:40:00 2012 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 E1E0421F8528 for ; Wed, 14 Nov 2012 10:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+RNjx+gUz1O for ; Wed, 14 Nov 2012 10:40:00 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3A421F8522 for ; Wed, 14 Nov 2012 10:40:00 -0800 (PST) Received: from localhost ([127.0.0.1]:39150 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TYhsO-0004te-Bb; Wed, 14 Nov 2012 19:39:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: bnordman@lbl.gov, n.brownlee@auckland.ac.nz, jparello@cisco.com X-Trac-Project: eman Date: Wed, 14 Nov 2012 18:39:52 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/eman/trac/ticket/21#comment:4 Message-ID: <079.54d6798257d6384f455f5c6cd61aa4d3@trac.tools.ietf.org> References: <064.71cdaa9804b4d5542ef8cf6433ee0054@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <064.71cdaa9804b4d5542ef8cf6433ee0054@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bnordman@lbl.gov, n.brownlee@auckland.ac.nz, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #21: h. Clarify the intended application of the Domain concept? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 18:40:01 -0000 #21: h. Clarify the intended application of the Domain concept? Changes (by jparello@…): * owner: all => bnordman@… -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: bnordman@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From n.brownlee@auckland.ac.nz Tue Nov 27 12:55:47 2012 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 CF76A1F0C70 for ; Tue, 27 Nov 2012 12:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8+y+iVt9LgU for ; Tue, 27 Nov 2012 12:55:47 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 075B81F0C67 for ; Tue, 27 Nov 2012 12:55:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1354049747; x=1385585747; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=OGzF+nyX8tDJgq3n5ajjZ2XzN+BYyjOCEwowO2ssXXM=; b=scYh9zgI+r+0qTns9tRj0BqWu22Rk0DRBj8yeQOW50zsW0JlPLmZA6Re EfLqgTGSG51Rs8malIMvHaqrxgkA1JIudHFFZieI3pDzPR2a06VVUWCiq TP8hvTsbxs6fOLsKToOsI2rc6p9xhdCax1tkGqadn7GOrSUMkyAivtI7I E=; X-IronPort-AV: E=Sophos;i="4.83,330,1352026800"; d="scan'208";a="159237695" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 28 Nov 2012 09:55:41 +1300 Message-ID: <50B528CA.70907@auckland.ac.nz> Date: Wed, 28 Nov 2012 09:55:38 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "eman@ietf.org" References: <509939B0.3070308@auckland.ac.nz> <852AF0ED49D9F24BBBFA1B4DEEBE3BA42382D196@xmb-rcd-x08.cisco.com> In-Reply-To: <852AF0ED49D9F24BBBFA1B4DEEBE3BA42382D196@xmb-rcd-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [eman] EMAN meeting minutes 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, 27 Nov 2012 20:55:47 -0000 Hi all: Although I wrote up the minutes for our meeting at IETF 85 before I left Atlanta, I realise now that I failed to send an announcement of them to the EMAN list. Here it is now, sorry for the delay ... The EMAN IETF-85 minutes are now on the Meeting Materials page, i.e. at http://www.ietf.org/proceedings/85/minutes/minutes-85-eman If you were at the meeting please check them; if there's anything that needs correcting, please let me know. You can find the audio recordings at http://www.ietf.org/audio/ietf85/ On the list there, ietf85-salona-20121108-1300-pm1.mp3 is the one for our EMAN meeting, I was able to download it them play it using VLC. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From trac+eman@trac.tools.ietf.org Wed Nov 28 09:09:16 2012 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 B164F21F857B for ; Wed, 28 Nov 2012 09:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwF-hAa5KIAq for ; Wed, 28 Nov 2012 09:09:16 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1572921F8528 for ; Wed, 28 Nov 2012 09:09:15 -0800 (PST) Received: from localhost ([127.0.0.1]:60385 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tdl85-000141-5e; Wed, 28 Nov 2012 18:08:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: n.brownlee@auckland.ac.nz, jparello@cisco.com X-Trac-Project: eman Date: Wed, 28 Nov 2012 17:08:57 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/4#comment:7 Message-ID: <079.f76203c81bcde949c7f0823139b325e2@trac.tools.ietf.org> References: <064.7a9d450cca2046de189ad1ffa76f63de@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <064.7a9d450cca2046de189ad1ffa76f63de@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #4: Reorganise sections X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 17:09:16 -0000 #4: Reorganise sections Comment (by jparello@cisco.com): removed all notes and examples. 1)Should section be alphabetized or remain in the pseudo containment order" 2) Can raft terminology be seperate wg item like http://tools.ietf.org/html/rfc4949 3) Notes and examples need placement in sections. As we do section review lets add from list. -- ---------------------------------------+------------------------- Reporter: n.brownlee@auckland.ac.nz | Owner: all Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | ---------------------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 28 10:28:56 2012 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 A19EC21F8472 for ; Wed, 28 Nov 2012 10:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAv1wO4-G7vh for ; Wed, 28 Nov 2012 10:28:56 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2285B21F8431 for ; Wed, 28 Nov 2012 10:28:55 -0800 (PST) Received: from localhost ([127.0.0.1]:38305 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TdmN8-0001NP-TJ; Wed, 28 Nov 2012 19:28:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: n.brownlee@auckland.ac.nz, jparello@cisco.com X-Trac-Project: eman Date: Wed, 28 Nov 2012 18:28:34 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/4#comment:8 Message-ID: <079.79a807eb57bf2e00c068b5197ad859a1@trac.tools.ietf.org> References: <064.7a9d450cca2046de189ad1ffa76f63de@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <064.7a9d450cca2046de189ad1ffa76f63de@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #4: Reorganise sections X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 18:28:56 -0000 #4: Reorganise sections Comment (by jparello@cisco.com): Authors call 1) keep as is no alpha unless gets big 2) no 3) removed examples -- ---------------------------------------+------------------------- Reporter: n.brownlee@auckland.ac.nz | Owner: all Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | ---------------------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 28 10:51:10 2012 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 3B3E821F857B for ; Wed, 28 Nov 2012 10:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNlg1OzSaPwx for ; Wed, 28 Nov 2012 10:51:09 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC1C21F8554 for ; Wed, 28 Nov 2012 10:51:09 -0800 (PST) Received: from localhost ([127.0.0.1]:39633 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tdmio-0003cZ-Kn; Wed, 28 Nov 2012 19:50:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 28 Nov 2012 18:50:58 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/24#comment:2 Message-ID: <079.d7c6716e500c483d25dae3b3b8a5a2b5@trac.tools.ietf.org> References: <064.ca336c45f21b50f12ec09f9571e0a99a@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <064.ca336c45f21b50f12ec09f9571e0a99a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #24: no need for a separate concept of a meter X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 18:51:10 -0000 #24: no need for a separate concept of a meter Changes (by n.brownlee@auckland.ac.nz): * status: new => closed * resolution: => fixed Comment: Agreed that in EMAN any device may perorm metering; sentence added to say that. -- ---------------------------------------+------------------------- Reporter: n.brownlee@auckland.ac.nz | Owner: all Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | ---------------------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 28 10:59:25 2012 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 9175221F8846 for ; Wed, 28 Nov 2012 10:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIAP2zJgZg1z for ; Wed, 28 Nov 2012 10:59:24 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BFC2B21F8844 for ; Wed, 28 Nov 2012 10:59:24 -0800 (PST) Received: from localhost ([127.0.0.1]:40542 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tdmqh-0002nW-GR; Wed, 28 Nov 2012 19:59:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 28 Nov 2012 18:59:07 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/23#comment:2 Message-ID: <079.d43c2fe1743eeb39fd187035b4dc50ec@trac.tools.ietf.org> References: <064.17f7a3002a261261e6002556e68c70b0@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <064.17f7a3002a261261e6002556e68c70b0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #23: Figure 6. Clarify that Parent/Child communication can be accomplished via EMAN X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 18:59:25 -0000 #23: Figure 6. Clarify that Parent/Child communication can be accomplished via EMAN Changes (by n.brownlee@auckland.ac.nz): * status: new => closed * resolution: => fixed Comment: Added comment that EMAN protocol (SNMP + EMAN MIBs) can do this, other protocols could also be used. -- ---------------------------------------+------------------------- Reporter: n.brownlee@auckland.ac.nz | Owner: all Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | ---------------------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Nov 28 11:16:59 2012 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 EBE4521F843A for ; Wed, 28 Nov 2012 11:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fD+Y9nOJLc90 for ; Wed, 28 Nov 2012 11:16:59 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBE921F8427 for ; Wed, 28 Nov 2012 11:16:47 -0800 (PST) Received: from localhost ([127.0.0.1]:41936 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tdn7a-0003cH-F7; Wed, 28 Nov 2012 20:16:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "eman issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: n.brownlee@auckland.ac.nz, jparello@cisco.com X-Trac-Project: eman Date: Wed, 28 Nov 2012 19:16:34 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/22#comment:2 Message-ID: <079.642703a2593e95d6fa5081a485bdd989@trac.tools.ietf.org> References: <064.71f954de497add7ce356c6764dff7588@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <064.71f954de497add7ce356c6764dff7588@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #22: i. Are there any power source or metering relationships that are not covered by data present about the wiring topology? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 19:17:00 -0000 #22: i. Are there any power source or metering relationships that are not covered by data present about the wiring topology? Comment (by jparello@cisco.com): Yes see Figure 12 and preceding section "Metering At a Point in Power Distribution" -- ---------------------------------------+------------------------- Reporter: n.brownlee@auckland.ac.nz | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | ---------------------------------------+------------------------- Ticket URL: eman