From moulchan@cisco.com Fri Jul 1 04:08:23 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD66A11E80CF for ; Fri, 1 Jul 2011 04:08:23 -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 ZBWM6VcsPWy7 for ; Fri, 1 Jul 2011 04:08:23 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2155011E8086 for ; Fri, 1 Jul 2011 04:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=1877; q=dns/txt; s=iport; t=1309518503; x=1310728103; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=1hmm33COJCI0zz1yei49u1mRKjmu/aL5fxq8LmEY4V8=; b=lp/uulLs/8x1va3twkzLBDIJ3cdWMQXQbwBpExkZWMtrnYzURHA7x3+K 1iIcNfBL8ksUrdrri3OvNDzU4HvH/xsVqinw1HSmltFMSBCFtVpt53V48 Km6OghPbQYK1lP4xjMnBeCUvL0N7Maf9pxLZGg/WFhzq6qbvpKS4WZCBh Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAAOqDU6tJV2Z/2dsb2JhbABEDpgrjzR3q2CeBIMfgxMEhz6Pc4tQ X-IronPort-AV: E=Sophos;i="4.65,457,1304294400"; d="scan'208";a="389942338" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2011 11:08:22 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p61B8M7C032570; Fri, 1 Jul 2011 11:08:22 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 06:08:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jul 2011 06:08:18 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] New draft on eman requirements - issue 1 - Device type Thread-Index: Acw2bEgLUSQNJgXDjE6Pk4zAd/RgeAAm3TUGADU3dJA= References: From: "Mouli Chandramouli (moulchan)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 01 Jul 2011 11:08:21.0800 (UTC) FILETIME=[30829280:01CC37DF] Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type 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, 01 Jul 2011 11:08:23 -0000 Hello, As Juergen has mentioned, while the first version has been released to solicit feedback, some of the concepts are still debated. The perspectives from the email list would be useful to shape the draft. I shall post some of the discussion points.=20 Thanks Mouli ------------ There is a requirement - http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt 5.1.1. Type of powered entity The energy management standard must provide means to retrieve and report the type of powered entities. I think it would be useful to expand this requirement. Device Type could be inferred as "IP Phone" or "Line Card 3", ... One possibility is to consider is a description of the device and then the type of device.=20 Powered Devices Description The energy management standard must provide means for identifying the entity with a powered device description, the domain to which the device belongs. Powered Entity Type The energy management standard must provide means to identify the powered device type such as consumer, provider, meter. -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Thursday, June 30, 2011 2:56 PM To: eman mailing list Subject: Re: [eman] New draft on eman requirements Dear all, I am sorry for posting another version just one day after the previous one. Now out is version -03 to be found at =20 http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt The reason was that a change in terminology ("powered device" -> "powered entity") was not done consistently in all sections, particularly not in the battery section. There are no further changes, particularly no technical changes compared to the previous version. Thanks, Juergen From moulchan@cisco.com Fri Jul 1 04:18:11 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7D111E809A for ; Fri, 1 Jul 2011 04:18:11 -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 hPPNXjqb2Uzz for ; Fri, 1 Jul 2011 04:18:10 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id C325E11E807B for ; Fri, 1 Jul 2011 04:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=1818; q=dns/txt; s=iport; t=1309519090; x=1310728690; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=122o6jJEBHmcG/eH2YrRVsQ29GrHAEx21BuKkDUi45w=; b=FgK5OaiQz8YCSryqZ8zyk9DnHzInGFbocTx6fZCQgwi/Mo9nh5GHNzEc BIe1cKhRCPvtFYuisBsitOCSUt9UNg0D427hs71U5GT0Kfn9jekWlBelI S3oN0WqUxY9CZITZEcPfElmA/yH5EBf9JXFIyvqNr99kaX2/jDFBmx6t+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAFysDU6tJXHA/2dsb2JhbABFDZgrjzR3q0qeBIMggxIEhz6Pc4tQ X-IronPort-AV: E=Sophos;i="4.65,457,1304294400"; d="scan'208";a="238439811" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-1.cisco.com with ESMTP; 01 Jul 2011 11:18:09 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p61BI9xY006136; Fri, 1 Jul 2011 11:18:09 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 06:18:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jul 2011 06:18:07 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] New draft on eman requirements - issue 2 - Device Identity Thread-Index: Acw2bEgLUSQNJgXDjE6Pk4zAd/RgeAAm3TUGADU3dJAAAMwxAA== References: From: "Mouli Chandramouli (moulchan)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 01 Jul 2011 11:18:09.0390 (UTC) FILETIME=[8EBDB0E0:01CC37E0] Subject: Re: [eman] New draft on eman requirements - issue 2 - Device Identity 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, 01 Jul 2011 11:18:11 -0000 Hello, There is a requirement - http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt on identity=20 4.1. Identifying powered entities The energy management standard must provide means for uniquely identifying powered entities that are monitored or controlled by an energy management system. Uniqueness must be given in a domain that is large enough to avoid collisions of identities at potential receivers of monitored information. Firstly, it would be useful to link this unique ID to other indices that may be deployed - in other words, link to other MIB modules.=20 Powered Entities Other Identifier The energy management standard must provide means to link the powered device unique id to existing other identifiers currently used in network management. Secondly, it would be useful to specify if the identity should persistent.=20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Thursday, June 30, 2011 2:56 PM To: eman mailing list Subject: Re: [eman] New draft on eman requirements Dear all, I am sorry for posting another version just one day after the previous one. Now out is version -03 to be found at =20 http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt The reason was that a change in terminology ("powered device" -> "powered entity") was not done consistently in all sections, particularly not in the battery section. There are no further changes, particularly no technical changes compared to the previous version. Thanks, Juergen _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From moulchan@cisco.com Fri Jul 1 04:25:46 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B0311E80B5 for ; Fri, 1 Jul 2011 04:25:46 -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 owFcQQ+oEE+p for ; Fri, 1 Jul 2011 04:25:46 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0F91411E807B for ; Fri, 1 Jul 2011 04:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=1642; q=dns/txt; s=iport; t=1309519546; x=1310729146; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=cEwTxVb4LqXQGrBimib0s00yhP/8qbjTdld8UVCdeV8=; b=gYQLPDGNj0nqKMl7ByBzl5Zq9YLTFiWz9yx9R8RzWUvJesU3clQbHnV+ EspoSOi1pSldezQYaJcLv8bIyv6dH5GXCvdLGrFzGcPliqOmbnMk9Tnuz 9FFL5Efw+5P+mg1sLrM8fhxqUzQ0z7ca5LEkoIvmKF13QfkWsrjAQTq7B A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAGquDU6tJV2a/2dsb2JhbABSmCuPNXerRJ4FhjIEhz6Pc4tQ X-IronPort-AV: E=Sophos;i="4.65,457,1304294400"; d="scan'208";a="351315904" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-3.cisco.com with ESMTP; 01 Jul 2011 11:25:45 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p61BPjnu025270; Fri, 1 Jul 2011 11:25:45 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 06:25:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jul 2011 06:25:42 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] New draft on eman requirements - issue 3 - Inlet/Outlet Thread-Index: Acw2bEgLUSQNJgXDjE6Pk4zAd/RgeAAm3TUGADU3dJAAAQ9GUA== References: From: "Mouli Chandramouli (moulchan)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 01 Jul 2011 11:25:44.0684 (UTC) FILETIME=[9E1E0AC0:01CC37E1] Subject: Re: [eman] New draft on eman requirements - issue 3 - Inlet/Outlet 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, 01 Jul 2011 11:25:46 -0000 There are two requirements - http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt 5.3.2. Corresponding power outlet The energy management standard must provide means for identifying the power outlet that provides the power received at a power inlet. 5.3.3. Corresponding power inlets The energy management standard must provide means for identifying the list of power inlets that receive the power provided at a power outlet It would be useful to explain the context of this requirement. This seems tracing the power distribution tree.=20 Secondly, for a power outlet or inlet, do all the power monitoring requirements apply or only some of them (such as power quality, ...)=20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Thursday, June 30, 2011 2:56 PM To: eman mailing list Subject: Re: [eman] New draft on eman requirements Dear all, I am sorry for posting another version just one day after the previous one. Now out is version -03 to be found at =20 http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt The reason was that a change in terminology ("powered device" -> "powered entity") was not done consistently in all sections, particularly not in the battery section. There are no further changes, particularly no technical changes compared to the previous version. Thanks, Juergen _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From moulchan@cisco.com Fri Jul 1 04:38:20 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68F121F8606 for ; Fri, 1 Jul 2011 04:38:20 -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 FMwMFqQo3Edl for ; Fri, 1 Jul 2011 04:38:20 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCDC21F8603 for ; Fri, 1 Jul 2011 04:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=975; q=dns/txt; s=iport; t=1309520300; x=1310729900; h=mime-version:content-transfer-encoding:subject:date: message-id:references:from:to; bh=hasXINZiJM7imHwoEvTnQSzg1my2m7q4RxZqfM71Xfs=; b=PCsVsMcK7HzulGNac5tNO1TptqRK2UuO1r/3Ccxas8BgayIroPto731V drDVwOduH7dkxk7sqGGm1bBZMfl5s+My+PxL5U0qYAgmaIpt7JVmwWZpq iYDe5iSpwS5rrSPFyO8i8DH3S6kbCTyV+6LQRkk52Owam+GQmpojvmmpB c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAMewDU6tJXG8/2dsb2JhbABSmCuPNXerLJ4DhjIEhz6Pc4tQ X-IronPort-AV: E=Sophos;i="4.65,457,1304294400"; d="scan'208";a="351322053" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-3.cisco.com with ESMTP; 01 Jul 2011 11:38:19 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p61BcJC8019553; Fri, 1 Jul 2011 11:38:19 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 06:38:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jul 2011 06:38:15 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] New draft on eman requirements - Comment - Terminology Thread-Index: Acw2bEgLUSQNJgXDjE6Pk4zAd/RgeAAm3TUGADU3dJAAAaDkwA== References: From: "Mouli Chandramouli (moulchan)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 01 Jul 2011 11:38:18.0633 (UTC) FILETIME=[5F818790:01CC37E3] Subject: Re: [eman] New draft on eman requirements - Comment - Terminology 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, 01 Jul 2011 11:38:20 -0000 http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt It would be useful to have consistent definitions of Power, Energy and Demand since these terms are used in many of the documents.=20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Thursday, June 30, 2011 2:56 PM To: eman mailing list Subject: Re: [eman] New draft on eman requirements Dear all, I am sorry for posting another version just one day after the previous one. Now out is version -03 to be found at =20 http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt The reason was that a change in terminology ("powered device" -> "powered entity") was not done consistently in all sections, particularly not in the battery section. There are no further changes, particularly no technical changes compared to the previous version. Thanks, Juergen From ietf@quittek.at Fri Jul 1 05:33:47 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3502B11E910F for ; Fri, 1 Jul 2011 05:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93ky8Vzah+Hv for ; Fri, 1 Jul 2011 05:33:46 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id C964311E9766 for ; Fri, 1 Jul 2011 05:10:31 -0700 (PDT) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MY6Nc-1R7R6B1aC0-00Uqbd; Fri, 01 Jul 2011 14:10:27 +0200 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <1127B34B-6899-4F1D-966E-ED841E25E554@quittek.at> Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Fri, 1 Jul 2011 14:10:21 +0200 To: Mouli Chandramouli (moulchan) X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:+JIcnzJ4vOCSrvdP2Ed1DI8JS7Pki7kyzwe8J559T5t UZLEV2auZBC8SRba9NSYxQRZSuhdcO4zmflvjmHO4eBIhqX0eH wQoig/OSy2nNe+Pw2pcsoCTzn00fFeAkeKbi1UZuGcYWgNJzB8 n/o+QKj5hVo9cpPSc+lBIVSPS7YxpGuXQjgLj2kdibH1UXovdN V1vhxy+EUU1SNXVV3zUdw== Cc: eman mailing list Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type 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, 01 Jul 2011 12:33:47 -0000 Hi Mouli, I'm glad you comment on this. It was too vague so far. Please see plies inline. Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan): > Hello, >=20 > As Juergen has mentioned, while the first version has been released to > solicit feedback, some of the concepts are still debated. > The perspectives from the email list would be useful to shape the = draft. >=20 > I shall post some of the discussion points.=20 >=20 > Thanks > Mouli >=20 > ------------ >=20 > There is a requirement - > = http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt >=20 >=20 > 5.1.1. Type of powered entity >=20 > The energy management standard must provide means to retrieve and > report the type of powered entities. >=20 > I think it would be useful to expand this requirement. Device Type = could > be inferred as "IP Phone" or "Line Card 3", ... Yes. The question is what is needed? > One possibility is to consider is a description of the device and then > the type of device.=20 >=20 > Powered Devices Description >=20 > The energy management standard must provide means for identifying = the > entity with a powered device description, the domain to which the > device belongs Is this two in one (description and domain)? What would be the requirement for a "description"?=20 Offering a text string for descriptions where arbitrary content can be = entered? I don't think the domain should be part of the device description- > Powered Entity Type >=20 > The energy management standard must provide means to identify the > powered device type such as consumer, provider, meter. It's still vague. What are device types?=20 Is there a fixed list? Is it maintained by IANA?=20 Is it a string where operators may enter arbitrary types? Thanks, Juergen > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of > Juergen Quittek > Sent: Thursday, June 30, 2011 2:56 PM > To: eman mailing list > Subject: Re: [eman] New draft on eman requirements >=20 > Dear all, >=20 > I am sorry for posting another version just one day after the previous > one. > Now out is version -03 to be found at >=20 > = http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt >=20 > The reason was that a change in terminology ("powered device" -> > "powered > entity") was not done consistently in all sections, particularly not = in > the > battery section. >=20 > There are no further changes, particularly no technical changes = compared > to > the previous version. >=20 > Thanks, >=20 > Juergen >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Fri Jul 1 05:52:05 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A3B11E86B9 for ; Fri, 1 Jul 2011 05:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDBEI0moPV6Z for ; Fri, 1 Jul 2011 05:52:04 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 93DA321E9E7D for ; Fri, 1 Jul 2011 05:28:20 -0700 (PDT) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MfIF8-1Qx1Ef1vxq-00OkqI; Fri, 01 Jul 2011 14:28:19 +0200 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: 7bit From: Juergen Quittek Date: Fri, 1 Jul 2011 14:28:13 +0200 To: Mouli Chandramouli (moulchan) X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:956+HulXQKnhQ/IWjSPoXEwM3/PuHppl1pptD9p2cc9 1GGuiq6wtxau+C+9TdKc+eQE6g7R5kRRhyfdlvhf+0742+LGvE RVtd8vUYqtQNSHSAWC//KtkmMeLCKHZoSTLTfc6wdwFaN9zaq0 rVmmXEEzAacFayctajY2+oHDdYlYogWX94/1IFPaig4xKFqEgQ GMtFcFXG8CYuMxVSSLe6Q== Cc: eman mailing list Subject: Re: [eman] New draft on eman requirements - issue 2 - Device Identity 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, 01 Jul 2011 12:52:05 -0000 Am 01.07.2011 um 13:18 schrieb Mouli Chandramouli (moulchan): > Hello, > > > There is a requirement - > http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt > > on identity > > > 4.1. Identifying powered entities > > The energy management standard must provide means for uniquely > identifying powered entities that are monitored or controlled by an > energy management system. Uniqueness must be given in a domain that > is large enough to avoid collisions of identities at potential > receivers of monitored information. > > > Firstly, it would be useful to link this unique ID to other indices that > may be deployed - in other words, link to other MIB modules. I have two comments on this. First, the text in the draft says "means for identifying". It does not say that "means" is a single identifier as you appear to imply in your comment. The requirement in the draft would support multiple identifiers linked with each other if necessary as "means for identifying powered entities". Second, I definitely do not want to have a requirement for using more than one identifier? If solutions can go with a single identifier, then why forcing them by requirement to have more. > Powered Entities Other Identifier > > The energy management standard must provide means to link the powered > device unique id to existing other identifiers currently used in > network management. Well, as said before, I would not like to see a requirement like this without having a requirement to use more than one identifier for the same entity. > Secondly, it would be useful to specify if the identity should > persistent. Would this be covered by OLD "means for uniquely identifying powered entities" NEW "means for uniquely and persistently identifying powered entities" ? Thanks, Juergen > Thanks > Mouli > > > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Quittek > Sent: Thursday, June 30, 2011 2:56 PM > To: eman mailing list > Subject: Re: [eman] New draft on eman requirements > > Dear all, > > I am sorry for posting another version just one day after the previous > one. > Now out is version -03 to be found at > > http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt > > The reason was that a change in terminology ("powered device" -> > "powered > entity") was not done consistently in all sections, particularly not in > the > battery section. > > There are no further changes, particularly no technical changes compared > to > the previous version. > > Thanks, > > Juergen > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From moulchan@cisco.com Fri Jul 1 05:52:22 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E21321F853A for ; Fri, 1 Jul 2011 05:52:22 -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 8Wp33A3wj97f for ; Fri, 1 Jul 2011 05:52:22 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id E72AA11E86CD for ; Fri, 1 Jul 2011 05:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=3614; q=dns/txt; s=iport; t=1309523353; x=1310732953; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=0qcxrqjB6d5qe9MvQTiLFJ+7WtFkxRLB7DSHP3Lmnc0=; b=fHj8a0m6h9zd0KySEPzSEMJWTWf+VgkkgBHIThg2I7RhUHtbQWyheB8N mlGqWUk8ik2c4Zak38P0tiKxjewCi/RkU5efyj/30mvvfCX7EzQ5hHhxS kgapr6GqXy9hze7P0kwIlxYpM49wRII9f11Fb1t5B4WNzSFQIuvm6fxz8 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAACa9DU6tJXG+/2dsb2JhbABEDpgrjzV3iHmiGZ1/gx+DEwSHPo9zi1A X-IronPort-AV: E=Sophos;i="4.65,458,1304294400"; d="scan'208";a="725380038" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-6.cisco.com with ESMTP; 01 Jul 2011 12:29:13 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p61CTDnI026921; Fri, 1 Jul 2011 12:29:13 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 07:29:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jul 2011 07:29:09 -0500 Message-ID: In-Reply-To: <1127B34B-6899-4F1D-966E-ED841E25E554@quittek.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] New draft on eman requirements - issue 1 - Device type Thread-Index: Acw35+OFDFe8krKVQV+fBPqF51LUAAAAb/Uw References: <1127B34B-6899-4F1D-966E-ED841E25E554@quittek.at> From: "Mouli Chandramouli (moulchan)" To: "Juergen Quittek" X-OriginalArrivalTime: 01 Jul 2011 12:29:13.0253 (UTC) FILETIME=[7C338D50:01CC37EA] Cc: eman mailing list Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type 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, 01 Jul 2011 12:52:22 -0000 -----Original Message----- From: Juergen Quittek [mailto:ietf@quittek.at]=20 Sent: Friday, July 01, 2011 5:40 PM To: Mouli Chandramouli (moulchan) Cc: eman mailing list Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type Hi Mouli, I'm glad you comment on this. It was too vague so far. Please see plies inline. Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan): > Hello, >=20 > As Juergen has mentioned, while the first version has been released to > solicit feedback, some of the concepts are still debated. > The perspectives from the email list would be useful to shape the draft. >=20 > I shall post some of the discussion points.=20 >=20 > Thanks > Mouli >=20 > ------------ >=20 > There is a requirement - > http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt >=20 >=20 > 5.1.1. Type of powered entity >=20 > The energy management standard must provide means to retrieve and > report the type of powered entities. >=20 > I think it would be useful to expand this requirement. Device Type could > be inferred as "IP Phone" or "Line Card 3", ... Yes. The question is what is needed? > One possibility is to consider is a description of the device and then > the type of device.=20 >=20 > Powered Devices Description >=20 > The energy management standard must provide means for identifying the > entity with a powered device description, the domain to which the > device belongs Is this two in one (description and domain)? What would be the requirement for a "description"?=20 Offering a text string for descriptions where arbitrary content can be entered? I don't think the domain should be part of the device description- Mouli>> OK. My intent is to spell out the requirement in to sub-requirements - Description (Text string)=20 MOuli>> Agreed. Domain to which the device belong could be another sub-requirement.=20 > Powered Entity Type >=20 > The energy management standard must provide means to identify the > powered device type such as consumer, provider, meter. It's still vague. What are device types?=20 Is there a fixed list? Is it maintained by IANA?=20 Is it a string where operators may enter arbitrary types? Mouli>> Thinking very simplistically, to further characterize a powered entity there can be three possibilities ' + ' or ' - ' or neutral.=20 MOuli>> So, a device can be consuming power or proving power or neutral. This information can be useful to validate the reading of power recorded from a device.=20 Thanks, Juergen Thanks Mouli > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Quittek > Sent: Thursday, June 30, 2011 2:56 PM > To: eman mailing list > Subject: Re: [eman] New draft on eman requirements >=20 > Dear all, >=20 > I am sorry for posting another version just one day after the previous > one. > Now out is version -03 to be found at >=20 > http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt >=20 > The reason was that a change in terminology ("powered device" -> > "powered > entity") was not done consistently in all sections, particularly not in > the > battery section. >=20 > There are no further changes, particularly no technical changes compared > to > the previous version. >=20 > Thanks, >=20 > Juergen >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Fri Jul 1 05:57:59 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9BD11E8989 for ; Fri, 1 Jul 2011 05:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eujSsqS3NafN for ; Fri, 1 Jul 2011 05:57:59 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2649D11E8394 for ; Fri, 1 Jul 2011 05:42:34 -0700 (PDT) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LvzHJ-1RcuOq0yOz-018Fsc; Fri, 01 Jul 2011 14:42:33 +0200 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: 7bit From: Juergen Quittek Date: Fri, 1 Jul 2011 14:42:27 +0200 To: Mouli Chandramouli (moulchan) X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:Xp+c0ev7xuhFr1gRiblACcutoHsamj7TEugj0ytTcl8 Xj3J8FB/k/3k0JK8I/r1ErhTRgp5LNLpA7g+PuCaH2Hq6r7pME IrPv0E++GbUJZK3RKKFxQhBa6GIQkMI75EJqgBjbkognDSYfvH SQTjAR2LIYXDekIgI9R3qubIGtBCeRv3mFs57dKE0koCxyhkOW 6X2wBPFkbK8BN2pE95uKg== Cc: eman mailing list Subject: Re: [eman] New draft on eman requirements - issue 3 - Inlet/Outlet 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, 01 Jul 2011 12:57:59 -0000 Am 01.07.2011 um 13:25 schrieb Mouli Chandramouli (moulchan): > > There are two requirements - > > > http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt > > 5.3.2. Corresponding power outlet > > The energy management standard must provide means for identifying the > power outlet that provides the power received at a power inlet. > > 5.3.3. Corresponding power inlets > > The energy management standard must provide means for identifying the > list of power inlets that receive the power provided at a power > outlet > > > It would be useful to explain the context of this requirement. This > seems tracing the power distribution tree. Yes, good point. Let's add such text to the next version. Anyway, in your terminology these relationships are just "power supply parent" and "power supply child". > Secondly, for a power outlet or inlet, do all the power monitoring > requirements apply or only some of them (such as power quality, ...) As said in the abstract and in the introduction: This requirements draft just asks a standard to provide means for reporting quality and all the other attributes. However, which must be implements for compliance needs to be specified by the MIB modules or other standards track documents. Obviously, there must be a clause in those standards documents allowing not to implement many things, such as power quality measurements at outlets. Thanks, Juergen > > Thanks > Mouli > > > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Quittek > Sent: Thursday, June 30, 2011 2:56 PM > To: eman mailing list > Subject: Re: [eman] New draft on eman requirements > > Dear all, > > I am sorry for posting another version just one day after the previous > one. > Now out is version -03 to be found at > > http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt > > The reason was that a change in terminology ("powered device" -> > "powered > entity") was not done consistently in all sections, particularly not in > the > battery section. > > There are no further changes, particularly no technical changes compared > to > the previous version. > > Thanks, > > Juergen > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Fri Jul 1 05:58:40 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEED11E8577 for ; Fri, 1 Jul 2011 05:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4x8H55TIBQsU for ; Fri, 1 Jul 2011 05:58:40 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 19A1811E8C78 for ; Fri, 1 Jul 2011 05:49:08 -0700 (PDT) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0LlVhP-1RAryh2qW7-00bM1C; Fri, 01 Jul 2011 14:49:05 +0200 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <4818DAB8-BE72-496E-99EC-1DA8F5B84309@quittek.at> Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Fri, 1 Jul 2011 14:48:58 +0200 To: Mouli Chandramouli (moulchan) X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:yF6ZBqERflvyRa5xdCvpFTHTlU+C8ifdRmW3MazPkHy lwksfAqSqCMrPjKtxgfjUBTztswIqrm/ShXCLo9O4YIcaJbAIr RXxf33y0kfbOZCQifgRxsCRPwflKHAYHJd4p31q8cxLTXqighU U/lCgWSzjzdFXnp/3hUf22tWIJsINjoEAMkUdDaghF3XVtqNZW J1DWYSKh8hD8GzhFynU8g== Cc: eman mailing list Subject: Re: [eman] New draft on eman requirements - Comment - Terminology 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, 01 Jul 2011 12:58:40 -0000 Yes, of course. You have my full agreement. However, we are not that far yet. There will be a new and probably better definition of these terms=20 in the next update of the framework. You can make the same comment then. There will also be a new definition of "demand". I did not include any = of the=20 ones we had so far in the requirements draft, because they were not = usable. However, as long as we are continuously improving our definitions=20 we do not have to take much care of having the same one in all drafts.=20= Once we all think we have arrived at a final definition, we should make=20= sure every document uses the same. Thanks, Juergen Am 01.07.2011 um 13:38 schrieb Mouli Chandramouli (moulchan): > = http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt >=20 > It would be useful to have consistent definitions of Power, Energy and > Demand since these terms are used in many of the documents.=20 >=20 > Thanks > Mouli >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of > Juergen Quittek > Sent: Thursday, June 30, 2011 2:56 PM > To: eman mailing list > Subject: Re: [eman] New draft on eman requirements >=20 > Dear all, >=20 > I am sorry for posting another version just one day after the previous > one. > Now out is version -03 to be found at >=20 > = http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt >=20 > The reason was that a change in terminology ("powered device" -> > "powered > entity") was not done consistently in all sections, particularly not = in > the > battery section. >=20 > There are no further changes, particularly no technical changes = compared > to > the previous version. >=20 > Thanks, >=20 > Juergen >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From bclaise@cisco.com Fri Jul 1 07:09:52 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160FE11E815F for ; Fri, 1 Jul 2011 07:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+RSmKn8SNN2 for ; Fri, 1 Jul 2011 07:09:51 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C9F8711E828B for ; Fri, 1 Jul 2011 07:09:21 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p61E9Kpv003087; Fri, 1 Jul 2011 16:09:20 +0200 (CEST) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p61E9KJf020262; Fri, 1 Jul 2011 16:09:20 +0200 (CEST) Message-ID: <4E0DD510.6040102@cisco.com> Date: Fri, 01 Jul 2011 16:09:20 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Juergen Quittek References: <1127B34B-6899-4F1D-966E-ED841E25E554@quittek.at> In-Reply-To: <1127B34B-6899-4F1D-966E-ED841E25E554@quittek.at> Content-Type: multipart/alternative; boundary="------------040300080309080000070700" Cc: eman mailing list Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type -> domain 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, 01 Jul 2011 14:09:52 -0000 This is a multi-part message in MIME format. --------------040300080309080000070700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Specifically dealing with the domain... 4.1. Identifying powered entities The energy management standard must provide means for uniquely identifying powered entities that are monitored or controlled by an energy management system. Uniqueness must be given in a domain that is large enough to avoid collisions of identities at potential receivers of monitored information. Since the domain is mentioned here, isn't it a case for a specific requirement regarding the domain? Regards, Benoit. > Hi Mouli, > > I'm glad you comment on this. It was too vague so far. > Please see plies inline. > > Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan): > >> Hello, >> >> As Juergen has mentioned, while the first version has been released to >> solicit feedback, some of the concepts are still debated. >> The perspectives from the email list would be useful to shape the draft. >> >> I shall post some of the discussion points. >> >> Thanks >> Mouli >> >> ------------ >> >> There is a requirement - >> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt >> >> >> 5.1.1. Type of powered entity >> >> The energy management standard must provide means to retrieve and >> report the type of powered entities. >> >> I think it would be useful to expand this requirement. Device Type could >> be inferred as "IP Phone" or "Line Card 3", ... > Yes. The question is what is needed? > >> One possibility is to consider is a description of the device and then >> the type of device. >> >> Powered Devices Description >> >> The energy management standard must provide means for identifying the >> entity with a powered device description, the domain to which the >> device belongs > Is this two in one (description and domain)? > > What would be the requirement for a "description"? > Offering a text string for descriptions where arbitrary content can be entered? > > I don't think the domain should be part of the device description- > >> Powered Entity Type >> >> The energy management standard must provide means to identify the >> powered device type such as consumer, provider, meter. > It's still vague. What are device types? > Is there a fixed list? Is it maintained by IANA? > Is it a string where operators may enter arbitrary types? > > Thanks, > > Juergen > >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of >> Juergen Quittek >> Sent: Thursday, June 30, 2011 2:56 PM >> To: eman mailing list >> Subject: Re: [eman] New draft on eman requirements >> >> Dear all, >> >> I am sorry for posting another version just one day after the previous >> one. >> Now out is version -03 to be found at >> >> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt >> >> The reason was that a change in terminology ("powered device" -> >> "powered >> entity") was not done consistently in all sections, particularly not in >> the >> battery section. >> >> There are no further changes, particularly no technical changes compared >> to >> the previous version. >> >> Thanks, >> >> Juergen >> >> _______________________________________________ >> 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 --------------040300080309080000070700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Specifically dealing with the domain...

4.1.  Identifying powered entities
   The energy management standard must provide means for uniquely
   identifying powered entities that are monitored or controlled by an
   energy management system.  Uniqueness must be given in a domain that
   is large enough to avoid collisions of identities at potential
   receivers of monitored information.
Since the domain is mentioned here, isn't it a case for a specific requirement regarding the domain?

Regards, Benoit.
Hi Mouli,

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

Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan):


Hello,

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

I shall post some of the discussion points. 

Thanks
Mouli

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

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


5.1.1.  Type of powered entity

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

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

Yes. The question is what is needed?


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

Powered Devices Description

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

Is this two in one (description and domain)?

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

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


Powered Entity Type

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

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

Thanks,

    Juergen


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

Dear all,

I am sorry for posting another version just one day after the previous
one.
Now out is version -03 to be found at

http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt

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

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

Thanks,

   Juergen

_______________________________________________
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

--------------040300080309080000070700-- From Quittek@neclab.eu Fri Jul 1 07:46:33 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C51A9E8013 for ; Fri, 1 Jul 2011 07:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 SXgBWCzRqAQn for ; Fri, 1 Jul 2011 07:46:32 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC939E800E for ; Fri, 1 Jul 2011 07:46:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3135128000211; Fri, 1 Jul 2011 16:46:31 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq0DCImq82iy; Fri, 1 Jul 2011 16:46:31 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1170D28000189; Fri, 1 Jul 2011 16:46:16 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.100]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Fri, 1 Jul 2011 16:46:16 +0200 From: Juergen Quittek To: Benoit Claise , Juergen Quittek Thread-Topic: [eman] New draft on eman requirements - issue 1 - Device type -> domain Thread-Index: AQHMN/idHLjl62nAlkmM9hmSWsTUy5TXi0UA Date: Fri, 1 Jul 2011 14:46:16 +0000 Message-ID: In-Reply-To: <4E0DD510.6040102@cisco.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.10.0.110428 x-originating-ip: [10.1.2.219] Content-Type: text/plain; charset="us-ascii" Content-ID: <0674BDB38AAC904B9A11A3FB8CA934B9@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type -> domain 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, 01 Jul 2011 14:46:33 -0000 Hi Benoit, This requirement is already in the draft: > 5.1.2. Grouping of powered entities >=20 > The energy management standard must provide means for grouping > powered entities, for example, into energy monitoring domains, energy > control domains, power supply domains, groups of entities of the same > type, etc. Does it cover what you are looking for? Thanks, Juergen Am 01.07.11 16:09 schrieb "Benoit Claise" unter : > Dear all, > =20 > Specifically dealing with the domain... > =20 > =20 > 4.1. Identifying powered entities > The energy management standard must provide means for uniquely > identifying powered entities that are monitored or controlled by an > energy management system. Uniqueness must be given in a domain that > is large enough to avoid collisions of identities at potential > receivers of monitored information. > Since the domain is mentioned here, isn't it a case for a specific > requirement regarding the domain? > =20 > Regards, Benoit. > =20 >> =20 >> Hi Mouli, >>=20 >> I'm glad you comment on this. It was too vague so far. >> Please see plies inline. >>=20 >> Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan): >>=20 >> =20 >>> =20 >>> Hello, >>>=20 >>> As Juergen has mentioned, while the first version has been released to >>> solicit feedback, some of the concepts are still debated. >>> The perspectives from the email list would be useful to shape the draft= . >>>=20 >>> I shall post some of the discussion points. >>>=20 >>> Thanks >>> Mouli >>>=20 >>> ------------ >>>=20 >>> There is a requirement - >>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt >>>=20 >>>=20 >>> 5.1.1. Type of powered entity >>>=20 >>> The energy management standard must provide means to retrieve and >>> report the type of powered entities. >>>=20 >>> I think it would be useful to expand this requirement. Device Type coul= d >>> be inferred as "IP Phone" or "Line Card 3", ... >>> =20 >> =20 >>=20 >> Yes. The question is what is needed? >>=20 >> =20 >>> =20 >>> One possibility is to consider is a description of the device and then >>> the type of device. >>>=20 >>> Powered Devices Description >>>=20 >>> The energy management standard must provide means for identifying the >>> entity with a powered device description, the domain to which the >>> device belongs >>> =20 >> =20 >>=20 >> Is this two in one (description and domain)? >>=20 >> What would be the requirement for a "description"? >> Offering a text string for descriptions where arbitrary content can be >> entered? >>=20 >> I don't think the domain should be part of the device description- >>=20 >> =20 >>> =20 >>> Powered Entity Type >>>=20 >>> The energy management standard must provide means to identify the >>> powered device type such as consumer, provider, meter. >>> =20 >> =20 >>=20 >> It's still vague. What are device types? >> Is there a fixed list? Is it maintained by IANA? >> Is it a string where operators may enter arbitrary types? >>=20 >> Thanks, >>=20 >> Juergen >>=20 >> =20 >>> =20 >>> -----Original Message----- >>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of >>> Juergen Quittek >>> Sent: Thursday, June 30, 2011 2:56 PM >>> To: eman mailing list >>> Subject: Re: [eman] New draft on eman requirements >>>=20 >>> Dear all, >>>=20 >>> I am sorry for posting another version just one day after the previous >>> one. >>> Now out is version -03 to be found at >>>=20 >>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt >>>=20 >>> The reason was that a change in terminology ("powered device" -> >>> "powered >>> entity") was not done consistently in all sections, particularly not in >>> the >>> battery section. >>>=20 >>> There are no further changes, particularly no technical changes compare= d >>> to >>> the previous version. >>>=20 >>> Thanks, >>>=20 >>> Juergen >>>=20 >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman >>> =20 >> =20 >>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >> =20 > =20 > =20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From bnordman@lbl.gov Fri Jul 1 14:50:47 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C76D11E81E3 for ; Fri, 1 Jul 2011 14:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.232 X-Spam-Level: X-Spam-Status: No, score=-5.232 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvjXhvYIWLWz for ; Fri, 1 Jul 2011 14:50:46 -0700 (PDT) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1255A11E81C4 for ; Fri, 1 Jul 2011 14:50:45 -0700 (PDT) X-Ironport-SBRS: 5.2 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIBAPc/Dk7RVdy0mGdsb2JhbABMBoJRnRcBiBAIFAEBAQEBCAkNBxQlrV6cK4M5gnkEhz6KdIwePIN3 X-IronPort-AV: E=Sophos;i="4.65,460,1304319600"; d="scan'208";a="45024938" Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport4.lbl.gov with ESMTP; 01 Jul 2011 14:50:44 -0700 Received: by mail-vx0-f180.google.com with SMTP id 7so4743276vxd.39 for ; Fri, 01 Jul 2011 14:50:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.34 with SMTP id i2mr1478529vdg.29.1309557044379; Fri, 01 Jul 2011 14:50:44 -0700 (PDT) Received: by 10.52.161.196 with HTTP; Fri, 1 Jul 2011 14:50:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Jul 2011 14:50:44 -0700 Message-ID: From: Bruce Nordman To: "Mouli Chandramouli (moulchan)" Content-Type: multipart/alternative; boundary=20cf307ac3bd717e9104a7090221 Cc: eman mailing list Subject: Re: [eman] New draft on eman requirements - Comment - Terminology 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, 01 Jul 2011 21:50:47 -0000 --20cf307ac3bd717e9104a7090221 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable One possible reference is: IEEE 100, "The Authoritative Dictionary of IEEE Standards Terms", IEEE. I have the Seventh Edition, 2000, which appears to be the most recent (perhaps it is now only revised electronically). I am not an engineer, but have chaired an IEEE working group. A measurement standard that I am very familiar with is IEC 62301 (Ed. 2), "Household electrical appliances =96 Measurement of standby power" - which addresses measurements of individual devices. It does NOT define power or energy in the standard, but instead references: IEC 60050-131, International Electrotechnical Vocabulary (IEV) =96 Part 131= : Circuit theory IEC 60050-300, International Electrotechnical Vocabulary (IEV) =96 Electric= al and electronic measurements and measuring instruments =96 Part 311: General terms relating to measure- ments =96 Part 312: General terms relating to electrical measurements =96 Part 313: Types of electrical measuring instruments =96 Part 314: Specific terms according to the type of instrumen= t So, would be good if someone could see what these say, or perhaps we can do the same and simply reference these without defining energy or power (except to specify the units). I do think we should reference 62301, at least as informative. It is widely referenced in energy test procedures for electronics (and presumably for appliances as well). Back to the IEEE Dictionary. Energy in the context of "metering" is: "The integral of active power with respect to time." Demand in the context of "electrical power systems in commercial buildings" is. "The electrical load at the receiving terminals averaged over a specified interval of time. Demand is expressed in kilowatts, kilovoltamperes, kilovars, amperes, or other suitable units. The interval of time is generally 15 minutes, 30 minutes, or 60 minutes." Other definitions listed are: "The average value of power or a related quantity over a specified interval of time" "The rate at which electrical energy is being used" "The rate of consumption, e.g. power, volume/hour." Power (most applicable definition) is: "The rate of generating, transferring, or using energy." Power--Active is: "The time average of the instantaneous power over one period of the wave." This same definition is listed for metering for "Active Power". Some terms have extremely lengthy definitions. Examples include electric energy, and active power. Electric Energy begins: "The electric energy delivered by an electric circuit during a time interva= l is the integral with respect to time of the instantaneous power at the terminals of entry of the circuit to a delineated region." A second definition is in its entirety "Usually, electric demand integrated over the period of one hour". Also worthy of consideration: Electricity Meter: "A device that measures and registers the integral of an electrical quantit= y with respect to time" A similar definition exists for "watthour meter". I would be in favor of short definitions that then point to IEC or IEEE. --Bruce On Fri, Jul 1, 2011 at 4:38 AM, Mouli Chandramouli (moulchan) < moulchan@cisco.com> wrote: > http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt > > It would be useful to have consistent definitions of Power, Energy and > Demand since these terms are used in many of the documents. > > Thanks > Mouli > > --=20 *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --20cf307ac3bd717e9104a7090221 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable One possible reference is:
=A0 IEEE 100, "The Authoritative Diction= ary of IEEE Standards Terms", IEEE.
I have the Seventh Edition, 200= 0, which appears to be the most recent
(perhaps it is now only revised e= lectronically).
I am not an engineer, but have chaired an IEEE working group.

A meas= urement standard that I am very familiar with is IEC 62301 (Ed. 2),
&quo= t;Household electrical appliances =96 Measurement of standby power" - = which
addresses measurements of individual devices.=A0 It does NOT define poweror energy in the standard, but instead references:
IEC 60050-131, International Electrotechnical Vocabulary (IE= V) =96 Part 131: Circuit theory
IEC 60050-300, International Electrotechnical Vocabulary (IEV) =96 Electric= al and electronic measurements and measuring instruments =96 Part 311: Gene= ral terms relating to measure- ments =96 Part 312: General terms relating t= o electrical measurements =96 Part 313: Types of electrical measuring instr= uments =96 Part 314: Specific terms according to the type of instrument
So, would be good if someone could see what these say, or perhaps we = can
do the same and simply reference these without defining energy or po= wer
(except to specify the units).=A0 I do think we should reference 623= 01, at least
as informative.=A0 It is widely referenced in energy test procedures for el= ectronics
(and presumably for appliances as well).

Back to the IE= EE Dictionary.
Energy in the context of "metering" is:
&quo= t;The integral of active power with respect to time."

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

Power (most appl= icable definition) is:
"The rate of generating, transferring, or us= ing energy."

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

Some terms have extremely lengt= hy definitions.=A0 Examples include
electric energy, and active power.

Electric Energy begins:
"= The electric energy delivered by an electric circuit during a time interval=
=A0is the integral with respect to time of the instantaneous power at t= he
=A0terminals of entry of the circuit to a delineated region."
A sec= ond definition is in its entirety
"Usually, electric demand integra= ted over the period of one hour".

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

I would be in favo= r of short definitions that then point to IEC or IEEE.

--Bruce


On Fri, Jul 1, 2011 at 4:= 38 AM, Mouli Chandramouli (moulchan) <moulchan@cisco.com> wrote:
http://www.ietf.org/internet-drafts/draft-ietf-e= man-requirements-03.txt

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

Thanks
Mouli


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

--20cf307ac3bd717e9104a7090221-- From jinchoe@gmail.com Tue Jul 5 20:43:35 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138F821F85E8 for ; Tue, 5 Jul 2011 20:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 4zPdt6xFkA9r for ; Tue, 5 Jul 2011 20:43:34 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 521C421F85E5 for ; Tue, 5 Jul 2011 20:43:34 -0700 (PDT) Received: by pvh18 with SMTP id 18so8735773pvh.31 for ; Tue, 05 Jul 2011 20:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=riDmKMTFlGu75J+WUp9NRphRbmTh4uJoUxOgCcwIq+4=; b=uRFhUmn0la/Q7flMeXc9Sqx4qqMHE/UTzs00ukh4M1xKWFnY18jXu0FAs3yxqTQNAm Cn9sSS8v1zC5BB7XP0ZY02clrRioTHCCEFtVomtreAPGNxroyZoeeoeYUuuIYtK1SMNT eaTrb1UZKUG8DFOW3D40EK/N+IW8ZZ8wFUprM= MIME-Version: 1.0 Received: by 10.68.36.135 with SMTP id q7mr9974451pbj.38.1309923813855; Tue, 05 Jul 2011 20:43:33 -0700 (PDT) Received: by 10.68.59.138 with HTTP; Tue, 5 Jul 2011 20:43:33 -0700 (PDT) Date: Wed, 6 Jul 2011 12:43:33 +0900 Message-ID: From: JinHyeock Choi To: Juergen Quittek Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: eman mailing list Subject: [eman] Comments on eman requirements X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 03:43:35 -0000 Dear Juergen and all thanks for the update and here are some comments. 1. Clarification of =91Power=92 and =91Energy=92 The relationship between power and (electric) energy is Power is the energy consumption rate (measured with watt) and energy is the integral of power over time (measured with joule or watthour)= . Energy management concerns both =91power=92 and =91energy=92 and now the term =91energy consmption=92 is used for both, and sometimes brings forth confusion. Maybe we can make it more clear by attaching the unit to be measured (either watt or watthour). For example such as =93amount of consumed energy measured by joule or watthour.=94 2. Power/ Energy and Time Both power and energy are time dependent parameter. Power can be measured at a specific moment or averaged over a certain time interval. Energy is measured over a time interval. When reporting =91power=92 or =91energy=92 value, i) a specific moment or ii) a time interval with which the measurement is made also should be provided. 3. Power state and Energy consumption > 5.5.3. Energy per power state > > The energy management standard must provide means for reporting the > consumed energy individually for each power state. Energy consumption depends on not only =91power state=92 but also =91traffic load=92. To make sense out of the monitored =91power=92 or =91energy=92 value, energy management system should also take into consideration corresponding =91traffic rate (measured by bps)=92 or =91accumulated traffic (measured by bits)=92. Otherwise it can=92t determine whether high power consumption is from low energy efficiency or high data traffic. 4. Power profile of powered entity > The basic objective of energy management is operating communication > networks and other equipment with minimal amount of energy, while > maintaining a certain level of service. For the above purpose, it would be of help for energy management system to be aware of the energy efficiency of each powered device (or entity), i.e. how much energy (joule) each device consumes per bit. Ideally energy efficiency would be provided as a power profile (or power model), a function which maps served traffic (bits or bps) into consumed energy (joule/ watt). For example, as a linear function of P =3D a*T + b, where P is energy consumption rate (watt) T is traffic rate (bps) and a, b are constant. I recommend energy efficiency or power profile to be included to the required information in Sec 5. Here are some more > 1. Introduction > > All requirements in this document must be > reflected by standards specifications to be developed based on these > requirements. Looks circular. We may do rid of =91based on these requirements.=92 > 2.1. Energy > > The term 'energy consumption' is commonly used for both, for > referring to the amount of consumed energy and also for referring to > the process of consuming energy. =91process of consuming energy=92 means =91rate of consuming enegy=92 right? > In the first case it addresses > consumed energy, in the second one it addresses power, typically an > average power. For clarification, we may modify =91consumed energy=92 with =91consumed energy measured by joule or watthour= =92 and =91power=92 with =91power measured by watt=92 > 4.2. Identifying components of powered devices > > The energy management standard must provide means for identifying not > just entire devices as powered entities, but also individual > components of powered devices. Shall we also identify (or represent) the (subordinate) relationship between powered device and its individual components? > 5.2.6. Maximum and average power per power state > > The energy management standard must provide means for retrieving the > maximum power and the average power as a typically static property > for each supported power state. Maximum power at maximum capacity? Average power in which sense? Just a arithmetic mean value between maximum and minimum power? > 5.4. Power > > For some network management tasks, it is required to obtain time > series of power values (or energy consumption values). I assume energy consumption value measured by watt. Am I right? > 5.5. Energy > > In order to monitor energy consumption in different power states, it > is useful if entities record their energy consumption per power state > and report these quantities. Energy consumption varies according to power state and traffic load. How do you take =91traffic load=92 into consideration? > 5.5.4. Time series of energy values > > The energy management standard must provide means for collecting time > series of energy values for each power inlet and for each power > outlet of an entity Energy would be measured over time interval. Would time series of energy values be measured over the sequence of time intervals in 5.5.2? > 8.1.1. Control of power states of other entities > > The energy management standard must provide means for an energy > management system to send power state control commands to entity that > concern the power states of other entities than the one the command > was send to. Is this always the case? Can=92t control command be sent to an entity that concern the power state of itself? > 8.1.4. List of all power state controllers > > =A0 The energy management standard must provide means for an entity that > =A0 has receives commands controlling its power state from other entities > =A0 to report the list of all those entities. Typo sub =91receives=92 with =91received=92 > 9. Security Considerations > > Secondly, it should be possible to prevent > malicious entities exercising control over entities. sub =91prevent malicious entities exercising=92 with =91prevent malicious entities from exercising=92 Thanks for your kind consideration. Best regards JinHyeock From karagian@cs.utwente.nl Tue Jul 5 23:33:48 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D3D21F85F8 for ; Tue, 5 Jul 2011 23:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.732 X-Spam-Level: * X-Spam-Status: No, score=1.732 tagged_above=-999 required=5 tests=[AWL=-1.460, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MANGLED_SEX=2.3, MIME_QP_LONG_LINE=1.396] 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 RHXSbfrZVTqX for ; Tue, 5 Jul 2011 23:33:47 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3843221F8589 for ; Tue, 5 Jul 2011 23:33:46 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p666W8g4025519; Wed, 6 Jul 2011 08:32:08 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 06 Jul 2011 06:33:47 +0000 To: "Juergen Quittek" , "eman mailing list" Date: Wed, 06 Jul 2011 06:33:47 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 06 Jul 2011 08:32:19 +0200 (MEST) Subject: Re: [eman] New draft on eman requirements X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 06:33:48 -0000 Hi Juergen, I think that the draft looks good! I have some comments on the open issues sections 12.3 and 12.4. In this email I will only address 12.3. In another email I will address 12.4. Regarding Section 12.3 Inlet/outlet combinations: -------------------------------- I am in favour of introducing a new kind of hybrid in/outlets. This is because such sockets are different than the typical inlet and outlet sockets. If these hybrid sockets are used then the requirements associated with inlet/outlet socket have to somehow be modified, see below: Change_1 related to Inlet/outlet combinations: 5.3. Power inlet and power outlet Powered entities have power inlets at which they are supplied with electric power. Many entities just have a single power inlet, while others have multiple ones. Often different power inlets are connected to separate power distribution trees. For energy monitoring, it is important information which power inlets an entity has, if power is available at an inlet and which of them are actually in use. Some entities have power outlets for supplying other entities with electric power. An entity may have multiple power outlets. Examples are a Power Distribution Units (PDU) and a Power over Ethernet (PoE) Power Sourcing Equipment (PSE). For identifying and potentially controlling the source of power received at an inlet, it is useful to identify the power outlet of another entity at which the received power is provided. Analogously, for each outlet it is of interest to identify the power inlets that receive the power provided at a certain outlet. Static properties of each power inlet and each power outlet are useful information for energy management. Static properties include the kind of electric current (Alternating Current (AC) or Direct Current (DC)), the nominal voltage, the nominal AC frequency, and the number of AC phases. INTO something like: 5.3. Power inlet, power outlet and hybrid power inlet/outlet Powered entities have power inlets at which they are supplied with electric power. Many entities just have a single power inlet, while others have multiple ones. Often different power inlets are connected to separate power distribution trees. For energy monitoring, it is important information which power inlets an entity has, if power is available at an inlet and which of them are actually in use. Some entities have power outlets for supplying other entities with electric power. An entity may have multiple power outlets. Examples are a Power Distribution Units (PDU) and a Power over Ethernet (PoE) Power Sourcing Equipment (PSE). There are entities where the inlet or outlet changes during operation from one kind to the other. An example is a battery that receives power at a socket at one time. Then the socket is an inlet. At another time the battery provides power at the same socket. Then it's an outlet. The same holds for entities with integrated power generators. This type of socket is denoted as a hybrid power inlet/outlet. For identifying and potentially controlling the source of power received at an inlet, it is useful to identify the power outlet of another entity at which the received power is provided. Analogously, for each outlet it is of interest to identify the power inlets that receive the power provided at a certain outlet. For hybrid power inlet/outlet it is for interest to identify and control when and for how long a hybrid socket operates as a power inlet and for how long it operates as a power outlet. Static properties of each power inlet and each power outlet are useful information for energy management. Static properties include the kind of electric current (Alternating Current (AC) or Direct Current (DC)), the nominal voltage, the nominal AC frequency, and the number of AC phases. Change_2: related to Inlet/outlet combinations: Please change from: 5.3.2. Corresponding power outlet The energy management standard must provide means for identifying the power outlet that provides the power received at a power inlet. INto something like: 5.3.2. Corresponding power outlet The energy management standard must provide means for identifying the power outlet that provides the power received at a power inlet or at a hybrid power inlet/outlet. ----------------------- Change_3: related to Inlet/outlet combinations: Please change from: 5.3.3. Corresponding power inlets The energy management standard must provide means for identifying the list of power inlets that receive the power provided at a power outlet. INto something like: 5.3.3. Corresponding power inlets The energy management standard must provide means for identifying the list of power inlets that receive the power provided at a power outlet or a hybrid power inlet/outlet. --------------- Change_4 related to Inlet/outlet combinations: Include a new section in 5.3, after section 5.3.3, something like: 5.3.x Corresponding hybrid power inlets/outlets The energy management standard must provide means for identifying the hybrid power inlet/outlet that provides the power received at a power inlet or another hybrid power inlet/outlet. ------------------ Change_5 related to Inlet/outlet combinations: Please change from: 5.3.4. Availability of power The energy management standard must provide means for monitoring the availability of power at each power inlet and each power outlet. This information indicates whether at a power providing outlet power supply is switched on or off. INto something like: 5.3.4. Availability of power The energy management standard must provide means for monitoring the availability of power at each power inlet, at each power outlet and at each hybrid power inlet/outlet. This information indicates whether at a power providing outlet the power supply is switched on or off. For a hybrid power inlet/outlet this indicates whether the hybrid inlet/outlet operates as an inlet or as an outlet. -------------- Change 6 related to Inlet/outlet combinations: Please change from: 5.3.5. Use of power The energy management standard must provide means for monitoring for each power inlet and each power outlet if it is in actual use. For the inlet this means that the entity actually receives power at the inlet. For the outlet this means that actually power is provided to one or more entities at the outlet. INTO something like: 5.3.5. Use of power The energy management standard must provide means for monitoring for each power inlet, for each power outlet and for each hybrid power inlet/outlet if it is in actual use. For the inlet this means that the entity actually receives power at the inlet. For the outlet this means that actually power is provided to one or more entities at the outlet. For the hybrid inlet/outlet this means that the energy management standard must be able to distinguish whether power is received to the hybrid inlet/outlet or power is provided by the hybrid inlet/outlet to one or more entities. ------------------ Change 7 related to Inlet/outlet combinations: Please a new subsection after subsection 6.2 6.2.x Controlling power supply and consumption The energy management standard must provide means for switching power supply off or turning power supply on at power outlets providing power to one or more powered entity. INTO something like: 6.2.x Controlling power supply and consumption The energy management standard must provide means for switching power supply off or turning power supply on at hybrid power inlet/outlets. Furthermore, the energy management standard must provide means for switching the power consumption off or turning power consumption on at hybrid power inlet/outlets. --------------- Best regards, Georgios PS: I will provide some comments on the aggregation related issue in another email On 6/30/2011, "Juergen Quittek" wrote: >Dear all, > >I am sorry for posting another version just one day after the previous one. >Now out is version -03 to be found at > http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt > >The reason was that a change in terminology ("powered device" -> "powered >entity") was not done consistently in all sections, particularly not in the >battery section. > >There are no further changes, particularly no technical changes compared to >the previous version. > >Thanks, > > Juergen > >Am 29.06.11 16:53 schrieb "Juergen Quittek" unter : > >> Dear all, >> >> I just posted a new version on the requirements draft. >> Please find it at >> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-02.txt >> >> We had intensive discussions among the authors and received a lot of usefu= l >> comments from John Parello. This resulted in many changes and a modified >> structure. We consider the version posted today as an intermediate one and >> intend to post another update before the cut-off date. >> >> Please have a look at the new structure and give us your feedback. >> >> Issues that we definitely want to solve for the next version are described >> in section 12. Among them are >> - High/Low power notifications >> - Power and energy time series? >> - Inlet/outlet combinations >> - Aggregation functions >> Your advice on these issues is highly appreciated. >> >> Thanks, >> >> Juergen >> >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman From moulchan@cisco.com Tue Jul 5 23:50:43 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0033921F869A for ; Tue, 5 Jul 2011 23:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-5.150, BAYES_00=-2.599, MANGLED_SEX=2.3] 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 vLmmuwgeOwy3 for ; Tue, 5 Jul 2011 23:50:42 -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 D541121F868D for ; Tue, 5 Jul 2011 23:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=10779; q=dns/txt; s=iport; t=1309935042; x=1311144642; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=6VgIn0UGcNa7qDbJLsd1dGuKQGXQP49jaHd6XzWhzjQ=; b=BYUC/TFmpnANzLegkk0wXTu6mtE7VKGLsAKXTS7VxI8PsKxHD0b6gFkF PrLMUdxuQZvi5IwUNiTHXGJQ2LP+S0s3ovGrDkf4cxwuV2QbgnCF/LGtS wMotals0M7YWy7I6r4LjIHxyBdVq1kNqEZyfGMJKC1s4JOfY+30UgSjM9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABAIoEFE6tJXHB/2dsb2JhbABFDphVjzZ3rkSeL4MhgxUEh0aPfYtX X-IronPort-AV: E=Sophos;i="4.65,484,1304294400"; d="scan'208";a="356084" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 06 Jul 2011 06:50:41 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p666ofq0021778; Wed, 6 Jul 2011 06:50:41 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 01:50:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jul 2011 01:50:36 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] New draft on eman requirements Thread-Index: Acw7pqwqLSa1fp28So6auDcAz8RUrQAAZhfQ References: From: "Mouli Chandramouli (moulchan)" To: "Georgios Karagiannis" , "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 06 Jul 2011 06:50:41.0019 (UTC) FILETIME=[053B5CB0:01CC3BA9] Subject: Re: [eman] New draft on eman requirements X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 06:50:43 -0000 Hi Georgios, It would help if you can provide some more of the context of what is a hybrid inlet/outlet. Where are these used ? =20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Wednesday, July 06, 2011 12:04 PM To: Juergen Quittek; eman mailing list Subject: Re: [eman] New draft on eman requirements Hi Juergen, I think that the draft looks good! I have some comments on the open issues sections 12.3 and 12.4. In this email I will only address 12.3. In another email I will address 12.4. Regarding Section 12.3 Inlet/outlet combinations: -------------------------------- I am in favour of introducing a new kind of hybrid in/outlets. This is because such sockets are different than the typical inlet and outlet sockets. If these hybrid sockets are used then the requirements associated with inlet/outlet socket have to somehow be modified, see below: Change_1 related to Inlet/outlet combinations: 5.3. Power inlet and power outlet Powered entities have power inlets at which they are supplied with electric power. Many entities just have a single power inlet, while others have multiple ones. Often different power inlets are connected to separate power distribution trees. For energy monitoring, it is important information which power inlets an entity has, if power is available at an inlet and which of them are actually in use. Some entities have power outlets for supplying other entities with electric power. An entity may have multiple power outlets. Examples are a Power Distribution Units (PDU) and a Power over Ethernet (PoE) Power Sourcing Equipment (PSE). For identifying and potentially controlling the source of power received at an inlet, it is useful to identify the power outlet of another entity at which the received power is provided. Analogously, for each outlet it is of interest to identify the power inlets that receive the power provided at a certain outlet. Static properties of each power inlet and each power outlet are useful information for energy management. Static properties include the kind of electric current (Alternating Current (AC) or Direct Current (DC)), the nominal voltage, the nominal AC frequency, and the number of AC phases. INTO something like: 5.3. Power inlet, power outlet and hybrid power inlet/outlet Powered entities have power inlets at which they are supplied with electric power. Many entities just have a single power inlet, while others have multiple ones. Often different power inlets are connected to separate power distribution trees. For energy monitoring, it is important information which power inlets an entity has, if power is available at an inlet and which of them are actually in use. Some entities have power outlets for supplying other entities with electric power. An entity may have multiple power outlets. Examples are a Power Distribution Units (PDU) and a Power over Ethernet (PoE) Power Sourcing Equipment (PSE). There are entities where the inlet or outlet changes during operation from one kind to the other. An example is a battery that receives power at a socket at one time. Then the socket is an inlet. At another time the battery provides power at the same socket. Then it's an outlet. The same holds for entities with integrated power generators. This type of socket is denoted as a hybrid power inlet/outlet. For identifying and potentially controlling the source of power received at an inlet, it is useful to identify the power outlet of another entity at which the received power is provided. Analogously, for each outlet it is of interest to identify the power inlets that receive the power provided at a certain outlet. For hybrid power inlet/outlet it is for interest to identify and control when and for how long a hybrid socket operates as a power inlet and for how long it operates as a power outlet. Static properties of each power inlet and each power outlet are useful information for energy management. Static properties include the kind of electric current (Alternating Current (AC) or Direct Current (DC)), the nominal voltage, the nominal AC frequency, and the number of AC phases. Change_2: related to Inlet/outlet combinations: Please change from: 5.3.2. Corresponding power outlet The energy management standard must provide means for identifying the power outlet that provides the power received at a power inlet. INto something like: 5.3.2. Corresponding power outlet The energy management standard must provide means for identifying the power outlet that provides the power received at a power inlet or at a hybrid power inlet/outlet. ----------------------- Change_3: related to Inlet/outlet combinations: Please change from: 5.3.3. Corresponding power inlets The energy management standard must provide means for identifying the list of power inlets that receive the power provided at a power outlet. INto something like: 5.3.3. Corresponding power inlets The energy management standard must provide means for identifying the list of power inlets that receive the power provided at a power outlet or a hybrid power inlet/outlet. --------------- Change_4 related to Inlet/outlet combinations: Include a new section in 5.3, after section 5.3.3, something like: 5.3.x Corresponding hybrid power inlets/outlets The energy management standard must provide means for identifying the hybrid power inlet/outlet that provides the power received at a power inlet or another hybrid power inlet/outlet. ------------------ Change_5 related to Inlet/outlet combinations: Please change from: 5.3.4. Availability of power The energy management standard must provide means for monitoring the availability of power at each power inlet and each power outlet. This information indicates whether at a power providing outlet power supply is switched on or off. INto something like: 5.3.4. Availability of power The energy management standard must provide means for monitoring the availability of power at each power inlet, at each power outlet and at each hybrid power inlet/outlet. This information indicates whether at a power providing outlet the power supply is switched on or off. For a hybrid power inlet/outlet this indicates whether the hybrid inlet/outlet operates as an inlet or as an outlet. -------------- Change 6 related to Inlet/outlet combinations: Please change from: 5.3.5. Use of power The energy management standard must provide means for monitoring for each power inlet and each power outlet if it is in actual use. For the inlet this means that the entity actually receives power at the inlet. For the outlet this means that actually power is provided to one or more entities at the outlet. INTO something like: 5.3.5. Use of power The energy management standard must provide means for monitoring for each power inlet, for each power outlet and for each hybrid power inlet/outlet if it is in actual use. For the inlet this means that the entity actually receives power at the inlet. For the outlet this means that actually power is provided to one or more entities at the outlet. For the hybrid inlet/outlet this means that the energy management standard must be able to distinguish whether power is received to the hybrid inlet/outlet or power is provided by the hybrid inlet/outlet to one or more entities. ------------------ Change 7 related to Inlet/outlet combinations: Please a new subsection after subsection 6.2 6.2.x Controlling power supply and consumption The energy management standard must provide means for switching power supply off or turning power supply on at power outlets providing power to one or more powered entity. INTO something like: 6.2.x Controlling power supply and consumption The energy management standard must provide means for switching power supply off or turning power supply on at hybrid power inlet/outlets. Furthermore, the energy management standard must provide means for switching the power consumption off or turning power consumption on at hybrid power inlet/outlets. --------------- Best regards, Georgios PS: I will provide some comments on the aggregation related issue in another email On 6/30/2011, "Juergen Quittek" wrote: >Dear all, > >I am sorry for posting another version just one day after the previous one. >Now out is version -03 to be found at > http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt > >The reason was that a change in terminology ("powered device" -> "powered >entity") was not done consistently in all sections, particularly not in the >battery section. > >There are no further changes, particularly no technical changes compared to >the previous version. > >Thanks, > > Juergen > >Am 29.06.11 16:53 schrieb "Juergen Quittek" unter : > >> Dear all, >> >> I just posted a new version on the requirements draft. >> Please find it at >> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-02.txt >> >> We had intensive discussions among the authors and received a lot of useful >> comments from John Parello. This resulted in many changes and a modified >> structure. We consider the version posted today as an intermediate one and >> intend to post another update before the cut-off date. >> >> Please have a look at the new structure and give us your feedback. >> >> Issues that we definitely want to solve for the next version are described >> in section 12. Among them are >> - High/Low power notifications >> - Power and energy time series? >> - Inlet/outlet combinations >> - Aggregation functions >> Your advice on these issues is highly appreciated. >> >> Thanks, >> >> Juergen >> >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From moulchan@cisco.com Wed Jul 6 00:26:03 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7099F21F8686 for ; Wed, 6 Jul 2011 00:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.863 X-Spam-Level: X-Spam-Status: No, score=-5.863 tagged_above=-999 required=5 tests=[AWL=-3.264, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9n7O9QymiiiQ for ; Wed, 6 Jul 2011 00:26:02 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1388021F867C for ; Wed, 6 Jul 2011 00:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=6857; q=dns/txt; s=iport; t=1309937162; x=1311146762; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=adlNsFnIEQvujxfPjbStLZSZxVFeBL2UMm4LIUemhwA=; b=GPNcnvu61J+ABy+PQQIfc15vjtusQr54D84HJ9c/Q5dDWUxs6B4DkfZ3 MNsz3kahbW0gS6WyRjo4PqkXAjPcIGAB8lCJiOOncmEfgzBbTI4J6E/uT WSy8yiWGuzEuXshqjfH2kglT2znLk6UxzlIHYtXQzOP3/mHCDTUuko9Z9 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABAOcNFE6tJXG//2dsb2JhbABFDphVjzJ3iHqlcJ4ygyGDFQSHRo99i1c X-IronPort-AV: E=Sophos;i="4.65,484,1304294400"; d="scan'208";a="359351" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 06 Jul 2011 07:26:00 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p667Q0NG014690; Wed, 6 Jul 2011 07:26:00 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 02:26:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jul 2011 02:25:57 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Comments on eman requirements Thread-Index: Acw7juRojBkReVAQT7y5oxwIuUoFvwAGqBzQ References: From: "Mouli Chandramouli (moulchan)" To: "JinHyeock Choi" , "Juergen Quittek" X-OriginalArrivalTime: 06 Jul 2011 07:26:00.0063 (UTC) FILETIME=[F447D0F0:01CC3BAD] Cc: eman mailing list Subject: Re: [eman] Comments on eman requirements X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 07:26:03 -0000 Hi JinHyeock, Thanks for your detailed comments.=20 As Juergen has mentioned in another email thread, perhaps, the = terminology section may be revised and updated.=20 Regarding your point on energy profile should take into consideration = traffic (bps) for network devices=20 - there are benchmarking studies of networking devices based on TEER = standard=20 http://www.3gpp.org/ATIS-Standards-helping-network That statistic can be derived by an NMS for a networking device by = polling the energy MIB and ifMIB counters.=20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = JinHyeock Choi Sent: Wednesday, July 06, 2011 9:14 AM To: Juergen Quittek Cc: eman mailing list Subject: [eman] Comments on eman requirements Dear Juergen and all thanks for the update and here are some comments. 1. Clarification of 'Power' and 'Energy' The relationship between power and (electric) energy is Power is the energy consumption rate (measured with watt) and energy is the integral of power over time (measured with joule or = watthour). Energy management concerns both 'power' and 'energy' and now the term 'energy consmption' is used for both, and sometimes brings forth confusion. Maybe we can make it more clear by attaching the unit to be measured (either watt or watthour). For example such as "amount of consumed energy measured by joule or watthour." 2. Power/ Energy and Time Both power and energy are time dependent parameter. Power can be measured at a specific moment or averaged over a certain time interval. Energy is measured over a time interval. When reporting 'power' or 'energy' value, i) a specific moment or ii) a time interval with which the measurement is made also should be provided. 3. Power state and Energy consumption > 5.5.3. Energy per power state > > The energy management standard must provide means for reporting the > consumed energy individually for each power state. Energy consumption depends on not only 'power state' but also 'traffic load'. To make sense out of the monitored 'power' or 'energy' value, energy management system should also take into consideration corresponding 'traffic rate (measured by bps)' or 'accumulated traffic (measured by bits)'. Otherwise it can't determine whether high power consumption is from low energy efficiency or high data traffic. 4. Power profile of powered entity > The basic objective of energy management is operating communication > networks and other equipment with minimal amount of energy, while > maintaining a certain level of service. For the above purpose, it would be of help for energy management system to be aware of the energy efficiency of each powered device (or entity), i.e. how much energy (joule) each device consumes per bit. Ideally energy efficiency would be provided as a power profile (or power model), a function which maps served traffic (bits or bps) into consumed energy (joule/ = watt). For example, as a linear function of P =3D a*T + b, where P is energy consumption rate (watt) T is traffic rate (bps) and a, b are constant. I recommend energy efficiency or power profile to be included to the required information in Sec 5. Here are some more > 1. Introduction > > All requirements in this document must be > reflected by standards specifications to be developed based on these > requirements. Looks circular. We may do rid of 'based on these requirements.' > 2.1. Energy > > The term 'energy consumption' is commonly used for both, for > referring to the amount of consumed energy and also for referring to > the process of consuming energy. 'process of consuming energy' means 'rate of consuming enegy' right? > In the first case it addresses > consumed energy, in the second one it addresses power, typically an > average power. For clarification, we may modify 'consumed energy' with 'consumed energy measured by joule or watthour' and 'power' with 'power measured by watt' > 4.2. Identifying components of powered devices > > The energy management standard must provide means for identifying not > just entire devices as powered entities, but also individual > components of powered devices. Shall we also identify (or represent) the (subordinate) relationship between powered device and its individual components? > 5.2.6. Maximum and average power per power state > > The energy management standard must provide means for retrieving the > maximum power and the average power as a typically static property > for each supported power state. Maximum power at maximum capacity? Average power in which sense? Just a arithmetic mean value between maximum and minimum power? > 5.4. Power > > For some network management tasks, it is required to obtain time > series of power values (or energy consumption values). I assume energy consumption value measured by watt. Am I right? > 5.5. Energy > > In order to monitor energy consumption in different power states, it > is useful if entities record their energy consumption per power state > and report these quantities. Energy consumption varies according to power state and traffic load. How do you take 'traffic load' into consideration? > 5.5.4. Time series of energy values > > The energy management standard must provide means for collecting time > series of energy values for each power inlet and for each power > outlet of an entity Energy would be measured over time interval. Would time series of energy values be measured over the sequence of time intervals in 5.5.2? > 8.1.1. Control of power states of other entities > > The energy management standard must provide means for an energy > management system to send power state control commands to entity that > concern the power states of other entities than the one the command > was send to. Is this always the case? Can't control command be sent to an entity that concern the power state of itself? > 8.1.4. List of all power state controllers > > =A0 The energy management standard must provide means for an entity = that > =A0 has receives commands controlling its power state from other = entities > =A0 to report the list of all those entities. Typo sub 'receives' with 'received' > 9. Security Considerations > > Secondly, it should be possible to prevent > malicious entities exercising control over entities. sub 'prevent malicious entities exercising' with 'prevent malicious entities from exercising' Thanks for your kind consideration. Best regards JinHyeock _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From karagian@cs.utwente.nl Wed Jul 6 00:30:24 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516EC21F86A5 for ; Wed, 6 Jul 2011 00:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.18 X-Spam-Level: * X-Spam-Status: No, score=1.18 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MANGLED_SEX=2.3] 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 5Ftbwhtah73v for ; Wed, 6 Jul 2011 00:30:23 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 21A0121F869D for ; Wed, 6 Jul 2011 00:30:22 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p667SkJK005920; Wed, 6 Jul 2011 09:28:46 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 06 Jul 2011 07:30:25 +0000 To: "Mouli Chandramouli (moulchan)" , "Juergen Quittek" , "eman mailing list" Date: Wed, 06 Jul 2011 07:30:24 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 06 Jul 2011 09:28:56 +0200 (MEST) Subject: Re: [eman] New draft on eman requirements X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 07:30:24 -0000 Hi Mouli Examples are given in Sectin 12.3 of the requirements draft: An example is a battery that receives power at a socket at one time. Then the socket is an inlet. At another time the battery provides power at the same socket. Then it's an outlet. The same holds for entities with integrated power generators. Best regards, Georgios On 7/6/2011, "Mouli Chandramouli (moulchan)" wrote: >Hi Georgios, > > >It would help if you can provide some more of the context of what is a >hybrid inlet/outlet. Where are these used ? =20 > >Thanks >Mouli > >-----Original Message----- >From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of >Georgios Karagiannis >Sent: Wednesday, July 06, 2011 12:04 PM >To: Juergen Quittek; eman mailing list >Subject: Re: [eman] New draft on eman requirements > >Hi Juergen, > >I think that the draft looks good! > >I have some comments on the open issues sections 12.3 and 12.4. In this >email I will only >address 12.3. In another email I will address 12.4. > >Regarding Section 12.3 Inlet/outlet combinations: >-------------------------------- > >I am in favour of introducing a new kind of hybrid in/outlets. This is >because such sockets are different than the typical inlet and outlet >sockets. > >If these hybrid sockets are used then the requirements associated with >inlet/outlet socket have to somehow be modified, see below: > > > >Change_1 related to Inlet/outlet combinations: > > >5.3. Power inlet and power outlet > > Powered entities have power inlets at which they are supplied with > electric power. Many entities just have a single power inlet, while > others have multiple ones. Often different power inlets are > connected to separate power distribution trees. For energy > monitoring, it is important information which power inlets an entity > has, if power is available at an inlet and which of them are actually > in use. > > Some entities have power outlets for supplying other entities with > electric power. An entity may have multiple power outlets. Examples > are a Power Distribution Units (PDU) and a Power over Ethernet (PoE) > Power Sourcing Equipment (PSE). > > For identifying and potentially controlling the source of power > received at an inlet, it is useful to identify the power outlet of > another entity at which the received power is provided. Analogously, > for each outlet it is of interest to identify the power inlets that > receive the power provided at a certain outlet. > > Static properties of each power inlet and each power outlet are > useful information for energy management. Static properties include > the kind of electric current (Alternating Current (AC) or Direct > Current (DC)), the nominal voltage, the nominal AC frequency, and the > number of AC phases. > >INTO something like: > >5.3. Power inlet, power outlet and hybrid power inlet/outlet > > Powered entities have power inlets at which they are supplied with > electric power. Many entities just have a single power inlet, while > others have multiple ones. Often different power inlets are > connected to separate power distribution trees. For energy > monitoring, it is important information which power inlets an entity > has, if power is available at an inlet and which of them are actually > in use. > > Some entities have power outlets for supplying other entities with > electric power. An entity may have multiple power outlets. Examples > are a Power Distribution Units (PDU) and a Power over Ethernet (PoE) > Power Sourcing Equipment (PSE). > > > There are entities where the inlet or outlet changes during > operation from one kind to the other. An example is a battery that > receives power at a socket at one time. Then the socket is an inlet. > At another time the battery provides power at the same socket. Then > it's an outlet. The same holds for entities with integrated power > generators. This type of socket is denoted as a hybrid power >inlet/outlet. > > For identifying and potentially controlling the source of power > received at an inlet, it is useful to identify the power outlet of > another entity at which the received power is provided. Analogously, > for each outlet it is of interest to identify the power inlets that > receive the power provided at a certain outlet. For hybrid power >inlet/outlet > it is for interest to identify and control when and for how long a > hybrid socket operates as a power inlet and for how long it operates > as a power outlet. > > Static properties of each power inlet and each power outlet are > useful information for energy management. Static properties include > the kind of electric current (Alternating Current (AC) or Direct > Current (DC)), the nominal voltage, the nominal AC frequency, and the > number of AC phases. > > > >Change_2: related to Inlet/outlet combinations: > >Please change from: > >5.3.2. Corresponding power outlet > > The energy management standard must provide means for identifying the > power outlet that provides the power received at a power inlet. > > >INto something like: > >5.3.2. Corresponding power outlet > > The energy management standard must provide means for identifying the > power outlet that provides the power received at a power inlet or at >a >hybrid power > inlet/outlet. > >----------------------- > >Change_3: related to Inlet/outlet combinations: > >Please change from: > > > >5.3.3. Corresponding power inlets > > The energy management standard must provide means for identifying the > list of power inlets that receive the power provided at a power > outlet. > >INto something like: > >5.3.3. Corresponding power inlets > > The energy management standard must provide means for identifying the > list of power inlets that receive the power provided at a power > outlet or a hybrid power inlet/outlet. > >--------------- > > > >Change_4 related to Inlet/outlet combinations: > >Include a new section in 5.3, after section 5.3.3, something like: > >5.3.x Corresponding hybrid power inlets/outlets > > The energy management standard must provide means for identifying the > hybrid power inlet/outlet that provides the power received at a power >inlet or > another hybrid power inlet/outlet. > >------------------ > >Change_5 related to Inlet/outlet combinations: > >Please change from: > >5.3.4. Availability of power > > The energy management standard must provide means for monitoring the > availability of power at each power inlet and each power outlet. > This information indicates whether at a power providing outlet power > supply is switched on or off. > >INto something like: > >5.3.4. Availability of power > > The energy management standard must provide means for monitoring the > availability of power at each power inlet, at each power outlet and >at >each > hybrid power inlet/outlet. > This information indicates whether at a power providing outlet > the power supply is switched on or off. For a hybrid power >inlet/outlet this indicates whether > the hybrid inlet/outlet operates as an inlet or as an outlet. > > >-------------- > >Change 6 related to Inlet/outlet combinations: > >Please change from: > >5.3.5. Use of power > > The energy management standard must provide means for monitoring for > each power inlet and each power outlet if it is in actual use. For > the inlet this means that the entity actually receives power at the > inlet. For the outlet this means that actually power is provided to > one or more entities at the outlet. > >INTO something like: > >5.3.5. Use of power > > The energy management standard must provide means for monitoring for > each power inlet, for each power outlet and for each hybrid power >inlet/outlet > if it is in actual use. For > the inlet this means that the entity actually receives power at the > inlet. For the outlet this means that actually power is provided to > one or more entities at the outlet. For the hybrid inlet/outlet this >means > that the energy management standard must be able to distinguish >whether > power is received to the hybrid inlet/outlet or power is provided by >the > hybrid inlet/outlet to one or more entities. > >------------------ > >Change 7 related to Inlet/outlet combinations: > >Please a new subsection after subsection 6.2 > >6.2.x Controlling power supply and consumption > The energy management standard must provide means for switching power > supply off or turning power supply on at power outlets providing > power to one or more powered entity. > >INTO something like: > >6.2.x Controlling power supply and consumption > > The energy management standard must provide means for switching power > supply off or turning power supply on at hybrid power inlet/outlets. > Furthermore, the energy management standard must provide means for >switching > the power consumption off or turning power consumption on at hybrid >power inlet/outlets. > >--------------- > >Best regards, >Georgios >PS: I will provide some comments on the aggregation related issue in >another email > > > > > > >On 6/30/2011, "Juergen Quittek" wrote: > >>Dear all, >> >>I am sorry for posting another version just one day after the previous >one. >>Now out is version -03 to be found at >> >http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt >> >>The reason was that a change in terminology ("powered device" -> >"powered >>entity") was not done consistently in all sections, particularly not in >the >>battery section. >> >>There are no further changes, particularly no technical changes >compared to >>the previous version. >> >>Thanks, >> >> Juergen >> >>Am 29.06.11 16:53 schrieb "Juergen Quittek" unter : >> >>> Dear all, >>> >>> I just posted a new version on the requirements draft. >>> Please find it at >>> >http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-02.txt >>> >>> We had intensive discussions among the authors and received a lot of >useful >>> comments from John Parello. This resulted in many changes and a >modified >>> structure. We consider the version posted today as an intermediate >one and >>> intend to post another update before the cut-off date. >>> >>> Please have a look at the new structure and give us your feedback. >>> >>> Issues that we definitely want to solve for the next version are >described >>> in section 12. Among them are >>> - High/Low power notifications >>> - Power and energy time series? >>> - Inlet/outlet combinations >>> - Aggregation functions >>> Your advice on these issues is highly appreciated. >>> >>> Thanks, >>> >>> Juergen >>> >>> _______________________________________________ >>> 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 bclaise@cisco.com Wed Jul 6 02:36:23 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8C921F852B for ; Wed, 6 Jul 2011 02:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUbFbWml-0ai for ; Wed, 6 Jul 2011 02:36:23 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C45EC21F851D for ; Wed, 6 Jul 2011 02:36:22 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p669WbGa013626; Wed, 6 Jul 2011 11:32:37 +0200 (CEST) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p669WaEW004194; Wed, 6 Jul 2011 11:32:36 +0200 (CEST) Message-ID: <4E142BB4.1060103@cisco.com> Date: Wed, 06 Jul 2011 11:32:36 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: eman mailing list Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type -> domain X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 09:36:24 -0000 Hi Juergen, Not exactly. There are actually two different concepts 1. the domain 2. grouping of powered entities. Practically, this is done with the keyword list in [EMAN-AWARE] The requirement 5.1.2 covers "grouping of powered entities" We're missing in section 4 a requirement such as: The energy management standard must provide means for identifying the domain to which the powered entity belongs. Regards, Benoit. > Hi Benoit, > > This requirement is already in the draft: > >> 5.1.2. Grouping of powered entities >> >> The energy management standard must provide means for grouping >> powered entities, for example, into energy monitoring domains, energy >> control domains, power supply domains, groups of entities of the same >> type, etc. > Does it cover what you are looking for? > > Thanks, > > Juergen > > > Am 01.07.11 16:09 schrieb "Benoit Claise" unter: > >> Dear all, >> >> Specifically dealing with the domain... >> >> >> 4.1. Identifying powered entities >> The energy management standard must provide means for uniquely >> identifying powered entities that are monitored or controlled by an >> energy management system. Uniqueness must be given in a domain that >> is large enough to avoid collisions of identities at potential >> receivers of monitored information. >> Since the domain is mentioned here, isn't it a case for a specific >> requirement regarding the domain? >> >> Regards, Benoit. >> >>> >>> Hi Mouli, >>> >>> I'm glad you comment on this. It was too vague so far. >>> Please see plies inline. >>> >>> Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan): >>> >>> >>>> >>>> Hello, >>>> >>>> As Juergen has mentioned, while the first version has been released to >>>> solicit feedback, some of the concepts are still debated. >>>> The perspectives from the email list would be useful to shape the draft. >>>> >>>> I shall post some of the discussion points. >>>> >>>> Thanks >>>> Mouli >>>> >>>> ------------ >>>> >>>> There is a requirement - >>>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt >>>> >>>> >>>> 5.1.1. Type of powered entity >>>> >>>> The energy management standard must provide means to retrieve and >>>> report the type of powered entities. >>>> >>>> I think it would be useful to expand this requirement. Device Type could >>>> be inferred as "IP Phone" or "Line Card 3", ... >>>> >>> >>> >>> Yes. The question is what is needed? >>> >>> >>>> >>>> One possibility is to consider is a description of the device and then >>>> the type of device. >>>> >>>> Powered Devices Description >>>> >>>> The energy management standard must provide means for identifying the >>>> entity with a powered device description, the domain to which the >>>> device belongs >>>> >>> >>> >>> Is this two in one (description and domain)? >>> >>> What would be the requirement for a "description"? >>> Offering a text string for descriptions where arbitrary content can be >>> entered? >>> >>> I don't think the domain should be part of the device description- >>> >>> >>>> >>>> Powered Entity Type >>>> >>>> The energy management standard must provide means to identify the >>>> powered device type such as consumer, provider, meter. >>>> >>> >>> >>> It's still vague. What are device types? >>> Is there a fixed list? Is it maintained by IANA? >>> Is it a string where operators may enter arbitrary types? >>> >>> Thanks, >>> >>> Juergen >>> >>> >>>> >>>> -----Original Message----- >>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of >>>> Juergen Quittek >>>> Sent: Thursday, June 30, 2011 2:56 PM >>>> To: eman mailing list >>>> Subject: Re: [eman] New draft on eman requirements >>>> >>>> Dear all, >>>> >>>> I am sorry for posting another version just one day after the previous >>>> one. >>>> Now out is version -03 to be found at >>>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt >>>> >>>> The reason was that a change in terminology ("powered device" -> >>>> "powered >>>> entity") was not done consistently in all sections, particularly not in >>>> the >>>> battery section. >>>> >>>> There are no further changes, particularly no technical changes compared >>>> to >>>> the previous version. >>>> >>>> Thanks, >>>> >>>> Juergen >>>> >>>> _______________________________________________ >>>> 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 bclaise@cisco.com Wed Jul 6 02:47:30 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6780E21F876A for ; Wed, 6 Jul 2011 02:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLqwhgtMM6Up for ; Wed, 6 Jul 2011 02:47:29 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 501BE21F875B for ; Wed, 6 Jul 2011 02:47:29 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p669Qvxe012900; Wed, 6 Jul 2011 11:26:57 +0200 (CEST) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p669QvEC029773; Wed, 6 Jul 2011 11:26:57 +0200 (CEST) Message-ID: <4E142A61.3010103@cisco.com> Date: Wed, 06 Jul 2011 11:26:57 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Juergen Quittek References: <1127B34B-6899-4F1D-966E-ED841E25E554@quittek.at> In-Reply-To: <1127B34B-6899-4F1D-966E-ED841E25E554@quittek.at> Content-Type: multipart/alternative; boundary="------------050804070605090608000604" Cc: eman mailing list Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 09:47:30 -0000 This is a multi-part message in MIME format. --------------050804070605090608000604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/07/2011 14:10, Juergen Quittek wrote: > Hi Mouli, > > I'm glad you comment on this. It was too vague so far. > Please see plies inline. > > Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan): > >> Hello, >> >> As Juergen has mentioned, while the first version has been released to >> solicit feedback, some of the concepts are still debated. >> The perspectives from the email list would be useful to shape the draft. >> >> I shall post some of the discussion points. >> >> Thanks >> Mouli >> >> ------------ >> >> There is a requirement - >> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt >> >> >> 5.1.1. Type of powered entity >> >> The energy management standard must provide means to retrieve and >> report the type of powered entities. >> >> I think it would be useful to expand this requirement. Device Type could >> be inferred as "IP Phone" or "Line Card 3", ... > Yes. The question is what is needed? We don't want we redo the ENTITY-MIB work, but I believe that having a way to map to the ENTITY-MIB index is important. The more generic requirements should be something such as: The energy management standard must provide means to map the power entities to existing managed device inventory such as the ENTITY-MIB. The energy management standard must provide means to map the power entities to existing energy related MIBs such as the POE and LLPD MIBs Those two requirements should be in the section 4. Identification of Powered Entities Coming back to this requirement 5.1.1. Type of powered entity The energy management standard must provide means to retrieve and report the type of powered entities. I believe the "type" is misleading. The main requirement is that we want the ability to group powered entities based on something, which could be the type, what the type definition you want. Therefore, I would remove the requirement 5.1.1 and only keep the current 5.1.2 5.1.2. Grouping of powered entities The energy management standard must provide means for grouping powered entities, for example, into energy monitoring domains, energy control domains, power supply domains, groups of entities of the same type, etc. Regards, Benoit. >> One possibility is to consider is a description of the device and then >> the type of device. >> >> Powered Devices Description >> >> The energy management standard must provide means for identifying the >> entity with a powered device description, the domain to which the >> device belongs > Is this two in one (description and domain)? > > What would be the requirement for a "description"? > Offering a text string for descriptions where arbitrary content can be entered? > > I don't think the domain should be part of the device description- > >> Powered Entity Type >> >> The energy management standard must provide means to identify the >> powered device type such as consumer, provider, meter. > It's still vague. What are device types? > Is there a fixed list? Is it maintained by IANA? > Is it a string where operators may enter arbitrary types? > > Thanks, > > Juergen > >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of >> Juergen Quittek >> Sent: Thursday, June 30, 2011 2:56 PM >> To: eman mailing list >> Subject: Re: [eman] New draft on eman requirements >> >> Dear all, >> >> I am sorry for posting another version just one day after the previous >> one. >> Now out is version -03 to be found at >> >> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt >> >> The reason was that a change in terminology ("powered device" -> >> "powered >> entity") was not done consistently in all sections, particularly not in >> the >> battery section. >> >> There are no further changes, particularly no technical changes compared >> to >> the previous version. >> >> Thanks, >> >> Juergen >> >> _______________________________________________ >> 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 --------------050804070605090608000604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/07/2011 14:10, Juergen Quittek wrote: 
Hi Mouli,

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

Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan):


Hello,

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

I shall post some of the discussion points. 

Thanks
Mouli

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

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


5.1.1.  Type of powered entity

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

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

Yes. The question is what is needed?
We don't want we redo the ENTITY-MIB work, but  I believe that having a way to map to the ENTITY-MIB index is important.
The more generic requirements should be something such as:
The energy management standard must provide means to map the power entities 
to existing managed device inventory such as the ENTITY-MIB.

The energy management standard must provide means to map the power entities 
to existing energy related MIBs such as the POE and LLPD MIBs
Those two requirements should be in the section 4. Identification of Powered Entities

Coming back to this requirement

5.1.1. Type of powered entity

The energy management standard must provide means to retrieve and
report the type of powered entities.
I believe the "type" is misleading. The main requirement is that we want the ability to group powered entities based on something, which could be the type, what the type definition you want.
Therefore, I would remove the requirement 5.1.1 and only keep the current 5.1.2
5.1.2.  Grouping of powered entities

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

Regards, Benoit.

      

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

Powered Devices Description

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


      

      
Is this two in one (description and domain)?

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

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



      

        
Powered Entity Type

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


      

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

Thanks,

    Juergen



      

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

Dear all,

I am sorry for posting another version just one day after the previous
one.
Now out is version -03 to be found at

http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt

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

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

Thanks,

   Juergen

_______________________________________________
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


    

    

  


--------------050804070605090608000604--

From bclaise@cisco.com  Wed Jul  6 03:02:35 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6847C21F8612 for ; Wed,  6 Jul 2011 03:02:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.558
X-Spam-Level: 
X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.040,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1u0nw4SLVfC5 for ; Wed,  6 Jul 2011 03:02:34 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 48D2821F8601 for ; Wed,  6 Jul 2011 03:02:34 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p669j1ro015563; Wed, 6 Jul 2011 11:45:01 +0200 (CEST)
Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p669j0sZ012860; Wed, 6 Jul 2011 11:45:00 +0200 (CEST)
Message-ID: <4E142E9C.7080205@cisco.com>
Date: Wed, 06 Jul 2011 11:45:00 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Juergen Quittek 
References: 		 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020301000201030203010506"
Cc: eman mailing list 
Subject: Re: [eman] New draft on eman requirements - issue 2 - Device	Identity
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Jul 2011 10:02:35 -0000

This is a multi-part message in MIME format.
--------------020301000201030203010506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Juergen,

[reading my emails in sequence. So this comment might overlap with my 
previous email]
> Am 01.07.2011 um 13:18 schrieb Mouli Chandramouli (moulchan):
>
>> Hello,
>>
>>
>> There is a requirement -
>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>
>> on identity
>>
>>
>> 4.1.  Identifying powered entities
>>
>>    The energy management standard must provide means for uniquely
>>    identifying powered entities that are monitored or controlled by an
>>    energy management system.  Uniqueness must be given in a domain that
>>    is large enough to avoid collisions of identities at potential
>>    receivers of monitored information.
>>
>>
>> Firstly, it would be useful to link this unique ID to other indices that
>> may be deployed - in other words, link to other MIB modules.
> I have two comments on this.
>
> First, the text in the draft says "means for identifying".
> It does not say that "means" is a single identifier as you
> appear to imply in your comment. The requirement in the draft
> would support multiple identifiers linked with each other if necessary
> as "means for identifying powered entities".
It would be better to clarify this text then.
> Second, I definitely do not want to have a requirement for using more
> than one identifier? If solutions can go with a single identifier,
> then why forcing them by requirement to have more.
I'm not sure how you deduce a requirement for multiple identifiers from:

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

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


>
>
>> Powered Entities Other Identifier
>>
>>    The energy management standard must provide means to link the powered
>>    device unique id to existing other identifiers currently used in
>>    network management.
> Well, as said before, I would not like to see a requirement like this
> without having a requirement to use more than one identifier for the
> same entity.
>
See my previous comment.
>> Secondly, it would be useful to specify if the identity should
>> persistent.
> Would this be covered by
> OLD
>     "means for uniquely identifying powered entities"
> NEW
>     "means for uniquely and persistently identifying powered entities"
Regarding the persistence, there are cases where the persistence is 
required and some others where it doesn't make sense.
So the requirement should be something such as (in section 4 
Identification of Powered Entities)

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


Regards, Benoit.


> ?
>
> Thanks,
>
>      Juergen
>
>> Thanks
>> Mouli
>>
>>
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
>> Juergen Quittek
>> Sent: Thursday, June 30, 2011 2:56 PM
>> To: eman mailing list
>> Subject: Re: [eman] New draft on eman requirements
>>
>> Dear all,
>>
>> I am sorry for posting another version just one day after the previous
>> one.
>> Now out is version -03 to be found at
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>
>> The reason was that a change in terminology ("powered device" ->
>> "powered
>> entity") was not done consistently in all sections, particularly not in
>> the
>> battery section.
>>
>> There are no further changes, particularly no technical changes compared
>> to
>> the previous version.
>>
>> Thanks,
>>
>>     Juergen
>>
>> _______________________________________________
>> 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


--------------020301000201030203010506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    Juergen,

    

    [reading my emails in sequence. So this comment might overlap with
    my previous email]

    

      
Am 01.07.2011 um 13:18 schrieb Mouli Chandramouli (moulchan):



      

        
Hello,


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

on identity 


4.1.  Identifying powered entities

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


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


      

      
I have two comments on this. 

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


    

    It would be better to clarify this text then.

    

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


    

    I'm not sure how you deduce a requirement for multiple identifiers
    from:

    

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

    

    I don't believe that there is a requirement for multiple
    identifiers. A primary identifier in MIB module is what's required.

    However, a link to other indices make sense.

    

    

    

      
  



      

        
Powered Entities Other Identifier

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


      

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



    

    See my previous comment.

    

      

      

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


      

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


    

    Regarding the persistence, there are cases where the persistence is
    required and some others where it doesn't make sense.

    So the requirement should be something such as (in section 4
    Identification of Powered Entities)

    

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

    

    Regards, Benoit.

    

    

    

      
?

Thanks,

    Juergen



      

        
Thanks
Mouli


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

Dear all,

I am sorry for posting another version just one day after the previous
one.
Now out is version -03 to be found at

http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt

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

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

Thanks,

   Juergen

_______________________________________________
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


    

    

  


--------------020301000201030203010506--

From bclaise@cisco.com  Wed Jul  6 03:39:24 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796DD21F874E for ; Wed,  6 Jul 2011 03:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level: 
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I04HBzuIOtRg for ; Wed,  6 Jul 2011 03:39:23 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEB621F8749 for ; Wed,  6 Jul 2011 03:39:23 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p66AdLmI022667 for ; Wed, 6 Jul 2011 12:39:21 +0200 (CEST)
Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p66AdD0m026688 for ; Wed, 6 Jul 2011 12:39:13 +0200 (CEST)
Message-ID: <4E143B50.5060205@cisco.com>
Date: Wed, 06 Jul 2011 12:39:13 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: eman mailing list 
Content-Type: multipart/alternative; boundary="------------050903020706030905090408"
Subject: [eman] Feedback on the EMAN requirement draft
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Jul 2011 10:39:24 -0000

This is a multi-part message in MIME format.
--------------050903020706030905090408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Here is some more feedback on the EMAN requirement draft

* The current table of content shows

    4.  Identification of Powered Entities . . . . . . . . . . . . . . 10

    5.  Required Information on Powered Entities . . . . . . . . . . . 11
      5.1.  General information on entities  . . . . . . . . . . . . . 11
      5.2.  Power state  . . . . . . . . . . . . . . . . . . . . . . . 12
      5.3.  Power inlet and power outlet . . . . . . . . . . . . . . . 14
      5.4.  Power  . . . . . . . . . . . . . . . . . . . . . . . . . . 16
      5.5.  Energy . . . . . . . . . . . . . . . . . . . . . . . . . . 18
      5.6.  Battery State  . . . . . . . . . . . . . . . . . . . . . . 19

    6.  Control of Powered Entities  . . . . . . . . . . . . . . . . . 21

    7.  Reporting on Other Powered Entities  . . . . . . . . . . . . . 22

    8.  Controlling Other Powered Entities . . . . . . . . . . . . . . 23
      8.1.  Controlling power states of other entities . . . . . . . . 23
      8.2.  Controlling power supply of other entities . . . . . . . . 24


It seems that only section 5 is about requirements.
Should the term required or requirement be added to the section 4, 6, 7 and 8?

* Also, I'm not sure why the following sentences are in section 5. These should be generic.

    Note that the fact that an energy management standard provides
    required means does not imply that all of them must be implemented by
    every compliant implementation.  The concrete specification of
    standards based on these requirements may label individual features
    as mandatory, recommended, or optional.

*  I still some requirements about "entity"

    5.2.1. Actual power state

    The energy management standard must provide means for reporting the
    actual power state of an entity.

Please check all instances of "entity" -> "powered entity"

* You have remove this, i.e. the reference to IPFIX

    Monitoring of power states and energy consumption can be performed in
    pull mode (for example, SNMP GET [RFC3410  ]) or in push mode (for
    example SNMP notification [RFC3410  ], Syslog [RFC5424  ], or IPFIX
    [RFC5101  ]).

Question: should the EMAN framework cover the IPFIX or not?

* this sentence is difficult to read


      7.5. Content of reports on other entities


    The energy management standard must provide means for an entity to
    indicate for each other entity on which it can provide energy-related
    information which energy-related information can be provided for this
    entity.

Regards, Benoit.

--------------050903020706030905090408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  

    
  
  
    Dear all,

    

    Here is some more feedback on the EMAN requirement draft

    

    * The current table of content shows

    
   4.  Identification of Powered Entities . . . . . . . . . . . . . . 10

   5.  Required Information on Powered Entities . . . . . . . . . . . 11
     5.1.  General information on entities  . . . . . . . . . . . . . 11
     5.2.  Power state  . . . . . . . . . . . . . . . . . . . . . . . 12
     5.3.  Power inlet and power outlet . . . . . . . . . . . . . . . 14
     5.4.  Power  . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.5.  Energy . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.6.  Battery State  . . . . . . . . . . . . . . . . . . . . . . 19

   6.  Control of Powered Entities  . . . . . . . . . . . . . . . . . 21

   7.  Reporting on Other Powered Entities  . . . . . . . . . . . . . 22

   8.  Controlling Other Powered Entities . . . . . . . . . . . . . . 23
     8.1.  Controlling power states of other entities . . . . . . . . 23
     8.2.  Controlling power supply of other entities . . . . . . . . 24


It seems that only section 5 is about requirements.
Should the term required or requirement be added to the section 4, 6, 7 and 8?

* Also, I'm not sure why the following sentences are in section 5. These should be generic.

   Note that the fact that an energy management standard provides
   required means does not imply that all of them must be implemented by
   every compliant implementation.  The concrete specification of
   standards based on these requirements may label individual features
   as mandatory, recommended, or optional.


    *  I still some requirements about "entity"

    
5.2.1. Actual power state

      

      The energy management standard must provide means for reporting
      the

      actual power state of an entity.

    

    

    Please check all instances of "entity" -> "powered entity"

    

    * You have remove this, i.e. the reference to IPFIX

    
   Monitoring of power states and energy consumption can be performed in
   pull mode (for example, SNMP GET [RFC3410]) or in push mode (for
   example SNMP notification [RFC3410], Syslog [RFC5424], or IPFIX
   [RFC5101]).


    Question: should the EMAN framework cover the IPFIX or not?

    

    * this sentence is difficult to read

    

    
7.5.  Content of reports on other entities

   The energy management standard must provide means for an entity to
   indicate for each other entity on which it can provide energy-related
   information which energy-related information can be provided for this
   entity.

    Regards, Benoit.

  


--------------050903020706030905090408--

From ietf@quittek.at  Wed Jul  6 03:40:18 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71C721F875E for ; Wed,  6 Jul 2011 03:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxuo0d0XUyot for ; Wed,  6 Jul 2011 03:40:18 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id D7D5121F874E for ; Wed,  6 Jul 2011 03:40:17 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0M4HbP-1RWEdP162t-00rnPL; Wed, 06 Jul 2011 12:40:16 +0200
References:  <4E142BB4.1060103@cisco.com>
In-Reply-To: <4E142BB4.1060103@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: 
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Wed, 6 Jul 2011 12:40:15 +0200
To: Benoit Claise 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:A6aiAVdfSwCi4Gjaz4vxwD3QOvBzLg0kzzemsCivzs1 ZLyNQpeiQG94p9wtwe4bKjrjzSI1WGT4VMMgQrqJxslkmeJJ5F 8VC2p+fmDP2pBqumuqgO9XrAUMRgUNwggwhlnqwHQMB5GS6oMe Cf4KiBpBumUhtDJNzk9M1niH8BXJtGS/e1V3vo1Ez5J614GUrv KPeQccyn/Atnoa8BUB01A==
Cc: eman mailing list 
Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type -> domain
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Jul 2011 10:40:18 -0000

Hi Benoit,

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

Thanks,

    Juergen

Am 06.07.2011 um 11:32 schrieb Benoit Claise:

> Hi Juergen,
>=20
> Not exactly.
>=20
> There are actually two different concepts
> 1. the domain
> 2. grouping of powered entities. Practically, this is done with the =
keyword list in [EMAN-AWARE]
>=20
> The requirement 5.1.2 covers "grouping of powered entities"
> We're missing in section 4 a requirement such as:
>=20
>   The energy management standard must provide means for identifying =
the domain to which the
>   powered entity belongs.
>=20
> Regards, Benoit.
>> Hi Benoit,
>>=20
>> This requirement is already in the draft:
>>=20
>>> 5.1.2.  Grouping of powered entities
>>>=20
>>>    The energy management standard must provide means for grouping
>>>    powered entities, for example, into energy monitoring domains, =
energy
>>>    control domains, power supply domains, groups of entities of the =
same
>>>    type, etc.
>> Does it cover what you are looking for?
>>=20
>> Thanks,
>>=20
>>     Juergen
>>=20
>>=20
>> Am 01.07.11 16:09 schrieb "Benoit Claise" unter:
>>=20
>>>   Dear all,
>>>=20
>>>  Specifically dealing with the domain...
>>>=20
>>>=20
>>> 4.1.  Identifying powered entities
>>>    The energy management standard must provide means for uniquely
>>>    identifying powered entities that are monitored or controlled by =
an
>>>    energy management system.  Uniqueness must be given in a domain =
that
>>>    is large enough to avoid collisions of identities at potential
>>>    receivers of monitored information.
>>>  Since the domain is mentioned here, isn't it a case for a specific
>>> requirement regarding the domain?
>>>=20
>>>  Regards, Benoit.
>>>=20
>>>>=20
>>>> Hi Mouli,
>>>>=20
>>>> I'm glad you comment on this. It was too vague so far.
>>>> Please see plies inline.
>>>>=20
>>>> Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan):
>>>>=20
>>>>=20
>>>>>=20
>>>>> Hello,
>>>>>=20
>>>>> As Juergen has mentioned, while the first version has been =
released to
>>>>> solicit feedback, some of the concepts are still debated.
>>>>> The perspectives from the email list would be useful to shape the =
draft.
>>>>>=20
>>>>> I shall post some of the discussion points.
>>>>>=20
>>>>> Thanks
>>>>> Mouli
>>>>>=20
>>>>> ------------
>>>>>=20
>>>>> There is a requirement -
>>>>> =
http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>>>>=20
>>>>>=20
>>>>> 5.1.1.  Type of powered entity
>>>>>=20
>>>>>   The energy management standard must provide means to retrieve =
and
>>>>>   report the type of powered entities.
>>>>>=20
>>>>> I think it would be useful to expand this requirement. Device Type =
could
>>>>> be inferred as "IP Phone" or "Line Card 3", ...
>>>>>=20
>>>>=20
>>>>=20
>>>> Yes. The question is what is needed?
>>>>=20
>>>>=20
>>>>>=20
>>>>> One possibility is to consider is a description of the device and =
then
>>>>> the type of device.
>>>>>=20
>>>>> Powered Devices Description
>>>>>=20
>>>>>   The energy management standard must provide means for =
identifying the
>>>>>   entity with a powered device description, the domain to which =
the
>>>>>   device belongs
>>>>>=20
>>>>=20
>>>>=20
>>>> Is this two in one (description and domain)?
>>>>=20
>>>> What would be the requirement for a "description"?
>>>> Offering a text string for descriptions where arbitrary content can =
be
>>>> entered?
>>>>=20
>>>> I don't think the domain should be part of the device description-
>>>>=20
>>>>=20
>>>>>=20
>>>>> Powered Entity Type
>>>>>=20
>>>>>   The energy management standard must provide means to identify =
the
>>>>>   powered device type such as consumer, provider, meter.
>>>>>=20
>>>>=20
>>>>=20
>>>> It's still vague. What are device types?
>>>> Is there a fixed list? Is it maintained by IANA?
>>>> Is it a string where operators may enter arbitrary types?
>>>>=20
>>>> Thanks,
>>>>=20
>>>>     Juergen
>>>>=20
>>>>=20
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On =
Behalf Of
>>>>> Juergen Quittek
>>>>> Sent: Thursday, June 30, 2011 2:56 PM
>>>>> To: eman mailing list
>>>>> Subject: Re: [eman] New draft on eman requirements
>>>>>=20
>>>>> Dear all,
>>>>>=20
>>>>> I am sorry for posting another version just one day after the =
previous
>>>>> one.
>>>>> Now out is version -03 to be found at
>>>>>=20
>>>>> =
http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>>>>=20
>>>>> The reason was that a change in terminology ("powered device" ->
>>>>> "powered
>>>>> entity") was not done consistently in all sections, particularly =
not in
>>>>> the
>>>>> battery section.
>>>>>=20
>>>>> There are no further changes, particularly no technical changes =
compared
>>>>> to
>>>>> the previous version.
>>>>>=20
>>>>> Thanks,
>>>>>=20
>>>>>    Juergen
>>>>>=20
>>>>> _______________________________________________
>>>>> eman mailing list
>>>>> eman@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> eman mailing list
>>>> eman@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/eman
>>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>=20


From bclaise@cisco.com  Wed Jul  6 04:01:00 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE2821F869A for ; Wed,  6 Jul 2011 04:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.564
X-Spam-Level: 
X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.034,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaAFhYvihL+O for ; Wed,  6 Jul 2011 04:00:59 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0A27421F862D for ; Wed,  6 Jul 2011 04:00:58 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p66B0wWp025317; Wed, 6 Jul 2011 13:00:58 +0200 (CEST)
Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p66B0vI5012702; Wed, 6 Jul 2011 13:00:57 +0200 (CEST)
Message-ID: <4E144069.70000@cisco.com>
Date: Wed, 06 Jul 2011 13:00:57 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Juergen Quittek 
References:  <4E142BB4.1060103@cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050008020904030403020406"
Cc: eman mailing list 
Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type ->	domain
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Jul 2011 11:01:00 -0000

This is a multi-part message in MIME format.
--------------050008020904030403020406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Juergen,

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


      4.1. Identifying powered entities


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


Regards, Benoit.
> Hi Benoit,
>
> OK, for me a domain is a group of entities.
> A domain could be
>    - "4th floor": all energy consumers on the 4th floor of a building
>    - "desktop phones": all desktop phone in an enterprise
>    - "Fuse 321": all powered entities receiving power via main fuse 123 in the energy distribution tree
>    - "meter 7": all entities that are metered by power meter 7
> There are  certainly many more examples.
> Why would a domain not be a group of entities?
>
> Thanks,
>
>      Juergen
>
> Am 06.07.2011 um 11:32 schrieb Benoit Claise:
>
>> Hi Juergen,
>>
>> Not exactly.
>>
>> There are actually two different concepts
>> 1. the domain
>> 2. grouping of powered entities. Practically, this is done with the keyword list in [EMAN-AWARE]
>>
>> The requirement 5.1.2 covers "grouping of powered entities"
>> We're missing in section 4 a requirement such as:
>>
>>    The energy management standard must provide means for identifying the domain to which the
>>    powered entity belongs.
>>
>> Regards, Benoit.
>>> Hi Benoit,
>>>
>>> This requirement is already in the draft:
>>>
>>>> 5.1.2.  Grouping of powered entities
>>>>
>>>>     The energy management standard must provide means for grouping
>>>>     powered entities, for example, into energy monitoring domains, energy
>>>>     control domains, power supply domains, groups of entities of the same
>>>>     type, etc.
>>> Does it cover what you are looking for?
>>>
>>> Thanks,
>>>
>>>      Juergen
>>>
>>>
>>> Am 01.07.11 16:09 schrieb "Benoit Claise" unter:
>>>
>>>>    Dear all,
>>>>
>>>>   Specifically dealing with the domain...
>>>>
>>>>
>>>> 4.1.  Identifying powered entities
>>>>     The energy management standard must provide means for uniquely
>>>>     identifying powered entities that are monitored or controlled by an
>>>>     energy management system.  Uniqueness must be given in a domain that
>>>>     is large enough to avoid collisions of identities at potential
>>>>     receivers of monitored information.
>>>>   Since the domain is mentioned here, isn't it a case for a specific
>>>> requirement regarding the domain?
>>>>
>>>>   Regards, Benoit.
>>>>
>>>>> Hi Mouli,
>>>>>
>>>>> I'm glad you comment on this. It was too vague so far.
>>>>> Please see plies inline.
>>>>>
>>>>> Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan):
>>>>>
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> As Juergen has mentioned, while the first version has been released to
>>>>>> solicit feedback, some of the concepts are still debated.
>>>>>> The perspectives from the email list would be useful to shape the draft.
>>>>>>
>>>>>> I shall post some of the discussion points.
>>>>>>
>>>>>> Thanks
>>>>>> Mouli
>>>>>>
>>>>>> ------------
>>>>>>
>>>>>> There is a requirement -
>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>>>>>
>>>>>>
>>>>>> 5.1.1.  Type of powered entity
>>>>>>
>>>>>>    The energy management standard must provide means to retrieve and
>>>>>>    report the type of powered entities.
>>>>>>
>>>>>> I think it would be useful to expand this requirement. Device Type could
>>>>>> be inferred as "IP Phone" or "Line Card 3", ...
>>>>>>
>>>>>
>>>>> Yes. The question is what is needed?
>>>>>
>>>>>
>>>>>> One possibility is to consider is a description of the device and then
>>>>>> the type of device.
>>>>>>
>>>>>> Powered Devices Description
>>>>>>
>>>>>>    The energy management standard must provide means for identifying the
>>>>>>    entity with a powered device description, the domain to which the
>>>>>>    device belongs
>>>>>>
>>>>>
>>>>> Is this two in one (description and domain)?
>>>>>
>>>>> What would be the requirement for a "description"?
>>>>> Offering a text string for descriptions where arbitrary content can be
>>>>> entered?
>>>>>
>>>>> I don't think the domain should be part of the device description-
>>>>>
>>>>>
>>>>>> Powered Entity Type
>>>>>>
>>>>>>    The energy management standard must provide means to identify the
>>>>>>    powered device type such as consumer, provider, meter.
>>>>>>
>>>>>
>>>>> It's still vague. What are device types?
>>>>> Is there a fixed list? Is it maintained by IANA?
>>>>> Is it a string where operators may enter arbitrary types?
>>>>>
>>>>> Thanks,
>>>>>
>>>>>      Juergen
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
>>>>>> Juergen Quittek
>>>>>> Sent: Thursday, June 30, 2011 2:56 PM
>>>>>> To: eman mailing list
>>>>>> Subject: Re: [eman] New draft on eman requirements
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> I am sorry for posting another version just one day after the previous
>>>>>> one.
>>>>>> Now out is version -03 to be found at
>>>>>>
>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>>>>>
>>>>>> The reason was that a change in terminology ("powered device" ->
>>>>>> "powered
>>>>>> entity") was not done consistently in all sections, particularly not in
>>>>>> the
>>>>>> battery section.
>>>>>>
>>>>>> There are no further changes, particularly no technical changes compared
>>>>>> to
>>>>>> the previous version.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>     Juergen
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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


--------------050008020904030403020406
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    Hi Juergen,

    

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

    
4.1.  Identifying powered entities

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

    

    Regards, Benoit.

    

      
Hi Benoit,

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

Thanks,

    Juergen

Am 06.07.2011 um 11:32 schrieb Benoit Claise:



      

        
Hi Juergen,

Not exactly.

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

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

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

Regards, Benoit.


        

          
Hi Benoit,

This requirement is already in the draft:



          

            
5.1.2.  Grouping of powered entities

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


          

          
Does it cover what you are looking for?

Thanks,

    Juergen


Am 01.07.11 16:09 schrieb "Benoit Claise" unter<bclaise@cisco.com>:



          

            
  Dear all,

 Specifically dealing with the domain...


4.1.  Identifying powered entities
   The energy management standard must provide means for uniquely
   identifying powered entities that are monitored or controlled by an
   energy management system.  Uniqueness must be given in a domain that
   is large enough to avoid collisions of identities at potential
   receivers of monitored information.
 Since the domain is mentioned here, isn't it a case for a specific
requirement regarding the domain?

 Regards, Benoit.



            

              
Hi Mouli,

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

Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan):




              

                
Hello,

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

I shall post some of the discussion points.

Thanks
Mouli

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

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


5.1.1.  Type of powered entity

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

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



              

              

Yes. The question is what is needed?




              

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

Powered Devices Description

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



              

              

Is this two in one (description and domain)?

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

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




              

                
Powered Entity Type

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



              

              

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

Thanks,

    Juergen




              

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

Dear all,

I am sorry for posting another version just one day after the previous
one.
Now out is version -03 to be found at

http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt

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

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

Thanks,

   Juergen

_______________________________________________
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


          

        

        

      

      

    

    

  


--------------050008020904030403020406--

From ietf@quittek.at  Wed Jul  6 04:03:31 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438C521F86CE for ; Wed,  6 Jul 2011 04:03:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 KHxLFDGjD6fx for ; Wed,  6 Jul 2011 04:03:30 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id EF9AB21F86D2 for ; Wed,  6 Jul 2011 04:03:29 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MNLx3-1QcWCl40oT-0070Js; Wed, 06 Jul 2011 13:03:27 +0200
References: 		  <4E142E9C.7080205@cisco.com>
In-Reply-To: <4E142E9C.7080205@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-5-930524955
Message-Id: 
From: Juergen Quittek 
Date: Wed, 6 Jul 2011 13:03:26 +0200
To: Benoit Claise 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:sofiCQF75y9tq/txvA2KnnauWQyzpFtl/frp7nCfJ4Z r/+gn9lr4tX0Yc6qwjqu58JNNWC8j6+L4j3nVL1IKGkxKJ0gnl mfR/dm94GMiKjazUBkCwsReNwN4BO7sp1/80VEWjm5iazpDCIq KedrSgzGRCv3GIw4iKxmNU2DXytK6YhfPauKBs1mGYjmCwf68Q bFKUrT6sq1tWALrMaasOA==
Cc: eman mailing list 
Subject: Re: [eman] New draft on eman requirements - issue 2 - Device	Identity
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Jul 2011 11:03:31 -0000

--Apple-Mail-5-930524955
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


Am 06.07.2011 um 11:45 schrieb Benoit Claise:

> Juergen,
>=20
> [reading my emails in sequence. So this comment might overlap with my =
previous email]
>> Am 01.07.2011 um 13:18 schrieb Mouli Chandramouli (moulchan):
>>=20
>>> Hello,
>>>=20
>>>=20
>>> There is a requirement -
>>> =
http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>>=20
>>> on identity=20
>>>=20
>>>=20
>>> 4.1.  Identifying powered entities
>>>=20
>>>   The energy management standard must provide means for uniquely
>>>   identifying powered entities that are monitored or controlled by =
an
>>>   energy management system.  Uniqueness must be given in a domain =
that
>>>   is large enough to avoid collisions of identities at potential
>>>   receivers of monitored information.
>>>=20
>>>=20
>>> Firstly, it would be useful to link this unique ID to other indices =
that
>>> may be deployed - in other words, link to other MIB modules.=20
>> I have two comments on this.=20
>>=20
>> First, the text in the draft says "means for identifying".=20
>> It does not say that "means" is a single identifier as you=20
>> appear to imply in your comment. The requirement in the draft
>> would support multiple identifiers linked with each other if =
necessary
>> as "means for identifying powered entities".
> It would be better to clarify this text then.
>> Second, I definitely do not want to have a requirement for using more=20=

>> than one identifier? If solutions can go with a single identifier,=20
>> then why forcing them by requirement to have more.
> I'm not sure how you deduce a requirement for multiple identifiers =
from:
> "Firstly, it would be useful to link this unique ID to other indices =
that
> may be deployed - in other words, link to other MIB modules."=20
> I don't believe that there is a requirement for multiple identifiers. =
A primary identifier in MIB module is what's required.
> However, a link to other indices make sense.

OK. I see your point.=20
But if we require links to other indices, we must give a concrete list =
of them
Otherwise I would not know how to check if the requirement is met.
If we can agree on finite list of indices to which an energy management =
standard MUST link entity identiites,=20
then I'd be glad to include it in the requirements.=20
>>  =20
>>=20
>>> Powered Entities Other Identifier
>>>=20
>>>   The energy management standard must provide means to link the =
powered
>>>   device unique id to existing other identifiers currently used in
>>>   network management.
>> Well, as said before, I would not like to see a requirement like this=20=

>> without having a requirement to use more than one identifier for the
>> same entity.
>>=20
> See my previous comment.

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

>>> Secondly, it would be useful to specify if the identity should
>>> persistent.=20
>> Would this be covered by=20
>> OLD
>>    "means for uniquely identifying powered entities"
>> NEW
>>    "means for uniquely and persistently identifying powered entities"
> Regarding the persistence, there are cases where the persistence is =
required and some others where it doesn't make sense.
> So the requirement should be something such as (in section 4 =
Identification of Powered Entities)
>=20
>    The energy management standard must provide means for indicating
>    whether the powered entities identification is persistent across a =
reboot
Fine. What about the following?

4.3.  Persistency of Identifiers

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

Thanks,

    Juergen

> Regards, Benoit.
>=20
>=20
>> ?
>>=20
>> Thanks,
>>=20
>>     Juergen
>>=20
>>> Thanks
>>> Mouli
>>>=20
>>>=20
>>> -----Original Message-----
>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of
>>> Juergen Quittek
>>> Sent: Thursday, June 30, 2011 2:56 PM
>>> To: eman mailing list
>>> Subject: Re: [eman] New draft on eman requirements
>>>=20
>>> Dear all,
>>>=20
>>> I am sorry for posting another version just one day after the =
previous
>>> one.
>>> Now out is version -03 to be found at
>>>=20
>>> =
http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>>=20
>>> The reason was that a change in terminology ("powered device" ->
>>> "powered
>>> entity") was not done consistently in all sections, particularly not =
in
>>> the
>>> battery section.
>>>=20
>>> There are no further changes, particularly no technical changes =
compared
>>> to
>>> the previous version.
>>>=20
>>> Thanks,
>>>=20
>>>    Juergen
>>>=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


--Apple-Mail-5-930524955
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


Am 06.07.2011 um 11:45 schrieb Benoit Claise:




    Juergen,

    

    [reading my emails in sequence. So this comment might overlap with
    my previous email]

    

      
Am 01.07.2011 um 13:18 schrieb Mouli Chandramouli (moulchan):



      

        
Hello,


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

on identity 


4.1.  Identifying powered entities

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


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


      

      
I have two comments on this. 

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


    

    It would be better to clarify this text then.

    

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


    

    I'm not sure how you deduce a requirement for multiple identifiers
    from:

    

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

    

    I don't believe that there is a requirement for multiple
    identifiers. A primary identifier in MIB module is what's required.

    However, a link to other indices make sense.

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



      

        
Powered Entities Other Identifier

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


      

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



    

    See my previous comment.

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

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


      

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


    

    Regarding the persistence, there are cases where the persistence is
    required and some others where it doesn't make sense.

    So the requirement should be something such as (in section 4
    Identification of Powered Entities)

    

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

4.3.  Persistency of Identifiers

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

Thanks,

    Juergen


    Regards, Benoit.

    

    

    

      
?

Thanks,

    Juergen



      

        
Thanks
Mouli


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

Dear all,

I am sorry for posting another version just one day after the previous
one.
Now out is version -03 to be found at

http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt

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

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

Thanks,

   Juergen

_______________________________________________
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


    

    

  





--Apple-Mail-5-930524955--

From moulchan@cisco.com  Wed Jul  6 04:12:10 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BC221F866C for ; Wed,  6 Jul 2011 04:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.455
X-Spam-Level: 
X-Spam-Status: No, score=-5.455 tagged_above=-999 required=5 tests=[AWL=-2.857, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gtc2LRHcsa2i for ; Wed,  6 Jul 2011 04:12:09 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAE421F8506 for ; Wed,  6 Jul 2011 04:12:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=21504; q=dns/txt; s=iport; t=1309950729; x=1311160329; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=mrN37+6o7RybkCv5Ojz+OKlOX65sfNgCno7bc96H5Zs=; b=VS8pzs+V4cMNCxfjiee7R6grvtcQGH30dd8wDpSazh8HfppQwoGOr9nS KLLQqwn2KewxWD4MAEDaZUUdf5k36LaJS61drV9Pb7InBQLZRphI7WiD/ TxD6pPepzuBa3qMkfLNtZ08NfLoCW42l9X/6pdLIG6zjgQ49PcH72ddNZ k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvoAAOpBFE6tJV2c/2dsb2JhbABGDYJRlgWPLXeuHp4vgyKDFASHRo9+i1c
X-IronPort-AV: E=Sophos;i="4.65,486,1304294400"; d="scan'208,217";a="380560"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 06 Jul 2011 11:12:09 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p66BC8np018845;  Wed, 6 Jul 2011 11:12:08 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 6 Jul 2011 06:12:08 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3BCD.8BAA1F5C"
Date: Wed, 6 Jul 2011 06:12:04 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] New draft on eman requirements - issue 2 - Device	Identity
Thread-Index: Acw7zFarRJ+GXb82Q7ieQzEte6fgvAAAE3eQ
References: 		  <4E142E9C.7080205@cisco.com> 
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Quittek" , "Benoit Claise (bclaise)" 
X-OriginalArrivalTime: 06 Jul 2011 11:12:08.0730 (UTC) FILETIME=[8BD617A0:01CC3BCD]
Cc: eman mailing list 
Subject: Re: [eman] New draft on eman requirements - issue 2 - Device	Identity
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Jul 2011 11:12:11 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC3BCD.8BAA1F5C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

=20

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

=20

=20

Am 06.07.2011 um 11:45 schrieb Benoit Claise:





Juergen,

[reading my emails in sequence. So this comment might overlap with my
previous email]



Am 01.07.2011 um 13:18 schrieb Mouli Chandramouli (moulchan):
=20

	Hello,
	=20
	=20
	There is a requirement -
=09
http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
	=20
	on identity=20
	=20
	=20
	4.1.  Identifying powered entities
	=20
	  The energy management standard must provide means for uniquely
	  identifying powered entities that are monitored or controlled
by an
	  energy management system.  Uniqueness must be given in a
domain that
	  is large enough to avoid collisions of identities at potential
	  receivers of monitored information.
	=20
	=20
	Firstly, it would be useful to link this unique ID to other
indices that
	may be deployed - in other words, link to other MIB modules.=20

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

It would be better to clarify this text then.



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

I'm not sure how you deduce a requirement for multiple identifiers from:

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

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

=20

OK. I see your point.=20

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

Otherwise I would not know how to check if the requirement is met.

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

then I'd be glad to include it in the requirements.=20

=20

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

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

=20

Thanks

Mouli

		=20

			Powered Entities Other Identifier
			=20
			  The energy management standard must provide
means to link the powered
			  device unique id to existing other identifiers
currently used in
			  network management.

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

	See my previous comment.

=20

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

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

=20

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

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

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

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

Fine. What about the following?

=20

4.3.  Persistency of Identifiers

=20

   The energy management standard must provide means for indicating

   whether identifiers of powered entities are persistent across a re-

   start of the entity that provides the identifiers.

=20

Thanks,

=20

    Juergen

=20

	Regards, Benoit.
=09
=09
=09
=09

	?
	=20
	Thanks,
	=20
	    Juergen
	=20

		Thanks
		Mouli
		=20
		=20
		-----Original Message-----
		From: eman-bounces@ietf.org
[mailto:eman-bounces@ietf.org] On Behalf Of
		Juergen Quittek
		Sent: Thursday, June 30, 2011 2:56 PM
		To: eman mailing list
		Subject: Re: [eman] New draft on eman requirements
		=20
		Dear all,
		=20
		I am sorry for posting another version just one day
after the previous
		one.
		Now out is version -03 to be found at
		=20
=09
http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
		=20
		The reason was that a change in terminology ("powered
device" ->
		"powered
		entity") was not done consistently in all sections,
particularly not in
		the
		battery section.
		=20
		There are no further changes, particularly no technical
changes compared
		to
		the previous version.
		=20
		Thanks,
		=20
		   Juergen
		=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


------_=_NextPart_001_01CC3BCD.8BAA1F5C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















 



 









From:=
 Juergen =
Quittek
[mailto:ietf@quittek.at] 

Sent: Wednesday, July 06, 2011 4:33 PM

To: Benoit Claise (bclaise)

Cc: Mouli Chandramouli (moulchan); eman mailing list

Subject: Re: [eman] New draft on eman requirements - issue 2 - =
Device
Identity









 



 









Am 06.07.2011 um 11:45 schrieb Benoit =
Claise:

















Juergen,



[reading my emails in sequence. So this comment might overlap with my =
previous
email]







Am 01.07.2011 um 13:18 schrieb Mouli Chandramouli =
(moulchan):
 



Hello,
 
 
There is =
a requirement -
http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-=
03.txt
 
on identity =

 
 
=

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

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



I have two comments on this. =

 
First, the text in the =
draft says "means for identifying". 
It =
does not say that "means" is a single identifier as you =

appear to imply in your comment. The requirement =
in the draft
would support multiple identifiers =
linked with each other if necessary
as "means =
for identifying powered entities".



It would be better to clarify this text then.







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



I'm not sure how you deduce a requirement for =
multiple
identifiers from:



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



I don't believe that there is a requirement for =
multiple
identifiers. A primary identifier in MIB module is what's required.

However, a link to other indices make sense.









 






OK. I see your point. 









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









Otherwise I would not know how to check if the =
requirement
is met.









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









then I'd be glad to include it in the =
requirements. 



 



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



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



 



Thanks



Mouli















 


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



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



See my previous comment.












 






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









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









 


















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



Would this be covered by =

OLD
   "means =
for uniquely identifying powered =
entities"
NEW
  =
 "means for uniquely and persistently identifying powered =
entities"



Regarding the =
persistence,
there are cases where the persistence is required and some others where =
it
doesn't make sense.

So the requirement should be something such as (in section 4 =
Identification of
Powered Entities)



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









Fine. What about the following?









 












4.3.  Persistency of =
Identifiers









 









   The energy management standard must =
provide
means for indicating









   whether identifiers of powered =
entities are
persistent across a re-









   start of the entity that provides the
identifiers.









 












Thanks,









 









    Juergen









 












Regards, Benoit.











?
 
Thanks,
 
    =
Juergen
 



Thanks
Mouli
 
 =

-----Original Message-----
From: =
eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] =
On Behalf Of
Juergen =
Quittek
Sent: Thursday, June 30, 2011 2:56 =
PM
To: eman mailing =
list
Subject: Re: [eman] New draft on eman =
requirements
 
Dear =
all,
 
I am sorry for =
posting another version just one day after the =
previous
one.
Now out is =
version -03 to be found =
at
 
http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-=
03.txt
 
The reason =
was that a change in terminology ("powered device" =
->
"powered
entity"=
;) was not done consistently in all sections, particularly not =
in
the
battery =
section.
 
There are no =
further changes, particularly no technical changes =
compared
to
the previous =
version.
 
Thanks,
 
   =
Juergen
 
________________=
_______________________________
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



 












 









------_=_NextPart_001_01CC3BCD.8BAA1F5C--

From ietf@quittek.at  Wed Jul  6 04:49:48 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0640921F86A0 for ; Wed,  6 Jul 2011 04:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 SUcpKlJWdF+j for ; Wed,  6 Jul 2011 04:49:47 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id DEB6C21F8680 for ; Wed,  6 Jul 2011 04:49:46 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0LpeUg-1R8pg72BlO-00fVkk; Wed, 06 Jul 2011 13:49:45 +0200
References: <4E143B50.5060205@cisco.com>
In-Reply-To: <4E143B50.5060205@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-6-933303487
Message-Id: <6AED1DF3-BDD0-4376-BD55-07B1C636C5DC@quittek.at>
From: Juergen Quittek 
Date: Wed, 6 Jul 2011 13:49:45 +0200
To: Benoit Claise 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:Z60sm6GClimnK9LA1K8StuumIrWUfKwPSOaG7FoVOB/ iDnZjiSpfXPN5CsKcn1G2i7Sxjb9deNZFSkVlUrPcAq47Xkmpj 7yAdOE7ZXIqXhj8WQQ7Ppk51aCSm6EWnnUo/kBiex4ZTHlAEyS oVRVxz5JiCMwgPRIbBPGXKm+eYXMrrGZIHcTODup8XZZ8gwOxF MIZUwn4258TNV7EiSnKNA==
Cc: eman mailing list 
Subject: Re: [eman] Feedback on the EMAN requirement draft
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Jul 2011 11:49:48 -0000

--Apple-Mail-6-933303487
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Benoit,

Am 06.07.2011 um 12:39 schrieb Benoit Claise:

> Dear all,
>=20
> Here is some more feedback on the EMAN requirement draft
>=20
> * The current table of content shows
>    4.  Identification of Powered Entities . . . . . . . . . . . . . . =
10
>=20
>    5.  Required Information on Powered Entities . . . . . . . . . . . =
11
>      5.1.  General information on entities  . . . . . . . . . . . . . =
11
>      5.2.  Power state  . . . . . . . . . . . . . . . . . . . . . . . =
12
>      5.3.  Power inlet and power outlet . . . . . . . . . . . . . . . =
14
>      5.4.  Power  . . . . . . . . . . . . . . . . . . . . . . . . . . =
16
>      5.5.  Energy . . . . . . . . . . . . . . . . . . . . . . . . . . =
18
>      5.6.  Battery State  . . . . . . . . . . . . . . . . . . . . . . =
19
>=20
>    6.  Control of Powered Entities  . . . . . . . . . . . . . . . . . =
21
>=20
>    7.  Reporting on Other Powered Entities  . . . . . . . . . . . . . =
22
>=20
>    8.  Controlling Other Powered Entities . . . . . . . . . . . . . . =
23
>      8.1.  Controlling power states of other entities . . . . . . . . =
23
>      8.2.  Controlling power supply of other entities . . . . . . . . =
24
>=20
>=20
> It seems that only section 5 is about requirements.
> Should the term required or requirement be added to the section 4, 6, =
7 and 8?
Right, that's an inconsistency. But since not surprisingly most sections =
in the requirements draft=20
are about requirements, I would rather suggest just removing "Required" =
from the title of section 5.=20
I would prefer this to having "Required" or "Requirements" in most of =
the section headings of=20
a document titled "Requirements".=20
> * Also, I'm not sure why the following sentences are in section 5. =
These should be generic.
>=20
>    Note that the fact that an energy management standard provides
>    required means does not imply that all of them must be implemented =
by
>    every compliant implementation.  The concrete specification of
>    standards based on these requirements may label individual features
>    as mandatory, recommended, or optional.
Yes, they are repeated here from the introduction. We can remove them.

> *  I still some requirements about "entity"
> 5.2.1. Actual power state
>=20
> The energy management standard must provide means for reporting the
> actual power state of an entity.
> Please check all instances of "entity" -> "powered entity"

I checked. There are many cases like "the power state of an entity".
Would you insist in always stating "the power state of a POWERED =
entity"?
I think the meaning would be unambiguous even without the change as it =
is in
"tags associated with a powered entity that indicate the entity's role" =
where=20
the second occurrence of 'entity' just omits the attribute "powered", =
because
the semantics is not a matter of any doubt.

Also there is for example a section where we say: "An entity in this =
document=20
may be an entire managed device or just a component of it." In such a =
case
I would prefer not to add "powered".

But I fully agree that we should avoid all potential ambiguities.=20
Particularly for the numbered detailed requirements I will make sure=20
that all are unambiguous and that the draft gets much more "power" =
inside :-)

> * You have remove this, i.e. the reference to IPFIX
>    Monitoring of power states and energy consumption can be performed =
in
>    pull mode (for example, SNMP GET [RFC3410]) or in push mode (for
>    example SNMP notification [RFC3410], Syslog [RFC5424], or IPFIX
>    [RFC5101]).
> Question: should the EMAN framework cover the IPFIX or not?

Is there a REQUIREMENT to use IPFIX?
If yes, it should be in.

> * this sentence is difficult to read
>=20
> 7.5.  Content of reports on other entities
>=20
>=20
>    The energy management standard must provide means for an entity to
>    indicate for each other entity on which it can provide =
energy-related
>    information which energy-related information can be provided for =
this
>    entity.
For other requirements I had similar problems. and solved it by not =
starting with "The energy ..."

What about

   For entities that provide energy-related information on other =
entities,
   the energy management standard must provide means to indicate which=20=

   energy-related information can be provided for which other entity.
?
Thanks,

    Juergen

> Regards, Benoit.
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


--Apple-Mail-6-933303487
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
Benoit,

Am 06.07.2011 um 12:39 schrieb Benoit =
Claise:




    Dear all,

    

    Here is some more feedback on the EMAN requirement draft

    

    * The current table of content shows

    
   4.  Identification of Powered Entities . . . . . . . . . . . =
. . . 10

   5.  Required Information on Powered Entities . . . . . . . . . . . 11
     5.1.  General information on entities  . . . . . . . . . . . . . 11
     5.2.  Power state  . . . . . . . . . . . . . . . . . . . . . . . 12
     5.3.  Power inlet and power outlet . . . . . . . . . . . . . . . 14
     5.4.  Power  . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.5.  Energy . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.6.  Battery State  . . . . . . . . . . . . . . . . . . . . . . 19

   6.  Control of Powered Entities  . . . . . . . . . . . . . . . . . 21

   7.  Reporting on Other Powered Entities  . . . . . . . . . . . . . 22

   8.  Controlling Other Powered Entities . . . . . . . . . . . . . . 23
     8.1.  Controlling power states of other entities . . . . . . . . 23
     8.2.  Controlling power supply of other entities . . . . . . . . 24


It seems that only section 5 is about requirements.
Should the term required or requirement be added to the section 4, 6, 7 =
and 8?

Right, that's an inconsistency. But since not =
surprisingly most sections in the requirements draft 
are =
about requirements, I would rather suggest just removing "Required" =
from the title of section 5. 
I would prefer this to =
having "Required" or "Requirements" in most of the section =
headings of 
a document titled =
"Requirements". 
* Also, I'm not sure why the =
following sentences are in section 5. These should be generic.

   Note that the fact that an energy management standard provides
   required means does not imply that all of them must be implemented by
   every compliant implementation.  The concrete specification of
   standards based on these requirements may label individual features
   as mandatory, recommended, or optional.

Yes, they are repeated here from the =
introduction. We can remove them.


    *  I still some requirements about "entity"

    
5.2.1. Actual power state

      

      The energy management standard must provide means for reporting
      the

      actual power state of an entity.

    

    

    Please check all instances of "entity" -> "powered =
entity"

I checked. There are many =
cases like "the power state of an entity".
Would you insist in =
always stating "the power state of a POWERED entity"?
I think =
the meaning would be unambiguous even without the change as it is =
in
"tags associated with a powered entity that indicate =
the entity's role" where 
the second occurrence of =
'entity' just omits the attribute "powered", because
the =
semantics is not a matter of any doubt.

Also =
there is for example a section where we say: "An entity in this =
document 
may be an entire managed device or just =
a component of it." In such a case
I would prefer not to =
add "powered".

But I fully agree that we should =
avoid all potential ambiguities. 
Particularly for the =
numbered detailed requirements I will make sure 
that all =
are unambiguous and that the draft gets much more "power" inside =
:-)


    * You have remove this, i.e. the reference to IPFIX

    
   Monitoring of power states and energy =
consumption can be performed in
   pull mode (for example, SNMP GET [RFC3410]) or in push mode (for
   example SNMP notification [RFC3410], Syslog [RFC5424], or IPFIX
   [RFC5101]).


    Question: should the EMAN framework cover the IPFIX or =
not?

Is there a REQUIREMENT to use =
IPFIX?
If yes, it should be in.


    * this sentence is difficult to read

    

    
7.5.  Content of reports on other =
entities

   The energy management standard must provide means for an entity to
   indicate for each other entity on which it can provide energy-related
   information which energy-related information can be provided for this
   entity.
For other requirements I had similar =
problems. and solved it by not starting with "The energy =
..."

What about

   For entities =
that provide energy-related information on other =
entities,
   the energy management standard must provide means to =
indicate    energy-related =
information can be provided for which other entity.
?

    Juergen


    Regards, Benoit.

  


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

=

--Apple-Mail-6-933303487--

From ietf@quittek.at  Wed Jul  6 04:53:37 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667D821F85B6 for ; Wed,  6 Jul 2011 04:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 ac-QjJYhkw30 for ; Wed,  6 Jul 2011 04:53:36 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 997CD21F8534 for ; Wed,  6 Jul 2011 04:53:36 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MMnOB-1Qbxgn0Lqp-008aqO; Wed, 06 Jul 2011 13:53:34 +0200
References: 		  <4E142E9C.7080205@cisco.com>  
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-7-933532038
Message-Id: <6972914F-F681-4EE9-B12E-608E172C9F9B@quittek.at>
From: Juergen Quittek 
Date: Wed, 6 Jul 2011 13:53:33 +0200
To: "Mouli Chandramouli (moulchan)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:Nb6amFzqWpnf5thOItIjezStUWse6pm0g3fbP9lm8Gu 60Y0GaFEBzsOueL7CMl8wMzOtU4x0oc6v2YvaBlcSBSWAw1Rmp Fv6PfKmLkbJfHRyeCsvKnmKrFvRq0Pv0KbCugAJ501RQv/3nHY n82WyvQvs6h2D5DTQs3bA7OCbrTwr9VRNTD1NHlsyMfCNvuLTi a8LRN6Wj4HErrT2YIbVng==
Cc: eman mailing list 
Subject: Re: [eman] New draft on eman requirements - issue 2 - Device	Identity
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Jul 2011 11:53:37 -0000

--Apple-Mail-7-933532038
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Mouli,

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

[snip]

> Second, I definitely do not want to have a requirement for using more=20=

> than one identifier? If solutions can go with a single identifier,=20
> then why forcing them by requirement to have more.
> I'm not sure how you deduce a requirement for multiple identifiers =
from:
> "Firstly, it would be useful to link this unique ID to other indices =
that
> may be deployed - in other words, link to other MIB modules."=20
> I don't believe that there is a requirement for multiple identifiers. =
A primary identifier in MIB module is what's required.
> However, a link to other indices make sense.
> =20
> OK. I see your point.=20
> But if we require links to other indices, we must give a concrete list =
of them
> Otherwise I would not know how to check if the requirement is met.
> If we can agree on finite list of indices to which an energy =
management standard MUST link entity identiites,=20
> then I'd be glad to include it in the requirements.=20
> =20
> Mouli>>>  IMHO, the link to the indices to the other MIB modules was =
to reuse the capabilities (indices) of MIB modules for the scope of the =
devices in EMAN.
> Mouli>>> If the requirement were to restrict to indices of a  finite =
number of MIB modules,  I am not sure that is the intended goal.

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

Thanks,

    Juergen

> =20
> Thanks
> Mouli


--Apple-Mail-7-933532038
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi Mouli,

Am 06.07.2011 um 13:12 =
schrieb Mouli Chandramouli (moulchan):
Second, I definitely do =
not want to have a requirement for using more 
than =
one identifier? If solutions can go with a single identifier, =

then why forcing them by requirement to have =
more.
I'm not sure how you deduce a requirement =
for multiple identifiers from:
"Firstly, it would be =
useful to link this unique ID to other indices that
may be =
deployed - in other words, link to other MIB modules." =

I don't believe that there is a requirement =
for multiple identifiers. A primary identifier in MIB module is what's =
required.
However, a link to other indices make =
sense.
OK. I see your =
point. 
But if we require links =
to other indices, we must give a concrete list of =
them
Otherwise I would not =
know how to check if the requirement is =
met.
If we can agree on finite =
list of indices to which an energy management standard MUST link entity =
identiites, 
then I'd be =
glad to include it in the requirements. 
 
Mouli>>>  IMHO, the =
link to the indices to the other MIB modules was to reuse the =
capabilities (indices) of MIB modules for the scope of the devices in =
EMAN.
>   - "desktop phones": all desktop phone in an enterprise
>>   - "Fuse 321": all powered entities receiving power via main fuse =
123 in the energy distribution tree
>>   - "meter 7": all entities that are metered by power meter 7
>> There are  certainly many more examples.
>> Why would a domain not be a group of entities?
>>=20
>> Thanks,
>>=20
>>     Juergen
>>=20
>> Am 06.07.2011 um 11:32 schrieb Benoit Claise:
>>=20
>>> Hi Juergen,
>>>=20
>>> Not exactly.
>>>=20
>>> There are actually two different concepts
>>> 1. the domain
>>> 2. grouping of powered entities. Practically, this is done with the =
keyword list in [EMAN-AWARE]
>>>=20
>>> The requirement 5.1.2 covers "grouping of powered entities"
>>> We're missing in section 4 a requirement such as:
>>>=20
>>>   The energy management standard must provide means for identifying =
the domain to which the
>>>   powered entity belongs.
>>>=20
>>> Regards, Benoit.
>>>> Hi Benoit,
>>>>=20
>>>> This requirement is already in the draft:
>>>>=20
>>>>> 5.1.2.  Grouping of powered entities
>>>>>=20
>>>>>    The energy management standard must provide means for grouping
>>>>>    powered entities, for example, into energy monitoring domains, =
energy
>>>>>    control domains, power supply domains, groups of entities of =
the same
>>>>>    type, etc.
>>>> Does it cover what you are looking for?
>>>>=20
>>>> Thanks,
>>>>=20
>>>>     Juergen
>>>>=20
>>>>=20
>>>> Am 01.07.11 16:09 schrieb "Benoit Claise" unter:
>>>>=20
>>>>>   Dear all,
>>>>>=20
>>>>>  Specifically dealing with the domain...
>>>>>=20
>>>>>=20
>>>>> 4.1.  Identifying powered entities
>>>>>    The energy management standard must provide means for uniquely
>>>>>    identifying powered entities that are monitored or controlled =
by an
>>>>>    energy management system.  Uniqueness must be given in a domain =
that
>>>>>    is large enough to avoid collisions of identities at potential
>>>>>    receivers of monitored information.
>>>>>  Since the domain is mentioned here, isn't it a case for a =
specific
>>>>> requirement regarding the domain?
>>>>>=20
>>>>>  Regards, Benoit.
>>>>>=20
>>>>>> Hi Mouli,
>>>>>>=20
>>>>>> I'm glad you comment on this. It was too vague so far.
>>>>>> Please see plies inline.
>>>>>>=20
>>>>>> Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan):
>>>>>>=20
>>>>>>=20
>>>>>>> Hello,
>>>>>>>=20
>>>>>>> As Juergen has mentioned, while the first version has been =
released to
>>>>>>> solicit feedback, some of the concepts are still debated.
>>>>>>> The perspectives from the email list would be useful to shape =
the draft.
>>>>>>>=20
>>>>>>> I shall post some of the discussion points.
>>>>>>>=20
>>>>>>> Thanks
>>>>>>> Mouli
>>>>>>>=20
>>>>>>> ------------
>>>>>>>=20
>>>>>>> There is a requirement -
>>>>>>> =
http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>>>>>>=20
>>>>>>>=20
>>>>>>> 5.1.1.  Type of powered entity
>>>>>>>=20
>>>>>>>   The energy management standard must provide means to retrieve =
and
>>>>>>>   report the type of powered entities.
>>>>>>>=20
>>>>>>> I think it would be useful to expand this requirement. Device =
Type could
>>>>>>> be inferred as "IP Phone" or "Line Card 3", ...
>>>>>>>=20
>>>>>>=20
>>>>>> Yes. The question is what is needed?
>>>>>>=20
>>>>>>=20
>>>>>>> One possibility is to consider is a description of the device =
and then
>>>>>>> the type of device.
>>>>>>>=20
>>>>>>> Powered Devices Description
>>>>>>>=20
>>>>>>>   The energy management standard must provide means for =
identifying the
>>>>>>>   entity with a powered device description, the domain to which =
the
>>>>>>>   device belongs
>>>>>>>=20
>>>>>>=20
>>>>>> Is this two in one (description and domain)?
>>>>>>=20
>>>>>> What would be the requirement for a "description"?
>>>>>> Offering a text string for descriptions where arbitrary content =
can be
>>>>>> entered?
>>>>>>=20
>>>>>> I don't think the domain should be part of the device =
description-
>>>>>>=20
>>>>>>=20
>>>>>>> Powered Entity Type
>>>>>>>=20
>>>>>>>   The energy management standard must provide means to identify =
the
>>>>>>>   powered device type such as consumer, provider, meter.
>>>>>>>=20
>>>>>>=20
>>>>>> It's still vague. What are device types?
>>>>>> Is there a fixed list? Is it maintained by IANA?
>>>>>> Is it a string where operators may enter arbitrary types?
>>>>>>=20
>>>>>> Thanks,
>>>>>>=20
>>>>>>     Juergen
>>>>>>=20
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On =
Behalf Of
>>>>>>> Juergen Quittek
>>>>>>> Sent: Thursday, June 30, 2011 2:56 PM
>>>>>>> To: eman mailing list
>>>>>>> Subject: Re: [eman] New draft on eman requirements
>>>>>>>=20
>>>>>>> Dear all,
>>>>>>>=20
>>>>>>> I am sorry for posting another version just one day after the =
previous
>>>>>>> one.
>>>>>>> Now out is version -03 to be found at
>>>>>>>=20
>>>>>>> =
http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>>>>>>=20
>>>>>>> The reason was that a change in terminology ("powered device" ->
>>>>>>> "powered
>>>>>>> entity") was not done consistently in all sections, particularly =
not in
>>>>>>> the
>>>>>>> battery section.
>>>>>>>=20
>>>>>>> There are no further changes, particularly no technical changes =
compared
>>>>>>> to
>>>>>>> the previous version.
>>>>>>>=20
>>>>>>> Thanks,
>>>>>>>=20
>>>>>>>    Juergen
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> eman mailing list
>>>>>>> eman@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> eman mailing list
>>>>>> eman@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> eman mailing list
>>>>> eman@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>=20
>>=20
>=20


--Apple-Mail-8-933704281
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

Hi Benoit,

Am 06.07.2011 um 13:00 schrieb Benoit Claise:




    Hi Juergen,

    

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

    
4.1.  Identifying powered entities

   The energy management standard must provide means for uniquely
   identifying powered entities that are monitored or controlled by an
   energy management system.  Uniqueness must be given in a domain that
   is large enough to avoid collisions of identities at potential
   receivers of monitored information.
Wouldn't in this context the domain be the group of all devices that are managed by the involved 
energy management systems?

Thanks,

    Juergen


    Regards, Benoit.

    

      
Hi Benoit,

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

Thanks,

    Juergen

Am 06.07.2011 um 11:32 schrieb Benoit Claise:



      

        
Hi Juergen,

Not exactly.

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

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

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

Regards, Benoit.


        

          
Hi Benoit,

This requirement is already in the draft:



          

            
5.1.2.  Grouping of powered entities

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


          

          
Does it cover what you are looking for?

Thanks,

    Juergen


Am 01.07.11 16:09 schrieb "Benoit Claise" unter<bclaise@cisco.com>:



          

            
  Dear all,

 Specifically dealing with the domain...


4.1.  Identifying powered entities
   The energy management standard must provide means for uniquely
   identifying powered entities that are monitored or controlled by an
   energy management system.  Uniqueness must be given in a domain that
   is large enough to avoid collisions of identities at potential
   receivers of monitored information.
 Since the domain is mentioned here, isn't it a case for a specific
requirement regarding the domain?

 Regards, Benoit.



            

              
Hi Mouli,

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

Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan):




              

                
Hello,

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

I shall post some of the discussion points.

Thanks
Mouli

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

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


5.1.1.  Type of powered entity

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

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



              

              
Yes. The question is what is needed?




              

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

Powered Devices Description

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



              

              
Is this two in one (description and domain)?

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

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




              

                
Powered Entity Type

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



              

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

Thanks,

    Juergen




              

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

Dear all,

I am sorry for posting another version just one day after the previous
one.
Now out is version -03 to be found at

http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt

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

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

Thanks,

   Juergen

_______________________________________________
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


          

        

        

      

      

    

    

  





--Apple-Mail-8-933704281--

From ietf@quittek.at  Wed Jul  6 04:59:30 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CD521F8523 for ; Wed,  6 Jul 2011 04:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 T6UeMTXiJ1Hj for ; Wed,  6 Jul 2011 04:59:30 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id CD12A21F8516 for ; Wed,  6 Jul 2011 04:59:29 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MZDuG-1Qx32y3TWm-00Kuma; Wed, 06 Jul 2011 13:59:28 +0200
References: 		 <1127B34B-6899-4F1D-966E-ED841E25E554@quittek.at> <4E142A61.3010103@cisco.com>
In-Reply-To: <4E142A61.3010103@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-9-933886767
Message-Id: <20248561-E87E-4CD0-9E57-E031B00E479A@quittek.at>
From: Juergen Quittek 
Date: Wed, 6 Jul 2011 13:59:28 +0200
To: Benoit Claise 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:jwax8Zhsg1B9l8fNNsd3ni+V5D+nrdiV35eadmcesjU gWzA80QlQvs3rSkjjV8vbdAQNGMzNeDSYqJ/cUoluYk0lnsOZQ /WcVuHeTilxfpgjNTiSgt4cCMhVeg9PF5wNEBhEPgLT9PeWiv1 pEfIWrPnigs++T7JlnWOL1z6TK36H3rUKBCBTBZ/FDA4eBtHww VSJzBd2lgn2z82sSSaaOw==
Cc: eman mailing list 
Subject: Re: [eman] New draft on eman requirements  - issue 1 - Device type
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Jul 2011 11:59:30 -0000

--Apple-Mail-9-933886767
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 06.07.2011  11:26, Benoit Claise wrote:

> On 01/07/2011 14:10, Juergen Quittek wrote:
>>=20
>> Hi Mouli,
>>=20
>> I'm glad you comment on this. It was too vague so far.
>> Please see plies inline.
>>=20
>> Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan):
>>=20
>>> Hello,
>>>=20
>>> As Juergen has mentioned, while the first version has been released =
to
>>> solicit feedback, some of the concepts are still debated.
>>> The perspectives from the email list would be useful to shape the =
draft.
>>>=20
>>> I shall post some of the discussion points.=20
>>>=20
>>> Thanks
>>> Mouli
>>>=20
>>> ------------
>>>=20
>>> There is a requirement -
>>> =
http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>>=20
>>>=20
>>> 5.1.1.  Type of powered entity
>>>=20
>>>   The energy management standard must provide means to retrieve and
>>>   report the type of powered entities.
>>>=20
>>> I think it would be useful to expand this requirement. Device Type =
could
>>> be inferred as "IP Phone" or "Line Card 3", ...
>> Yes. The question is what is needed?
> We don't want we redo the ENTITY-MIB work, but  I believe that having =
a way to map to the ENTITY-MIB index is important.
> The more generic requirements should be something such as:
> The energy management standard must provide means to map the power =
entities=20
> to existing managed device inventory such as the ENTITY-MIB.
>=20
> The energy management standard must provide means to map the power =
entities=20
> to existing energy related MIBs such as the POE and LLPD MIBs
>=20
> Those two requirements should be in the section 4. Identification of =
Powered Entities

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

> Coming back to this requirement
>=20
> 5.1.1. Type of powered entity
>=20
> The energy management standard must provide means to retrieve and
> report the type of powered entities.
> I believe the "type" is misleading. The main requirement is that we =
want the ability to group powered entities based on something, which =
could be the type, what the type definition you want.
> Therefore, I would remove the requirement 5.1.1 and only keep the =
current 5.1.2
> 5.1.2.  Grouping of powered entities
>=20
>    The energy management standard must provide means for grouping
>    powered entities, for example, into energy monitoring domains, =
energy
>    control domains, power supply domains, groups of entities of the =
same
>    type, etc.
I agree. I do not know what an entity type is. So let's remove 5.1.1.
However, 5.1.2 also talks about entities of the same type :-)
Shall we remove "type" also here?

Thanks,

    Juergen



--Apple-Mail-9-933886767
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


On 06.07.2011  11:26, Benoit Claise wrote:




    On 01/07/2011 14:10, Juergen Quittek wrote:
    

      
Hi Mouli,

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

Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan):



      

        
Hello,

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

I shall post some of the discussion points. 

Thanks
Mouli

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

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


5.1.1.  Type of powered entity

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

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


      

      
Yes. The question is what is needed?


    

    We don't want we redo the ENTITY-MIB work, but  I believe that
    having a way to map to the ENTITY-MIB index is important.

    The more generic requirements should be something such as:

    

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

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



    

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

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

Coming back to this requirement

    

    
5.1.1. Type of powered entity

      

      The energy management standard must provide means to retrieve and

      report the type of powered entities.

    I believe the "type" is misleading. The main requirement is that we
    want the ability to group powered entities based on something, which
    could be the type, what the type definition you want.

    Therefore, I would remove the requirement 5.1.1 and only keep the
    current 5.1.2

    

      
5.1.2.  Grouping of powered entities

   The energy management standard must provide means for grouping
   powered entities, for example, into energy monitoring domains, energy
   control domains, power supply domains, groups of entities of the same
   type, etc.
I agree. I do not know what an entity type is. So let's remove 5.1.1.
However, 5.1.2 also talks about entities of the same type :-)
Shall we remove "type" also here?

Thanks,

    Juergen



--Apple-Mail-9-933886767--

From ietf@quittek.at  Wed Jul  6 06:52:13 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FE721F8741 for ; Wed,  6 Jul 2011 06:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YMj0Du9l2py for ; Wed,  6 Jul 2011 06:52:12 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id BD6CF21F861C for ; Wed,  6 Jul 2011 06:52:08 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0MFW2y-1QhkJs3PKG-00EMWA; Wed, 06 Jul 2011 15:52:05 +0200
References: 
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
Message-Id: <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at>
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Wed, 6 Jul 2011 15:52:04 +0200
To: JinHyeock Choi 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:8+fpefuQJ9UKTgsgBc35kVSngbdiEaT2QFegwjBemoU gkjWwLtJDKtoRYuTbBw9oWXtbqhtRv1yKJPrZzqXLtC23Qybvx UPsjJAHVhVgVuw5R2ulZG1urJRlr/Nk9j6p8H36mkHv+Rrg4K2 qd1fZFyu/7yzXHcTFYlGPwCo8iD6GvXOkrZYRMbTFkYGI+azkD v5Vu9TJPxf2hd9N43PBeg==
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Jul 2011 13:52:13 -0000

Dear JinHyeock,

Thank you for your detailed review.
Please find replies inline.

Am 06.07.2011 um 05:43 schrieb JinHyeock Choi:

> Dear Juergen and all
>=20
> thanks for the update and here are some comments.
>=20
> 1. Clarification of =91Power=92 and =91Energy=92
> The relationship between power and (electric) energy is
> Power is the energy consumption rate (measured with watt) and
> energy is the integral of power over time (measured with joule or =
watthour).
>=20
> Energy management concerns both =91power=92 and =91energy=92 and
> now the term =91energy consmption=92 is used for both,
> and sometimes brings forth confusion.
>=20
> Maybe we can make it more clear
> by attaching the unit to be measured (either watt or watthour).
> For example such as
> =93amount of consumed energy measured by joule or watthour.=94

I see your point. The alternative would be adding a clarification to
the terminology section. What about appending

   However, in this document the term "consumed energy" always refers
   to an energy quantity and not to a power quantity.=20

to section 2.1 Energy?=20

> 2. Power/ Energy and Time
> Both power and energy are time dependent parameter.
>=20
> Power can be measured at a specific moment
> or averaged over a certain time interval.
> Energy is measured over a time interval.
>=20
> When reporting =91power=92 or =91energy=92 value,
> i) a specific moment or ii) a time interval
> with which the measurement is made also should be provided.

Yes, that's a good point. I think for energy measurements this is =
covered=20
by requirement 5.5.2.  Time intervals, but for power monitoring this is =
missing.

What about adding the following requirement?
5.4.2.  Power measurement interval

   The energy management standard must provide means for reporting the
   corresponding time interval for which a power value is reported.  A
   time interval can be very short for reporting approximations of
   instantaneous power or rather long for reporting demand values.

> 3. Power state and Energy consumption
>=20
>> 5.5.3. Energy per power state
>>=20
>> The energy management standard must provide means for reporting the
>> consumed energy individually for each power state.
>=20
> Energy consumption depends on
> not only =91power state=92 but also =91traffic load=92.
>=20
> To make sense out of the monitored =91power=92 or =91energy=92 value,
> energy management system should also take into consideration
> corresponding  =91traffic rate (measured by bps)=92 or =91accumulated
> traffic (measured by bits)=92.
>=20
> Otherwise it can=92t determine
> whether high power consumption is from low energy efficiency
> or high data traffic.

What would be the requirement?

A comment on the issue:=20
Proportionality between traffic and energy is a tricky thing.=20
I read reports on measurements at low-end routers that show
decreasing energy consumption with increasing traffic.

> 4. Power profile of powered entity
>=20
>> The basic objective of energy management is operating communication
>> networks and other equipment with minimal amount of energy, while
>> maintaining a certain level of service.
>=20
> For the above purpose, it would be of help
> for energy management system to be aware of
> the energy efficiency of each powered device (or entity),
> i.e. how much energy (joule) each device consumes per bit.
>=20
> Ideally energy efficiency would be provided as
> a power profile (or power model), a function
> which maps served traffic (bits or bps) into consumed energy (joule/ =
watt).
>=20
> For example, as a linear function of
>=20
> P =3D a*T + b,
>=20
> where P is energy consumption rate (watt)
> T is traffic rate (bps)
> and a, b are constant.
>=20
> I recommend
> energy efficiency or power profile
> to be included to the required information in Sec 5.

This would be a requirement for switches, routers, etc. only.
For PCs, displays, light bulbs, it would not be applicable.

Would it not be sufficient to just report the power and have the =
joule/bit
be computed by a management system that reads the interface MIB modules =
if available?

> Here are some more
>=20
>> 1. Introduction
>>=20
>> All requirements in this document must be
>> reflected by standards specifications to be developed based on these
>> requirements.
>=20
> Looks circular. We may do rid of =91based on these requirements.=92
>=20

Right.

>> 2.1. Energy
>>=20
>> The term 'energy consumption' is commonly used for both, for
>> referring to the amount of consumed energy and also for referring to
>> the process of consuming energy.
>=20
> =91process of consuming energy=92 means
> =91rate of consuming enegy=92 right?
>=20

Yes, I'll fix it.

>=20
>> In the first case it addresses
>> consumed energy, in the second one it addresses power, typically an
>> average power.
>=20
> For clarification, we may modify
> =91consumed energy=92 with =91consumed energy measured by joule or =
watthour=92
> and
> =91power=92 with =91power measured by watt=92

Good. Let's apply this change.

>> 4.2. Identifying components of powered devices
>>=20
>> The energy management standard must provide means for identifying not
>> just entire devices as powered entities, but also individual
>> components of powered devices.
>=20
> Shall we also identify (or represent) the (subordinate) relationship
> between powered device and its individual components?

There are already standards for this available.
Shall we still make a requirement out of it in order to clarify that =
this is=20
needed for energy management as well?
>=20
>> 5.2.6. Maximum and average power per power state
>>=20
>> The energy management standard must provide means for retrieving the
>> maximum power and the average power as a typically static property
>> for each supported power state.
>=20
> Maximum power at maximum capacity?

We do not have a general definition of capacity.
This varies too much among the range of devices that we intend to =
support.

> Average power in which sense?
> Just a arithmetic mean value between maximum and minimum power?

I was thinking about the average expected energy consumption in a =
particular power state.
I admit that this may be difficult to predict. But before asking an =
entity to switch to another
power state it would make sense to have information about the chances of =
saving power
and for avoiding to bring the device into a state that even consumes =
more power.

>> 5.4. Power
>>=20
>> For some network management tasks, it is required to obtain time
>> series of power values (or energy consumption values).
>=20
> I assume energy consumption value measured by watt.
> Am I right?

No here it is either or: power or energy time series. But I see this is =
confusing.
What about removing "(or energy consumption values)"?

>> 5.5. Energy
>>=20
>> In order to monitor energy consumption in different power states, it
>> is useful if entities record their energy consumption per power state
>> and report these quantities.
>=20
> Energy consumption varies according to power state and traffic load.
> How do you take =91traffic load=92 into consideration?

We do not have any generic term for load. If you can provide one, please =
send it.

>> 5.5.4. Time series of energy values
>>=20
>> The energy management standard must provide means for collecting time
>> series of energy values for each power inlet and for each power
>> outlet of an entity
>=20
> Energy would be measured over time interval.
>=20
> Would time series of energy values be measured
> over the sequence of time intervals in 5.5.2?

Yes. There are different ways to do so.

A time series can contain values that give the total energy since the =
last re-start=20
up to an indicated measurement time. Alternatively, you can have time =
series of energy
consumption for consecutive time intervals, one value each. Or you can =
have this for
overlapping time intervals. 5.5.2 shows all of them.

>> 8.1.1. Control of power states of other entities
>>=20
>> The energy management standard must provide means for an energy
>> management system to send power state control commands to entity that
>> concern the power states of other entities than the one the command
>> was send to.
>=20
> Is this always the case?
> Can=92t control command be sent to an entity that concern the power
> state of itself?

We have the scenario of building networks that do not use IP.=20
In such a case a gateway or proxy will be addressed by control=20
commands for devices in the non-IP network.

>> 8.1.4. List of all power state controllers
>>=20
>>   The energy management standard must provide means for an entity =
that
>>   has receives commands controlling its power state from other =
entities
>>   to report the list of all those entities.
>=20
> Typo
> sub =91receives=92 with =91received=92

Fixed. But the fix was deleting "has"

>> 9. Security Considerations
>>=20
>> Secondly, it should be possible to prevent
>> malicious entities exercising control over entities.
>=20
> sub =91prevent malicious entities exercising=92 with
> =91prevent malicious entities from exercising=92

Fixed.

Many thanks,

    Juergen


> Thanks for your kind consideration.
>=20
> Best regards
>=20
> JinHyeock
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From jinchoe@gmail.com  Wed Jul  6 07:22:41 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE9C21F85F9 for ; Wed,  6 Jul 2011 07:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 xdYhA8PbH0LA for ; Wed,  6 Jul 2011 07:22:40 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 950DB21F8605 for ; Wed,  6 Jul 2011 07:22:35 -0700 (PDT)
Received: by pvh18 with SMTP id 18so9363985pvh.31 for ; Wed, 06 Jul 2011 07:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1jI05tXbJm0CAwdE7AgKh5LhDpOHzJouRQMofKZQKHk=; b=AWr60z+fNt6XXw8kqMDP0ZzeG6UeLAFcj7sBUfFLhxLT1QMCKMtOG2r7DodKD/REf2 lIrSHCbJSofrCW+hdP75k6etMfORMhJRLuEf4V1vG8XUxBRaZjcNoVx6OZD8S0Y2fa4R +0C8N+z7dNyK+R4n+CSCZcVS/BKHD1lAuZisk=
MIME-Version: 1.0
Received: by 10.68.66.101 with SMTP id e5mr2363414pbt.239.1309962155010; Wed, 06 Jul 2011 07:22:35 -0700 (PDT)
Received: by 10.68.59.138 with HTTP; Wed, 6 Jul 2011 07:22:34 -0700 (PDT)
In-Reply-To: 
References:    
Date: Wed, 6 Jul 2011 23:22:34 +0900
Message-ID: 
From: JinHyeock Choi 
To: Bruce Nordman 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: eman mailing list 
Subject: Re: [eman] New draft on eman requirements - Comment - Terminology
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Jul 2011 14:22:41 -0000

Bruce

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

agree.

In Physics,
=91Power (unit of watt)=92 and =91Energy (unit of joule)=92 are well define=
d terms
just like =91Force (unit of newton)=92.

For =91power=92 and =91energy=92
we can just use the definitions made in Physics.

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

best regards

JinHyeock


On Sat, Jul 2, 2011 at 6:50 AM, Bruce Nordman  wrote:
> One possible reference is:
> =A0 IEEE 100, "The Authoritative Dictionary of IEEE Standards Terms", IEE=
E.
> I have the Seventh Edition, 2000, which appears to be the most recent
> (perhaps it is now only revised electronically).
> I am not an engineer, but have chaired an IEEE working group.
>
> A measurement standard that I am very familiar with is IEC 62301 (Ed. 2),
> "Household electrical appliances =96 Measurement of standby power" - whic=
h
> addresses measurements of individual devices.=A0 It does NOT define power
> or energy in the standard, but instead references:
> IEC 60050-131, International Electrotechnical Vocabulary (IEV) =96 Part 1=
31:
> Circuit theory
> IEC 60050-300, International Electrotechnical Vocabulary (IEV) =96 Electr=
ical
> and electronic measurements and measuring instruments =96 Part 311: Gener=
al
> terms relating to measure- ments =96 Part 312: General terms relating to
> electrical measurements =96 Part 313: Types of electrical measuring
> instruments =96 Part 314: Specific terms according to the type of instrum=
ent
> So, would be good if someone could see what these say, or perhaps we can
> do the same and simply reference these without defining energy or power
> (except to specify the units).=A0 I do think we should reference 62301, a=
t
> least
> as informative.=A0 It is widely referenced in energy test procedures for
> electronics
> (and presumably for appliances as well).
>
> Back to the IEEE Dictionary.
> Energy in the context of "metering" is:
> "The integral of active power with respect to time."
>
> Demand in the context of "electrical power systems in commercial building=
s"
> is.
> "The electrical load at the receiving terminals averaged over a
> =A0specified interval of time.=A0 Demand is expressed in kilowatts,
> =A0kilovoltamperes, kilovars, amperes, or other suitable units.
> =A0The interval of time is generally 15 minutes, 30 minutes, or 60 minute=
s."
> Other definitions listed are:
> "The average value of power or a related quantity over a specified interv=
al
> of time"
> "The rate at which electrical energy is being used"
> "The rate of consumption, e.g. power, volume/hour."
>
> Power (most applicable definition) is:
> "The rate of generating, transferring, or using energy."
>
> Power--Active is:
> "The time average of the instantaneous power over one period of the wave.=
"
> This same definition is listed for metering for "Active Power".
>
> Some terms have extremely lengthy definitions.=A0 Examples include
> electric energy, and active power.
>
> Electric Energy begins:
> "The electric energy delivered by an electric circuit during a time inter=
val
> =A0is the integral with respect to time of the instantaneous power at the
> =A0terminals of entry of the circuit to a delineated region."
> A second definition is in its entirety
> "Usually, electric demand integrated over the period of one hour".
>
> Also worthy of consideration:
> Electricity Meter:
> "A device that measures and registers the integral of an electrical quant=
ity
> with
> =A0respect to time"
> A similar definition exists for "watthour meter".
>
> I would be in favor of short definitions that then point to IEC or IEEE.
>
> --Bruce
>
>
> On Fri, Jul 1, 2011 at 4:38 AM, Mouli Chandramouli (moulchan)
>  wrote:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>
>> It would be useful to have consistent definitions of Power, Energy and
>> Demand since these terms are used in many of the documents.
>>
>> Thanks
>> Mouli
>>
>
> --
> Bruce Nordman
> Lawrence Berkeley National Laboratory
> eetd.lbl.gov/ea/nordman
> BNordman@LBL.gov
> 510-486-7089
> m: 510-501-7943
>
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>
>

From karagian@cs.utwente.nl  Wed Jul  6 13:35:08 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D011121F8BD3 for ; Wed,  6 Jul 2011 13:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.962
X-Spam-Level: *
X-Spam-Status: No, score=1.962 tagged_above=-999 required=5 tests=[AWL=-1.230,  BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MANGLED_SEX=2.3, MIME_QP_LONG_LINE=1.396]
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 jwI11cSBwcwP for ; Wed,  6 Jul 2011 13:35:07 -0700 (PDT)
Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB5E21F8BC6 for ; Wed,  6 Jul 2011 13:35:07 -0700 (PDT)
Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p66KXUFX021136;  Wed, 6 Jul 2011 22:33:30 +0200 (MEST)
Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 06 Jul 2011 20:35:10 +0000
To: "Juergen Quittek" , "eman mailing list" 
Date: Wed, 06 Jul 2011 20:35:09 +0000
X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl)
Message-ID: 
In-Reply-To: 
From: "Georgios Karagiannis" 
Bounce-To: "Georgios Karagiannis" 
Errors-To: "Georgios Karagiannis" 
MIME-Version: 1.0 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 06 Jul 2011 22:33:41 +0200 (MEST)
Subject: Re: [eman] New draft on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Jul 2011 20:35:08 -0000

Hi Juergen,

Aggregated functions may be related to:

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

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

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

Best regards,
Georgios



The requirements on aggregation functions  and

On 7/6/2011, "Georgios Karagiannis"  wrote:

>Hi Juergen,
>
>I think that the draft looks good!
>
>I have some comments on the open issues sections 12.3 and 12.4. In this
>email I will only
>address 12.3. In another email I will address 12.4.
>
>Regarding Section 12.3 Inlet/outlet combinations:
>--------------------------------
>
>I am in favour of introducing a new kind of hybrid in/outlets. This is
>because such sockets are different than the typical inlet and outlet
>sockets.
>
>If these hybrid sockets are used then the requirements associated with
>inlet/outlet socket have to somehow be modified, see below:
>
>
>
>Change_1 related to Inlet/outlet combinations:
>
>
>5.3.  Power inlet and power outlet
>
>   Powered entities have power inlets at which they are supplied with
>   electric power.  Many entities just have a single power inlet, while
>   others have multiple ones.  Often different power inlets are
>   connected to separate power distribution trees.  For energy
>   monitoring, it is important information which power inlets an entity
>   has, if power is available at an inlet and which of them are actually
>   in use.
>
>   Some entities have power outlets for supplying other entities with
>   electric power.  An entity may have multiple power outlets.  Examples
>   are a Power Distribution Units (PDU) and a Power over Ethernet (PoE)
>   Power Sourcing Equipment (PSE).
>
>   For identifying and potentially controlling the source of power
>   received at an inlet, it is useful to identify the power outlet of
>   another entity at which the received power is provided.  Analogously,
>   for each outlet it is of interest to identify the power inlets that
>   receive the power provided at a certain outlet.
>
>   Static properties of each power inlet and each power outlet are
>   useful information for energy management.  Static properties include
>   the kind of electric current (Alternating Current (AC) or Direct
>   Current (DC)), the nominal voltage, the nominal AC frequency, and the
>   number of AC phases.
>
>INTO something like:
>
>5.3.  Power inlet, power outlet and hybrid power inlet/outlet
>
>   Powered entities have power inlets at which they are supplied with
>   electric power.  Many entities just have a single power inlet, while
>   others have multiple ones.  Often different power inlets are
>   connected to separate power distribution trees.  For energy
>   monitoring, it is important information which power inlets an entity
>   has, if power is available at an inlet and which of them are actually
>   in use.
>
>   Some entities have power outlets for supplying other entities with
>   electric power.  An entity may have multiple power outlets.  Examples
>   are a Power Distribution Units (PDU) and a Power over Ethernet (PoE)
>   Power Sourcing Equipment (PSE).
>
>
>   There are entities where the inlet or outlet changes during
>   operation from one kind to the other.  An example is a battery that
>   receives power at a socket at one time.  Then the socket is an inlet.
>   At another time the battery provides power at the same socket.  Then
>   it's an outlet.  The same holds for entities with integrated power
>   generators. This type of socket is denoted as a hybrid power
>inlet/outlet.
>
>   For identifying and potentially controlling the source of power
>   received at an inlet, it is useful to identify the power outlet of
>   another entity at which the received power is provided.  Analogously,
>   for each outlet it is of interest to identify the power inlets that
>   receive the power provided at a certain outlet. For hybrid power
>inlet/outlet
>   it is for interest to identify and control when and for how long a
>   hybrid socket operates as a power inlet and for how long it operates
>   as a power outlet.
>
>   Static properties of each power inlet and each power outlet are
>   useful information for energy management.  Static properties include
>   the kind of electric current (Alternating Current (AC) or Direct
>   Current (DC)), the nominal voltage, the nominal AC frequency, and the
>   number of AC phases.
>
>
>
>Change_2: related to Inlet/outlet combinations:
>
>Please change from:
>
>5.3.2.  Corresponding power outlet
>
>   The energy management standard must provide means for identifying the
>   power outlet that provides the power received at a power inlet.
>
>
>INto something like:
>
>5.3.2.  Corresponding power outlet
>
>   The energy management standard must provide means for identifying the
>   power outlet that provides the power received at a power inlet or at a
>hybrid power
>   inlet/outlet.
>
>-----------------------
>
>Change_3: related to Inlet/outlet combinations:
>
>Please change from:
>
>
>
>5.3.3.  Corresponding power inlets
>
>   The energy management standard must provide means for identifying the
>   list of power inlets that receive the power provided at a power
>   outlet.
>
>INto something like:
>
>5.3.3.  Corresponding power inlets
>
>   The energy management standard must provide means for identifying the
>   list of power inlets that receive the power provided at a power
>   outlet or a hybrid power inlet/outlet.
>
>---------------
>
>
>
>Change_4 related to Inlet/outlet combinations:
>
>Include a new section in 5.3, after section 5.3.3, something like:
>
>5.3.x Corresponding hybrid power inlets/outlets
>
>   The energy management standard must provide means for identifying the
>   hybrid power inlet/outlet that provides the power received at a power
>inlet or
>   another hybrid power inlet/outlet.
>
>------------------
>
>Change_5 related to Inlet/outlet combinations:
>
>Please change from:
>
>5.3.4.  Availability of power
>
>   The energy management standard must provide means for monitoring the
>   availability of power at each power inlet and each power outlet.
>   This information indicates whether at a power providing outlet power
>   supply is switched on or off.
>
>INto something like:
>
>5.3.4.  Availability of power
>
>   The energy management standard must provide means for monitoring the
>   availability of power at each power inlet, at each power outlet and at
>each
>   hybrid power inlet/outlet.
>   This information indicates whether at a power providing outlet
>   the power supply is switched on or off. For a hybrid power
>inlet/outlet this indicates whether
>   the hybrid inlet/outlet operates as an inlet or as an outlet.
>
>
>--------------
>
>Change 6 related to Inlet/outlet combinations:
>
>Please change from:
>
>5.3.5.  Use of power
>
>   The energy management standard must provide means for monitoring for
>   each power inlet and each power outlet if it is in actual use.  For
>   the inlet this means that the entity actually receives power at the
>   inlet.  For the outlet this means that actually power is provided to
>   one or more entities at the outlet.
>
>INTO something like:
>
>5.3.5.  Use of power
>
>   The energy management standard must provide means for monitoring for
>   each power inlet, for each power outlet and for each hybrid power
>inlet/outlet
>   if it is in actual use.  For
>   the inlet this means that the entity actually receives power at the
>   inlet.  For the outlet this means that actually power is provided to
>   one or more entities at the outlet. For the hybrid inlet/outlet this
>means
>   that the energy management standard must be able to distinguish whether
>   power is received to the hybrid inlet/outlet or power is provided by
>the
>   hybrid inlet/outlet to one or more entities.
>
>------------------
>
>Change 7 related to Inlet/outlet combinations:
>
>Please a new subsection after subsection 6.2
>
>6.2.x Controlling power supply and consumption
>   The energy management standard must provide means for switching power
>   supply off or turning power supply on at power outlets providing
>   power to one or more powered entity.
>
>INTO something like:
>
>6.2.x Controlling power supply and consumption
>
>   The energy management standard must provide means for switching power
>   supply off or turning power supply on at hybrid power inlet/outlets.
>   Furthermore, the energy management standard must provide means for
>switching
>   the power consumption off or turning power consumption on at hybrid
>power inlet/outlets.
>
>---------------
>
>Best regards,
>Georgios
>PS: I will provide some comments on the aggregation related issue in
>another email
>
>
>
>
>
>
>On 6/30/2011, "Juergen Quittek"  wrote:
>
>>Dear all,
>>
>>I am sorry for posting another version just one day after the previous one.
>>Now out is version -03 to be found at
>>    http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>
>>The reason was that a change in terminology ("powered device" -> "powered
>>entity") was not done consistently in all sections, particularly not in the
>>battery section.
>>
>>There are no further changes, particularly no technical changes compared to
>>the previous version.
>>
>>Thanks,
>>
>>    Juergen
>>
>>Am 29.06.11 16:53 schrieb "Juergen Quittek" unter :
>>
>>> Dear all,
>>>
>>> I just posted a new version on the requirements draft.
>>> Please find it at
>>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-02.txt
>>>
>>> We had intensive discussions among the authors and received a lot of usef=
ul
>>> comments from John Parello. This resulted in many changes and a modified
>>> structure. We consider the version posted today as an intermediate one an=
d
>>> intend to post another update before the cut-off date.
>>>
>>> Please have a look at the new structure and give us your feedback.
>>>
>>> Issues that we definitely want to solve for the next version are describe=
d
>>> in section 12. Among them are
>>>   - High/Low power notifications
>>>   - Power and energy time series?
>>>   - Inlet/outlet combinations
>>>   - Aggregation functions
>>> Your advice on these issues is highly appreciated.
>>>
>>> Thanks,
>>>
>>>     Juergen
>>>
>>> _______________________________________________
>>> 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 jinchoe@gmail.com  Wed Jul  6 20:08:20 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFFC21F895C for ; Wed,  6 Jul 2011 20:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Bf72QFxTNz28 for ; Wed,  6 Jul 2011 20:08:19 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D0C1321F8870 for ; Wed,  6 Jul 2011 20:08:19 -0700 (PDT)
Received: by pwj5 with SMTP id 5so506175pwj.31 for ; Wed, 06 Jul 2011 20:08:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nQa8B7wwuwzFsAKN2cBtOqe6P3luTSs65c6u77MnNXY=; b=sNi/oK23I+1+DzPi9sFsiKz0jMrHZFMywEB88nlSNwX+EK/kgt2u6OPt3gcFVhWDW+ 47t07OLMwhfQf0NhivZ76S0kyRz0SFvBeLEUJZh5gfDsHs4AdTIGhfyR5XwDpU4roQB/ wWoqUvjQugn3dLIxqxu11ybdYFp0Jbm6bLzzA=
MIME-Version: 1.0
Received: by 10.68.47.4 with SMTP id z4mr389062pbm.306.1310008098243; Wed, 06 Jul 2011 20:08:18 -0700 (PDT)
Received: by 10.68.59.138 with HTTP; Wed, 6 Jul 2011 20:08:18 -0700 (PDT)
In-Reply-To: 
References:  
Date: Thu, 7 Jul 2011 12:08:18 +0900
Message-ID: 
From: JinHyeock Choi 
To: "Mouli Chandramouli (moulchan)" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Jul 2011 03:08:20 -0000

Dear Mouli

> Thanks for your detailed comments.

thanks for the draft to comment on. :-)

> As Juergen has mentioned in another email thread, perhaps, the terminolog=
y section may be revised and updated.

ok.

> Regarding your point on energy profile should take into consideration tra=
ffic (bps) for network devices
>
> =A0- there are benchmarking studies of networking devices based on TEER s=
tandard
>
> http://www.3gpp.org/ATIS-Standards-helping-network

thanks for the inforamiton.

> That statistic can be derived by an NMS for a networking device by pollin=
g the energy MIB and ifMIB counters.

This will do and perhaps is the way to compute power profile (or
energy efficiency)

thanks for your kind consideration.

Best regards

JinHyeock

From jinchoe@gmail.com  Wed Jul  6 20:08:53 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3343421F895C for ; Wed,  6 Jul 2011 20:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level: 
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, 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 qxA6rF9h0Zgk for ; Wed,  6 Jul 2011 20:08:52 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 62F5A21F8870 for ; Wed,  6 Jul 2011 20:08:52 -0700 (PDT)
Received: by pwj5 with SMTP id 5so506530pwj.31 for ; Wed, 06 Jul 2011 20:08:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BPQfvVexVxgU+U3uu61eJ3PWJd9JiCaQrr3B9wMLqDU=; b=AkVFxhlCCtz3GJq/t+YVFvvauoDuuuvtqdzbZNgSeZz1Rfz0eeDPhMjZVBxf2k027U llk4B4a64TqKjPLDpNBNALXE5NEUfeDbXZHkNaIHjY05o5EMu5Fzk938qeUanhZftSMk 3Ad+HO9twGdbmJ82PzU6S2Wen33impY4sPE+o=
MIME-Version: 1.0
Received: by 10.68.18.34 with SMTP id t2mr389530pbd.507.1310008131965; Wed, 06 Jul 2011 20:08:51 -0700 (PDT)
Received: by 10.68.59.138 with HTTP; Wed, 6 Jul 2011 20:08:51 -0700 (PDT)
In-Reply-To: <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at>
References:  <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at>
Date: Thu, 7 Jul 2011 12:08:51 +0900
Message-ID: 
From: JinHyeock Choi 
To: Juergen Quittek 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Jul 2011 03:08:53 -0000

Dear Juergen

thanks for kind and thoughtful reply.

>> 1. Clarification of =91Power=92 and =91Energy=92
>>
>> Energy management concerns both =91power=92 and =91energy=92 and
>> now the term =91energy consmption=92 is used for both,
>> and sometimes brings forth confusion.
>>
>> Maybe we can make it more clear
>> by attaching the unit to be measured (either watt or watthour).
>> For example such as
>> =93amount of consumed energy measured by joule or watthour.=94
>
> I see your point. The alternative would be adding a clarification to
> the terminology section. What about appending
>
> =A0 However, in this document the term "consumed energy" always refers
> =A0 to an energy quantity and not to a power quantity.
>
> to section 2.1 Energy?

fine with me.

Sometimes people have trouble distinguishng =91power=92 and =91energy=92
at least that=92s the case for me.
(it has been a long while since I pored over Physics textbook.)

Though =91power=92 and =91energy=92 have different meanings
clearly defined in Physics,
their everyday usage can be intermingling
such as =91power efficiency=92 and =91energy efficiency=92

>> 2. Power/ Energy and Time
>> Both power and energy are time dependent parameter.
>>
>> When reporting =91power=92 or =91energy=92 value,
>> i) a specific moment or ii) a time interval
>> with which the measurement is made also should be provided.
>
> Yes, that's a good point. I think for energy measurements this is covered
> by requirement 5.5.2. =A0Time intervals, but for power monitoring this is=
 missing.
>
> What about adding the following requirement?
> 5.4.2. =A0Power measurement interval
>
> =A0 The energy management standard must provide means for reporting the
> =A0 corresponding time interval for which a power value is reported. =A0A
> =A0 time interval can be very short for reporting approximations of
> =A0 instantaneous power or rather long for reporting demand values.

In principle,
power itself is an instantateous value
and measured at a moment (not over interval).

So how about rephrasing

  =A0 The energy management standard must provide means for reporting the
  =A0 corresponding time or time interval for which a power value is report=
ed.
  =A0 The power value can be measured at the corresponding time or averaged
  =A0 over the corresponding time interval.

>> 3. Power state and Energy consumption
>>
>>> 5.5.3. Energy per power state
>>>
>>> The energy management standard must provide means for reporting the
>>> consumed energy individually for each power state.
>>
>> Energy consumption depends on
>> not only =91power state=92 but also =91traffic load=92.
>>
>> To make sense out of the monitored =91power=92 or =91energy=92 value,
>> energy management system should also take into consideration
>> corresponding =A0=91traffic rate (measured by bps)=92 or =91accumulated
>> traffic (measured by bits)=92.
>>
>> Otherwise it can=92t determine
>> whether high power consumption is from low energy efficiency
>> or high data traffic.
>
> What would be the requirement?

How about

    The energy management standard must provide means for reporting the
    consumed energy individually for each power state,
    with which enegy management system can derive an average expected
    energy consumption for each power state.

to clarify the reason behind per-power state reporting
> A comment on the issue:
> Proportionality between traffic and energy is a tricky thing.
> I read reports on measurements at low-end routers that show
> decreasing energy consumption with increasing traffic.

Interesting.
Power consumption remaining the same irrespective of traffic load
is not unusual but power consumption inversely proportional
to traffic load is a novelty.
Can you give me a pointer?

>> 4. Power profile of powered entity
>>
>> For the above purpose, it would be of help
>> for energy management system to be aware of
>> the energy efficiency of each powered device (or entity),
>> i.e. how much energy (joule) each device consumes per bit.
>>
>> Ideally energy efficiency would be provided as
>> a power profile (or power model), a function
>> which maps served traffic (bits or bps) into consumed energy (joule/ wat=
t).
>>
>> I recommend
>> energy efficiency or power profile
>> to be included to the required information in Sec 5.
>
> This would be a requirement for switches, routers, etc. only.
> For PCs, displays, light bulbs, it would not be applicable.

I see.

> Would it not be sufficient to just report the power and have the joule/bi=
t
> be computed by a management system that reads the interface MIB modules
> if available?

ok.

For energy management,
power profile would be needed
but maybe better be acquired indirectly
via a kind of resolution scheme.

>>> 4.2. Identifying components of powered devices
>>>
>>> The energy management standard must provide means for identifying not
>>> just entire devices as powered entities, but also individual
>>> components of powered devices.
>>
>> Shall we also identify (or represent) the (subordinate) relationship
>> between powered device and its individual components?
>
> There are already standards for this available.
> Shall we still make a requirement out of it in order to clarify that this=
 is
> needed for energy management as well?

Such representatin of subordinate relationship would be useful
but I=92m not sure about making it a requirement.
If WG doesn=92t have a strong opinion about it,
let=92s leave it as it is. :-)

>>> 5.2.6. Maximum and average power per power state
>>>
>>> The energy management standard must provide means for retrieving the
>>> maximum power and the average power as a typically static property
>>> for each supported power state.
>>
>> Average power in which sense?
>> Just a arithmetic mean value between maximum and minimum power?
>
> I was thinking about the average expected energy consumption in a particu=
lar power state.
> I admit that this may be difficult to predict.

yes,
even at the same power state,
enrgy consumption can vary substantially depending on traffic load.

> But before asking an entity to switch to another
> power state it would make sense to have information about the chances of =
saving power
> and for avoiding to bring the device into a state that even consumes more=
 power.

agree.

>>> 5.4. Power
>>>
>>> For some network management tasks, it is required to obtain time
>>> series of power values (or energy consumption values).
>>
>> I assume energy consumption value measured by watt.
>> Am I right?
>
> No here it is either or: power or energy time series. But I see this is c=
onfusing.
> What about removing "(or energy consumption values)"?

ok. thanks for clarificaiton.

>>> 5.5. Energy
>>>
>>> In order to monitor energy consumption in different power states, it
>>> is useful if entities record their energy consumption per power state
>>> and report these quantities.
>>
>> Energy consumption varies according to power state and traffic load.
>> How do you take =91traffic load=92 into consideration?
>
> We do not have any generic term for load. If you can provide one, please =
send it.

=91bps=92 or =91(accumulated) bit=92 would do for network equipments
such as router or switich.

However, for more generic work load,
I don=92t have a good idea.

>> Energy would be measured over time interval.
>>
>> Would time series of energy values be measured
>> over the sequence of time intervals in 5.5.2?
>
> Yes. There are different ways to do so.
>
> A time series can contain values that give the total energy since the las=
t re-start
> up to an indicated measurement time. Alternatively, you can have time ser=
ies of energy
> consumption for consecutive time intervals, one value each. Or you can ha=
ve this for
> overlapping time intervals. 5.5.2 shows all of them.

ok.

Please allow me to split hairs
cocnerning the terms =91series=92 and =91sequence=92
which are currently both used in in 5.5.2 and 5.5.4.

Precisely speaking, in mathematics,
=91series=92 is the sum of the terms of =91sequence=92,
so in our context, =91sequence=92 is better.

Bets regards

JinHyeock

From ietf@quittek.at  Wed Jul  6 20:39:55 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB1921F8A20 for ; Wed,  6 Jul 2011 20:39:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.751
X-Spam-Level: **
X-Spam-Status: No, score=2.751 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYiG5M0wn-K3 for ; Wed,  6 Jul 2011 20:39:54 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id B667C21F8A1C for ; Wed,  6 Jul 2011 20:39:53 -0700 (PDT)
Received: from [192.168.1.102] (HSI-KBW-085-216-027-035.hsi.kabelbw.de [85.216.27.35]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0M0bqI-1RXJUm2y3q-00uAyY; Thu, 07 Jul 2011 05:39:50 +0200
References:  <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at> 
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
Message-Id: 
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Thu, 7 Jul 2011 05:39:50 +0200
To: JinHyeock Choi 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:Hucxmx8AoGjbGpB5fyC2Hb9z0Wv2IO4cW//J4IC4KdT Y/reyMZc1HskT4fFE840dzE4+iPZf0BAas5zHb79OYTMQiySyK mviOuVh2ulHG30oCqtXiNZyuvLIGB+XSuk2+gFF3pr1UsdPZwZ 8g7OBVwL1y2WekT8cNjetKyPT9FmRZsvdjxu8wbNuBCnrhtEbu ea9OeP/iESbIUDSh+3nZw==
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Jul 2011 03:39:55 -0000

Dear JinHyeock,

Thanks for the constructive suggestions.
Please find replies inline.

Am 07.07.2011 um 05:08 schrieb JinHyeock Choi:

> Dear Juergen
>=20
> thanks for kind and thoughtful reply.
>=20
>>> 1. Clarification of =91Power=92 and =91Energy=92
>>>=20
>>> Energy management concerns both =91power=92 and =91energy=92 and
>>> now the term =91energy consmption=92 is used for both,
>>> and sometimes brings forth confusion.
>>>=20
>>> Maybe we can make it more clear
>>> by attaching the unit to be measured (either watt or watthour).
>>> For example such as
>>> =93amount of consumed energy measured by joule or watthour.=94
>>=20
>> I see your point. The alternative would be adding a clarification to
>> the terminology section. What about appending
>>=20
>>   However, in this document the term "consumed energy" always refers
>>   to an energy quantity and not to a power quantity.
>>=20
>> to section 2.1 Energy?
>=20
> fine with me.
>=20
> Sometimes people have trouble distinguishng =91power=92 and =91energy=92=

> at least that=92s the case for me.
> (it has been a long while since I pored over Physics textbook.)
>=20
> Though =91power=92 and =91energy=92 have different meanings
> clearly defined in Physics,
> their everyday usage can be intermingling
> such as =91power efficiency=92 and =91energy efficiency=92

OK. I will add units as you suggested above:

   However, in this document the term "consumed energy" always refers to
   an energy quantity (measured in joule, watthour, etc.) and not to a
   power quantity (measured in watt).

>>> 2. Power/ Energy and Time
>>> Both power and energy are time dependent parameter.
>>>=20
>>> When reporting =91power=92 or =91energy=92 value,
>>> i) a specific moment or ii) a time interval
>>> with which the measurement is made also should be provided.
>>=20
>> Yes, that's a good point. I think for energy measurements this is =
covered
>> by requirement 5.5.2.  Time intervals, but for power monitoring this =
is missing.
>>=20
>> What about adding the following requirement?
>> 5.4.2.  Power measurement interval
>>=20
>>   The energy management standard must provide means for reporting the
>>   corresponding time interval for which a power value is reported.  A
>>   time interval can be very short for reporting approximations of
>>   instantaneous power or rather long for reporting demand values.
>=20
> In principle,
> power itself is an instantateous value
> and measured at a moment (not over interval).
>=20
> So how about rephrasing
>=20
>    The energy management standard must provide means for reporting the
>    corresponding time or time interval for which a power value is =
reported.
>    The power value can be measured at the corresponding time or =
averaged
>    over the corresponding time interval.

Fine with me.

>>> 3. Power state and Energy consumption
>>>=20
>>>> 5.5.3. Energy per power state
>>>>=20
>>>> The energy management standard must provide means for reporting the
>>>> consumed energy individually for each power state.
>>>=20
>>> Energy consumption depends on
>>> not only =91power state=92 but also =91traffic load=92.
>>>=20
>>> To make sense out of the monitored =91power=92 or =91energy=92 =
value,
>>> energy management system should also take into consideration
>>> corresponding  =91traffic rate (measured by bps)=92 or =91accumulated
>>> traffic (measured by bits)=92.
>>>=20
>>> Otherwise it can=92t determine
>>> whether high power consumption is from low energy efficiency
>>> or high data traffic.
>>=20
>> What would be the requirement?
>=20
> How about
>=20
>    The energy management standard must provide means for reporting the
>    consumed energy individually for each power state,
>    with which enegy management system can derive an average expected
>    energy consumption for each power state.

This sounds like a good proposal.
I'll check it and come back on it later.

> to clarify the reason behind per-power state reporting
>> A comment on the issue:
>> Proportionality between traffic and energy is a tricky thing.
>> I read reports on measurements at low-end routers that show
>> decreasing energy consumption with increasing traffic.
>=20
> Interesting.
> Power consumption remaining the same irrespective of traffic load
> is not unusual but power consumption inversely proportional
> to traffic load is a novelty.
> Can you give me a pointer?

http://www.irit.fr/~Georges.Da-Costa/cse09.pdf

>>> 4. Power profile of powered entity
>>>=20
>>> For the above purpose, it would be of help
>>> for energy management system to be aware of
>>> the energy efficiency of each powered device (or entity),
>>> i.e. how much energy (joule) each device consumes per bit.
>>>=20
>>> Ideally energy efficiency would be provided as
>>> a power profile (or power model), a function
>>> which maps served traffic (bits or bps) into consumed energy (joule/ =
watt).
>>>=20
>>> I recommend
>>> energy efficiency or power profile
>>> to be included to the required information in Sec 5.
>>=20
>> This would be a requirement for switches, routers, etc. only.
>> For PCs, displays, light bulbs, it would not be applicable.
>=20
> I see.
>=20
>> Would it not be sufficient to just report the power and have the =
joule/bit
>> be computed by a management system that reads the interface MIB =
modules
>> if available?
>=20
> ok.
>=20
> For energy management,
> power profile would be needed
> but maybe better be acquired indirectly
> via a kind of resolution scheme.
>=20
>>>> 4.2. Identifying components of powered devices
>>>>=20
>>>> The energy management standard must provide means for identifying =
not
>>>> just entire devices as powered entities, but also individual
>>>> components of powered devices.
>>>=20
>>> Shall we also identify (or represent) the (subordinate) relationship
>>> between powered device and its individual components?
>>=20
>> There are already standards for this available.
>> Shall we still make a requirement out of it in order to clarify that =
this is
>> needed for energy management as well?
>=20
> Such representatin of subordinate relationship would be useful
> but I=92m not sure about making it a requirement.
> If WG doesn=92t have a strong opinion about it,
> let=92s leave it as it is. :-)
>=20
>>>> 5.2.6. Maximum and average power per power state
>>>>=20
>>>> The energy management standard must provide means for retrieving =
the
>>>> maximum power and the average power as a typically static property
>>>> for each supported power state.
>>>=20
>>> Average power in which sense?
>>> Just a arithmetic mean value between maximum and minimum power?
>>=20
>> I was thinking about the average expected energy consumption in a =
particular power state.
>> I admit that this may be difficult to predict.
>=20
> yes,
> even at the same power state,
> enrgy consumption can vary substantially depending on traffic load.
>=20
>> But before asking an entity to switch to another
>> power state it would make sense to have information about the chances =
of saving power
>> and for avoiding to bring the device into a state that even consumes =
more power.
>=20
> agree.
>=20
>>>> 5.4. Power
>>>>=20
>>>> For some network management tasks, it is required to obtain time
>>>> series of power values (or energy consumption values).
>>>=20
>>> I assume energy consumption value measured by watt.
>>> Am I right?
>>=20
>> No here it is either or: power or energy time series. But I see this =
is confusing.
>> What about removing "(or energy consumption values)"?
>=20
> ok. thanks for clarificaiton.
>=20
>>>> 5.5. Energy
>>>>=20
>>>> In order to monitor energy consumption in different power states, =
it
>>>> is useful if entities record their energy consumption per power =
state
>>>> and report these quantities.
>>>=20
>>> Energy consumption varies according to power state and traffic load.
>>> How do you take =91traffic load=92 into consideration?
>>=20
>> We do not have any generic term for load. If you can provide one, =
please send it.
>=20
> =91bps=92 or =91(accumulated) bit=92 would do for network equipments
> such as router or switich.
>=20
> However, for more generic work load,
> I don=92t have a good idea.
>=20
>>> Energy would be measured over time interval.
>>>=20
>>> Would time series of energy values be measured
>>> over the sequence of time intervals in 5.5.2?
>>=20
>> Yes. There are different ways to do so.
>>=20
>> A time series can contain values that give the total energy since the =
last re-start
>> up to an indicated measurement time. Alternatively, you can have time =
series of energy
>> consumption for consecutive time intervals, one value each. Or you =
can have this for
>> overlapping time intervals. 5.5.2 shows all of them.
>=20
> ok.
>=20
> Please allow me to split hairs
> cocnerning the terms =91series=92 and =91sequence=92
> which are currently both used in in 5.5.2 and 5.5.4.
>=20
> Precisely speaking, in mathematics,
> =91series=92 is the sum of the terms of =91sequence=92,
> so in our context, =91sequence=92 is better.

I'd be fine with using sequence.
Would it be OK to say "time sequence of power values" instead of "time =
series of power values"?

Thanks,

    Juergen

> Bets regards
>=20
> JinHyeock


From jparello@cisco.com  Wed Jul  6 20:56:03 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1BE21F8A90 for ; Wed,  6 Jul 2011 20:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.401
X-Spam-Level: **
X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5]
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 tQP7DogQ0DNL for ; Wed,  6 Jul 2011 20:56:02 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7560D21F8621 for ; Wed,  6 Jul 2011 20:56:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=3066; q=dns/txt; s=iport; t=1310010962; x=1311220562; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=LRWGdwaAYHfxf3dEZ9/QQHJXFvGF7iW1MUqmAReuk7c=; b=iv9I/WYlDhawDMwQKd8mmvxtjHq5O+PjFLD5n+f+P32SoX4C41cX5Y5a RhiMXQMOIo9pmJntoFq+TT6gL+R1ASAzLkDbVEzxuJhH0PbzxWrl2SUm0 6975LOM5WUlKEJdzDveEpUqRxiOArZjGt2JjRmN59MRd/jUrq3LT1AjrK M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUBAGItFU6rRDoG/2dsb2JhbABTmGSPM3eIe6USnX2GNwSHSZADi1s
X-IronPort-AV: E=Sophos;i="4.65,491,1304294400";  d="scan'208";a="519816"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-7.cisco.com with ESMTP; 07 Jul 2011 03:55:59 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p673txfR008070; Thu, 7 Jul 2011 03:55:59 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 6 Jul 2011 20:55:59 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 6 Jul 2011 20:51:11 -0700
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] Comments on eman requirements
Thread-Index: Acw8V42LNBAGcSRAQO6XkwbST8FxdQAACymg
References: <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at> 
From: "John Parello (jparello)" 
To: "Juergen Quittek" , "JinHyeock Choi" 
X-OriginalArrivalTime: 07 Jul 2011 03:55:59.0411 (UTC) FILETIME=[C81EA830:01CC3C59]
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Jul 2011 03:56:03 -0000

Hi,


In general we should not be making up terms that we mutually agree on. I
agree with the other threads that taking definitions from well
established source is much better.

For the basic things like Power and Energy etc there are well
established definition in IEC for utility meters and like devices,
ASHRAE, and IMO the new ISO50001 - which defines Energy Management and
constituent parts - has a concise normative reference for these.=20

http://www.iso.org/iso/catalogue_detail?csnumber=3D51297

You can also refer to the ODVA CIP presentation I did at IETF-80 which
discussed just this topic on Power Energy and Demand definitions etc

For the discussion below on 'Energy' the definitions from the above
sources just say time (no need to add series, sequence or interval)
unless you are referring to Demand or taking Energy and Power reading
over time (which already have time in them). In fact adding those will
make Demand more confusing.

Again there's quite some years of precedence for these values in utility
and industrial devices.

Jp

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Juergen Quittek
Sent: Wednesday, July 06, 2011 8:40 PM
To: JinHyeock Choi
Cc: eman mailing list
Subject: Re: [eman] Comments on eman requirements

Dear JinHyeock,

>>>> 5.4. Power
>>>>=20
>>>> For some network management tasks, it is required to obtain time
>>>> series of power values (or energy consumption values).
>>>=20
>>> I assume energy consumption value measured by watt.
>>> Am I right?
>>=20
>> No here it is either or: power or energy time series. But I see this
is confusing.
>> What about removing "(or energy consumption values)"?
>=20
> ok. thanks for clarificaiton.
>=20
>>>> 5.5. Energy
>>>>=20

>>> Energy would be measured over time interval.
>>>=20

Just "over time" no need to say series or interval.

Jp

=20
>>> Would time series of energy values be measured
>>> over the sequence of time intervals in 5.5.2?
>>=20
>> Yes. There are different ways to do so.
>>=20
>> A time series can contain values that give the total energy since the
last re-start
>> up to an indicated measurement time. Alternatively, you can have time
series of energy
>> consumption for consecutive time intervals, one value each. Or you
can have this for
>> overlapping time intervals. 5.5.2 shows all of them.
>=20
> ok.
>=20
> Please allow me to split hairs
> cocnerning the terms 'series' and 'sequence'
> which are currently both used in in 5.5.2 and 5.5.4.
>=20
> Precisely speaking, in mathematics,
> 'series' is the sum of the terms of 'sequence',
> so in our context, 'sequence' is better.

I'd be fine with using sequence.
Would it be OK to say "time sequence of power values" instead of "time
series of power values"?

Thanks,

    Juergen

> Bets regards
>=20
> JinHyeock

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

From jinchoe@gmail.com  Wed Jul  6 21:41:38 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49FF21F88CF for ; Wed,  6 Jul 2011 21:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level: 
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, 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 T6Q78nEs9goX for ; Wed,  6 Jul 2011 21:41:38 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8122021F8837 for ; Wed,  6 Jul 2011 21:41:31 -0700 (PDT)
Received: by pvh18 with SMTP id 18so234805pvh.31 for ; Wed, 06 Jul 2011 21:41:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=N+yW7KI7fsBz/PplLMXXQ/95u4TMIRWPrLzApX5B4zU=; b=BaSyD94Ks4zNCrjZsHU0VSgc8jpYZjWrt83uq3GGyK9abBDWTt863RGu8K8yobZd1o gZYrxqMdizqsThrh/us1M9MXgmuEx6JVx1PVqFqKPZoyua836jrib/cH7Rl7sTqfqKG/ 1u3CKrDXTvdLkM3eNXft89lsYxucii/rWr9s8=
MIME-Version: 1.0
Received: by 10.68.47.4 with SMTP id z4mr481821pbm.306.1310013690828; Wed, 06 Jul 2011 21:41:30 -0700 (PDT)
Received: by 10.68.59.138 with HTTP; Wed, 6 Jul 2011 21:41:30 -0700 (PDT)
In-Reply-To: 
References:  <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at>  
Date: Thu, 7 Jul 2011 13:41:30 +0900
Message-ID: 
From: JinHyeock Choi 
To: Juergen Quittek 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Jul 2011 04:41:39 -0000

Dear Juergen

> Thanks for the constructive suggestions.

thanks for your kind words.

>> Interesting.
>> Power consumption remaining the same irrespective of traffic load
>> is not unusual but power consumption inversely proportional
>> to traffic load is a novelty.
>> Can you give me a pointer?
>
> http://www.irit.fr/~Georges.Da-Costa/cse09.pdf

thanks for a prompt reply.

>> Precisely speaking, in mathematics,
>> =91series=92 is the sum of the terms of =91sequence=92,
>> so in our context, =91sequence=92 is better.
>
> I'd be fine with using sequence.
> Would it be OK to say "time sequence of power values" instead of "time se=
ries of power values"?

That would be great.
Thanks for your putting my mind at ease. :-)
This is just a small issue
which I can live with but would rather without.

Best regards

JinHyeock

From jinchoe@gmail.com  Wed Jul  6 22:16:45 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FB621F888F for ; Wed,  6 Jul 2011 22:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level: 
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=1.250,  BAYES_00=-2.599, 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 fIT5ofhUEV-z for ; Wed,  6 Jul 2011 22:16:44 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38ACA21F88C2 for ; Wed,  6 Jul 2011 22:16:44 -0700 (PDT)
Received: by pzk5 with SMTP id 5so685951pzk.31 for ; Wed, 06 Jul 2011 22:16:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dN2FaRaCt9yyxVwsNnIxDaVoCKEOC2hTcfU/FIfNJgI=; b=lI42L21rcuW3r8sJsRWU1Jmev4H76mTbnkY8lJMdJyWu2nDDwsppSNsIF4e/Hi3k9j 9U4yKqqXe0jdmVfaF+fKcujb7pjdLoE2EPLmPQH94BNILEaVCb5BePVvCMII7h6WVC3/ wBw2Mh9MAOmZqBdkpIqb/Jm8/Ywz+rhTwoVjc=
MIME-Version: 1.0
Received: by 10.68.69.114 with SMTP id d18mr581243pbu.172.1310015801850; Wed, 06 Jul 2011 22:16:41 -0700 (PDT)
Received: by 10.68.59.138 with HTTP; Wed, 6 Jul 2011 22:16:41 -0700 (PDT)
In-Reply-To: 
References:  <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at>   
Date: Thu, 7 Jul 2011 14:16:41 +0900
Message-ID: 
From: JinHyeock Choi 
To: "John Parello (jparello)" 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Jul 2011 05:16:45 -0000

Dear John

> For the basic things like Power and Energy etc there are well
> established definition in IEC for utility meters and like devices,
> ASHRAE, and IMO the new ISO50001 - which defines Energy Management and
> constituent parts - has a concise normative reference for these.
>
> http://www.iso.org/iso/catalogue_detail?csnumber=3D51297

Unfortunately the above demands to pay for the document. :-(
Would you kindly provide the definitions for =91power=92 and =91energy=92?

> You can also refer to the ODVA CIP presentation I did at IETF-80 which
> discussed just this topic on Power Energy and Demand definitions etc
>
> For the discussion below on 'Energy' the definitions from the above
> sources just say time (no need to add series, sequence or interval)

Allow me to quote Bruce=92s mail for =91energy=92 definition.

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

The integral implies
the domain over which integration is taken,
which I represent with the term =91time interval=92.

Also the statement below also mentions =91time interval=92

   "The electric energy delivered by an electric circuit during a time inte=
rval
      is the integral with respect to time of the instantaneous power at th=
e
      terminals of entry of the circuit to a delineated region."

Maybe this is from the ambiguity inherent in the word =91time=92.

=91Time=92 may imply a specific moment as in =91on time=92
or some period or interval as in =91long time.=92
(Actually Korean language has two different words for those.)

=91(Electric) energy=92, as its unit =91watthour=92 indicates,
concerns =91time=92 in the second sense.

Thanks for your kind consideration.

Best regards

JinHyeock

From internet-drafts@ietf.org  Thu Jul  7 04:32:40 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2028C21F87F8; Thu,  7 Jul 2011 04:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.581
X-Spam-Level: 
X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 Rb7psIdEQoVU; Thu,  7 Jul 2011 04:32:39 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B294921F87D6; Thu,  7 Jul 2011 04:32:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.55
Message-ID: <20110707113239.10819.22466.idtracker@ietfa.amsl.com>
Date: Thu, 07 Jul 2011 04:32:39 -0700
Cc: eman@ietf.org
Subject: [eman] I-D Action: draft-ietf-eman-battery-mib-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: Thu, 07 Jul 2011 11:32:40 -0000

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

	Title           : Definition of Managed Objects for Battery Monitoring
	Author(s)       : Juergen Quittek
                          Rolf Winter
                          Thomas Dietz
	Filename        : draft-ietf-eman-battery-mib-02.txt
	Pages           : 25
	Date            : 2011-07-07

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines managed objects that provide information on
   the status of batteries in managed devices.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eman-battery-mib-02.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-eman-battery-mib-02.txt

From Rolf.Winter@neclab.eu  Thu Jul  7 04:55:30 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC30421F8838 for ; Thu,  7 Jul 2011 04:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.087
X-Spam-Level: 
X-Spam-Status: No, score=-102.087 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 1+BDPnN6t9xG for ; Thu,  7 Jul 2011 04:55:30 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 50D0E21F881C for ; Thu,  7 Jul 2011 04:55:30 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 064AF2800032D for ; Thu,  7 Jul 2011 13:55:29 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHt8ttQcgxc8 for ; Thu,  7 Jul 2011 13:55:28 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DDE0B28000327 for ; Thu,  7 Jul 2011 13:55:23 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.22]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Thu, 7 Jul 2011 13:55:24 +0200
From: Rolf Winter 
To: "eman@ietf.org" 
Thread-Topic: updated version of the battery MIB
Thread-Index: Acw8nMCIvCGzz09FQg+FKwbZ9WYHGg==
Date: Thu, 7 Jul 2011 11:55:23 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D1CFBAF43@DAPHNIS.office.hd>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.6.28]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [eman] updated version of the battery MIB
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Jul 2011 11:55:31 -0000

Hi,

we just posted a new version of the battery MIB. It contains the following =
changes:

- we added objects for the maximum charging current, the recommended curren=
t to be used for trickle charging and a notification for battery
- we adopted the cycle definition of the Smart Battery Data Specification
- the former takes care of two open issues, we removed the one on battery h=
ealth as we e.g. have the cycle count as an approximate metric for this and=
 some other information in the MIB
- We added a new open issue asking how close we should align in general to =
the Smart Battery Data Specification

These are the main changes in this version. I think we make very good progr=
ess on this document. Thanks a lot for all the input received so far. We wo=
uld appreciate any further comments, so please keep them coming.

Best,

Rolf


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London =
W3 6BL | Registered in England 2832014=20



From bclaise@cisco.com  Thu Jul  7 06:10:22 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33DB21F86CC for ; Thu,  7 Jul 2011 06:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.571
X-Spam-Level: 
X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R1ce9upP0MQ for ; Thu,  7 Jul 2011 06:10:21 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 24A2821F85B2 for ; Thu,  7 Jul 2011 06:10:00 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p67CYjel024794; Thu, 7 Jul 2011 14:34:45 +0200 (CEST)
Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p67CYexU026708; Thu, 7 Jul 2011 14:34:41 +0200 (CEST)
Message-ID: <4E15A7E0.2010104@cisco.com>
Date: Thu, 07 Jul 2011 14:34:40 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Juergen Quittek 
References: <4E143B50.5060205@cisco.com> <6AED1DF3-BDD0-4376-BD55-07B1C636C5DC@quittek.at>
In-Reply-To: <6AED1DF3-BDD0-4376-BD55-07B1C636C5DC@quittek.at>
Content-Type: multipart/alternative; boundary="------------060102020908010004010602"
Cc: eman mailing list 
Subject: Re: [eman] Feedback on the EMAN requirement draft
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Jul 2011 13:10:22 -0000

This is a multi-part message in MIME format.
--------------060102020908010004010602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Juergen,
> Hi Benoit,
>
> Am 06.07.2011 um 12:39 schrieb Benoit Claise:
>
>> Dear all,
>>
>> Here is some more feedback on the EMAN requirement draft
>>
>> * The current table of content shows
>>     4.  Identification of Powered Entities . . . . . . . . . . . . . . 10
>>
>>     5.  Required Information on Powered Entities . . . . . . . . . . . 11
>>       5.1.  General information on entities  . . . . . . . . . . . . . 11
>>       5.2.  Power state  . . . . . . . . . . . . . . . . . . . . . . . 12
>>       5.3.  Power inlet and power outlet . . . . . . . . . . . . . . . 14
>>       5.4.  Power  . . . . . . . . . . . . . . . . . . . . . . . . . . 16
>>       5.5.  Energy . . . . . . . . . . . . . . . . . . . . . . . . . . 18
>>       5.6.  Battery State  . . . . . . . . . . . . . . . . . . . . . . 19
>>
>>     6.  Control of Powered Entities  . . . . . . . . . . . . . . . . . 21
>>
>>     7.  Reporting on Other Powered Entities  . . . . . . . . . . . . . 22
>>
>>     8.  Controlling Other Powered Entities . . . . . . . . . . . . . . 23
>>       8.1.  Controlling power states of other entities . . . . . . . . 23
>>       8.2.  Controlling power supply of other entities . . . . . . . . 24
>>
>>
>> It seems that only section 5 is about requirements.
>> Should the term required or requirement be added to the section 4, 6, 7 and 8?
> Right, that's an inconsistency. But since not surprisingly most 
> sections in the requirements draft
> are about requirements, I would rather suggest just removing 
> "Required" from the title of section 5.
> I would prefer this to having "Required" or "Requirements" in most of 
> the section headings of
> a document titled "Requirements".
[BC] just looking for consistency here, nothing more.
>> * Also, I'm not sure why the following sentences are in section 5. These should be generic.
>>
>>     Note that the fact that an energy management standard provides
>>     required means does not imply that all of them must be implemented by
>>     every compliant implementation.  The concrete specification of
>>     standards based on these requirements may label individual features
>>     as mandatory, recommended, or optional.
> Yes, they are repeated here from the introduction. We can remove them.
>
>> *  I still some requirements about "entity"
>>
>>     5.2.1. Actual power state
>>
>>     The energy management standard must provide means for reporting the
>>     actual power state of an entity.
>>
>> Please check all instances of "entity" -> "powered entity"
>
> I checked. There are many cases like "the power state of an entity".
> Would you insist in always stating "the power state of a POWERED entity"?
> I think the meaning would be unambiguous even without the change as it 
> is in
> "tags associated with a powered entity that indicate the entity's 
> role" where
> the second occurrence of 'entity' just omits the attribute "powered", 
> because
> the semantics is not a matter of any doubt.
>
> Also there is for example a section where we say: "An entity in this 
> document
> may be an entire managed device or just a component of it." In such a case
> I would prefer not to add "powered".
>
> But I fully agree that we should avoid all potential ambiguities.
> Particularly for the numbered detailed requirements I will make sure
> that all are unambiguous and that the draft gets much more "power" 
> inside :-)
>
>> * You have remove this, i.e. the reference to IPFIX
>>     Monitoring of power states and energy consumption can be performed in
>>     pull mode (for example, SNMP GET [RFC3410  ]) or in push mode (for
>>     example SNMP notification [RFC3410  ], Syslog [RFC5424  ], or IPFIX
>>     [RFC5101  ]).
>> Question: should the EMAN framework cover the IPFIX or not?
>
> Is there a REQUIREMENT to use IPFIX?
> If yes, it should be in.
The point is that is that the [EMAN-FMWK] has been going back and forth, 
adding and removing IPFIX based on the requirements
- initially IPFIX was mentioned in [EMAN-REQ]
- then we see now:

    A solution for this is that the
    concerned entity or another entity closely interacting with the
    concerned entity collect time series of power values and make them
    available via push or pull mechanisms to receivers of the
    information.

So, the questions are:
- Is IPFIX a requirement? Personally, I don't think we should mention it 
in [EMAN-REQ]
- However, what other mechanism do we have to PUSH time series of power 
values (no, SNMP notifications are not suitable)? So should we or not 
include IPFIX in the [EMAN-FMWK]?
>
>> * this sentence is difficult to read
>>
>>
>>       7.5. Content of reports on other entities
>>
>>
>>     The energy management standard must provide means for an entity to
>>     indicate for each other entity on which it can provide energy-related
>>     information which energy-related information can be provided for this
>>     entity.
> For other requirements I had similar problems. and solved it by not 
> starting with "The energy ..."
>
> What about
>
> For entities that provide energy-related information on other entities,
> the energy management standard must provide means to indicate which
> energy-related information can be provided for which otherentity.
> ?
that's better.

Regards, Benoit (as a contributor)
> Thanks,
>     Juergen
>> Regards, Benoit.
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org 
>> https://www.ietf.org/mailman/listinfo/eman
>


--------------060102020908010004010602
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    Hi Juergen,

    
Hi Benoit,
      


        

          
Am 06.07.2011 um 12:39 schrieb Benoit Claise:

          

          

            
 Dear all,

              

              Here is some more feedback on the EMAN requirement draft

              

              * The current table of content shows

              
   4.  Identification of Powered Entities . . . . . . . . . . . . . . 10

   5.  Required Information on Powered Entities . . . . . . . . . . . 11
     5.1.  General information on entities  . . . . . . . . . . . . . 11
     5.2.  Power state  . . . . . . . . . . . . . . . . . . . . . . . 12
     5.3.  Power inlet and power outlet . . . . . . . . . . . . . . . 14
     5.4.  Power  . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.5.  Energy . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.6.  Battery State  . . . . . . . . . . . . . . . . . . . . . . 19

   6.  Control of Powered Entities  . . . . . . . . . . . . . . . . . 21

   7.  Reporting on Other Powered Entities  . . . . . . . . . . . . . 22

   8.  Controlling Other Powered Entities . . . . . . . . . . . . . . 23
     8.1.  Controlling power states of other entities . . . . . . . . 23
     8.2.  Controlling power supply of other entities . . . . . . . . 24


It seems that only section 5 is about requirements.
Should the term required or requirement be added to the section 4, 6, 7 and 8?


            

          

          Right, that's an inconsistency. But since not surprisingly
          most sections in the requirements draft 

        
are about requirements, I would rather suggest just
          removing "Required" from the title of section 5. 

        
I would prefer this to having "Required" or "Requirements"
          in most of the section headings of 

        
a document titled "Requirements". 

        

      

    

    [BC] just looking for consistency here, nothing more.

    

      

        

          

            

              
* Also, I'm not sure why the following sentences are in section 5. These should be generic.

   Note that the fact that an energy management standard provides
   required means does not imply that all of them must be implemented by
   every compliant implementation.  The concrete specification of
   standards based on these requirements may label individual features
   as mandatory, recommended, or optional.


            

          

          Yes, they are repeated here from the introduction. We can
          remove them.

        


          

            
 *  I still some
              requirements about "entity"

              
5.2.1. Actual power state

                

                The energy management standard must provide means for
                reporting the

                actual power state of an entity.

              

              Please check all instances of "entity" -> "powered
              entity"

            

          

          


          

          I checked. There are many cases like "the power state of an
          entity".

        
Would you insist in always stating "the power state of a
          POWERED entity"?

        
I think the meaning would be unambiguous even without the
          change as it is in

        
"tags associated with a powered entity that indicate the
          entity's role" where 

        
the second occurrence of 'entity' just omits the attribute
          "powered", because

        
the semantics is not a matter of any doubt.

        


        

        
Also there is for example a section where we say: "An
          entity in this document 

        
may be an entire managed device or just a component of it."
          In such a case

        
I would prefer not to add "powered".

        


        

        
But I fully agree that we should avoid all potential
          ambiguities. 

        
Particularly for the numbered detailed requirements I will
          make sure 

        
that all are unambiguous and that the draft gets much more
          "power" inside :-)

        


        

        

          

            
 * You have remove
              this, i.e. the reference to IPFIX

              
   Monitoring of power states and energy consumption can be performed in
   pull mode (for example, SNMP GET [RFC3410]) or in push mode (for
   example SNMP notification [RFC3410], Syslog [RFC5424], or IPFIX
   [RFC5101]).


              Question: should the EMAN framework cover the IPFIX or
              not?

            

          

          


          

          Is there a REQUIREMENT to use IPFIX?

        
If yes, it should be in.

      

    

    The point is that is that the [EMAN-FMWK] has been going back and
    forth, adding and removing IPFIX based on the requirements

    - initially IPFIX was mentioned in [EMAN-REQ]

    - then we see now: 

    
   A solution for this is that the
   concerned entity or another entity closely interacting with the
   concerned entity collect time series of power values and make them
   available via push or pull mechanisms to receivers of the
   information.

    So, the questions are:

    - Is IPFIX a requirement? Personally, I don't think we should
    mention it in [EMAN-REQ]

    - However, what other mechanism do we have to PUSH time series of
    power values (no, SNMP notifications are not suitable)? So should we
    or not include IPFIX in the [EMAN-FMWK]?

    

      

        


          

            
 * this sentence is
              difficult to read

              

              
7.5.  Content of reports on other entities

   The energy management standard must provide means for an entity to
   indicate for each other entity on which it can provide energy-related
   information which energy-related information can be provided for this
   entity.

            

          

          For other requirements I had similar problems. and solved it
          by not starting with "The energy ..."

        


        

        
What about

        


          

        
 For entities that provide
            energy-related information on other entities,

        
 the energy management standard must
            provide means to indicate which 

        
 energy-related information
            can be provided for which other entity.

        

          

            

              
?

            

          

        

      

    

    that's better.

    

    Regards, Benoit (as a contributor)

    

      

        

          

            

              
Thanks,


    Juergen



            

          

        

        

          

            
 Regards, Benoit.

            

            _______________________________________________

            eman mailing list

            eman@ietf.org

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

          

        

        

      

    

    

  


--------------060102020908010004010602--

From ietf@quittek.at  Thu Jul  7 06:25:12 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622541F0C36 for ; Thu,  7 Jul 2011 06:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.251
X-Spam-Level: 
X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[AWL=-2.500,  BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brW8sG6iGPmF for ; Thu,  7 Jul 2011 06:25:11 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id E51141F0C34 for ; Thu,  7 Jul 2011 06:25:10 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MYpHi-1R1NWT3N4s-00VU4d; Thu, 07 Jul 2011 15:25:08 +0200
References: <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at>  
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <1B997F36-808C-4EB7-94EA-514567340BA2@quittek.at>
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Thu, 7 Jul 2011 15:25:07 +0200
To: "John Parello (jparello)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:wsNaAm9f+UgwTZcfiORLWiODQuHQQy1vN0xt0J/pzcj I/zF1jP0j4XClD5ch9PjCRNDsY3DzuC7FJ8HVk++VY+YQs11cJ RiZvOCz2cpPNHfyvwcHI32Ng18BScXdnAav4s7zN7jFapK9p5D 9ltGYnJgXL36Xi5UV1zqdizUvKVDB5e0rhaZ9eqU966riA/4u/ Iy2NozOrfwi37Hr0nEgaA==
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Jul 2011 13:25:12 -0000

Hi Paul,

Am 07.07.2011 um 05:51 schrieb John Parello (jparello):

> Hi,
>=20
>=20
> In general we should not be making up terms that we mutually agree on. =
I

I fully agree. But I would like to make the point that there we do not =
yet have an=20
agreement on this issue. I like the terms from IEC as well as the ones =
from IEEE.
Both are competent standards bodies in this area. But so far the =
discussions=20
with contributions from many people have not converged. I see a clear =
trend=20
towards adopting terms defined by other standards bodies and being in =
use=20
for many years.

Still, seeing Bruce's mail on this topic who , for example, gave us four=20=

commonly used definitions of demand, there are still choices to be made.
I'll be glad seeing us reaching a final agreement on which terms to =
choose
very soon.

> agree with the other threads that taking definitions from well
> established source is much better.
>=20
> For the basic things like Power and Energy etc there are well
> established definition in IEC for utility meters and like devices,
> ASHRAE, and IMO the new ISO50001 - which defines Energy Management and
> constituent parts - has a concise normative reference for these.=20
>=20
> http://www.iso.org/iso/catalogue_detail?csnumber=3D51297
>=20
> You can also refer to the ODVA CIP presentation I did at IETF-80 which
> discussed just this topic on Power Energy and Demand definitions etc
>=20
> For the discussion below on 'Energy' the definitions from the above
> sources just say time (no need to add series, sequence or interval)
> unless you are referring to Demand or taking Energy and Power reading
> over time (which already have time in them). In fact adding those will
> make Demand more confusing.

The discussion on the requirement to store time series/sequences of=20
measured values at the entity seems to be independent of our base =
terminology.

The discussion over time intervals was very useful for me.
Particularly, when I came to the point that I am not sure anymore
that we want to have instantaneous power reported for AC power.
As you know, the instantaneous power for AC is alternating and=20
typically has a value of zero for 50 or 60 times a second. So we =
definitely
want to have a power value that is not instantaneous, but at least =
averaged
over half a period of alternation. Thus all power/demand values we are
dealing with are average values.

> Again there's quite some years of precedence for these values in =
utility
> and industrial devices.

That's great and highly appreciated.

Thanks,

    Juergen


> Jp
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of
> Juergen Quittek
> Sent: Wednesday, July 06, 2011 8:40 PM
> To: JinHyeock Choi
> Cc: eman mailing list
> Subject: Re: [eman] Comments on eman requirements
>=20
> Dear JinHyeock,
>=20
>>>>> 5.4. Power
>>>>>=20
>>>>> For some network management tasks, it is required to obtain time
>>>>> series of power values (or energy consumption values).
>>>>=20
>>>> I assume energy consumption value measured by watt.
>>>> Am I right?
>>>=20
>>> No here it is either or: power or energy time series. But I see this
> is confusing.
>>> What about removing "(or energy consumption values)"?
>>=20
>> ok. thanks for clarificaiton.
>>=20
>>>>> 5.5. Energy
>>>>>=20
> 
>>>> Energy would be measured over time interval.
>>>>=20
>=20
> Just "over time" no need to say series or interval.
>=20
> Jp
>=20
>=20
>>>> Would time series of energy values be measured
>>>> over the sequence of time intervals in 5.5.2?
>>>=20
>>> Yes. There are different ways to do so.
>>>=20
>>> A time series can contain values that give the total energy since =
the
> last re-start
>>> up to an indicated measurement time. Alternatively, you can have =
time
> series of energy
>>> consumption for consecutive time intervals, one value each. Or you
> can have this for
>>> overlapping time intervals. 5.5.2 shows all of them.
>>=20
>> ok.
>>=20
>> Please allow me to split hairs
>> cocnerning the terms 'series' and 'sequence'
>> which are currently both used in in 5.5.2 and 5.5.4.
>>=20
>> Precisely speaking, in mathematics,
>> 'series' is the sum of the terms of 'sequence',
>> so in our context, 'sequence' is better.
>=20
> I'd be fine with using sequence.
> Would it be OK to say "time sequence of power values" instead of "time
> series of power values"?
>=20
> Thanks,
>=20
>    Juergen
>=20
>> Bets regards
>>=20
>> JinHyeock
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From ietf@quittek.at  Thu Jul  7 06:30:26 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562CB1F0C42 for ; Thu,  7 Jul 2011 06:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.04
X-Spam-Level: 
X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.208,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 6FRZLZBqSh2D for ; Thu,  7 Jul 2011 06:30:25 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id A015B1F0C41 for ; Thu,  7 Jul 2011 06:30:24 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MRQMu-1R7SNh081A-00SeL3; Thu, 07 Jul 2011 15:30:21 +0200
References: <4E143B50.5060205@cisco.com> <6AED1DF3-BDD0-4376-BD55-07B1C636C5DC@quittek.at> <4E15A7E0.2010104@cisco.com>
In-Reply-To: <4E15A7E0.2010104@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-10-1025739542
Message-Id: <0E6CF371-23AD-47A4-9F2D-9AE5FAFEC1A1@quittek.at>
From: Juergen Quittek 
Date: Thu, 7 Jul 2011 15:30:21 +0200
To: Benoit Claise 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:4rLAQSqdV/igEP1UlieHs1vtdGF9W1fvxcjLzHZcmVW q1tlHEpZF1Q+Vfbv9TNylHWpWJPnk/Cn+4GFHOVhU7aYAjavr6 9doEbKcnFpLC5XhbQP1N35CooN0/zUsxf//9vZ5TZue1kq8dLI KHH74qkV/TpzQxKio+/H9PAYrMC6sPNdUpIlPBWUP8Pdo816c8 Y8TPDKmGK0BHqyTuBLlvw==
Cc: eman mailing list 
Subject: Re: [eman] Feedback on the EMAN requirement draft
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Jul 2011 13:30:26 -0000

--Apple-Mail-10-1025739542
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Benoit,

Am 07.07.2011 um 14:34 schrieb Benoit Claise:

> Hi Juergen,
>> Hi Benoit,
>>=20
>> Am 06.07.2011 um 12:39 schrieb Benoit Claise:
>>=20
>>> Dear all,
>>>=20
>>> Here is some more feedback on the EMAN requirement draft
>>>=20
>>> * The current table of content shows
>>>    4.  Identification of Powered Entities . . . . . . . . . . . . . =
. 10
>>>=20
>>>    5.  Required Information on Powered Entities . . . . . . . . . . =
. 11
>>>      5.1.  General information on entities  . . . . . . . . . . . . =
. 11
>>>      5.2.  Power state  . . . . . . . . . . . . . . . . . . . . . . =
. 12
>>>      5.3.  Power inlet and power outlet . . . . . . . . . . . . . . =
. 14
>>>      5.4.  Power  . . . . . . . . . . . . . . . . . . . . . . . . . =
. 16
>>>      5.5.  Energy . . . . . . . . . . . . . . . . . . . . . . . . . =
. 18
>>>      5.6.  Battery State  . . . . . . . . . . . . . . . . . . . . . =
. 19
>>>=20
>>>    6.  Control of Powered Entities  . . . . . . . . . . . . . . . . =
. 21
>>>=20
>>>    7.  Reporting on Other Powered Entities  . . . . . . . . . . . . =
. 22
>>>=20
>>>    8.  Controlling Other Powered Entities . . . . . . . . . . . . . =
. 23
>>>      8.1.  Controlling power states of other entities . . . . . . . =
. 23
>>>      8.2.  Controlling power supply of other entities . . . . . . . =
. 24
>>>=20
>>>=20
>>> It seems that only section 5 is about requirements.
>>> Should the term required or requirement be added to the section 4, =
6, 7 and 8?
>> Right, that's an inconsistency. But since not surprisingly most =
sections in the requirements draft=20
>> are about requirements, I would rather suggest just removing =
"Required" from the title of section 5.=20
>> I would prefer this to having "Required" or "Requirements" in most of =
the section headings of=20
>> a document titled "Requirements".=20
> [BC] just looking for consistency here, nothing more.

OK. I'll change it in the next revision.
>>> * Also, I'm not sure why the following sentences are in section 5. =
These should be generic.
>>>=20
>>>    Note that the fact that an energy management standard provides
>>>    required means does not imply that all of them must be =
implemented by
>>>    every compliant implementation.  The concrete specification of
>>>    standards based on these requirements may label individual =
features
>>>    as mandatory, recommended, or optional.
>> Yes, they are repeated here from the introduction. We can remove =
them.
>>=20
>>> *  I still some requirements about "entity"
>>> 5.2.1. Actual power state
>>>=20
>>> The energy management standard must provide means for reporting the
>>> actual power state of an entity.
>>> Please check all instances of "entity" -> "powered entity"
>>=20
>> I checked. There are many cases like "the power state of an entity".
>> Would you insist in always stating "the power state of a POWERED =
entity"?
>> I think the meaning would be unambiguous even without the change as =
it is in
>> "tags associated with a powered entity that indicate the entity's =
role" where=20
>> the second occurrence of 'entity' just omits the attribute "powered", =
because
>> the semantics is not a matter of any doubt.
>>=20
>> Also there is for example a section where we say: "An entity in this =
document=20
>> may be an entire managed device or just a component of it." In such a =
case
>> I would prefer not to add "powered".
>>=20
>> But I fully agree that we should avoid all potential ambiguities.=20
>> Particularly for the numbered detailed requirements I will make sure=20=

>> that all are unambiguous and that the draft gets much more "power" =
inside :-)
>>=20
>>> * You have remove this, i.e. the reference to IPFIX
>>>    Monitoring of power states and energy consumption can be =
performed in
>>>    pull mode (for example, SNMP GET [RFC3410]) or in push mode (for
>>>    example SNMP notification [RFC3410], Syslog [RFC5424], or IPFIX
>>>    [RFC5101]).
>>> Question: should the EMAN framework cover the IPFIX or not?
>>=20
>> Is there a REQUIREMENT to use IPFIX?
>> If yes, it should be in.
> The point is that is that the [EMAN-FMWK] has been going back and =
forth, adding and removing IPFIX based on the requirements
> - initially IPFIX was mentioned in [EMAN-REQ]
> - then we see now:=20
>    A solution for this is that the
>    concerned entity or another entity closely interacting with the
>    concerned entity collect time series of power values and make them
>    available via push or pull mechanisms to receivers of the
>    information.
> So, the questions are:
> - Is IPFIX a requirement? Personally, I don't think we should mention =
it in [EMAN-REQ]

I share this view.

> - However, what other mechanism do we have to PUSH time series of =
power values (no, SNMP notifications are not suitable)? So should we or =
not include IPFIX in the [EMAN-FMWK]?

I think the push pull discussion is well located in the framework.
I would definitely mention IPFIX there. I am not sure if we should=20
mention it just as a potential push technology or if we should already
select a push technology in the framework.

>>=20
>>> * this sentence is difficult to read
>>>=20
>>> 7.5.  Content of reports on other entities
>>>=20
>>>=20
>>>    The energy management standard must provide means for an entity =
to
>>>    indicate for each other entity on which it can provide =
energy-related
>>>    information which energy-related information can be provided for =
this
>>>    entity.
>> For other requirements I had similar problems. and solved it by not =
starting with "The energy ..."
>>=20
>> What about
>>=20
>>=20
>>          =20
>>  For entities that provide
>>             energy-related information on other entities,
>>  the energy management standard must
>>             provide means to indicate which=20
>>  energy-related information
>>             can be provided for which other entity.
>> ?
> that's better.

OK. I'll add it to the next version.

Thanks,

    Juergen


> Regards, Benoit (as a contributor)
>> Thanks,
>>     Juergen
>>> Regards, Benoit.
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>>=20
>=20


--Apple-Mail-10-1025739542
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

Hi Benoit,

Am 07.07.2011 um 14:34 schrieb Benoit Claise:




    Hi Juergen,

    
Hi Benoit,
      


        

          
Am 06.07.2011 um 12:39 schrieb Benoit Claise:

          

          

            
 Dear all,

              

              Here is some more feedback on the EMAN requirement draft

              

              * The current table of content shows

              
   4.  Identification of Powered Entities . . . . . . . . . . . . . . 10

   5.  Required Information on Powered Entities . . . . . . . . . . . 11
     5.1.  General information on entities  . . . . . . . . . . . . . 11
     5.2.  Power state  . . . . . . . . . . . . . . . . . . . . . . . 12
     5.3.  Power inlet and power outlet . . . . . . . . . . . . . . . 14
     5.4.  Power  . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.5.  Energy . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.6.  Battery State  . . . . . . . . . . . . . . . . . . . . . . 19

   6.  Control of Powered Entities  . . . . . . . . . . . . . . . . . 21

   7.  Reporting on Other Powered Entities  . . . . . . . . . . . . . 22

   8.  Controlling Other Powered Entities . . . . . . . . . . . . . . 23
     8.1.  Controlling power states of other entities . . . . . . . . 23
     8.2.  Controlling power supply of other entities . . . . . . . . 24


It seems that only section 5 is about requirements.
Should the term required or requirement be added to the section 4, 6, 7 and 8?


            

          

          Right, that's an inconsistency. But since not surprisingly
          most sections in the requirements draft 

        
are about requirements, I would rather suggest just
          removing "Required" from the title of section 5. 

        
I would prefer this to having "Required" or "Requirements"
          in most of the section headings of 

        
a document titled "Requirements". 

        

      

    

    [BC] just looking for consistency here, nothing more.

OK. I'll change it in the next revision.

    

      

        

          

            

              
* Also, I'm not sure why the following sentences are in section 5. These should be generic.

   Note that the fact that an energy management standard provides
   required means does not imply that all of them must be implemented by
   every compliant implementation.  The concrete specification of
   standards based on these requirements may label individual features
   as mandatory, recommended, or optional.


            

          

          Yes, they are repeated here from the introduction. We can
          remove them.

        


          

            
 *  I still some
              requirements about "entity"

              
5.2.1. Actual power state

                

                The energy management standard must provide means for
                reporting the

                actual power state of an entity.

              

              Please check all instances of "entity" -> "powered
              entity"

            

          

          


          

          I checked. There are many cases like "the power state of an
          entity".

        
Would you insist in always stating "the power state of a
          POWERED entity"?

        
I think the meaning would be unambiguous even without the
          change as it is in

        
"tags associated with a powered entity that indicate the
          entity's role" where 

        
the second occurrence of 'entity' just omits the attribute
          "powered", because

        
the semantics is not a matter of any doubt.

        


        

        
Also there is for example a section where we say: "An
          entity in this document 

        
may be an entire managed device or just a component of it."
          In such a case

        
I would prefer not to add "powered".

        


        

        
But I fully agree that we should avoid all potential
          ambiguities. 

        
Particularly for the numbered detailed requirements I will
          make sure 

        
that all are unambiguous and that the draft gets much more
          "power" inside :-)

        


        

        

          

            
 * You have remove
              this, i.e. the reference to IPFIX

              
   Monitoring of power states and energy consumption can be performed in
   pull mode (for example, SNMP GET [RFC3410]) or in push mode (for
   example SNMP notification [RFC3410], Syslog [RFC5424], or IPFIX
   [RFC5101]).


              Question: should the EMAN framework cover the IPFIX or
              not?

            

          

          


          

          Is there a REQUIREMENT to use IPFIX?

        
If yes, it should be in.

      

    

    The point is that is that the [EMAN-FMWK] has been going back and
    forth, adding and removing IPFIX based on the requirements

    - initially IPFIX was mentioned in [EMAN-REQ]

    - then we see now: 

    
   A solution for this is that the
   concerned entity or another entity closely interacting with the
   concerned entity collect time series of power values and make them
   available via push or pull mechanisms to receivers of the
   information.

    So, the questions are:

    - Is IPFIX a requirement? Personally, I don't think we should
    mention it in [EMAN-REQ]

I share this view.


    - However, what other mechanism do we have to PUSH time series of
    power values (no, SNMP notifications are not suitable)? So should we
    or not include IPFIX in the [EMAN-FMWK]?

I think the push pull discussion is well located in the framework.
I would definitely mention IPFIX there. I am not sure if we should 
mention it just as a potential push technology or if we should already
select a push technology in the framework.


    

      

        


          

            
 * this sentence is
              difficult to read

              

              
7.5.  Content of reports on other entities

   The energy management standard must provide means for an entity to
   indicate for each other entity on which it can provide energy-related
   information which energy-related information can be provided for this
   entity.

            

          

          For other requirements I had similar problems. and solved it
          by not starting with "The energy ..."

        


        

        
What about

        


          

        
 For entities that provide
            energy-related information on other entities,

        
 the energy management standard must
            provide means to indicate which 

        
 energy-related information
            can be provided for which other entity.

        

          

            

              
?

            

          

        

      

    

    that's better.

OK. I'll add it to the next version.

Thanks,

    Juergen



    Regards, Benoit (as a contributor)

    

      

        

          

            

              
Thanks,


    Juergen



            

          

        

        

          

            
 Regards, Benoit.

            

            _______________________________________________

            eman mailing list

            eman@ietf.org

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

          

        

        

      

    

    

  





--Apple-Mail-10-1025739542--

From Michael.Suchoff@raritan.com  Thu Jul  7 08:14:39 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAA021F88A7 for ; Thu,  7 Jul 2011 08:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.401
X-Spam-Level: **
X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5]
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 PL506BKh3rjf for ; Thu,  7 Jul 2011 08:14:38 -0700 (PDT)
Received: from fig.raritan.com (fig.raritan.com [12.144.63.197]) by ietfa.amsl.com (Postfix) with ESMTP id 20BF121F8888 for ; Thu,  7 Jul 2011 08:14:37 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 7 Jul 2011 11:14:28 -0400
Message-ID: <9C329342B62B87498B92834DEC9FF51E0D238F6F@fig.raritan.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] Comments on eman requirements
Thread-Index: Acw8Uz9212BVqactTs6KhxOxr7ed+gAYeOgg
References: <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at> 
From: "Michael Suchoff" 
To: "JinHyeock Choi" , "Juergen Quittek" 
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Jul 2011 15:14:39 -0000

AC power is not reported as an instantaneous value but as an average - =
the minimum averaging time being 1/2 AC cycle.

A plot of the instantaneous AC power is a sinusoidal waveform at 2X the =
AC power frequency.  For example, assume V =3D 100V RMS, I =3D 1A RMS, =
F=3D60Hz with power factor 1.0.  The power waveform would be a 120Hz =
sinusoidal with amplitude 200 and average value 100.  The average value =
is the active (real) power.

The power waveform can be explained mathematically using the product to =
sum formula we learned in high school trigonometry class....

Sin(a) * sin(b) =3D .5 * (cos(a-b) - cos(a+b)

"a" and "b" are frequency (phase term not shown for simplicity) which =
are identical.  Cos(a-b) =3D 0 which is the real component of power and =
whose average value is shown on a watt meter.  Cos(a+b) is the 2X =
frequency component whose average value is 0.


-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of =
JinHyeock Choi
Sent: Wednesday, July 06, 2011 11:09 PM
To: Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] Comments on eman requirements

Dear Juergen

thanks for kind and thoughtful reply.

>> 1. Clarification of 'Power' and 'Energy'
>>
>> Energy management concerns both 'power' and 'energy' and
>> now the term 'energy consmption' is used for both,
>> and sometimes brings forth confusion.
>>
>> Maybe we can make it more clear
>> by attaching the unit to be measured (either watt or watthour).
>> For example such as
>> "amount of consumed energy measured by joule or watthour."
>
> I see your point. The alternative would be adding a clarification to
> the terminology section. What about appending
>
> =A0 However, in this document the term "consumed energy" always refers
> =A0 to an energy quantity and not to a power quantity.
>
> to section 2.1 Energy?

fine with me.

Sometimes people have trouble distinguishng 'power' and 'energy'
at least that's the case for me.
(it has been a long while since I pored over Physics textbook.)

Though 'power' and 'energy' have different meanings
clearly defined in Physics,
their everyday usage can be intermingling
such as 'power efficiency' and 'energy efficiency'

>> 2. Power/ Energy and Time
>> Both power and energy are time dependent parameter.
>>
>> When reporting 'power' or 'energy' value,
>> i) a specific moment or ii) a time interval
>> with which the measurement is made also should be provided.
>
> Yes, that's a good point. I think for energy measurements this is =
covered
> by requirement 5.5.2. =A0Time intervals, but for power monitoring this =
is missing.
>
> What about adding the following requirement?
> 5.4.2. =A0Power measurement interval
>
> =A0 The energy management standard must provide means for reporting =
the
> =A0 corresponding time interval for which a power value is reported. =
=A0A
> =A0 time interval can be very short for reporting approximations of
> =A0 instantaneous power or rather long for reporting demand values.

In principle,
power itself is an instantateous value
and measured at a moment (not over interval).

So how about rephrasing

  =A0 The energy management standard must provide means for reporting =
the
  =A0 corresponding time or time interval for which a power value is =
reported.
  =A0 The power value can be measured at the corresponding time or =
averaged
  =A0 over the corresponding time interval.

>> 3. Power state and Energy consumption
>>
>>> 5.5.3. Energy per power state
>>>
>>> The energy management standard must provide means for reporting the
>>> consumed energy individually for each power state.
>>
>> Energy consumption depends on
>> not only 'power state' but also 'traffic load'.
>>
>> To make sense out of the monitored 'power' or 'energy' value,
>> energy management system should also take into consideration
>> corresponding =A0'traffic rate (measured by bps)' or 'accumulated
>> traffic (measured by bits)'.
>>
>> Otherwise it can't determine
>> whether high power consumption is from low energy efficiency
>> or high data traffic.
>
> What would be the requirement?

How about

    The energy management standard must provide means for reporting the
    consumed energy individually for each power state,
    with which enegy management system can derive an average expected
    energy consumption for each power state.

to clarify the reason behind per-power state reporting
> A comment on the issue:
> Proportionality between traffic and energy is a tricky thing.
> I read reports on measurements at low-end routers that show
> decreasing energy consumption with increasing traffic.

Interesting.
Power consumption remaining the same irrespective of traffic load
is not unusual but power consumption inversely proportional
to traffic load is a novelty.
Can you give me a pointer?

>> 4. Power profile of powered entity
>>
>> For the above purpose, it would be of help
>> for energy management system to be aware of
>> the energy efficiency of each powered device (or entity),
>> i.e. how much energy (joule) each device consumes per bit.
>>
>> Ideally energy efficiency would be provided as
>> a power profile (or power model), a function
>> which maps served traffic (bits or bps) into consumed energy (joule/ =
watt).
>>
>> I recommend
>> energy efficiency or power profile
>> to be included to the required information in Sec 5.
>
> This would be a requirement for switches, routers, etc. only.
> For PCs, displays, light bulbs, it would not be applicable.

I see.

> Would it not be sufficient to just report the power and have the =
joule/bit
> be computed by a management system that reads the interface MIB =
modules
> if available?

ok.

For energy management,
power profile would be needed
but maybe better be acquired indirectly
via a kind of resolution scheme.

>>> 4.2. Identifying components of powered devices
>>>
>>> The energy management standard must provide means for identifying =
not
>>> just entire devices as powered entities, but also individual
>>> components of powered devices.
>>
>> Shall we also identify (or represent) the (subordinate) relationship
>> between powered device and its individual components?
>
> There are already standards for this available.
> Shall we still make a requirement out of it in order to clarify that =
this is
> needed for energy management as well?

Such representatin of subordinate relationship would be useful
but I'm not sure about making it a requirement.
If WG doesn't have a strong opinion about it,
let's leave it as it is. :-)

>>> 5.2.6. Maximum and average power per power state
>>>
>>> The energy management standard must provide means for retrieving the
>>> maximum power and the average power as a typically static property
>>> for each supported power state.
>>
>> Average power in which sense?
>> Just a arithmetic mean value between maximum and minimum power?
>
> I was thinking about the average expected energy consumption in a =
particular power state.
> I admit that this may be difficult to predict.

yes,
even at the same power state,
enrgy consumption can vary substantially depending on traffic load.

> But before asking an entity to switch to another
> power state it would make sense to have information about the chances =
of saving power
> and for avoiding to bring the device into a state that even consumes =
more power.

agree.

>>> 5.4. Power
>>>
>>> For some network management tasks, it is required to obtain time
>>> series of power values (or energy consumption values).
>>
>> I assume energy consumption value measured by watt.
>> Am I right?
>
> No here it is either or: power or energy time series. But I see this =
is confusing.
> What about removing "(or energy consumption values)"?

ok. thanks for clarificaiton.

>>> 5.5. Energy
>>>
>>> In order to monitor energy consumption in different power states, it
>>> is useful if entities record their energy consumption per power =
state
>>> and report these quantities.
>>
>> Energy consumption varies according to power state and traffic load.
>> How do you take 'traffic load' into consideration?
>
> We do not have any generic term for load. If you can provide one, =
please send it.

'bps' or '(accumulated) bit' would do for network equipments
such as router or switich.

However, for more generic work load,
I don't have a good idea.

>> Energy would be measured over time interval.
>>
>> Would time series of energy values be measured
>> over the sequence of time intervals in 5.5.2?
>
> Yes. There are different ways to do so.
>
> A time series can contain values that give the total energy since the =
last re-start
> up to an indicated measurement time. Alternatively, you can have time =
series of energy
> consumption for consecutive time intervals, one value each. Or you can =
have this for
> overlapping time intervals. 5.5.2 shows all of them.

ok.

Please allow me to split hairs
cocnerning the terms 'series' and 'sequence'
which are currently both used in in 5.5.2 and 5.5.4.

Precisely speaking, in mathematics,
'series' is the sum of the terms of 'sequence',
so in our context, 'sequence' is better.

Bets regards

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

From bclaise@cisco.com  Thu Jul  7 08:26:47 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D280D21F8681 for ; Thu,  7 Jul 2011 08:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level: 
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.026,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKsaAYXtUCpU for ; Thu,  7 Jul 2011 08:26:47 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D492E21F8680 for ; Thu,  7 Jul 2011 08:26:46 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p67FQjlS016175 for ; Thu, 7 Jul 2011 17:26:45 +0200 (CEST)
Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p67FQfOq011441 for ; Thu, 7 Jul 2011 17:26:41 +0200 (CEST)
Message-ID: <4E15D031.4090303@cisco.com>
Date: Thu, 07 Jul 2011 17:26:41 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: eman mailing list 
Content-Type: multipart/alternative; boundary="------------010106060908000509040607"
Subject: [eman] draft-tychon-eman-applicability-statement-02: review
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, 07 Jul 2011 15:26:47 -0000

This is a multi-part message in MIME format.
--------------010106060908000509040607
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear authors,

Thanks for your draft.

Some feedback.
- the draft would benefit from consistent terminology. Actually, all 
drafts in the WG would benefit from this. I guess it will be one of the 
main points during our meeting.
- Small editorial note, IETF draft don't use "we", "our", etc...
- sentences such as "Energy Management can be implemented by extending 
existing SNMP support to the EMAN specific MIBs to deal with energy 
reporting."
     The charter mentions: "The EMAN WG will develop an applicability 
statement, describing the variety of applications that can use the 
energy framework and associated MIB modules."
     So you can take as granted that the framework and the associated 
MIB modules are developed.
     I understand that this is a difficult task: on one side, the WG 
asked you to put all the use cases in the EMAN applicability statement 
in order to create the framework, and on the other side, you must assume 
that the draft has a framework already ;-)
     So let me focus only on the "section 2 
. 
Scenarios and Target devices" and "3. Use case patterns" in the rest of 
the email
- I don't really understand this text and the relation to the title


          2.4. Mid-level managers


             This use case describes the scenario of devices that receive power
             supply from one source. The reporting of power measurement and
             possibly control can be performed by some other entity.


- I don't really understand the section 2.7. Data center devices. It 
seems to be a mix of smart PDU (already covered), HVAC, and hierarchy of 
switches.
"The switch can be the aggregator for the power consumption of the data 
center." How would the switches communicate with the PDUs?
- "Scenario 8: Battery powered devices" would certainly need its own 
section.
- section 3. Use case patterns. You might want to express that the draft 
does certainly not cover all the use cases.
Hence, you wanted to extract the use case patterns. And that some other 
use cases that match the pattern should be covered as well.


Bottom line, even they can be improved, I like the sections 2 and 3.

Regards, Benoit (as a contributor)



--------------010106060908000509040607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  

    
  
  
    Dear authors,

    

    Thanks for your draft.

    

    Some feedback.

    - the draft would benefit from consistent terminology. Actually, all
    drafts in the WG would benefit from this. I guess it will be one of
    the main points during our meeting.

    - Small editorial note, IETF draft don't use "we", "our", etc...

    - sentences such as "Energy Management can be implemented by
    extending existing SNMP support to the EMAN specific MIBs to deal
    with energy reporting."

        The charter mentions: "The EMAN WG will develop an applicability
    statement, describing the variety of applications that can use the
    energy framework and associated MIB modules."

        So you can take as granted that the framework and the associated
    MIB modules are developed.

        I understand that this is a difficult task: on one side, the WG
    asked you to put all the use cases in the EMAN applicability
    statement in order to create the framework, and on the other side,
    you must assume that the draft has a framework already ;-)

        So let me focus only on the "section 2.
    Scenarios and Target devices" and "3. Use case patterns" in the rest
    of the email

    - I don't really understand this text and the relation to the title

    

      
2.4. Mid-level managers

  
        This use case describes the scenario of devices that receive power
        supply from one source. The reporting of power measurement and
        possibly control can be performed by some other entity.



    

    - I don't really understand the section 2.7. Data center devices. It
    seems to be a mix of smart PDU (already covered), HVAC, and
    hierarchy of switches.

    "The switch can be the aggregator for the power consumption of the
    data center." How would the switches communicate with the PDUs?

    - "Scenario 8: Battery powered devices" would certainly need its own
    section.

    - section 3. Use case patterns. You might want to express that the
    draft does certainly not cover all the use cases.

    Hence, you wanted to extract the use case patterns. And that some
    other use cases that match the pattern should be covered as well.

    

    

    Bottom line, even they can be improved, I like the sections 2 and 3.

    

    Regards, Benoit (as a contributor)

    

    

      



    

  


--------------010106060908000509040607--

From Michael.Suchoff@raritan.com  Thu Jul  7 12:41:06 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3166711E80A9 for ; Thu,  7 Jul 2011 12:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.401
X-Spam-Level: **
X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5]
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 fa9TKa4eUIZm for ; Thu,  7 Jul 2011 12:41:05 -0700 (PDT)
Received: from fig.raritan.com (fig.raritan.com [12.144.63.197]) by ietfa.amsl.com (Postfix) with ESMTP id D472C11E8072 for ; Thu,  7 Jul 2011 12:41:04 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 7 Jul 2011 15:40:56 -0400
Message-ID: <9C329342B62B87498B92834DEC9FF51E0D2A399B@fig.raritan.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] Comments on eman requirements
Thread-Index: Acw8Uz9212BVqactTs6KhxOxr7ed+gAYeOggAAlqulA=
References: <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at> 
From: "Michael Suchoff" 
To: "Michael Suchoff" , "JinHyeock Choi" , "Juergen Quittek" 
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Jul 2011 19:41:06 -0000

Correction to my prior e-mail.

Cos(a-b) =3D 1 when a =3D=3D b.

This first term is where power factor is derived.  If there is a phase =
difference between voltage and current, then this first term will =
evaluate to cos(p) where p is the phase difference between voltage and =
current.  When p =3D 0 (no phase shift) power factor =3D cos(0) =3D 1.  =
In a purely inductive or capacitive load, the phase shift of current is =
90 degrees relative to voltage, so this first term is cos(90) which is 0 =
- power factor is 0 and no power is delivered to load.

The main point of my original comment is the instantaneous power varies =
between 0 and 2*power - so it would not be correct to define power as =
the instantaneous value.

-----Original Message-----
From: Michael Suchoff=20
Sent: Thursday, July 07, 2011 11:14 AM
To: 'JinHyeock Choi'; Juergen Quittek
Cc: eman mailing list
Subject: RE: [eman] Comments on eman requirements

AC power is not reported as an instantaneous value but as an average - =
the minimum averaging time being 1/2 AC cycle.

A plot of the instantaneous AC power is a sinusoidal waveform at 2X the =
AC power frequency.  For example, assume V =3D 100V RMS, I =3D 1A RMS, =
F=3D60Hz with power factor 1.0.  The power waveform would be a 120Hz =
sinusoidal with amplitude 200 and average value 100.  The average value =
is the active (real) power.

The power waveform can be explained mathematically using the product to =
sum formula we learned in high school trigonometry class....

Sin(a) * sin(b) =3D .5 * (cos(a-b) - cos(a+b)

"a" and "b" are frequency (phase term not shown for simplicity) which =
are identical.  Cos(a-b) =3D 0 which is the real component of power and =
whose average value is shown on a watt meter.  Cos(a+b) is the 2X =
frequency component whose average value is 0.


-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of =
JinHyeock Choi
Sent: Wednesday, July 06, 2011 11:09 PM
To: Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] Comments on eman requirements

Dear Juergen

thanks for kind and thoughtful reply.

>> 1. Clarification of 'Power' and 'Energy'
>>
>> Energy management concerns both 'power' and 'energy' and
>> now the term 'energy consmption' is used for both,
>> and sometimes brings forth confusion.
>>
>> Maybe we can make it more clear
>> by attaching the unit to be measured (either watt or watthour).
>> For example such as
>> "amount of consumed energy measured by joule or watthour."
>
> I see your point. The alternative would be adding a clarification to
> the terminology section. What about appending
>
> =A0 However, in this document the term "consumed energy" always refers
> =A0 to an energy quantity and not to a power quantity.
>
> to section 2.1 Energy?

fine with me.

Sometimes people have trouble distinguishng 'power' and 'energy'
at least that's the case for me.
(it has been a long while since I pored over Physics textbook.)

Though 'power' and 'energy' have different meanings
clearly defined in Physics,
their everyday usage can be intermingling
such as 'power efficiency' and 'energy efficiency'

>> 2. Power/ Energy and Time
>> Both power and energy are time dependent parameter.
>>
>> When reporting 'power' or 'energy' value,
>> i) a specific moment or ii) a time interval
>> with which the measurement is made also should be provided.
>
> Yes, that's a good point. I think for energy measurements this is =
covered
> by requirement 5.5.2. =A0Time intervals, but for power monitoring this =
is missing.
>
> What about adding the following requirement?
> 5.4.2. =A0Power measurement interval
>
> =A0 The energy management standard must provide means for reporting =
the
> =A0 corresponding time interval for which a power value is reported. =
=A0A
> =A0 time interval can be very short for reporting approximations of
> =A0 instantaneous power or rather long for reporting demand values.

In principle,
power itself is an instantateous value
and measured at a moment (not over interval).

So how about rephrasing

  =A0 The energy management standard must provide means for reporting =
the
  =A0 corresponding time or time interval for which a power value is =
reported.
  =A0 The power value can be measured at the corresponding time or =
averaged
  =A0 over the corresponding time interval.

>> 3. Power state and Energy consumption
>>
>>> 5.5.3. Energy per power state
>>>
>>> The energy management standard must provide means for reporting the
>>> consumed energy individually for each power state.
>>
>> Energy consumption depends on
>> not only 'power state' but also 'traffic load'.
>>
>> To make sense out of the monitored 'power' or 'energy' value,
>> energy management system should also take into consideration
>> corresponding =A0'traffic rate (measured by bps)' or 'accumulated
>> traffic (measured by bits)'.
>>
>> Otherwise it can't determine
>> whether high power consumption is from low energy efficiency
>> or high data traffic.
>
> What would be the requirement?

How about

    The energy management standard must provide means for reporting the
    consumed energy individually for each power state,
    with which enegy management system can derive an average expected
    energy consumption for each power state.

to clarify the reason behind per-power state reporting
> A comment on the issue:
> Proportionality between traffic and energy is a tricky thing.
> I read reports on measurements at low-end routers that show
> decreasing energy consumption with increasing traffic.

Interesting.
Power consumption remaining the same irrespective of traffic load
is not unusual but power consumption inversely proportional
to traffic load is a novelty.
Can you give me a pointer?

>> 4. Power profile of powered entity
>>
>> For the above purpose, it would be of help
>> for energy management system to be aware of
>> the energy efficiency of each powered device (or entity),
>> i.e. how much energy (joule) each device consumes per bit.
>>
>> Ideally energy efficiency would be provided as
>> a power profile (or power model), a function
>> which maps served traffic (bits or bps) into consumed energy (joule/ =
watt).
>>
>> I recommend
>> energy efficiency or power profile
>> to be included to the required information in Sec 5.
>
> This would be a requirement for switches, routers, etc. only.
> For PCs, displays, light bulbs, it would not be applicable.

I see.

> Would it not be sufficient to just report the power and have the =
joule/bit
> be computed by a management system that reads the interface MIB =
modules
> if available?

ok.

For energy management,
power profile would be needed
but maybe better be acquired indirectly
via a kind of resolution scheme.

>>> 4.2. Identifying components of powered devices
>>>
>>> The energy management standard must provide means for identifying =
not
>>> just entire devices as powered entities, but also individual
>>> components of powered devices.
>>
>> Shall we also identify (or represent) the (subordinate) relationship
>> between powered device and its individual components?
>
> There are already standards for this available.
> Shall we still make a requirement out of it in order to clarify that =
this is
> needed for energy management as well?

Such representatin of subordinate relationship would be useful
but I'm not sure about making it a requirement.
If WG doesn't have a strong opinion about it,
let's leave it as it is. :-)

>>> 5.2.6. Maximum and average power per power state
>>>
>>> The energy management standard must provide means for retrieving the
>>> maximum power and the average power as a typically static property
>>> for each supported power state.
>>
>> Average power in which sense?
>> Just a arithmetic mean value between maximum and minimum power?
>
> I was thinking about the average expected energy consumption in a =
particular power state.
> I admit that this may be difficult to predict.

yes,
even at the same power state,
enrgy consumption can vary substantially depending on traffic load.

> But before asking an entity to switch to another
> power state it would make sense to have information about the chances =
of saving power
> and for avoiding to bring the device into a state that even consumes =
more power.

agree.

>>> 5.4. Power
>>>
>>> For some network management tasks, it is required to obtain time
>>> series of power values (or energy consumption values).
>>
>> I assume energy consumption value measured by watt.
>> Am I right?
>
> No here it is either or: power or energy time series. But I see this =
is confusing.
> What about removing "(or energy consumption values)"?

ok. thanks for clarificaiton.

>>> 5.5. Energy
>>>
>>> In order to monitor energy consumption in different power states, it
>>> is useful if entities record their energy consumption per power =
state
>>> and report these quantities.
>>
>> Energy consumption varies according to power state and traffic load.
>> How do you take 'traffic load' into consideration?
>
> We do not have any generic term for load. If you can provide one, =
please send it.

'bps' or '(accumulated) bit' would do for network equipments
such as router or switich.

However, for more generic work load,
I don't have a good idea.

>> Energy would be measured over time interval.
>>
>> Would time series of energy values be measured
>> over the sequence of time intervals in 5.5.2?
>
> Yes. There are different ways to do so.
>
> A time series can contain values that give the total energy since the =
last re-start
> up to an indicated measurement time. Alternatively, you can have time =
series of energy
> consumption for consecutive time intervals, one value each. Or you can =
have this for
> overlapping time intervals. 5.5.2 shows all of them.

ok.

Please allow me to split hairs
cocnerning the terms 'series' and 'sequence'
which are currently both used in in 5.5.2 and 5.5.4.

Precisely speaking, in mathematics,
'series' is the sum of the terms of 'sequence',
so in our context, 'sequence' is better.

Bets regards

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

From bclaise@cisco.com  Thu Jul  7 17:18:21 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3AC21F8915 for ; Thu,  7 Jul 2011 17:18:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level: 
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUO5veknhwNF for ; Thu,  7 Jul 2011 17:18:20 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7F13B21F88E7 for ; Thu,  7 Jul 2011 17:18:19 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p68070Wk013576; Fri, 8 Jul 2011 02:07:01 +0200 (CEST)
Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6806s7j016886; Fri, 8 Jul 2011 02:06:55 +0200 (CEST)
Message-ID: <4E164A1E.8040009@cisco.com>
Date: Fri, 08 Jul 2011 02:06:54 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Juergen Quittek 
References:  <4E142BB4.1060103@cisco.com>	 <4E144069.70000@cisco.com> <7B683350-C40C-4C3B-9200-0CA1E821BDE6@quittek.at>
In-Reply-To: <7B683350-C40C-4C3B-9200-0CA1E821BDE6@quittek.at>
Content-Type: multipart/alternative; boundary="------------010603020108080607080802"
Cc: eman mailing list 
Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type ->	domain
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, 08 Jul 2011 00:18:21 -0000

This is a multi-part message in MIME format.
--------------010603020108080607080802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Juergen,
> Hi Benoit,
>
> Am 06.07.2011 um 13:00 schrieb Benoit Claise:
>
>> Hi Juergen,
>>
>> Because the domain is used for identity uniqueness, while the group 
>> goal is helping the reporting
>>
>>
>>       4.1. Identifying powered entities
>>
>>
>>     The energy management standard must provide means for uniquely
>>     identifying powered entities that are monitored or controlled by an
>>     energy management system.  Uniqueness must be given in a domain that
>>     is large enough to avoid collisions of identities at potential
>>     receivers of monitored information.
> Wouldn't in this context the domain be the group of all devices that 
> are managed by the involved
> energy management systems?
I believe that we have too many notions behind domains and groups
     domain = identification uniqueness domain
     domain = the group of all devices that are managed by the 
involved energy management system
     domain = metering domain
     group = arbitrary group

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

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

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



Regards, Benoit.
>
> Thanks,
>
>     Juergen
>
>> Regards, Benoit.
>>> Hi Benoit,
>>>
>>> OK, for me a domain is a group of entities.
>>> A domain could be
>>>    - "4th floor": all energy consumers on the 4th floor of a building
>>>    - "desktop phones": all desktop phone in an enterprise
>>>    - "Fuse 321": all powered entities receiving power via main fuse 123 in the energy distribution tree
>>>    - "meter 7": all entities that are metered by power meter 7
>>> There are  certainly many more examples.
>>> Why would a domain not be a group of entities?
>>>
>>> Thanks,
>>>
>>>      Juergen
>>>
>>> Am 06.07.2011 um 11:32 schrieb Benoit Claise:
>>>
>>>> Hi Juergen,
>>>>
>>>> Not exactly.
>>>>
>>>> There are actually two different concepts
>>>> 1. the domain
>>>> 2. grouping of powered entities. Practically, this is done with the keyword list in [EMAN-AWARE]
>>>>
>>>> The requirement 5.1.2 covers "grouping of powered entities"
>>>> We're missing in section 4 a requirement such as:
>>>>
>>>>    The energy management standard must provide means for identifying the domain to which the
>>>>    powered entity belongs.
>>>>
>>>> Regards, Benoit.
>>>>> Hi Benoit,
>>>>>
>>>>> This requirement is already in the draft:
>>>>>
>>>>>> 5.1.2.  Grouping of powered entities
>>>>>>
>>>>>>     The energy management standard must provide means for grouping
>>>>>>     powered entities, for example, into energy monitoring domains, energy
>>>>>>     control domains, power supply domains, groups of entities of the same
>>>>>>     type, etc.
>>>>> Does it cover what you are looking for?
>>>>>
>>>>> Thanks,
>>>>>
>>>>>      Juergen
>>>>>
>>>>>
>>>>> Am 01.07.11 16:09 schrieb "Benoit Claise" unter:
>>>>>
>>>>>>    Dear all,
>>>>>>
>>>>>>   Specifically dealing with the domain...
>>>>>>
>>>>>>
>>>>>> 4.1.  Identifying powered entities
>>>>>>     The energy management standard must provide means for uniquely
>>>>>>     identifying powered entities that are monitored or controlled by an
>>>>>>     energy management system.  Uniqueness must be given in a domain that
>>>>>>     is large enough to avoid collisions of identities at potential
>>>>>>     receivers of monitored information.
>>>>>>   Since the domain is mentioned here, isn't it a case for a specific
>>>>>> requirement regarding the domain?
>>>>>>
>>>>>>   Regards, Benoit.
>>>>>>
>>>>>>> Hi Mouli,
>>>>>>>
>>>>>>> I'm glad you comment on this. It was too vague so far.
>>>>>>> Please see plies inline.
>>>>>>>
>>>>>>> Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan):
>>>>>>>
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> As Juergen has mentioned, while the first version has been released to
>>>>>>>> solicit feedback, some of the concepts are still debated.
>>>>>>>> The perspectives from the email list would be useful to shape the draft.
>>>>>>>>
>>>>>>>> I shall post some of the discussion points.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Mouli
>>>>>>>>
>>>>>>>> ------------
>>>>>>>>
>>>>>>>> There is a requirement -
>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>>>>>>>
>>>>>>>>
>>>>>>>> 5.1.1.  Type of powered entity
>>>>>>>>
>>>>>>>>    The energy management standard must provide means to retrieve and
>>>>>>>>    report the type of powered entities.
>>>>>>>>
>>>>>>>> I think it would be useful to expand this requirement. Device Type could
>>>>>>>> be inferred as "IP Phone" or "Line Card 3", ...
>>>>>>>>
>>>>>>> Yes. The question is what is needed?
>>>>>>>
>>>>>>>
>>>>>>>> One possibility is to consider is a description of the device and then
>>>>>>>> the type of device.
>>>>>>>>
>>>>>>>> Powered Devices Description
>>>>>>>>
>>>>>>>>    The energy management standard must provide means for identifying the
>>>>>>>>    entity with a powered device description, the domain to which the
>>>>>>>>    device belongs
>>>>>>>>
>>>>>>> Is this two in one (description and domain)?
>>>>>>>
>>>>>>> What would be the requirement for a "description"?
>>>>>>> Offering a text string for descriptions where arbitrary content can be
>>>>>>> entered?
>>>>>>>
>>>>>>> I don't think the domain should be part of the device description-
>>>>>>>
>>>>>>>
>>>>>>>> Powered Entity Type
>>>>>>>>
>>>>>>>>    The energy management standard must provide means to identify the
>>>>>>>>    powered device type such as consumer, provider, meter.
>>>>>>>>
>>>>>>> It's still vague. What are device types?
>>>>>>> Is there a fixed list? Is it maintained by IANA?
>>>>>>> Is it a string where operators may enter arbitrary types?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>      Juergen
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From:eman-bounces@ietf.org  [mailto:eman-bounces@ietf.org] On Behalf Of
>>>>>>>> Juergen Quittek
>>>>>>>> Sent: Thursday, June 30, 2011 2:56 PM
>>>>>>>> To: eman mailing list
>>>>>>>> Subject: Re: [eman] New draft on eman requirements
>>>>>>>>
>>>>>>>> Dear all,
>>>>>>>>
>>>>>>>> I am sorry for posting another version just one day after the previous
>>>>>>>> one.
>>>>>>>> Now out is version -03 to be found at
>>>>>>>>
>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>>>>>>>
>>>>>>>> The reason was that a change in terminology ("powered device" ->
>>>>>>>> "powered
>>>>>>>> entity") was not done consistently in all sections, particularly not in
>>>>>>>> the
>>>>>>>> battery section.
>>>>>>>>
>>>>>>>> There are no further changes, particularly no technical changes compared
>>>>>>>> to
>>>>>>>> the previous version.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>>     Juergen
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>
>


--------------010603020108080607080802
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    Hi Juergen,

    
Hi Benoit,
      


      

      

        

          
Am 06.07.2011 um 13:00 schrieb Benoit Claise:

          

          

            
 Hi Juergen,

              

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

              
4.1.  Identifying powered entities

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

            

          

          
Wouldn't in this context the domain be the group of all
            devices that are managed by the involved 

          
energy management systems?

        

      

    

    I believe that we have too many notions behind domains and groups

        domain = identification uniqueness domain

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

        domain = metering domain

        group = arbitrary group

    

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

    

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

    
        1. Length and format of PowerMonitorId. The pmPowerMonitorID
          should be a unique id that identfies the device in the
          universe. A UUID using RFC 4122 seems to suffice. However an
          x.509 certificate conforming to RFC 5280 could also be
          appropriate. We have specified the field as variable 16 bytes
          but would like feedback and consensus on the format that is
          appropriate.

    

    

    Regards, Benoit.

    

      

        

          


          

          
Thanks,

          


          

          
    Juergen

          


          

          

            
 Regards, Benoit.

              

                
Hi Benoit,

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

Thanks,

    Juergen

Am 06.07.2011 um 11:32 schrieb Benoit Claise:



                

                  
Hi Juergen,

Not exactly.

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

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

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

Regards, Benoit.


                  

                    
Hi Benoit,

This requirement is already in the draft:



                    

                      
5.1.2.  Grouping of powered entities

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


                    

                    
Does it cover what you are looking for?

Thanks,

    Juergen


Am 01.07.11 16:09 schrieb "Benoit Claise" unter<bclaise@cisco.com>:



                    

                      
  Dear all,

 Specifically dealing with the domain...


4.1.  Identifying powered entities
   The energy management standard must provide means for uniquely
   identifying powered entities that are monitored or controlled by an
   energy management system.  Uniqueness must be given in a domain that
   is large enough to avoid collisions of identities at potential
   receivers of monitored information.
 Since the domain is mentioned here, isn't it a case for a specific
requirement regarding the domain?

 Regards, Benoit.



                      

                        
Hi Mouli,

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

Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan):




                        

                          
Hello,

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

I shall post some of the discussion points.

Thanks
Mouli

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

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


5.1.1.  Type of powered entity

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

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



                        

                        
Yes. The question is what is needed?




                        

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

Powered Devices Description

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



                        

                        
Is this two in one (description and domain)?

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

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




                        

                          
Powered Entity Type

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



                        

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

Thanks,

    Juergen




                        

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

Dear all,

I am sorry for posting another version just one day after the previous
one.
Now out is version -03 to be found at

http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt

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

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

Thanks,

   Juergen

_______________________________________________
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


                    

                  

                

              

              

            

          

        

        

      

    

    

  


--------------010603020108080607080802--

From bnordman@lbl.gov  Thu Jul  7 23:30:21 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED3A21F8917 for ; Thu,  7 Jul 2011 23:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.604
X-Spam-Level: 
X-Spam-Status: No, score=-5.604 tagged_above=-999 required=5 tests=[AWL=0.372,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAsgRQV3jm-H for ; Thu,  7 Jul 2011 23:30:20 -0700 (PDT)
Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 95C4321F890B for ; Thu,  7 Jul 2011 23:30:17 -0700 (PDT)
X-Ironport-SBRS: 5.2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArUBAPSiFk7RVdy0mGdsb2JhbABNBoJRnF4BiAoIFAEBAQEBCAkNBxQlsBqcSAKDOoJ8BIdMiwCMLjyDeg
X-IronPort-AV: E=Sophos;i="4.65,498,1304319600"; d="scan'208";a="46044969"
Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport3.lbl.gov with ESMTP; 07 Jul 2011 23:30:16 -0700
Received: by mail-vx0-f180.google.com with SMTP id 7so2254530vxd.39 for ; Thu, 07 Jul 2011 23:30:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.110.133 with SMTP id ia5mr2255049vdb.239.1310106616441; Thu, 07 Jul 2011 23:30:16 -0700 (PDT)
Received: by 10.52.161.8 with HTTP; Thu, 7 Jul 2011 23:30:16 -0700 (PDT)
In-Reply-To: <20110525155303.GA20245@elstar.local>
References: <20110330091150.GB29695@elstar.local>      <20110525155303.GA20245@elstar.local>
Date: Thu, 7 Jul 2011 23:30:16 -0700
Message-ID: 
From: Bruce Nordman 
To: eman@ietf.org
Content-Type: multipart/alternative; boundary=bcaec54861aa7daaa404a788f785
Subject: Re: [eman] js review of draft-claise-energy-monitoring-mib-07
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, 08 Jul 2011 06:30:21 -0000

--bcaec54861aa7daaa404a788f785
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 25, 2011 at 8:53 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> ...
>
> Interesting would be situations where network activity causes many
> systems to change state simulaneously and even worse causes subsequent
> synchronization of the following power state changes.
>
> /js
>
(coming to this thread very late)

Years ago I pondered the risk to the electricity grid of an earthquake
(I do live in California) triggering many occupancy sensors for
lighting at the same time causing a sharp jump in power demand
in a region that could destabilize the grid.  It turns out earthquakes
actually move relatively slowly (closer to the speed of sound) and
so this not a risk.

However, an attack which woke up many PCs (or similar devices)
at the same time with network traffic could accomplish such an
instantaneous increase.  Even if the packets were subsequently
ignored by the PC when awake, the fact of powering up from sleep
would still happen.

I don't think EMAN makes this potential problem worse than it
already is.

--Bruce

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



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

--bcaec54861aa7daaa404a788f785
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Wed, May 25, 2011 at 8:53 AM, Juergen=
 Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote=
:


...




Interesting would be situations where network activity causes many
systems to change state simulaneously and even worse causes subsequent

synchronization of the following power state changes.




/js
(coming to this thread very late)



Years ago I pondered the risk to the electricity grid of an earthquake

(I do live in California) triggering many occupancy sensors for

lighting at the same time causing a sharp jump in power demand

in a region that could destabilize the grid.=A0 It turns out earthquakes
actually move relatively slowly (closer to the speed of sound) and

so this not a risk.



However, an attack which woke up many PCs (or similar devices)

at the same time with network traffic could accomplish such an

instantaneous increase.=A0 Even if the packets were subsequently

ignored by the PC when awake, the fact of powering up from sleep

would still happen.



I don't think EMAN makes this potential problem worse than it

already is.



--Bruce 



--

Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH
Phone: +49=
 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany

Fax: =A0 +=
49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>

_______________________________________________





-- 
Bruce Nordman
=
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman

BNordman@LBL.gov
510-486-7089
m: 510-501-7943



--bcaec54861aa7daaa404a788f785--

From bnordman@lbl.gov  Fri Jul  8 00:17:45 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5421221F86CA for ; Fri,  8 Jul 2011 00:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.728
X-Spam-Level: 
X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[AWL=0.248,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTXILtcHTt5f for ; Fri,  8 Jul 2011 00:17:44 -0700 (PDT)
Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 94EE421F84F6 for ; Fri,  8 Jul 2011 00:16:51 -0700 (PDT)
X-Ironport-SBRS: 5.2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArUBAOStFk7RVdy0mGdsb2JhbABNBoJRnF4Bhy5cCBQBAQEBAQgJDQcUJYh7pyycRoM8gnwEh0yLAIwuPIN6
X-IronPort-AV: E=Sophos;i="4.65,498,1304319600"; d="scan'208";a="45496192"
Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport4.lbl.gov with ESMTP; 08 Jul 2011 00:16:50 -0700
Received: by vxd7 with SMTP id 7so2296168vxd.39 for ; Fri, 08 Jul 2011 00:16:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.66.199 with SMTP id h7mr2028838vdt.119.1310109410355; Fri, 08 Jul 2011 00:16:50 -0700 (PDT)
Received: by 10.52.161.8 with HTTP; Fri, 8 Jul 2011 00:16:50 -0700 (PDT)
In-Reply-To: <20248561-E87E-4CD0-9E57-E031B00E479A@quittek.at>
References:    <1127B34B-6899-4F1D-966E-ED841E25E554@quittek.at> <4E142A61.3010103@cisco.com> <20248561-E87E-4CD0-9E57-E031B00E479A@quittek.at>
Date: Fri, 8 Jul 2011 00:16:50 -0700
Message-ID: 
From: Bruce Nordman 
To: eman mailing list 
Content-Type: multipart/alternative; boundary=20cf3079b8cc056b9304a7899e49
Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type
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, 08 Jul 2011 07:17:45 -0000

--20cf3079b8cc056b9304a7899e49
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jul 6, 2011 at 4:59 AM, Juergen Quittek  wrote:

> On 06.07.2011  11:26, Benoit Claise wrote:
> ....
>
> Coming back to this requirement
>
> 5.1.1. Type of powered entity
>
> The energy management standard must provide means to retrieve and
> report the type of powered entities.
>
> I believe the "type" is misleading. The main requirement is that we want
> the ability to group powered entities based on something, which could be the
> type, what the type definition you want.
> Therefore, I would remove the requirement 5.1.1 and only keep the current
> 5.1.2
>
> 5.1.2.  Grouping of powered entities
>
>    The energy management standard must provide means for grouping
>    powered entities, for example, into energy monitoring domains, energy
>    control domains, power supply domains, groups of entities of the same
>    type, etc.
>
> I agree. I do not know what an entity type is. So let's remove 5.1.1.
> However, 5.1.2 also talks about entities of the same type :-)
> Shall we remove "type" also here?
>

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

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

Thanks,

--Bruce


>
>


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

--20cf3079b8cc056b9304a7899e49
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Wed, Jul 6, 2011 at 4:59 AM, Juergen =
Quittek <ietf@quitt=
ek.at> wrote:


=

On 06.07.2011 =A011:26, Benoit Claise wrote:
....


Coming back to this requirement

    

    
5.1.1. Type of powered entity

      

      The energy management standard must provide means to retrieve and

      report the type of powered entities.

    I believe the "type" is misleading. The main requirement is t=
hat we
    want the ability to group powered entities based on something, which
    could be the type, what the type definition you want.

    Therefore, I would remove the requirement 5.1.1 and only keep the
    current 5.1.2

    

      
5.1.2.  Grouping of powered entities

   The energy management standard must provide means for grouping
   powered entities, for example, into energy monitoring domains, energy
   control domains, power supply domains, groups of entities of the same
   type, etc.
I agree. I do not =
know what an entity type is. So let's remove 5.1.1.
However, =
5.1.2 also talks about entities of the same type :-)
Shall we rem=
ove "type" also here?



I have to disagree completely on this point.A major barrier to understanding energy use in
buildings and in doing t=
hings to reduce it is
lack of information about what devices are 

present in a building and how much each
one is using.=A0 We are going in=
to great detail
about the quantities of energy, but seem to
want to a=
void saying anything about what
the device actually is.

Accomplis=
hing this and meeting the needs of

energy efficiency need not be burdensome.
Just a few variables can point=
 to a standard
index of device types (or "product types" inmy line of work) and short brand/model
information.

Thanks,


--Bruce
=A0




-- 
Bruce Nordman

Lawrence Berkeley National Laboratory<=
/span>
eetd=
.lbl.gov/ea/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7=
943




--20cf3079b8cc056b9304a7899e49--

From bnordman@lbl.gov  Fri Jul  8 00:24:18 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5300221F8652 for ; Fri,  8 Jul 2011 00:24:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.79
X-Spam-Level: 
X-Spam-Status: No, score=-5.79 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVzsj5yuHvG1 for ; Fri,  8 Jul 2011 00:24:17 -0700 (PDT)
Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 45E8621F87AC for ; Fri,  8 Jul 2011 00:24:17 -0700 (PDT)
X-Ironport-SBRS: 3.8
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtACADCwFk7RVdQ0imdsb2JhbABNBoJRlXoBhmMBiAoIFAEBAQoJDQcSBiGtXIJRnEuDPIJ8BIdMiwCMLjyDeg
X-IronPort-AV: E=Sophos;i="4.65,498,1304319600"; d="scan'208";a="45496397"
Received: from mail-vw0-f52.google.com ([209.85.212.52]) by ironport4.lbl.gov with ESMTP; 08 Jul 2011 00:24:16 -0700
Received: by vws16 with SMTP id 16so2396524vws.39 for ; Fri, 08 Jul 2011 00:24:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.175.170 with SMTP id cb10mr643602vdc.79.1310109854477; Fri, 08 Jul 2011 00:24:14 -0700 (PDT)
Received: by 10.52.161.8 with HTTP; Fri, 8 Jul 2011 00:24:14 -0700 (PDT)
Date: Fri, 8 Jul 2011 00:24:14 -0700
Message-ID: 
From: Bruce Nordman 
To: eman mailing list 
Content-Type: multipart/alternative; boundary=bcaec5101cd77e2e3f04a789b8f9
Subject: [eman] Requirements comments, part I
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, 08 Jul 2011 07:24:18 -0000

--bcaec5101cd77e2e3f04a789b8f9
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Much appreciation to the authors for the considerable
work and progress on this draft.  These comments as
a contributor.  I am posting in three parts due to the
large number of comments.
--Bruce

Part I:

 Terms

=93building energy management=94 infrastructure,

  I would call these =93building management=94 since energy may not be the
primary

  purpose =96 functional considerations are more likely to be primary.  Thi=
s
does

  not preclude that they address energy as part of what they do.

=93building networks=94

  I use this term only to refer to IP networks that include non-electronic
devices

  (e.g. lights, appliances, HVAC, etc.).  I don=92t use it to refer to non-=
IP
control

  systems.  There are a number of suitable terms like =91building automatio=
n
systems=92,

  =91building control systems=92, etc.   Since the eman protocol is indiffe=
rent
to the type

  of device so long at it is IP, we may not need the term =93building netwo=
rk=94
in the

  requirements draft (it should go into the applicability statement though)



General issues

- I think we need to introduce the concept of a device being =93disconnecte=
d=94

  from power.  This is a subset of the Off state.

- Related to this, devices in Off may generally lack network connectivity.

  I think we need to think through options on how to deal with this.

- There may be cases where time or energy is =93missed=94 when devices are

  off, disconnected, and/or reset.  If a device becomes aware that it may

  have missed some time or energy, it could flag the time this occurred.

- I am not sure what =93useful=94 means in the context of requirements.

  I suppose it could be that it is a requirement for the standard, or that

   the feature should be considered but not mandatory.

- I completely agree with the =93entity=94 concept but do think that someti=
mes

  we will want to distinguish between requirements for these, for devices,

  and for components.



2.3 Powered entity

  There may be self-powered devices (e.g. energy harvesting switches or
sensors)
  on the IP network, so these won=92t consume external power.  The qualifie=
r

  =93In general,=94 may be enough to acknowledge this edge case.



3.1 Power States

  I don=92t think that =93full power=94 and =93reduced power=94 are differe=
nt basic
types of

  power states =96 I think they are both forms of the on state.  Identifyin=
g
=93full=94

  separately is arbitrary.  (For something like a computer, =93idle=94 is t=
he
most common

  state so would be the one to call out separately rather than =93full=94)



3.3 Local and network-wide energy management

  I would drop all but first sentence of third paragraph =96 true but not
needed here.


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

--bcaec5101cd77e2e3f04a789b8f9
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Much appreciation to the authors for the considerable
work and progress =
on this draft.=A0 These comments as
a contributor.=A0 I am posting in th=
ree parts due to the
large number of comments.
--Bruce

Part I:=




















<=
font size=3D"2">Terms



=93building energy management=94 infrastruc=
ture, 



=A0 I would call
these =93building management=94 since energy may not be the primary<=
/p>=A0 purpose =96
functional considerations are more likely to be primary.=A0 Th=
is does



=A0 not preclude
that they address energy as part of what they do.



=93building networks=94



=A0 I use this
term only to refer to IP networks that include non-electronic devices



=A0 (e.g. lights,
appliances, HVAC, etc.).=A0 I don=92t
use it to refer to non-IP control



=A0 systems.=A0 T=
here are a number of suitable terms
like =91building automation systems=92,



=A0 =91building
control systems=92, etc.=A0=A0 Since
the eman protocol is indifferent to the type



=A0 of device so
long at it is IP, we may not need the term =93building network=94 in the



=A0 requirements
draft (it should go into the applicability statement though) 



=A0



General issues
<=
span style=3D"font-family: arial,helvetica,sans-serif;">


- I think we need to introduce the concept =
of a device being
=93disconnected=94



=A0 from power.=A0 This is a subset of the Off state.



- Related to this, devices in Off may gener=
ally lack network
connectivity.



=A0 I think we
need to think through options on how to deal with this.



- There may be cases where time or energy i=
s =93missed=94 when
devices are



=A0 off,
disconnected, and/or reset.=A0 If a
device becomes aware that it may



=A0 have missed
some time or energy, it could flag the time this occurred.



- I am not sure what =93useful=94 means in =
the context of
requirements.



=A0 I suppose it
could be that it is a requirement for the standard, or that



=A0=A0 the
feature should be considered but not mandatory.
=



- I completely agree with the =93entity=94 =
concept but do think
that sometimes



=A0 we will want
to distinguish between requirements for these, for devices,



=A0 and for
components.



=A0



2.3 Powered entity



=A0 There may be
self-powered devices (e.g. energy harvesting switches or sensors)

=A0 on the IP network, so these won=92t
consume external power.=A0 The
qualifier 



=A0 =93In general,=94
may be enough to acknowledge this edge case.



=A0



3.1 Power States



=A0 I don=92t think
that =93full power=94 and =93reduced power=94 are different basic types of<=
/font>



=A0 power states =96
I think they are both forms of the on state.=A0 Identifying =
=93full=94



=A0 separately is
arbitrary.=A0 (For something like a
computer, =93idle=94 is the most common



=A0 state so would
be the one to call out separately rather than =93full=94)



=A0



3.3 Local and network-wide energy managemen=
t



=A0 I would drop
all but first sentence of third paragraph =96 true but not needed here.





-- 
Bruce Nordman
Lawrence Berkeley National Laboratoryeetd.lbl.gov=
/ea/nordman

BNordman@LBL.gov
510-486-7089
m: 510-501-7943



--bcaec5101cd77e2e3f04a789b8f9--

From bnordman@lbl.gov  Fri Jul  8 00:25:11 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98BA21F878A for ; Fri,  8 Jul 2011 00:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.827
X-Spam-Level: 
X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=0.149,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHVxKHaLHlXI for ; Fri,  8 Jul 2011 00:25:10 -0700 (PDT)
Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id D88F921F8592 for ; Fri,  8 Jul 2011 00:25:10 -0700 (PDT)
X-Ironport-SBRS: 5.2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArcBALmvFk7RVdy0mGdsb2JhbABFCAaCUZV6AYZjAYgKCBQBAQEBAQgJDQcUJa1BglGcS4MiGoJ8BIdMiwCMLjyDeg
X-IronPort-AV: E=Sophos;i="4.65,498,1304319600"; d="scan'208";a="46046489"
Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport3.lbl.gov with ESMTP; 08 Jul 2011 00:25:10 -0700
Received: by vxd7 with SMTP id 7so2303731vxd.39 for ; Fri, 08 Jul 2011 00:25:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.177.196 with SMTP id cs4mr2281865vdc.279.1310109909711; Fri, 08 Jul 2011 00:25:09 -0700 (PDT)
Received: by 10.52.161.8 with HTTP; Fri, 8 Jul 2011 00:25:09 -0700 (PDT)
Date: Fri, 8 Jul 2011 00:25:09 -0700
Message-ID: 
From: Bruce Nordman 
To: eman mailing list 
Content-Type: multipart/alternative; boundary=20cf3071cbaac8fc3104a789bb21
Subject: [eman] Requirements comments, part II
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, 08 Jul 2011 07:25:11 -0000

--20cf3071cbaac8fc3104a789bb21
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Part II:

 5. Required Information on Powered Entities

  It would be helpful to identify variables that are static vs. those that
are dynamic.

  There are some that are absolutely static, and others that just rarely
change.



5.1.1 Type of powered entity

  Add =93according to some standard classification=94.



5.2 Power State

  I disagree that a device should have multiple power state sets.  This put=
s
the

  burden of translating between sets on the device, when it is much better
put

  on the management system.  In an email from May 3, Juergen S noted:

    =93Traditionally, it was always assumed that an SNMP management system

     can more easily adapt to devices than the other way round.=94

  Also the first three sentences of paragraph four should be dropped.



5.2.1 Actual Power State

  There are transition states, when a device is in the process of moving

  from one long-term stable state to another.  I think this fact should be

  mentioned, though I don=92t think we should attempt to model them.

  The expectation should be that these are mapped into the On state,

  since that will most closely resemble its power levels.



5.3 Power inlet and power outlet

  I am not fond of inlet and outlet but don=92t have a better pair of terms=
 to
suggest.

  Do we anticipate that these may be used for components of devices, or

  only for entire devices?



5.3.4 Availability of power

  In most cases I agree that this is just On or Off.  However, PoE and USB

  (and emerging standards such as UPAMD) have a mode in which only

  a minimal amount of power is provided, to enable a device to request

  more.  So, I propose that a =93Minimum=94 (or similar term) be added as

  a possible third state for this.  This could also apply to control
requirements.



5.4.2 Confidence in power values

  This sounds =93mechanism=94 or =93method=94 rather than =93confidence=94.

  Also, I would combine this with the following accuracy requirement,

  since estimation could vary dramatically in accuracy depending on

  the product.  Or, drop this requirement entirely and stick only to

  accuracy.



5.4.8 Power supply impedance

  I am not an engineer, but is this needed?  I ask since I don=92t remember

  ever seeing it used in my energy efficiency research.  Other metrics such

  as power factor are often raised.



5.4.9 Time series of power values

  The second half of this implies that time series functionality can be

  accomplished by means other than EMAN itself.  I heartily agree.

  This same issue arises in 5.5 and 5.5.2 =96 I think should be outside of
EMAN.



5.5. Energy

  I think the time component of accumulated energy values should be

  relative to the first time the entity is used =96 that is, never reset, s=
o

  not on =93restart=94.  A monitoring system can do any intervaling it want=
s

  to =96 there is no reason to burden or complicate the device, and we don=
=92t

  want to reset the meter else risk great potential confusion.




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

--20cf3071cbaac8fc3104a789bb21
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Part II=
:


















<=
font size=3D"2">5. Required Information on Powered Entities



=A0 It would be
helpful to identify variables that are static vs. those that are dynamic.



=A0 There are some
that are absolutely static, and others that just rarely change.
<=
font style=3D"font-family: arial,helvetica,sans-serif;" size=3D"2">


=A0 



5.1.1 Type of powered entity



=A0 Add =93according
to some standard classification=94.



=A0



5.2 Power State



=A0 I disagree
that a device should have multiple power state sets.=A0 This p=
uts the



=A0 burden of
translating between sets on the device, when it is much better put


=A0 on the
management system.=A0 In an email
from May 3, Juergen S noted:



=A0=A0=A0
=93Traditionally, it was always assumed that an SNMP management syst=
em



=A0=A0=A0=A0
can more easily adapt to devices than the other way round.=94=




=A0 Also the first
three sentences of paragraph four should be dropped.



=A0



5.2.1 Actual Power State



=A0 There are
transition states, when a device is in the process of moving



=A0 from one
long-term stable state to another.=A0
I think this fact should be



=A0 mentioned,
though I don=92t think we should attempt to model them.



=A0 The
expectation should be that these are mapped into the On state,



=A0 since that
will most closely resemble its power levels.



=A0



5.3 Power inlet and power outlet



=A0 I am not fond
of inlet and outlet but don=92t have a better pair of terms to suggest.



=A0 Do we
anticipate that these may be used for components of devices, or
<=
font style=3D"font-family: arial,helvetica,sans-serif;" size=3D"2">


=A0 only for
entire devices?



=A0



5.3.4 Availability of power



=A0 In most cases
I agree that this is just On or Off.=A0
However, PoE and USB



=A0 (and emerging
standards such as UPAMD) have a mode in which only



=A0 a minimal
amount of power is provided, to enable a device to request



=A0 more.=A0 So, I propose=
 that a =93Minimum=94 (or
similar term) be added as



=A0 a possible
third state for this.=A0 This could
also apply to control requirements.



=A0



5.4.2 Confidence in power values



=A0 This sounds
=93mechanism=94 or =93method=94 rather than =93confidence=94.



=A0 Also, I would
combine this with the following accuracy requirement,



=A0 since
estimation could vary dramatically in accuracy depending on



=A0 the product.=A0 Or, dr=
op this requirement entirely and
stick only to



=A0 accuracy.



=A0



5.4.8 Power supply impedance



=A0 I am not an
engineer, but is this needed?=A0 I
ask since I don=92t remember



=A0 ever seeing it
used in my energy efficiency research.=A0
Other metrics such



=A0 as power
factor are often raised.



=A0



5.4.9 Time series of power values



=A0 The second
half of this implies that time series functionality can be



=A0 accomplished
by means other than EMAN itself.=A0 I
heartily agree.



=A0 This same
issue arises in 5.5 and 5.5.2 =96 I think should be outside of EMAN.=




=A0



5.5. Energy



=A0 I think the
time component of accumulated energy values should be 



=A0 relative to
the first time the entity is used =96 that is, never reset, so



=A0 not on
=93restart=94. =A0A monitoring system can
do any intervaling it wants



=A0 to =96 there is
no reason to burden or complicate the device, and we don=92t



=A0 want to reset
the meter else risk great potential confusion.



=A0





-- 
Bruce Nordman
Lawrence Berkeley National La=
boratory
eetd.lbl.gov/ea/nordman

BNordman@LBL.gov
510-486-7089
m: 510-501-7943



--20cf3071cbaac8fc3104a789bb21--

From bnordman@lbl.gov  Fri Jul  8 00:26:01 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91A621F87E8 for ; Fri,  8 Jul 2011 00:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.852
X-Spam-Level: 
X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.124,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHfS0BbI-qWA for ; Fri,  8 Jul 2011 00:26:00 -0700 (PDT)
Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFFC21F87D4 for ; Fri,  8 Jul 2011 00:26:00 -0700 (PDT)
X-Ironport-SBRS: 5.2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArcBADCwFk7RVdy0mGdsb2JhbABNBoJRlXoBhmMBiAoIFAEBAQEBCAkNBxQlrVyCUZxLgzyCfASHTIsAjC48g3o
X-IronPort-AV: E=Sophos;i="4.65,498,1304319600"; d="scan'208";a="45496442"
Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport4.lbl.gov with ESMTP; 08 Jul 2011 00:25:59 -0700
Received: by vxd7 with SMTP id 7so2304468vxd.39 for ; Fri, 08 Jul 2011 00:25:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.92.132 with SMTP id cm4mr2424045vdb.266.1310109959236; Fri, 08 Jul 2011 00:25:59 -0700 (PDT)
Received: by 10.52.161.8 with HTTP; Fri, 8 Jul 2011 00:25:59 -0700 (PDT)
Date: Fri, 8 Jul 2011 00:25:59 -0700
Message-ID: 
From: Bruce Nordman 
To: eman mailing list 
Content-Type: multipart/alternative; boundary=20cf307f3358bcadf804a789be48
Subject: [eman] Requirements comments, part III
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, 08 Jul 2011 07:26:01 -0000

--20cf307f3358bcadf804a789be48
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Part III:

 7. Reporting on Other Powered Entities

  We need some additional terms here to streamline the text (and ultimately

  our thinking).  I nominate:

    =93powered entity=94 (which may be =93self-reporting=94)

    =93reporting entity=94 (can be =93self=94 or =93other=94)

    =93other entity=94 (a reporting entity reporting not on itself; likely =
a
different

        term would be better for this)

    =93controlled entity=94, =93controlling entity=94 (section 8.1)

    =93switched entity=94, =93switching entity=94 (section 8.2)



  Also, there are two cases for an =93other entity=94.  One is where the po=
wered

  entity cannot report the value in question itself (either because it can=
=92t
report

  anything, or doesn=92t know the value in question, e.g. when metering is
external).

  The second is where the powered entity can report, but the other entity i=
s

  doing the reporting for some convenience.  We need to be aware of both
even

  if the framework does not need to make the distinction.



  There may be multiple other reporting entities, not just a single one.



  Do components of devices ever report, or do only devices do the reporting=
?

  This seems like an important point.



8. Controlling other powered entities

  Do components ever do controlling or are they ever controlled directly,

  or is it only entire devices that are controlled?



9. Security considerations

  Should there be any discussion of the sensitivity of the content of the

  monitoring data, or only whether the data in general can be accessed

  by unauthorized parties?



12.3 Inlet/outlet combinations

  A socket should not change from inlet to outlet.  There should be both

  logically existing, with at least one always zero.  That they share the
same

  physical wire is not important.



12.4 Aggregation functions

  Yes, there should be requirements for this.  Aggregation is the summing

  across multiple entities.  Reporting this sum is just a normal reporting
operation,

  though reporting an aggregate value is never self-reporting.



12.5 Add defn of =91demand=92?

  No.



12.8

  IEEE 1621, =93Standard for User Interface Elements in Power Control of

  Electronic Devices Employed in Office/Consumer Environments=94,

  2004 (reaffirmed 2009).



  IEEE 802.3az, IEEE LAN/MAN Standards Committee of the IEEE Computer
Society. =93Draft P802.3azTM/D3.0, Draft Standard for Information technolog=
y=97
Telecommunications and information exchange between systems=97Local and
metropolitan area networks=97Specific requirements. Part 3: Carrier Sense
Multiple Access with Collision Detection (CSMA/CD) Access Method and
Physical Layer Specifications Amendment: Media Access Control parameters,
Physical Layers and management parameters for Energy-Efficient Ethernet.=94
(September, 2010)




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

--20cf307f3358bcadf804a789be48
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

P=
art III:


















<=
font size=3D"2">7. Reporting on Other Powered Entities 



=A0 We need some
additional terms here to streamline the text (and ultimately



=A0 our
thinking).=A0 I nominate:



=A0=A0=A0
=93powered entity=94 (which may be =93self-reporting=94)
<=
font size=3D"2">


=A0=A0=A0
=93reporting entity=94 (can be =93self=94 or =93other=94)
=



=A0=A0=A0
=93other entity=94 (a reporting entity reporting not on itself; like=
ly a
different



=A0=A0=A0=A0=A0=A0=A0 term wou=
ld be better for
this)



=A0=A0=A0
=93controlled entity=94, =93controlling entity=94 (section 8.1)



=A0=A0=A0
=93switched entity=94, =93switching entity=94 (section 8.2)


=A0



=A0 Also, there
are two cases for an =93other entity=94.=A0
One is where the powered



=A0 entity cannot
report the value in question itself (either because it can=92t report



=A0 anything, or
doesn=92t know the value in question, e.g. when metering is external).



=A0 The second is
where the powered entity can report, but the other entity is



=A0 doing the
reporting for some convenience.=A0 We
need to be aware of both even



=A0 if the
framework does not need to make the distinction.



=A0



=A0 There may be
multiple other reporting entities, not just a single one.



=A0



=A0 Do components
of devices ever report, or do only devices do the reporting?



=A0 This seems
like an important point.



=A0 



8. Controlling other powered entities



=A0 Do components
ever do controlling or are they ever controlled directly,



=A0 or is it only
entire devices that are controlled?



=A0



9. Security considerations



=A0 Should there
be any discussion of the sensitivity of the content of the



=A0 monitoring
data, or only whether the data in general can be accessed



=A0 by
unauthorized parties?



=A0



12.3 Inlet/outlet combinations



=A0 A socket
should not change from inlet to outlet.=A0
There should be both



=A0 logically
existing, with at least one always zero.=A0
That they share the same



=A0 physical wire
is not important.



=A0



12.4 Aggregation functions



=A0 Yes, there
should be requirements for this.=A0
Aggregation is the summing



=A0 across
multiple entities.=A0 Reporting this
sum is just a normal reporting operation,



=A0 though
reporting an aggregate value is never self-reporting.



=A0



12.5 Add defn of =91demand=92?



=A0 No.



=A0



12.8



=A0 IEEE 1621, =93Standard
for User Interface Elements in Power Control of 



=A0 Electronic
Devices Employed in Office/Consumer Environments=94, 



=A0 2004
(reaffirmed 2009).



=A0



=A0 IEEE 802.3az, IEEE
LAN/MAN Standards Committee of the IEEE Computer Society. =93Draft
P802.3azTM/D3.0, Draft Standard for Information technology=97 Telecommunica=
tions
and information exchange between systems=97Local and metropolitan area
networks=97Specific requirements. Part 3: Carrier Sense Multiple Access wit=
h
Collision Detection (CSMA/CD) Access Method and Physical Layer Specificatio=
ns
Amendment: Media Access Control parameters, Physical Layers and management
parameters for Energy-Efficient Ethernet.=94 (September, 2010)



=A0





-- 
Bruce Nordma=
n
Lawrence Berkeley Nati=
onal Laboratory
eetd.lbl.gov/ea/nordman

BNordman@LBL.gov
510-486-7089
m: 510-501-7943



--20cf307f3358bcadf804a789be48--

From ietf@quittek.at  Fri Jul  8 01:46:40 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D66921F876D for ; Fri,  8 Jul 2011 01:46:40 -0700 (PDT)
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=-2.307,  BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhc0wezuGaPM for ; Fri,  8 Jul 2011 01:46:39 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7394121F874F for ; Fri,  8 Jul 2011 01:46:39 -0700 (PDT)
Received: from [10.7.0.92] (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0LpNZt-1R8xkO2ItB-00fBhY; Fri, 08 Jul 2011 10:46:38 +0200
References: <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at>  <9C329342B62B87498B92834DEC9FF51E0D238F6F@fig.raritan.com>
In-Reply-To: <9C329342B62B87498B92834DEC9FF51E0D238F6F@fig.raritan.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: 
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Fri, 8 Jul 2011 10:46:37 +0200
To: Michael Suchoff 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:b7CqKgH9yKbskL9HxCchkJEf9glk5Ng1MWUADrbb/qT 2cUcdJdP/lbo/WuTq8vr/ubQhfX/Gwg7EhtpB4y/D0aGPxeZYS /jLdeyo2ChXYHXJ/xbpisieR6W8vVbpGIgMtdMzHkyEEPgVsHh 2SJIvbjQnXySgA7n6G2yooNaKw7Vojb/z1SYnH69MAR0nSBUbP 1A/Ub/qm/mdm56CHKB+OQ==
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Jul 2011 08:46:40 -0000

Dear Michael,

You are absolutely right.=20
And I wrote the same story already in an earlier message:

For AC power measurement there is always a reporting interval.

Thanks,

    Juergen

Am 07.07.2011 um 17:14 schrieb Michael Suchoff:

> AC power is not reported as an instantaneous value but as an average - =
the minimum averaging time being 1/2 AC cycle.
>=20
> A plot of the instantaneous AC power is a sinusoidal waveform at 2X =
the AC power frequency.  For example, assume V =3D 100V RMS, I =3D 1A =
RMS, F=3D60Hz with power factor 1.0.  The power waveform would be a =
120Hz sinusoidal with amplitude 200 and average value 100.  The average =
value is the active (real) power.
>=20
> The power waveform can be explained mathematically using the product =
to sum formula we learned in high school trigonometry class....
>=20
> Sin(a) * sin(b) =3D .5 * (cos(a-b) - cos(a+b)
>=20
> "a" and "b" are frequency (phase term not shown for simplicity) which =
are identical.  Cos(a-b) =3D 0 which is the real component of power and =
whose average value is shown on a watt meter.  Cos(a+b) is the 2X =
frequency component whose average value is 0.
>=20
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of JinHyeock Choi
> Sent: Wednesday, July 06, 2011 11:09 PM
> To: Juergen Quittek
> Cc: eman mailing list
> Subject: Re: [eman] Comments on eman requirements
>=20
> Dear Juergen
>=20
> thanks for kind and thoughtful reply.
>=20
>>> 1. Clarification of 'Power' and 'Energy'
>>>=20
>>> Energy management concerns both 'power' and 'energy' and
>>> now the term 'energy consmption' is used for both,
>>> and sometimes brings forth confusion.
>>>=20
>>> Maybe we can make it more clear
>>> by attaching the unit to be measured (either watt or watthour).
>>> For example such as
>>> "amount of consumed energy measured by joule or watthour."
>>=20
>> I see your point. The alternative would be adding a clarification to
>> the terminology section. What about appending
>>=20
>>   However, in this document the term "consumed energy" always refers
>>   to an energy quantity and not to a power quantity.
>>=20
>> to section 2.1 Energy?
>=20
> fine with me.
>=20
> Sometimes people have trouble distinguishng 'power' and 'energy'
> at least that's the case for me.
> (it has been a long while since I pored over Physics textbook.)
>=20
> Though 'power' and 'energy' have different meanings
> clearly defined in Physics,
> their everyday usage can be intermingling
> such as 'power efficiency' and 'energy efficiency'
>=20
>>> 2. Power/ Energy and Time
>>> Both power and energy are time dependent parameter.
>>>=20
>>> When reporting 'power' or 'energy' value,
>>> i) a specific moment or ii) a time interval
>>> with which the measurement is made also should be provided.
>>=20
>> Yes, that's a good point. I think for energy measurements this is =
covered
>> by requirement 5.5.2.  Time intervals, but for power monitoring this =
is missing.
>>=20
>> What about adding the following requirement?
>> 5.4.2.  Power measurement interval
>>=20
>>   The energy management standard must provide means for reporting the
>>   corresponding time interval for which a power value is reported.  A
>>   time interval can be very short for reporting approximations of
>>   instantaneous power or rather long for reporting demand values.
>=20
> In principle,
> power itself is an instantateous value
> and measured at a moment (not over interval).
>=20
> So how about rephrasing
>=20
>    The energy management standard must provide means for reporting the
>    corresponding time or time interval for which a power value is =
reported.
>    The power value can be measured at the corresponding time or =
averaged
>    over the corresponding time interval.
>=20
>>> 3. Power state and Energy consumption
>>>=20
>>>> 5.5.3. Energy per power state
>>>>=20
>>>> The energy management standard must provide means for reporting the
>>>> consumed energy individually for each power state.
>>>=20
>>> Energy consumption depends on
>>> not only 'power state' but also 'traffic load'.
>>>=20
>>> To make sense out of the monitored 'power' or 'energy' value,
>>> energy management system should also take into consideration
>>> corresponding  'traffic rate (measured by bps)' or 'accumulated
>>> traffic (measured by bits)'.
>>>=20
>>> Otherwise it can't determine
>>> whether high power consumption is from low energy efficiency
>>> or high data traffic.
>>=20
>> What would be the requirement?
>=20
> How about
>=20
>    The energy management standard must provide means for reporting the
>    consumed energy individually for each power state,
>    with which enegy management system can derive an average expected
>    energy consumption for each power state.
>=20
> to clarify the reason behind per-power state reporting
>> A comment on the issue:
>> Proportionality between traffic and energy is a tricky thing.
>> I read reports on measurements at low-end routers that show
>> decreasing energy consumption with increasing traffic.
>=20
> Interesting.
> Power consumption remaining the same irrespective of traffic load
> is not unusual but power consumption inversely proportional
> to traffic load is a novelty.
> Can you give me a pointer?
>=20
>>> 4. Power profile of powered entity
>>>=20
>>> For the above purpose, it would be of help
>>> for energy management system to be aware of
>>> the energy efficiency of each powered device (or entity),
>>> i.e. how much energy (joule) each device consumes per bit.
>>>=20
>>> Ideally energy efficiency would be provided as
>>> a power profile (or power model), a function
>>> which maps served traffic (bits or bps) into consumed energy (joule/ =
watt).
>>>=20
>>> I recommend
>>> energy efficiency or power profile
>>> to be included to the required information in Sec 5.
>>=20
>> This would be a requirement for switches, routers, etc. only.
>> For PCs, displays, light bulbs, it would not be applicable.
>=20
> I see.
>=20
>> Would it not be sufficient to just report the power and have the =
joule/bit
>> be computed by a management system that reads the interface MIB =
modules
>> if available?
>=20
> ok.
>=20
> For energy management,
> power profile would be needed
> but maybe better be acquired indirectly
> via a kind of resolution scheme.
>=20
>>>> 4.2. Identifying components of powered devices
>>>>=20
>>>> The energy management standard must provide means for identifying =
not
>>>> just entire devices as powered entities, but also individual
>>>> components of powered devices.
>>>=20
>>> Shall we also identify (or represent) the (subordinate) relationship
>>> between powered device and its individual components?
>>=20
>> There are already standards for this available.
>> Shall we still make a requirement out of it in order to clarify that =
this is
>> needed for energy management as well?
>=20
> Such representatin of subordinate relationship would be useful
> but I'm not sure about making it a requirement.
> If WG doesn't have a strong opinion about it,
> let's leave it as it is. :-)
>=20
>>>> 5.2.6. Maximum and average power per power state
>>>>=20
>>>> The energy management standard must provide means for retrieving =
the
>>>> maximum power and the average power as a typically static property
>>>> for each supported power state.
>>>=20
>>> Average power in which sense?
>>> Just a arithmetic mean value between maximum and minimum power?
>>=20
>> I was thinking about the average expected energy consumption in a =
particular power state.
>> I admit that this may be difficult to predict.
>=20
> yes,
> even at the same power state,
> enrgy consumption can vary substantially depending on traffic load.
>=20
>> But before asking an entity to switch to another
>> power state it would make sense to have information about the chances =
of saving power
>> and for avoiding to bring the device into a state that even consumes =
more power.
>=20
> agree.
>=20
>>>> 5.4. Power
>>>>=20
>>>> For some network management tasks, it is required to obtain time
>>>> series of power values (or energy consumption values).
>>>=20
>>> I assume energy consumption value measured by watt.
>>> Am I right?
>>=20
>> No here it is either or: power or energy time series. But I see this =
is confusing.
>> What about removing "(or energy consumption values)"?
>=20
> ok. thanks for clarificaiton.
>=20
>>>> 5.5. Energy
>>>>=20
>>>> In order to monitor energy consumption in different power states, =
it
>>>> is useful if entities record their energy consumption per power =
state
>>>> and report these quantities.
>>>=20
>>> Energy consumption varies according to power state and traffic load.
>>> How do you take 'traffic load' into consideration?
>>=20
>> We do not have any generic term for load. If you can provide one, =
please send it.
>=20
> 'bps' or '(accumulated) bit' would do for network equipments
> such as router or switich.
>=20
> However, for more generic work load,
> I don't have a good idea.
>=20
>>> Energy would be measured over time interval.
>>>=20
>>> Would time series of energy values be measured
>>> over the sequence of time intervals in 5.5.2?
>>=20
>> Yes. There are different ways to do so.
>>=20
>> A time series can contain values that give the total energy since the =
last re-start
>> up to an indicated measurement time. Alternatively, you can have time =
series of energy
>> consumption for consecutive time intervals, one value each. Or you =
can have this for
>> overlapping time intervals. 5.5.2 shows all of them.
>=20
> ok.
>=20
> Please allow me to split hairs
> cocnerning the terms 'series' and 'sequence'
> which are currently both used in in 5.5.2 and 5.5.4.
>=20
> Precisely speaking, in mathematics,
> 'series' is the sum of the terms of 'sequence',
> so in our context, 'sequence' is better.
>=20
> Bets regards
>=20
> JinHyeock
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From ietf@quittek.at  Fri Jul  8 02:25:12 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6B021F88FE for ; Fri,  8 Jul 2011 02:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level: 
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.357,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 AMSWlG4wy-KP for ; Fri,  8 Jul 2011 02:25:12 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id D47FF21F88E6 for ; Fri,  8 Jul 2011 02:25:11 -0700 (PDT)
Received: from [10.7.0.92] (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MAulY-1QmqX241oa-00A1ok; Fri, 08 Jul 2011 11:25:10 +0200
References:  <4E142BB4.1060103@cisco.com>	 <4E144069.70000@cisco.com> <7B683350-C40C-4C3B-9200-0CA1E821BDE6@quittek.at> <4E164A1E.8040009@cisco.com>
In-Reply-To: <4E164A1E.8040009@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-11--1050056715
Message-Id: <697CB07B-406F-40E1-8EEC-4DA9B4ED8C0C@quittek.at>
From: Juergen Quittek 
Date: Fri, 8 Jul 2011 11:25:08 +0200
To: Benoit Claise 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:ZbC1W868PsOocSPeDEQ0XhPsoBt+OcGZgsjC5IrZb1l rxJ7nTu5qxFl/9HO4Xo5rOFUCFB4WeO/etE1wfWYEqIaGgo7Ol C0o7rI2G/PkLF8V9ye2QliZqURSzUrSRc6CKJCQmCb0vNsVUa/ Brug11zLt836GC7PLd6vn+S16CROz6AVJw4yICHPO0AzDkaV3Z dNJe6FY2d8g/G3fR5P9TA==
Cc: eman mailing list 
Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type ->	domain
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, 08 Jul 2011 09:25:13 -0000

--Apple-Mail-11--1050056715
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Benoit,

Am 08.07.2011 um 02:06 schrieb Benoit Claise:

> Hi Juergen,
>> Hi Benoit,
>>=20
>> Am 06.07.2011 um 13:00 schrieb Benoit Claise:
>>=20
>>> Hi Juergen,
>>>=20
>>> Because the domain is used for identity uniqueness, while the group =
goal is helping the reporting
>>> 4.1.  Identifying powered entities
>>>=20
>>>=20
>>>    The energy management standard must provide means for uniquely
>>>    identifying powered entities that are monitored or controlled by =
an
>>>    energy management system.  Uniqueness must be given in a domain =
that
>>>    is large enough to avoid collisions of identities at potential
>>>    receivers of monitored information.
>> Wouldn't in this context the domain be the group of all devices that =
are managed by the involved=20
>> energy management systems?
> I believe that we have too many notions behind domains and groups
>     domain =3D identification uniqueness domain

Sorry, I don't know what this is.

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

That would be a domain.
>     domain =3D metering domain

That's another domain.

>     group =3D arbitrary group

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

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

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

Thanks,

    Juergen


--Apple-Mail-11--1050056715
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
Benoit,

Am 08.07.2011 um 02:06 schrieb Benoit =
Claise:




    Hi Juergen,

    
Hi Benoit,
      


      

      

        

          
Am 06.07.2011 um 13:00 schrieb Benoit Claise:

          

          

            
 Hi Juergen,

              

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

              
4.1.  Identifying =
powered entities

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

            

          

          
Wouldn't in this context the domain be the group of all
            devices that are managed by the involved 

          
energy management systems?

        

      

    

    I believe that we have too many notions behind domains and =
groups

        domain =3D identification uniqueness =
domain

Sorry, I don't know what =
this is.


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

That would be a =
domain.

        domain =3D metering =
domain

That's another =
domain.


        group =3D arbitrary =
group

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

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

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

Thanks,

 &nbs=
p;  Juergen

=

--Apple-Mail-11--1050056715--

From internet-drafts@ietf.org  Fri Jul  8 03:04:43 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B2921F8902; Fri,  8 Jul 2011 03:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.582
X-Spam-Level: 
X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 zozgwAyaj5Q0; Fri,  8 Jul 2011 03:04:42 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D2921F88FE; Fri,  8 Jul 2011 03:04:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.55
Message-ID: <20110708100442.13560.19622.idtracker@ietfa.amsl.com>
Date: Fri, 08 Jul 2011 03:04:42 -0700
Cc: eman@ietf.org
Subject: [eman] I-D Action: draft-ietf-eman-framework-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: Fri, 08 Jul 2011 10:04:43 -0000

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

	Title           : Energy Management Framework
	Author(s)       : Benoit Claise
                          John Parello
                          Brad Schoening
                          Juergen Quittek
	Filename        : draft-ietf-eman-framework-02.txt
	Pages           : 39
	Date            : 2011-07-08

        This document defines a framework for providing Energy
        Management for devices within or connected to communication
        networks.  The framework defines a domain of Energy Management
        devices that is a logical unit of Energy Management. Within a
        domain each device is identified, classified and given context.
        Devices can be monitored and/or controlled with respect to
        power, power state, energy, demand, electrical quality, and
        battery.  Additionally the framework models relationships and
        capabilities between devices in a domain.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eman-framework-02.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-eman-framework-02.txt

From jparello@cisco.com  Fri Jul  8 06:19:03 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32F621F89E9 for ; Fri,  8 Jul 2011 06:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level: 
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=2.500,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7U-l2IPTdK1 for ; Fri,  8 Jul 2011 06:19:03 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2092921F89E8 for ; Fri,  8 Jul 2011 06:19:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=1371; q=dns/txt; s=iport; t=1310131143; x=1311340743; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=LVDi2UMw4/GYFR6AmYBJumvb6erHpUjYA9LtaTCDb9s=; b=EK8rBF0pjdf5LQB46265d4Ix0DyCcxRhK7e75TauRdgezZKPKQLydz/M aebjGBHhCKJEwoCbVlky/n7Yn1QVCskGGIP1qG24I918KPB6SwromPbHO w6EekkVixhtPS68+E92uNzUThHQztWvRlS9XlyjXURR5jijpqh9PyzVsp w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAKgCF06rRDoI/2dsb2JhbABTp0V3rFuBIp1/hjgEh0yQBote
X-IronPort-AV: E=Sophos;i="4.65,499,1304294400";  d="scan'208";a="1035245"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-4.cisco.com with ESMTP; 08 Jul 2011 13:19:02 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p68DJ2YN008317 for ; Fri, 8 Jul 2011 13:19:02 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 8 Jul 2011 06:19:02 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 8 Jul 2011 06:14:08 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New Version Notification for draft-ietf-eman-framework-02.txt
Thread-Index: Acw9cOu5UXbNqAzHSJydyR8zQQAKxg==
From: "John Parello (jparello)" 
To: "eman mailing list" 
X-OriginalArrivalTime: 08 Jul 2011 13:19:02.0142 (UTC) FILETIME=[9A9C11E0:01CC3D71]
Subject: [eman] New Version Notification for draft-ietf-eman-framework-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: Fri, 08 Jul 2011 13:19:03 -0000

Hi All,

We have posted a new draft of the framework. The access details are
below.

This draft contains considerable revisions and changes to align with the
requirements draft and the two mib drafts that are in progress.

We also incorporated items that were discussed on the list such as
multiple power state sets, terminology and alignment with other
standards such as ISO50001.

Some open issues are:

- Alignment with use cases in the applicability statement (or any use
cases from your work)
- Alignment with IPFIX
- Feedback as to whether more UML / use case references are needed
- Power Monitor renamed to Energy Managed Object
- We use a term Power Quality but is Electrical Characteristics more
appropriate
- Coverage of capabilities and relationships are appropriate for your
types of devices and use

Thanks to everyone on the list discussions and all the work from the
authors.

Your advice and feedback on the open issues and any other aspects of the
doc are greatly appreciated.

Thanks
John
-------------

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eman-framework-02.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-eman-framework-02.txt

From jparello@cisco.com  Fri Jul  8 06:29:23 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD7221F8A6E for ; Fri,  8 Jul 2011 06:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.349
X-Spam-Level: 
X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=1.250,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+NTnplHM0J5 for ; Fri,  8 Jul 2011 06:29:22 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 57C4321F8A6B for ; Fri,  8 Jul 2011 06:29:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=1930; q=dns/txt; s=iport; t=1310131762; x=1311341362; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=cjJJOXtpt6FmkQEcxWUPLQgoDf84Uxu5W5CHvfzD4nM=; b=fwaYu+G4gnX8bTqMo1zKJSvBUbC+g/DjE69yUqPbI+qZQfaYUDhlLPjV 8moHq0iPKm6eysdMJTKPPO2zU8Hv5NvIFWXj0mxIkuG0kPgLUr6KzKpRF jdJwN1Lr5Lc70q23SLVl2QCESoy1zIyU/6OmkfK9tQLmQ/Ug4ck+N7kXY s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvUAAEgFF06rRDoI/2dsb2JhbABTmA6PN3etfJ19hjgEh0yQBote
X-IronPort-AV: E=Sophos;i="4.65,499,1304294400";  d="scan'208";a="1039914"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-7.cisco.com with ESMTP; 08 Jul 2011 13:29:21 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p68DTLpt016946 for ; Fri, 8 Jul 2011 13:29:21 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 8 Jul 2011 06:29:21 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 8 Jul 2011 06:24:24 -0700
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] New Version Notification for draft-ietf-eman-framework-02.txt
Thread-Index: Acw9cOu5UXbNqAzHSJydyR8zQQAKxgAAQROg
References: 
From: "John Parello (jparello)" 
To: "eman mailing list" 
X-OriginalArrivalTime: 08 Jul 2011 13:29:21.0317 (UTC) FILETIME=[0BAAAD50:01CC3D73]
Subject: [eman] New Version Notification for draft-ietf-eman-framework-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: Fri, 08 Jul 2011 13:29:23 -0000

Hi,

Also please note:

- The terminology section contains concise definitions for terms and the
parts of the framework
- We have a more detailed description of the relationships between
Energy Managed Objects=20
- The Parent / Child pattern we first introduced has been more clearly
defined to incorporate the types of relationships=20

Thanks
Jp

-----Original Message-----
From: John Parello (jparello)=20
Sent: Friday, July 08, 2011 6:14 AM
To: eman mailing list
Subject: New Version Notification for draft-ietf-eman-framework-02.txt

Hi All,

We have posted a new draft of the framework. The access details are
below.

This draft contains considerable revisions and changes to align with the
requirements draft and the two mib drafts that are in progress.

We also incorporated items that were discussed on the list such as
multiple power state sets, terminology and alignment with other
standards such as ISO50001.

Some open issues are:

- Alignment with use cases in the applicability statement (or any use
cases from your work)
- Alignment with IPFIX
- Feedback as to whether more UML / use case references are needed
- Power Monitor renamed to Energy Managed Object
- We use a term Power Quality but is Electrical Characteristics more
appropriate
- Coverage of capabilities and relationships are appropriate for your
types of devices and use

Thanks to everyone on the list discussions and all the work from the
authors.

Your advice and feedback on the open issues and any other aspects of the
doc are greatly appreciated.

Thanks
John
-------------

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eman-framework-02.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-eman-framework-02.txt

From bclaise@cisco.com  Fri Jul  8 08:43:11 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECC321F8AEE for ; Fri,  8 Jul 2011 08:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.575
X-Spam-Level: 
X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RWyez6-lHU3 for ; Fri,  8 Jul 2011 08:43:11 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3253221F8AE7 for ; Fri,  8 Jul 2011 08:43:11 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p68Fh8wW005077 for ; Fri, 8 Jul 2011 17:43:08 +0200 (CEST)
Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p68Fh7Vb024854 for ; Fri, 8 Jul 2011 17:43:08 +0200 (CEST)
Message-ID: <4E17258C.6040302@cisco.com>
Date: Fri, 08 Jul 2011 08:43:08 -0700
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: eman mailing list 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [eman] agenda items for EMAN WG 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: Fri, 08 Jul 2011 15:43:12 -0000

Dear all,

Please let the list know who will be presenting the different drafts.

Regards, Bruce & Benoit.

From internet-drafts@ietf.org  Sun Jul 10 15:25:30 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC8821F87C3; Sun, 10 Jul 2011 15:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.521
X-Spam-Level: 
X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 NZUNxzu8TjzV; Sun, 10 Jul 2011 15:25:29 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A647921F87A8; Sun, 10 Jul 2011 15:25:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.55
Message-ID: <20110710222529.31341.24418.idtracker@ietfa.amsl.com>
Date: Sun, 10 Jul 2011 15:25:29 -0700
Cc: eman@ietf.org
Subject: [eman] I-D Action: draft-ietf-eman-energy-aware-mib-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, 10 Jul 2011 22:25:30 -0000

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

	Title           : Energy-aware Networks and Devices MIB
	Author(s)       : John Parello
                          Benoit Claise
	Filename        : draft-ietf-eman-energy-aware-mib-02.txt
	Pages           : 29
	Date            : 2011-07-10

        This document defines a subset of the Management Information
        Base (MIB) for power and energy monitoring of devices.  The
        module addresses devices identification, context information,
        and the relationship between reporting devices, remote devices,
        and monitoring probes.

     =


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eman-energy-aware-mib-02.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-eman-energy-aware-mib-02.txt

From Quittek@neclab.eu  Mon Jul 11 04:17:27 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC99021F858E; Mon, 11 Jul 2011 04:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.85
X-Spam-Level: 
X-Spam-Status: No, score=-101.85 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799, 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 vMSMBfxuzggO; Mon, 11 Jul 2011 04:17:27 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id D77BF21F8553; Mon, 11 Jul 2011 04:17:26 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id D143628000213; Mon, 11 Jul 2011 13:17:25 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGNhmiekGWrB; Mon, 11 Jul 2011 13:17:25 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id B5F9E28000174; Mon, 11 Jul 2011 13:16:55 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.22]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 11 Jul 2011 13:16:56 +0200
From: Juergen Quittek 
To: "irtf-discuss@irtf.org" , "ietf@ietf.org" , "irtf-chair@irtf.org" 
Thread-Topic: Bar BOF for IRTF work on energy efficiency
Thread-Index: Acw/vAlXyn6sUzFFFUCPPLipvPwj5Q==
Date: Mon, 11 Jul 2011 11:16:54 +0000
Message-ID: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.10.0.110428
x-originating-ip: [10.1.2.219]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <939614CF3E763A41B780F2533258B57E@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "opsawg@ietf.org" , eman mailing list , "smartpowerdir@ietf.org" 
Subject: [eman] Bar BOF for IRTF work on energy efficiency
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, 11 Jul 2011 11:17:28 -0000

Dear all,

Energy-efficiency is of growing importance for the Internet and thus also
for the IETF.  There is already an IETF WG in the OPS area on energy
management (eman) and in several other WGs people are starting to consider
energy efficiency of the protocols they design.

It looks like energy efficiency has the potential to become a cross topic
affecting many areas we are working on.  But before adding action items on
energy efficiency to IETF WGs it appears to be wise to first investigate th=
e
general problems of IETF protocols concerning energy efficiency.  One
example are keep-alive messages that keep devices from going to sleep mode
even if there are no real service requests.

One way to address the problem is to start general investigations on energy
efficiency in the IRTF.  At http://www.green-communications.net/eerg/ we
make a proposal for a new energy efficiency research group (eerg) in the
IRTF.  Please note that we consider this rather as a proposal for new work
items.  We may find that these are better shared among existing RGs.  But i=
f
not, we would propose establishing a new RG.  There is also a mailing list
at https://listserv.netlab.nec.de/mailman/listinfo/eerg to discuss about
these issues.

For all those of you who are interested in this, we will organize a bar BOF
on Wednesday evening, July 27, after the plenary at 20:15.  The location
will be posted at the web site and on the mailing list mentioned above.  If
you would like to join, please create an entry at the doodle at
http://doodle.com/vvvpbgcmm2r78abi .  This helps organizing a location for
the bar BOF that fits all of us.

Please feel free to forward this announcement to further interested people.

See you at the bar BOF,

    Juergen


From Quittek@neclab.eu  Mon Jul 11 06:18:16 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7133421F8B68 for ; Mon, 11 Jul 2011 06:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.135
X-Spam-Level: 
X-Spam-Status: No, score=-102.135 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 FHp4w0tyN54P for ; Mon, 11 Jul 2011 06:18:15 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 145A421F8B6A for ; Mon, 11 Jul 2011 06:18:14 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7B58A28000305; Mon, 11 Jul 2011 15:18:13 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgLoShbdOGT3; Mon, 11 Jul 2011 15:18:13 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 58B7128000174; Mon, 11 Jul 2011 15:18:03 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.22]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 11 Jul 2011 15:18:03 +0200
From: Juergen Quittek 
To: Bruce Nordman , eman mailing list 
Thread-Topic: [eman] Requirements comments, part I
Thread-Index: AQHMPUAcdpLa2ljbQEqk0dpSKLgmr5TnH2iA
Date: Mon, 11 Jul 2011 13:18:02 +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-Entourage/13.10.0.110428
x-originating-ip: [10.1.2.219]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <2E8E85A0A8FBBA489BDDDA43FD2913C2@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [eman] Requirements comments, part I
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, 11 Jul 2011 13:18:16 -0000

Hi Bruce,

Thanks for your comments.
Please find replies inline.

Am 08.07.11 09:24 schrieb "Bruce Nordman" unter :

> Much appreciation to the authors for the considerable
> work and progress on this draft.  These comments as
> a contributor.  I am posting in three parts due to the
> large number of comments.
> --Bruce
>=20
> Part I:
>=20
>=20
> Terms
> =B3building energy management=B2 infrastructure,
>   I would call these =B3building management=B2 since energy may not be th=
e primary

I removed "energy".

>   purpose =AD functional considerations are more likely to be primary.  T=
his
> does
>   not preclude that they address energy as part of what they do.
> =B3building networks=B2
>   I use this term only to refer to IP networks that include non-electroni=
c
> devices
>   (e.g. lights, appliances, HVAC, etc.).  I don=B9t use it to refer to no=
n-IP
> control
>   systems.  There are a number of suitable terms like =8Cbuilding automat=
ion
> systems=B9,
>   =8Cbuilding control systems=B9, etc.   Since the eman protocol is indif=
ferent to
> the type
>   of device so long at it is IP, we may not need the term =B3building net=
work=B2
> in the
>   requirements draft (it should go into the applicability statement thoug=
h)

I am not sure which further changes to apply. Let's discuss this for
revision -05.

> General issues
> - I think we need to introduce the concept of a device being =B3disconnec=
ted=B2
>   from power.  This is a subset of the Off state.

Yes. Good point. Unfortunately too much for today. I add it as open issue.

> - Related to this, devices in Off may generally lack network connectivity=
.
>   I think we need to think through options on how to deal with this.
> - There may be cases where time or energy is =B3missed=B2 when devices ar=
e
>   off, disconnected, and/or reset.  If a device becomes aware that it may
>   have missed some time or energy, it could flag the time this occurred.
> - I am not sure what =B3useful=B2 means in the context of requirements.
>   I suppose it could be that it is a requirement for the standard, or tha=
t
>    the feature should be considered but not mandatory.

I replaced most occurrences of "useful" with "required".

> - I completely agree with the =B3entity=B2 concept but do think that some=
times
>   we will want to distinguish between requirements for these, for devices=
,
>   and for components.

OK.

> 2.3 Powered entity
>   There may be self-powered devices (e.g. energy harvesting switches or
> sensors)
>   on the IP network, so these won=B9t consume external power.  The qualif=
ier
>   =B3In general,=B2 may be enough to acknowledge this edge case.

OK.

> 3.1 Power States
>   I don=B9t think that =B3full power=B2 and =B3reduced power=B2 are diffe=
rent basic
> types of
>   power states =AD I think they are both forms of the on state.  Identify=
ing
> =B3full=B2
>   separately is arbitrary.  (For something like a computer, =B3idle=B2 is=
 the most
> common
>   state so would be the one to call out separately rather than =B3full=B2=
)

added to the list of open issues.

> 3.3 Local and network-wide energy management
>   I would drop all but first sentence of third paragraph =AD true but not=
 needed
> here.

You may be right. However, this was the results of long discussions among
the authors. Let's keep it for now and discuss for future revisions. Added
it to list of open issues.

    Juergen


From Quittek@neclab.eu  Mon Jul 11 06:49:04 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1558C21F8B98 for ; Mon, 11 Jul 2011 06:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.149
X-Spam-Level: 
X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Dz24Hq61lfo2 for ; Mon, 11 Jul 2011 06:49:03 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B7C3F21F8B5E for ; Mon, 11 Jul 2011 06:49:02 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 04C2A2800031D; Mon, 11 Jul 2011 15:49:02 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7HkjduSN7Mh; Mon, 11 Jul 2011 15:49:01 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id D956128000174; Mon, 11 Jul 2011 15:48:51 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.22]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 11 Jul 2011 15:48:51 +0200
From: Juergen Quittek 
To: Bruce Nordman , eman mailing list 
Thread-Topic: [eman] Requirements comments, part II
Thread-Index: AQHMPUA8T/69FRR+kkybHVp1cLmY3JTnKAQA
Date: Mon, 11 Jul 2011 13:48:51 +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-Entourage/13.10.0.110428
x-originating-ip: [10.1.2.219]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <5261760B3F04904E84903CC4C7827D3D@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [eman] Requirements comments, part II
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, 11 Jul 2011 13:49:04 -0000

Hi Bruce,

Am 08.07.11 09:25 schrieb "Bruce Nordman" unter :

> Part II:
>=20
>=20
> 5. Required Information on Powered Entities
>   It would be helpful to identify variables that are static vs. those tha=
t are
> dynamic.
>   There are some that are absolutely static, and others that just rarely
> change.

Right. But I think this can be done in the framework or the MIB module.
The Battery MIB clearly separates static from dynamic values.

> 5.1.1 Type of powered entity
>   Add =B3according to some standard classification=B2.

OK.

I another discussion we were arguing about removing or not removing section
5.1.1 on entity types. I had it deteled but now put it back and added a new
open issue.

> 5.2 Power State
>   I disagree that a device should have multiple power state sets.  This p=
uts
> the
>   burden of translating between sets on the device, when it is much bette=
r put
>   on the management system.  In an email from May 3, Juergen S noted:
>    =B3Traditionally, it was always assumed that an SNMP management system
>     can more easily adapt to devices than the other way round.=B2

I think we had consensus on multiple states in the WG.
Let's discuss this separately.

>   Also the first three sentences of paragraph four should be dropped.

Done.

> 5.2.1 Actual Power State
>   There are transition states, when a device is in the process of moving
>   from one long-term stable state to another. I think this fact should be
>   mentioned, though I don=B9t think we should attempt to model them.
>   The expectation should be that these are mapped into the On state,
>   since that will most closely resemble its power levels.

What would need to be added? just a note?

> 5.3 Power inlet and power outlet
>   I am not fond of inlet and outlet but don=B9t have a better pair of ter=
ms to
> suggest.
>   Do we anticipate that these may be used for components of devices, or
>   only for entire devices?

I see them particularly for entire devices.
I would appreciate good proposals for better terms.
=20
> 5.3.4 Availability of power
>   In most cases I agree that this is just On or Off. However, PoE and USB
>   (and emerging standards such as UPAMD) have a mode in which only
>   a minimal amount of power is provided, to enable a device to request
>   more.  So, I propose that a =B3Minimum=B2 (or similar term) be added as
>   a possible third state for this.  This could also apply to control
> requirements.

agreed. However, I would like to read 803.at again before fixing the term.
Added to open issues.

> 5.4.2 Confidence in power values
>   This sounds =B3mechanism=B2 or =B3method=B2 rather than =B3confidence=
=B2.
>   Also, I would combine this with the following accuracy requirement,
>   since estimation could vary dramatically in accuracy depending on
>   the product.  Or, drop this requirement entirely and stick only to
>   accuracy.

Added to open issues.

> 5.4.8 Power supply impedance
>   I am not an engineer, but is this needed?  I ask since I don=B9t rememb=
er
>   ever seeing it used in my energy efficiency research. Other metrics suc=
h
>   as power factor are often raised.

added to open issues.

> 5.4.9 Time series of power values
>   The second half of this implies that time series functionality can be
>   accomplished by means other than EMAN itself.  I heartily agree.
>   This same issue arises in 5.5 and 5.5.2 =AD I think should be outside o=
f EMAN.

What do you mean with 'means other than EMAN?

> 5.5. Energy
>   I think the time component of accumulated energy values should be
>   relative to the first time the entity is used =AD that is, never reset,=
 so
>   not on =B3restart=B2.  A monitoring system can do any intervaling it wa=
nts
>   to =AD there is no reason to burden or complicate the device, and we do=
n=B9t
>   want to reset the meter else risk great potential confusion.

that would be a tough requirement for devices without persistent
(non-volatile) storage. Wouldn't this bee too strong for a requirement?

    Juergen


From Quittek@neclab.eu  Mon Jul 11 06:53:19 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF10721F8B73 for ; Mon, 11 Jul 2011 06:53:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.16
X-Spam-Level: 
X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 1YCzvsi8Hvf1 for ; Mon, 11 Jul 2011 06:53:19 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 174F321F8B5D for ; Mon, 11 Jul 2011 06:53:19 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 54BD0280002FE; Mon, 11 Jul 2011 15:53:18 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTyk5tyGOmop; Mon, 11 Jul 2011 15:53:18 +0200 (CEST)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3522128000174; Mon, 11 Jul 2011 15:53:08 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.22]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Mon, 11 Jul 2011 15:53:08 +0200
From: Juergen Quittek 
To: Bruce Nordman , eman mailing list 
Thread-Topic: [eman] New draft on eman requirements - issue 1 - Device type
Thread-Index: AQHMPT96LcB/iLDTj0uk4E1b8BSqi5TnKTYA
Date: Mon, 11 Jul 2011 13:53:06 +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-Entourage/13.10.0.110428
x-originating-ip: [10.1.2.219]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <672C1DFDF196B3439B4F6EDE6E8C01B7@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type
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, 11 Jul 2011 13:53:19 -0000

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

    Juergen

Am 08.07.11 09:16 schrieb "Bruce Nordman" unter :

>=20
>=20
> On Wed, Jul 6, 2011 at 4:59 AM, Juergen Quittek  wrote:
>> On 06.07.2011  11:26, Benoit Claise wrote:
>> ....
>>=20
>>> Coming back to this requirement
>>> =20
>>> =20
>>>> 5.1.1. Type of powered entity
>>>> =20
>>>>  The energy management standard must provide means to retrieve and
>>>>  report the type of powered entities.
>>>  I believe the "type" is misleading. The main requirement is that we wa=
nt
>>> the ability to group powered entities based on something, which could b=
e the
>>> type, what the type definition you want.
>>>  Therefore, I would remove the requirement 5.1.1 and only keep the curr=
ent
>>> 5.1.2
>>> =20
>>>> =20
>>>> 5.1.2.  Grouping of powered entities
>>>>=20
>>>>    The energy management standard must provide means for grouping
>>>>    powered entities, for example, into energy monitoring domains, ener=
gy
>>>>    control domains, power supply domains, groups of entities of the sa=
me
>>>>    type, etc.
>> I agree. I do not know what an entity type is. So let's remove 5.1.1.
>> However, 5.1.2 also talks about entities of the same type :-)
>> Shall we remove "type" also here?
>=20
> I have to disagree completely on this point.
> A major barrier to understanding energy use in
> buildings and in doing things to reduce it is
> lack of information about what devices are
> present in a building and how much each
> one is using.  We are going into great detail
> about the quantities of energy, but seem to
> want to avoid saying anything about what
> the device actually is.
>=20
> Accomplishing this and meeting the needs of
> energy efficiency need not be burdensome.
> Just a few variables can point to a standard
> index of device types (or "product types" in
> my line of work) and short brand/model
> information.
>=20
> Thanks,
>=20
> --Bruce
> =20
>>=20
>=20
>=20


From Quittek@neclab.eu  Mon Jul 11 08:56:32 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7C021F8C3D for ; Mon, 11 Jul 2011 08:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.169
X-Spam-Level: 
X-Spam-Status: No, score=-102.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 zEfdgjoEyALI for ; Mon, 11 Jul 2011 08:56:32 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E548C21F8B94 for ; Mon, 11 Jul 2011 08:56:28 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 39799280002FE; Mon, 11 Jul 2011 17:56:28 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFIv+1qGZuGU; Mon, 11 Jul 2011 17:56:28 +0200 (CEST)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1C22028000174; Mon, 11 Jul 2011 17:56:18 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.22]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Mon, 11 Jul 2011 17:56:18 +0200
From: Juergen Quittek 
To: Bruce Nordman , eman mailing list 
Thread-Topic: [eman] Requirements comments, part III
Thread-Index: AQHMPUBZquSQ7NxTvEqOZMIZX0fXTpTnS5+A
Date: Mon, 11 Jul 2011 15:56:16 +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-Entourage/13.10.0.110428
x-originating-ip: [10.1.2.219]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <1B1E83C505DE284A961AD8DDB28F8EC9@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [eman] Requirements comments, part III
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, 11 Jul 2011 15:56:32 -0000

Am 08.07.11 09:25 schrieb "Bruce Nordman" unter :

> Part III:
>=20
>=20
> 7. Reporting on Other Powered Entities
>   We need some additional terms here to streamline the text (and ultimate=
ly
>   our thinking).  I nominate:
>    =B3powered entity=B2 (which may be =B3self-reporting=B2)
>    =B3reporting entity=B2 (can be =B3self=B2 or =B3other=B2)
>    =B3other entity=B2 (a reporting entity reporting not on itself; likely=
 a
> different
>         term would be better for this)
>    =B3controlled entity=B2, =B3controlling entity=B2 (section 8.1)
>    =B3switched entity=B2, =B3switching entity=B2 (section 8.2)
> =20
>   Also, there are two cases for an =B3other entity=B2. One is where the p=
owered
>   entity cannot report the value in question itself (either because it ca=
n=B9t
> report
>   anything, or doesn=B9t know the value in question, e.g. when metering i=
s
> external).
>   The second is where the powered entity can report, but the other entity=
 is
>   doing the reporting for some convenience.  We need to be aware of both =
even
>   if the framework does not need to make the distinction.
> =20
>   There may be multiple other reporting entities, not just a single one.
> =20
>   Do components of devices ever report, or do only devices do the reporti=
ng?
>   This seems like an important point.

OK, this is needs some time to finalize terms.
Let's do it in revision -05. Added to open issues.
 =20
> 8. Controlling other powered entities
>   Do components ever do controlling or are they ever controlled directly,
>   or is it only entire devices that are controlled?

Both should be possible.

> 9. Security considerations
>   Should there be any discussion of the sensitivity of the content of the
>   monitoring data, or only whether the data in general can be accessed
>   by unauthorized parties?

Yes. This is missing. We should revise them. Added top open issues.
=20
> 12.3 Inlet/outlet combinations
>   A socket should not change from inlet to outlet. There should be both
>   logically existing, with at least one always zero. That they share the =
same
>   physical wire is not important.

the connector for a battery can have both directions.

> 12.4 Aggregation functions
>   Yes, there should be requirements for this. Aggregation is the summing
>   across multiple entities.  Reporting this sum is just a normal reportin=
g
> operation,
>   though reporting an aggregate value is never self-reporting.

Right. We just need to elaborate the requirements.

> 12.5 Add defn of =8Cdemand=B9?
>   No.

This is a controversial issue in the WG.
=20
> 12.8
>   IEEE 1621, =B3Standard for User Interface Elements in Power Control of
>   Electronic Devices Employed in Office/Consumer Environments=B2,
>   2004 (reaffirmed 2009).
> =20
>   IEEE 802.3az, IEEE LAN/MAN Standards Committee of the IEEE Computer Soc=
iety.
> =B3Draft P802.3azTM/D3.0, Draft Standard for Information technology=8B
> Telecommunications and information exchange between systems=8BLocal and
> metropolitan area networks=8BSpecific requirements. Part 3: Carrier Sense
> Multiple Access with Collision Detection (CSMA/CD) Access Method and Phys=
ical
> Layer Specifications Amendment: Media Access Control parameters, Physical
> Layers and management parameters for Energy-Efficient Ethernet.=B2 (Septe=
mber,
> 2010)

Thanks, I will add them when revising all references in revision -05.

    Juergen


From internet-drafts@ietf.org  Mon Jul 11 10:08:27 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98ADE21F8E81; Mon, 11 Jul 2011 10:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.582
X-Spam-Level: 
X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 jeliDoJkEfV5; Mon, 11 Jul 2011 10:08:27 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048A021F8E7F; Mon, 11 Jul 2011 10:08:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.55
Message-ID: <20110711170827.31774.30827.idtracker@ietfa.amsl.com>
Date: Mon, 11 Jul 2011 10:08:27 -0700
Cc: eman@ietf.org
Subject: [eman] I-D Action: draft-ietf-eman-requirements-04.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: Mon, 11 Jul 2011 17:08:27 -0000

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

	Title           : Requirements for Energy Management
	Author(s)       : Juergen Quittek
                          Rolf Winter
                          Thomas Dietz
                          Benoit Claise
                          Mouli Chandramouli
	Filename        : draft-ietf-eman-requirements-04.txt
	Pages           : 35
	Date            : 2011-07-11

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


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-04.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-eman-requirements-04.txt

From bclaise@cisco.com  Mon Jul 11 11:19:13 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5849F21F8F07 for ; Mon, 11 Jul 2011 11:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level: 
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImVKssiHTp+m for ; Mon, 11 Jul 2011 11:19:12 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 510CD21F8ED7 for ; Mon, 11 Jul 2011 11:19:12 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6BIJB64005116 for ; Mon, 11 Jul 2011 20:19:11 +0200 (CEST)
Received: from [10.82.241.70] (rtp-vpn2-326.cisco.com [10.82.241.70]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6BIJ5b5006741 for ; Mon, 11 Jul 2011 20:19:06 +0200 (CEST)
Message-ID: <4E1B3E98.5060902@cisco.com>
Date: Mon, 11 Jul 2011 11:19:04 -0700
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: eman mailing list 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [eman] webex request?
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, 11 Jul 2011 18:19:13 -0000

Dear all,

Does anybody plan to attend remotely the coming EMAN WG meeting?
Note that jabber and the audio channel are available by default.
Do you need more interactivity, i.e. a webex meeting, to be set up for 
this meeting?

Regards, Bruce and Benoit

From moulchan@cisco.com  Mon Jul 11 22:47:55 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C799621F8D32 for ; Mon, 11 Jul 2011 22:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.138
X-Spam-Level: 
X-Spam-Status: No, score=-5.138 tagged_above=-999 required=5 tests=[AWL=-2.539, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chPrluaT2fvY for ; Mon, 11 Jul 2011 22:47:55 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0A94D21F8D25 for ; Mon, 11 Jul 2011 22:47:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=2436; q=dns/txt; s=iport; t=1310449675; x=1311659275; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=qqO5igflbU43YSLaamQTowEbbFSECTwp+uDFDW/aHfE=; b=Ux8wzCkm1X4PyBfejb2K11Rk3CgByMKhHPB0Vmh0O36PZg3LcddLG7hX XDwJSYul5kxP0YcKcxJRI6RN70I6/zVDJp+FLHL/roDsZ5Lqah1ej1YPb LxQIR6/Lgi/t9ggqnHVhENPaZI5UdesBBTVJjqtulcD3xHGQ8MjnTHM+8 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvMAAHrfG06tJV2b/2dsb2JhbABThESTKo5LcHeqcoEijR+Qe4ErhAAwXwSHT5ATi2E
X-IronPort-AV: E=Sophos;i="4.65,518,1304294400";  d="scan'208";a="1984564"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 12 Jul 2011 05:47:54 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6C5lsPc021943 for ; Tue, 12 Jul 2011 05:47:54 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 12 Jul 2011 00:47:54 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Tue, 12 Jul 2011 00:47:50 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New Version Notification for draft-claise-energy-monitoring-mib-09.txt
Thread-Index: Acw/95ZeNQYR4NkhSKCHIzL47cEwfgAABh2wABdPDsA=
From: "Mouli Chandramouli (moulchan)" 
To: "eman mailing list" 
X-OriginalArrivalTime: 12 Jul 2011 05:47:54.0404 (UTC) FILETIME=[3EA20640:01CC4057]
Subject: [eman] New Version Notification for draft-claise-energy-monitoring-mib-09.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, 12 Jul 2011 05:47:55 -0000

SGksDQoNCkFuIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUgTUlCIGRyYWZ0IGhhcyBiZWVuIHN1Ym1p
dHRlZCBhbmQgY29udGFpbnMgdGhlIGZvbGxvd2luZyBjaGFuZ2VzLiANCg0KaHR0cDovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtY2xhaXNlLWVuZXJneS1tb25pdG9yaW5nLW1pYi0wOQ0KDQpU
aGUgZGlmZiBjYW4gYmUgc2VlbiBhdCANCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/
ZGlmZnR5cGU9LS1od2RpZmYmdXJsMj1kcmFmdC1jbGFpc2UtZW5lcmd5LW1vbml0b3JpbmctbWli
LTA5LnR4dA0KDQoNCi0gdXBkYXRlZCB0aGUgUG93ZXIgU3RhdGUgU2VyaWVzIHdpdGggUG93ZXIg
U3RhdGUgc2V0IHRvIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgdGVybWlub2xvZ3kgaW4gdGhlIHJl
cXVpcmVtZW50cyBkcmFmdCANCi0gdXBkYXRlZCB0aGUgSUVDIHJlZmVyZW5jZXMgZm9yIEFjY3Vy
YWN5IENsYXNzIGFuZCBQb3dlciBRdWFsaXR5IGJhc2VkIElFQyA2MTg1MCBhbmQgSUVDLjYyMDUz
LTIyDQotIHVwZGF0ZWQgdGhlIFVNTCBkaWFncmFtIGZvciBNb25pdG9yaW5nIE1JQiB0byBzaG93
IHRoZSBkZXBlbmRlbmNpZXMgDQotIHVwZGF0ZWQgdGhlIE9wZW4gSXNzdWVzIGJhc2VkIG9uIHRo
ZSBmZWVkYmFjayB3ZSBoYXZlIGhhZCBmcm9tIHRoZSBFTUFOIFdHIGVtYWlsIGxpc3QuIFdlIGhv
cGUgdG8gcmVzb2x2ZSB0aGVzZSBpc3N1ZXMgb24gZW1haWwgYW5kL29yIFdHIGRpc2N1c3Npb24g
QCBRdWViZWMNCi0gY29tcGlsZWQgdGhlIE1JQg0KDQpUaGFua3MNCk1vdWxpDQoNCi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0
bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBKdWx5IDExLCAyMDEx
IDExOjUzIFBNDQpUbzogTW91bGkgQ2hhbmRyYW1vdWxpIChtb3VsY2hhbikNCkNjOiB0aG9tYXMu
ZGlldHpAbmVjbGFiLmV1OyBCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKTsgcXVpdHRla0BuZWNsYWIu
ZXU7IE1vdWxpIENoYW5kcmFtb3VsaSAobW91bGNoYW4pOyBicmFkQGJyYWRzY2hvZW5pbmcuY29t
DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWNsYWlzZS1lbmVy
Z3ktbW9uaXRvcmluZy1taWItMDkudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1j
bGFpc2UtZW5lcmd5LW1vbml0b3JpbmctbWliLTA5LnR4dA0KDQogaGFzIGJlZW4gc3VjY2Vzc2Z1
bGx5IHN1Ym1pdHRlZCBieSBNb3VsaSBDaGFuZHJhbW91bGkgYW5kIHBvc3RlZCB0byB0aGUgSUVU
RiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWNsYWlzZS1lbmVyZ3ktbW9uaXRvcmlu
Zy1taWINClJldmlzaW9uOgkgMDkNClRpdGxlOgkJIFBvd2VyIGFuZCBFbmVyZ3kgTW9uaXRvcmlu
ZyBNSUINCkNyZWF0aW9uIGRhdGU6CSAyMDExLTA3LTA4DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1
Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogNzQNCg0KQWJzdHJhY3Q6DQogICAgICAgIFRoaXMg
ZG9jdW1lbnQgZGVmaW5lcyBhIHN1YnNldCBvZiB0aGUgTWFuYWdlbWVudCBJbmZvcm1hdGlvbg0K
ICAgICAgICBCYXNlIChNSUIpIGZvciBwb3dlciBhbmQgZW5lcmd5IG1vbml0b3Jpbmcgb2YgZGV2
aWNlcy4NCg0KICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBT
ZWNyZXRhcmlhdA0K

From Quittek@neclab.eu  Tue Jul 12 02:00:46 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F80D21F90F3 for ; Tue, 12 Jul 2011 02:00:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.176
X-Spam-Level: 
X-Spam-Status: No, score=-102.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 lQp-BU+KIAHg for ; Tue, 12 Jul 2011 02:00:46 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E388021F912A for ; Tue, 12 Jul 2011 02:00:45 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3D95A28000301 for ; Tue, 12 Jul 2011 11:00:45 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veMWR+NjqVUq for ; Tue, 12 Jul 2011 11:00:45 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 20F1228000174 for ; Tue, 12 Jul 2011 11:00:40 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.22]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Tue, 12 Jul 2011 11:00:40 +0200
From: Juergen Quittek 
To: eman mailing list 
Thread-Topic: new revision of eman requirements
Thread-Index: AcxAcisSZRUzanmdsk2o6MS8wxG5wA==
Date: Tue, 12 Jul 2011 09:00:39 +0000
Message-ID: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.10.0.110428
x-originating-ip: [10.1.2.219]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3059E265C1C8494490D798D626E415C7@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [eman] new revision of eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Jul 2011 09:00:46 -0000

Dear all,

I posted a new version of the eman requirements yesterday.
Please find it at=20
http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/

All changes applied are based on comments on the mailing list on the
previous version that was posted two weeks ago.

Many thanks to all who read the draft and made comments on the mailing list=
.

Since I could not solve all issues raised on the mailing list, out list of
open issues has become longer and has 18 entries. You'll find them in
section 12 of the draft.

I would like you to particularly provide your input on the following open
issues:

(12.2) Do we have a requirement for high/low power notifications?
   I think we don't.

(12.3) Power and energy time series?
   Currently the draft states requirements for reporting time series
   of power and energy values.
     - Do we really need both?
     - Do we need just one? If yes, which one?
         -- IF I had to choose one, I would pick energy values.
     - Or is there no real requirement for time series
       stored in MiB variables?
          -- This concept is rarely applied to monitoring of
             other MIB variables, for example, packet numbers
             at IP interfaces.

(12.5) Aggregation functions
   Are there requirements on aggregation?
   Which are they?
      Georgios already commented on that on the list.
      I did not have enough time to digest his input

(12.6) Add a definition of 'demand'
   I got controversial comments on this issue. Some say
   we need to have requirements for reporting demand.
   Others say just reporting power over time intervals is sufficient.

(12.11) Shall we add a new power state 'disconnected from power'?

(12.12) Shall we remove the power state 'reduced power'

(12.14) Do we need entity types?
   Entity are requested by requirement 5.1.1. there were controversial
   opinions on the mailing list on whether or not the entity type
   should be removed from the requirements. The entity type would assign
   a type to a device or entity, such as "switch", "host", "display",
   "desktop phone", "light bulb", etc.

(12.16) Is there a need for metering power supply impedance?
   currently we have a requirement for providing means to report the
   impedance of a power source (requirement 5.4.9). Do we really need this?


Of course, feel free to also comment on the other open issues or to raise
new ones. All such contributions are highly appreciated.

Thanks,

    Juergen


From Quittek@neclab.eu  Tue Jul 12 07:28:23 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507B221F8CCE for ; Tue, 12 Jul 2011 07:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.182
X-Spam-Level: 
X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 tc74BBEoolST for ; Tue, 12 Jul 2011 07:28:22 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B99A121F8CBC for ; Tue, 12 Jul 2011 07:28:22 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 32C672800031D for ; Tue, 12 Jul 2011 16:28:22 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBjcf3zG4g4q for ; Tue, 12 Jul 2011 16:28:22 +0200 (CEST)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 171C928000305 for ; Tue, 12 Jul 2011 16:28:17 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.22]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Tue, 12 Jul 2011 16:28:17 +0200
From: Juergen Quittek 
To: eman mailing list 
Thread-Topic: new reference model based on power interfaces
Thread-Index: AcxAn++Om9vBh2PLw0CTtywXipx2Iw==
Date: Tue, 12 Jul 2011 14:28:18 +0000
Message-ID: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.10.0.110428
x-originating-ip: [10.1.2.219]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <381A954C7FEE334881A100335EED71C1@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [eman] new reference model based on power interfaces
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, 12 Jul 2011 14:28:23 -0000

Dear all,

Just before the deadline Bruce and I posted a new version -02 of the
reference model for energy management. Please find it at
http://datatracker.ietf.org/doc/draft-quittek-eman-reference-model/

The previous version -01 was based on boxes and functions. It was much abou=
t
which service is provided where. The result was a long list of new terms
such as power state monitor and power supply controller. The resulting mode=
l
was usable for explaining the things we want to do in eman, but big and
complex. Also the model in the framework document does not seem to be simpl=
e
and Internet-style.

That's why there is an entire new model in the new version -02 of the
reference model draft which is much simpler and much closer to existing IET=
F
concepts.

The new model is very short and is based on the concept of power interfaces=
.
We see power interfaces as very similar to network interfaces. They connect
a device to a shared (power) transmission medium, the power line. A power
interface can be in mode inlet or outlet and it may have metering
capabilities. Finally, it can (if available) provide information on other
devices connected to the same medium. This is already almost all that is
needed.=20

We call a device with one or more power interfaces in inlet mode a powered
entity (PE), and a device with one or more power interfaces in outlet mode =
a
power source (PS). If there is metering capability, we call it a power mete=
r
(PM).  No more terms are needed!

The concept of a power interface has been adopted from the Power over
Ethernet specification where powered devices (PDs) and power sourcing
equipment (PSE) are connected to shared transmission media via power
interfaces.

Integration of energy management into existing NMS systems becomes much
simpler than with models we discussed before, because the concept is very
similar to the concept of network interfaces and thus similar structures in
MIB modules and NMS systems can be used. Also a MIB module according to the
new model would become much simpler than the ones we already have.

If you still want to compare it to the previous model, you will find it in
the Appendix of the new draft (that's why it is so long).

Unfortunately, time was not enough to fully explain all details of the new
model sufficiently. We will update the draft soon with full explanations.

Of course, comments are highly appreciated.

Thanks,

    Juergen


From moulchan@cisco.com  Wed Jul 13 01:51:45 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E434221F8AF9 for ; Wed, 13 Jul 2011 01:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.384
X-Spam-Level: 
X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=-4.785, BAYES_00=-2.599, GB_SUMOF=5]
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 QPkEQDaQOLMf for ; Wed, 13 Jul 2011 01:51:41 -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 D759A21F8AF6 for ; Wed, 13 Jul 2011 01:51:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=1437; q=dns/txt; s=iport; t=1310547102; x=1311756702; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=LEOHCL8Q5epJrAqh9kH5XDisiigfHo8h/mjDWeWI7f0=; b=GIyMsFN6YxdoIsotFnSINP2hrx6sgn3TReEp6tSWna3+/bbGVhFbf63Y Xcafy+XZylB0WX6AP5Stv/rfxBYFaMtGdSouWEqZfsvDi6aGw90j5zedw UTnG2BEXIyQvYNe5sogNIStKQG/nMtx5exb6nwHPNZ6xPt8Z71FPj7Lz7 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvMAABNbHU6tJXG+/2dsb2JhbABKCRuXYY8+d4h6pRyeHIMtgi5fBIdRkBiLYg
X-IronPort-AV: E=Sophos;i="4.65,524,1304294400";  d="scan'208";a="2452753"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 13 Jul 2011 08:51:41 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6D8pfXH009729;  Wed, 13 Jul 2011 08:51:41 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 13 Jul 2011 03:51:41 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Jul 2011 03:51:37 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] Comments on eman requirements
Thread-Index: Acw8YCsr0Xc4WdOwQvCcSCLRlqbYfAE2Q+cg
References: <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at> 
From: "Mouli Chandramouli (moulchan)" 
To: "JinHyeock Choi" , "Juergen Quittek" 
X-OriginalArrivalTime: 13 Jul 2011 08:51:41.0235 (UTC) FILETIME=[158CA830:01CC413A]
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2011 08:51:46 -0000

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
JinHyeock Choi
Sent: Thursday, July 07, 2011 10:12 AM
To: Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] Comments on eman requirements

Dear Juergen

> Thanks for the constructive suggestions.

thanks for your kind words.

>> Interesting.
>> Power consumption remaining the same irrespective of traffic load
>> is not unusual but power consumption inversely proportional
>> to traffic load is a novelty.
>> Can you give me a pointer?
>
> http://www.irit.fr/~Georges.Da-Costa/cse09.pdf

thanks for a prompt reply.

>> Precisely speaking, in mathematics,
>> 'series' is the sum of the terms of 'sequence',
>> so in our context, 'sequence' is better.
>
> I'd be fine with using sequence.
> Would it be OK to say "time sequence of power values" instead of "time
series of power values"?

Hi JinHyeock,

A small nit.=20

"Time Series" is the classical statistical term (many text books) for
any data collected over time, which is probably what is meant here
Energy data collected over time.=20

Sequences and Series are terms used in Real Analysis. =20

Sorry.  Could not resist my karma from my previous incarnation as a
mathematician !

Thanks
Mouli

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

From jinchoe@gmail.com  Wed Jul 13 02:01:21 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B90821F8687 for ; Wed, 13 Jul 2011 02:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.266
X-Spam-Level: 
X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599, GB_SUMOF=5, 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 pZHqKQl0mUzQ for ; Wed, 13 Jul 2011 02:01:17 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEA721F8891 for ; Wed, 13 Jul 2011 02:01:17 -0700 (PDT)
Received: by pzk5 with SMTP id 5so6538190pzk.31 for ; Wed, 13 Jul 2011 02:01:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9SliiI42b6NxzIh6+o9BIfYbiuTzhH4VNrv55ycjsIo=; b=ZSttqr57Zl8/ndMAWKP7xb/I/X7ZmExY0IQLa/odD6m8s+XBgHBkX2CasVu92ZPFZj UBOUiCXJF9uRqawL6TFG/Xdzv1AuRqJHotnp9pENwyGmjz7xbnCSycNd6xZz5n+EmyVM lMsW9YshODb0Kx2cFE1cx/pZ3eRv8y8fzVsGI=
MIME-Version: 1.0
Received: by 10.68.31.105 with SMTP id z9mr1131561pbh.486.1310547677140; Wed, 13 Jul 2011 02:01:17 -0700 (PDT)
Received: by 10.68.63.230 with HTTP; Wed, 13 Jul 2011 02:01:17 -0700 (PDT)
In-Reply-To: 
References:  <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at>    
Date: Wed, 13 Jul 2011 18:01:17 +0900
Message-ID: 
From: JinHyeock Choi 
To: "Mouli Chandramouli (moulchan)" 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2011 09:01:21 -0000

Hi Mouli

thanks for the clarificaiton.

> "Time Series" is the classical statistical term (many text books) for
> any data collected over time, which is probably what is meant here
> Energy data collected over time.

ok. If that=92s the well established term, I=92m fine with that.

> Sequences and Series are terms used in Real Analysis.

that=92s what I have in mind.
In Analysis, there is a clear difference.

> Sorry. Could not resist my karma from my previous incarnation as a
> mathematician !

The same here. Neither could I resist it.
We fret over definitions like a princess over a pea. :-)

best regards

JinHyeock


> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> JinHyeock Choi
> Sent: Thursday, July 07, 2011 10:12 AM
> To: Juergen Quittek
> Cc: eman mailing list
> Subject: Re: [eman] Comments on eman requirements
>
> Dear Juergen
>
>> Thanks for the constructive suggestions.
>
> thanks for your kind words.
>
>>> Interesting.
>>> Power consumption remaining the same irrespective of traffic load
>>> is not unusual but power consumption inversely proportional
>>> to traffic load is a novelty.
>>> Can you give me a pointer?
>>
>> http://www.irit.fr/~Georges.Da-Costa/cse09.pdf
>
> thanks for a prompt reply.
>
>>> Precisely speaking, in mathematics,
>>> 'series' is the sum of the terms of 'sequence',
>>> so in our context, 'sequence' is better.
>>
>> I'd be fine with using sequence.
>> Would it be OK to say "time sequence of power values" instead of "time
> series of power values"?
>
> Hi JinHyeock,
>
> A small nit.
>
> "Time Series" is the classical statistical term (many text books) for
> any data collected over time, which is probably what is meant here
> Energy data collected over time.
>
> Sequences and Series are terms used in Real Analysis.
>
> Sorry. =A0Could not resist my karma from my previous incarnation as a
> mathematician !
>
> Thanks
> Mouli
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>

From moulchan@cisco.com  Wed Jul 13 02:27:36 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A6721F8B06 for ; Wed, 13 Jul 2011 02:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-4.350, BAYES_00=-2.599, GB_SUMOF=5]
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 oGV+LmYvFby8 for ; Wed, 13 Jul 2011 02:27:33 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DDBBC21F83E2 for ; Wed, 13 Jul 2011 02:27:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=5821; q=dns/txt; s=iport; t=1310549253; x=1311758853; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=r/vfQakj+U11KQuU+aC3KbKyvu5dqICeIJIBmavvDa0=; b=Ifx/skdKyIAwFHrvRsGKu5wQHbXhf+OYtwxEBWu/9ZXK7cNg70jyPIE1 l9AJwiHQFU35GYZ/RwcZklTkSer8T9Z1ClyEx7XTWbrwgTwjwPa6bK9RX Lw+o1sTa3eWaWulyd2sRy72KlJl63JziD6MzrlnMZ511FquzVTAOF89rS I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvEAAGJkHU6tJV2d/2dsb2JhbABTl3yPPneIeqUinh6FW18Eh1GQGIti
X-IronPort-AV: E=Sophos;i="4.65,524,1304294400";  d="scan'208";a="2461444"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 13 Jul 2011 09:27:31 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p6D9RVU0019451;  Wed, 13 Jul 2011 09:27:31 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 13 Jul 2011 04:27:31 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Jul 2011 04:27:28 -0500
Message-ID: 
In-Reply-To: <1B997F36-808C-4EB7-94EA-514567340BA2@quittek.at>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] Comments on eman requirements
Thread-Index: Acw8qVP2nFKIEQzMQeqvhsunopuGWwEkXsew
References: <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at> <1B997F36-808C-4EB7-94EA-514567340BA2@quittek.at>
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Quittek" , "John Parello (jparello)" 
X-OriginalArrivalTime: 13 Jul 2011 09:27:31.0832 (UTC) FILETIME=[1767B780:01CC413F]
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2011 09:27:36 -0000

Hi Juergen,

As evident in this email thread, there is a clear need for on consensus
in terminology - which I had initially expressed=20
http://www.ietf.org/mail-archive/web/eman/current/msg00554.html

Power and Energy are not new concepts. A mathematical definition of
Energy and Power should be available in standard Physics text books.
Perhaps, in IETF EMAN WG drafts, it is possible to reuse a definition
from other electrical standards - IEC, ISO or IEEE.

For the benefit, it would be good to have the snippet (posted in the
email list) of these definitions from these other standards and then we
can converge on the definition soon.

Thanks
Mouli

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Juergen Quittek
Sent: Thursday, July 07, 2011 6:55 PM
To: John Parello (jparello)
Cc: eman mailing list
Subject: Re: [eman] Comments on eman requirements

Hi Paul,

Am 07.07.2011 um 05:51 schrieb John Parello (jparello):

> Hi,
>=20
>=20
> In general we should not be making up terms that we mutually agree on.
I

I fully agree. But I would like to make the point that there we do not
yet have an=20
agreement on this issue. I like the terms from IEC as well as the ones
from IEEE.
Both are competent standards bodies in this area. But so far the
discussions=20
with contributions from many people have not converged. I see a clear
trend=20
towards adopting terms defined by other standards bodies and being in
use=20
for many years.

Still, seeing Bruce's mail on this topic who , for example, gave us four

commonly used definitions of demand, there are still choices to be made.
I'll be glad seeing us reaching a final agreement on which terms to
choose
very soon.

> agree with the other threads that taking definitions from well
> established source is much better.
>=20
> For the basic things like Power and Energy etc there are well
> established definition in IEC for utility meters and like devices,
> ASHRAE, and IMO the new ISO50001 - which defines Energy Management and
> constituent parts - has a concise normative reference for these.=20
>=20
> http://www.iso.org/iso/catalogue_detail?csnumber=3D51297
>=20
> You can also refer to the ODVA CIP presentation I did at IETF-80 which
> discussed just this topic on Power Energy and Demand definitions etc
>=20
> For the discussion below on 'Energy' the definitions from the above
> sources just say time (no need to add series, sequence or interval)
> unless you are referring to Demand or taking Energy and Power reading
> over time (which already have time in them). In fact adding those will
> make Demand more confusing.

The discussion on the requirement to store time series/sequences of=20
measured values at the entity seems to be independent of our base
terminology.

The discussion over time intervals was very useful for me.
Particularly, when I came to the point that I am not sure anymore
that we want to have instantaneous power reported for AC power.
As you know, the instantaneous power for AC is alternating and=20
typically has a value of zero for 50 or 60 times a second. So we
definitely
want to have a power value that is not instantaneous, but at least
averaged
over half a period of alternation. Thus all power/demand values we are
dealing with are average values.

> Again there's quite some years of precedence for these values in
utility
> and industrial devices.

That's great and highly appreciated.

Thanks,

    Juergen


> Jp
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
Of
> Juergen Quittek
> Sent: Wednesday, July 06, 2011 8:40 PM
> To: JinHyeock Choi
> Cc: eman mailing list
> Subject: Re: [eman] Comments on eman requirements
>=20
> Dear JinHyeock,
>=20
>>>>> 5.4. Power
>>>>>=20
>>>>> For some network management tasks, it is required to obtain time
>>>>> series of power values (or energy consumption values).
>>>>=20
>>>> I assume energy consumption value measured by watt.
>>>> Am I right?
>>>=20
>>> No here it is either or: power or energy time series. But I see this
> is confusing.
>>> What about removing "(or energy consumption values)"?
>>=20
>> ok. thanks for clarificaiton.
>>=20
>>>>> 5.5. Energy
>>>>>=20
> 
>>>> Energy would be measured over time interval.
>>>>=20
>=20
> Just "over time" no need to say series or interval.
>=20
> Jp
>=20
>=20
>>>> Would time series of energy values be measured
>>>> over the sequence of time intervals in 5.5.2?
>>>=20
>>> Yes. There are different ways to do so.
>>>=20
>>> A time series can contain values that give the total energy since
the
> last re-start
>>> up to an indicated measurement time. Alternatively, you can have
time
> series of energy
>>> consumption for consecutive time intervals, one value each. Or you
> can have this for
>>> overlapping time intervals. 5.5.2 shows all of them.
>>=20
>> ok.
>>=20
>> Please allow me to split hairs
>> cocnerning the terms 'series' and 'sequence'
>> which are currently both used in in 5.5.2 and 5.5.4.
>>=20
>> Precisely speaking, in mathematics,
>> 'series' is the sum of the terms of 'sequence',
>> so in our context, 'sequence' is better.
>=20
> I'd be fine with using sequence.
> Would it be OK to say "time sequence of power values" instead of "time
> series of power values"?
>=20
> Thanks,
>=20
>    Juergen
>=20
>> Bets regards
>>=20
>> JinHyeock
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman

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

From moulchan@cisco.com  Wed Jul 13 03:10:14 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4E711E8098 for ; Wed, 13 Jul 2011 03:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.586
X-Spam-Level: 
X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=-3.987, BAYES_00=-2.599, GB_SUMOF=5]
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 2s-jsndAqX30 for ; Wed, 13 Jul 2011 03:10:10 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6CD21F8789 for ; Wed, 13 Jul 2011 03:09:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=11443; q=dns/txt; s=iport; t=1310551810; x=1311761410; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ODypWl3+WiRfExPdTNys4TGu9CpofZaQX9F1yu1K/CE=; b=AO1gvIycJaVhPqF0b8zoI5LE5NLmPCAVvwDY5f9MnOoIA+SMSobCn/a2 DOgMqb0hIDbtcpqK0j9x0VScrqSXx98H/48iWmjrgI4QKcv/jCs6ibar5 T08plJP/OotTB6wbMC7fZF/DbanAIgYm9kWE6U6OEnlif7fchgkWnHUk5 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvIAAL9tHU6tJXG8/2dsb2JhbABGBQmXfI8+d4h6pSGeHIMiC4IuXwSHUZAYi2Ie
X-IronPort-AV: E=Sophos;i="4.65,524,1304294400";  d="scan'208";a="2473480"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 13 Jul 2011 10:09:26 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6DA9PTn022178;  Wed, 13 Jul 2011 10:09:25 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 13 Jul 2011 05:09:24 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Jul 2011 05:09:20 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] Comments on eman requirements
Thread-Index: Acw9S5C5jl5D+4V7Q1WfLLykgXoSQQD94k6A
References: <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at><9C329342B62B87498B92834DEC9FF51E0D238F6F@fig.raritan.com> 
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Quittek" , "Michael Suchoff" 
X-OriginalArrivalTime: 13 Jul 2011 10:09:24.0866 (UTC) FILETIME=[F14A4620:01CC4144]
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2011 10:10:14 -0000

Hi Juergen,

I think there is some confusion on measurement - what is meant by
instantaneous power measurement.=20

For the sake of clarity, let us assume there is an external meter, which
measures the power of the electrical device at a given time instant and
it is possible to read the meter reading. The reported value is the
power consumed by the device at that time - 100 watts...

I do not think the intent is to measure Alternating Current at the
granularity of 50 or 60 sinusoidal cycles per second. Not sure if there
are even devices to measure current at that level.=20

So, the meter does the averaging internally and reports the power
consumed at a given time. From a energy monitoring or planning
perspective, that would seem to be adequate.=20

Any thoughts.=20

Thanks
Mouli

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Juergen Quittek
Sent: Friday, July 08, 2011 2:17 PM
To: Michael Suchoff
Cc: eman mailing list
Subject: Re: [eman] Comments on eman requirements

Dear Michael,

You are absolutely right.=20
And I wrote the same story already in an earlier message:

For AC power measurement there is always a reporting interval.

Thanks,

    Juergen

Am 07.07.2011 um 17:14 schrieb Michael Suchoff:

> AC power is not reported as an instantaneous value but as an average -
the minimum averaging time being 1/2 AC cycle.
>=20
> A plot of the instantaneous AC power is a sinusoidal waveform at 2X
the AC power frequency.  For example, assume V =3D 100V RMS, I =3D 1A =
RMS,
F=3D60Hz with power factor 1.0.  The power waveform would be a 120Hz
sinusoidal with amplitude 200 and average value 100.  The average value
is the active (real) power.
>=20
> The power waveform can be explained mathematically using the product
to sum formula we learned in high school trigonometry class....
>=20
> Sin(a) * sin(b) =3D .5 * (cos(a-b) - cos(a+b)
>=20
> "a" and "b" are frequency (phase term not shown for simplicity) which
are identical.  Cos(a-b) =3D 0 which is the real component of power and
whose average value is shown on a watt meter.  Cos(a+b) is the 2X
frequency component whose average value is 0.
>=20
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
Of JinHyeock Choi
> Sent: Wednesday, July 06, 2011 11:09 PM
> To: Juergen Quittek
> Cc: eman mailing list
> Subject: Re: [eman] Comments on eman requirements
>=20
> Dear Juergen
>=20
> thanks for kind and thoughtful reply.
>=20
>>> 1. Clarification of 'Power' and 'Energy'
>>>=20
>>> Energy management concerns both 'power' and 'energy' and
>>> now the term 'energy consmption' is used for both,
>>> and sometimes brings forth confusion.
>>>=20
>>> Maybe we can make it more clear
>>> by attaching the unit to be measured (either watt or watthour).
>>> For example such as
>>> "amount of consumed energy measured by joule or watthour."
>>=20
>> I see your point. The alternative would be adding a clarification to
>> the terminology section. What about appending
>>=20
>>   However, in this document the term "consumed energy" always refers
>>   to an energy quantity and not to a power quantity.
>>=20
>> to section 2.1 Energy?
>=20
> fine with me.
>=20
> Sometimes people have trouble distinguishng 'power' and 'energy'
> at least that's the case for me.
> (it has been a long while since I pored over Physics textbook.)
>=20
> Though 'power' and 'energy' have different meanings
> clearly defined in Physics,
> their everyday usage can be intermingling
> such as 'power efficiency' and 'energy efficiency'
>=20
>>> 2. Power/ Energy and Time
>>> Both power and energy are time dependent parameter.
>>>=20
>>> When reporting 'power' or 'energy' value,
>>> i) a specific moment or ii) a time interval
>>> with which the measurement is made also should be provided.
>>=20
>> Yes, that's a good point. I think for energy measurements this is
covered
>> by requirement 5.5.2.  Time intervals, but for power monitoring this
is missing.
>>=20
>> What about adding the following requirement?
>> 5.4.2.  Power measurement interval
>>=20
>>   The energy management standard must provide means for reporting the
>>   corresponding time interval for which a power value is reported.  A
>>   time interval can be very short for reporting approximations of
>>   instantaneous power or rather long for reporting demand values.
>=20
> In principle,
> power itself is an instantateous value
> and measured at a moment (not over interval).
>=20
> So how about rephrasing
>=20
>    The energy management standard must provide means for reporting the
>    corresponding time or time interval for which a power value is
reported.
>    The power value can be measured at the corresponding time or
averaged
>    over the corresponding time interval.
>=20
>>> 3. Power state and Energy consumption
>>>=20
>>>> 5.5.3. Energy per power state
>>>>=20
>>>> The energy management standard must provide means for reporting the
>>>> consumed energy individually for each power state.
>>>=20
>>> Energy consumption depends on
>>> not only 'power state' but also 'traffic load'.
>>>=20
>>> To make sense out of the monitored 'power' or 'energy' value,
>>> energy management system should also take into consideration
>>> corresponding  'traffic rate (measured by bps)' or 'accumulated
>>> traffic (measured by bits)'.
>>>=20
>>> Otherwise it can't determine
>>> whether high power consumption is from low energy efficiency
>>> or high data traffic.
>>=20
>> What would be the requirement?
>=20
> How about
>=20
>    The energy management standard must provide means for reporting the
>    consumed energy individually for each power state,
>    with which enegy management system can derive an average expected
>    energy consumption for each power state.
>=20
> to clarify the reason behind per-power state reporting
>> A comment on the issue:
>> Proportionality between traffic and energy is a tricky thing.
>> I read reports on measurements at low-end routers that show
>> decreasing energy consumption with increasing traffic.
>=20
> Interesting.
> Power consumption remaining the same irrespective of traffic load
> is not unusual but power consumption inversely proportional
> to traffic load is a novelty.
> Can you give me a pointer?
>=20
>>> 4. Power profile of powered entity
>>>=20
>>> For the above purpose, it would be of help
>>> for energy management system to be aware of
>>> the energy efficiency of each powered device (or entity),
>>> i.e. how much energy (joule) each device consumes per bit.
>>>=20
>>> Ideally energy efficiency would be provided as
>>> a power profile (or power model), a function
>>> which maps served traffic (bits or bps) into consumed energy (joule/
watt).
>>>=20
>>> I recommend
>>> energy efficiency or power profile
>>> to be included to the required information in Sec 5.
>>=20
>> This would be a requirement for switches, routers, etc. only.
>> For PCs, displays, light bulbs, it would not be applicable.
>=20
> I see.
>=20
>> Would it not be sufficient to just report the power and have the
joule/bit
>> be computed by a management system that reads the interface MIB
modules
>> if available?
>=20
> ok.
>=20
> For energy management,
> power profile would be needed
> but maybe better be acquired indirectly
> via a kind of resolution scheme.
>=20
>>>> 4.2. Identifying components of powered devices
>>>>=20
>>>> The energy management standard must provide means for identifying
not
>>>> just entire devices as powered entities, but also individual
>>>> components of powered devices.
>>>=20
>>> Shall we also identify (or represent) the (subordinate) relationship
>>> between powered device and its individual components?
>>=20
>> There are already standards for this available.
>> Shall we still make a requirement out of it in order to clarify that
this is
>> needed for energy management as well?
>=20
> Such representatin of subordinate relationship would be useful
> but I'm not sure about making it a requirement.
> If WG doesn't have a strong opinion about it,
> let's leave it as it is. :-)
>=20
>>>> 5.2.6. Maximum and average power per power state
>>>>=20
>>>> The energy management standard must provide means for retrieving
the
>>>> maximum power and the average power as a typically static property
>>>> for each supported power state.
>>>=20
>>> Average power in which sense?
>>> Just a arithmetic mean value between maximum and minimum power?
>>=20
>> I was thinking about the average expected energy consumption in a
particular power state.
>> I admit that this may be difficult to predict.
>=20
> yes,
> even at the same power state,
> enrgy consumption can vary substantially depending on traffic load.
>=20
>> But before asking an entity to switch to another
>> power state it would make sense to have information about the chances
of saving power
>> and for avoiding to bring the device into a state that even consumes
more power.
>=20
> agree.
>=20
>>>> 5.4. Power
>>>>=20
>>>> For some network management tasks, it is required to obtain time
>>>> series of power values (or energy consumption values).
>>>=20
>>> I assume energy consumption value measured by watt.
>>> Am I right?
>>=20
>> No here it is either or: power or energy time series. But I see this
is confusing.
>> What about removing "(or energy consumption values)"?
>=20
> ok. thanks for clarificaiton.
>=20
>>>> 5.5. Energy
>>>>=20
>>>> In order to monitor energy consumption in different power states,
it
>>>> is useful if entities record their energy consumption per power
state
>>>> and report these quantities.
>>>=20
>>> Energy consumption varies according to power state and traffic load.
>>> How do you take 'traffic load' into consideration?
>>=20
>> We do not have any generic term for load. If you can provide one,
please send it.
>=20
> 'bps' or '(accumulated) bit' would do for network equipments
> such as router or switich.
>=20
> However, for more generic work load,
> I don't have a good idea.
>=20
>>> Energy would be measured over time interval.
>>>=20
>>> Would time series of energy values be measured
>>> over the sequence of time intervals in 5.5.2?
>>=20
>> Yes. There are different ways to do so.
>>=20
>> A time series can contain values that give the total energy since the
last re-start
>> up to an indicated measurement time. Alternatively, you can have time
series of energy
>> consumption for consecutive time intervals, one value each. Or you
can have this for
>> overlapping time intervals. 5.5.2 shows all of them.
>=20
> ok.
>=20
> Please allow me to split hairs
> cocnerning the terms 'series' and 'sequence'
> which are currently both used in in 5.5.2 and 5.5.4.
>=20
> Precisely speaking, in mathematics,
> 'series' is the sum of the terms of 'sequence',
> so in our context, 'sequence' is better.
>=20
> Bets regards
>=20
> JinHyeock
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman

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

From moulchan@cisco.com  Wed Jul 13 05:28:37 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D2B11E80BB for ; Wed, 13 Jul 2011 05:28:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.78
X-Spam-Level: 
X-Spam-Status: No, score=-3.78 tagged_above=-999 required=5 tests=[AWL=-1.181,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCmySt+hnEru for ; Wed, 13 Jul 2011 05:28:33 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B352511E80B9 for ; Wed, 13 Jul 2011 05:28:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=1284; q=dns/txt; s=iport; t=1310560113; x=1311769713; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=E4o5/4S5rIejV2KPEbWmSW8HQekDROeeFcfyRW9Kz5w=; b=boqZHtMq1JnVU6uGTd+zHdZubCyKt9mG8WTbp/q51hQYoRf6wxLbmA3X dxd591Bu6zLQssu+4V8Ty1Fz7Y/kWRNHO9y7khjhjlBexHIW5yXuWOgI/ 1MtLktCxJ7YFHjbAZUZ8Kwnohkg05TtKYzw7XIEuuxGNA/TnCrHL/TwYS k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvEAAMKOHU6tJXHB/2dsb2JhbABTl32PPneuG54ihVtfBIdRkBiLYg
X-IronPort-AV: E=Sophos;i="4.65,525,1304294400";  d="scan'208";a="2509466"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 13 Jul 2011 12:28:33 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p6DCSX1v017764;  Wed, 13 Jul 2011 12:28:33 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 13 Jul 2011 07:28:33 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Jul 2011 07:28:29 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - open issue 12.3
Thread-Index: AcxAcisSZRUzanmdsk2o6MS8wxG5wAA5KgAA
References: 
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Quittek" , "eman mailing list" 
X-OriginalArrivalTime: 13 Jul 2011 12:28:33.0335 (UTC) FILETIME=[615D8C70:01CC4158]
Subject: Re: [eman] new revision of eman requirements - open issue 12.3
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2011 12:28:38 -0000

Regarding the Time Series debate - the crucial question - where is the
data / measurements stored.=20
It would not be possible for small devices to store such data for a
sufficiently long time period.=20

The NMS can store the values for a sufficiently long period of time, for
trending analysis.=20

In the case of demand measurement, since the maximum over a window is
computed, it is important for the device store atleast a window length
of measurements.=20

I am not sure about that Requirement 5.4.10 - Time Series of Power
Values - to be stored in the device

Thanks
Mouli


-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Juergen Quittek
Sent: Tuesday, July 12, 2011 2:31 PM
To: eman mailing list
Subject: [eman] new revision of eman requirements

Dear all,

I posted a new version of the eman requirements yesterday.
Please find it at=20
http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/


Of course, feel free to also comment on the other open issues or to
raise
new ones. All such contributions are highly appreciated.

Thanks,

    Juergen

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

From moulchan@cisco.com  Wed Jul 13 05:52:23 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4353921F84C7 for ; Wed, 13 Jul 2011 05:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.695
X-Spam-Level: 
X-Spam-Status: No, score=-3.695 tagged_above=-999 required=5 tests=[AWL=-1.096, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3dirB31p5U7 for ; Wed, 13 Jul 2011 05:52:19 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6343B21F8510 for ; Wed, 13 Jul 2011 05:52:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=1426; q=dns/txt; s=iport; t=1310561539; x=1311771139; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=HUDH0T2sPqcst9M6bph6AtlUqsjRI/nVEcEeiqUtz10=; b=adtqcPwXdav9EIJZzxdhf+D8toBqUo853HWLRVu4sOUkNFvqhrE/J7SP hrfDY9u+5Gjo2Y/hy7DM64/KQ3TzPkbl+SBolP19ODYBOue54ct6oYl/0 Kj/mmyyE7drLNq/N/9PK9luUviAuIZKCRHUT+ePuS4ZarUNz8tZzAI4BC A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvEAAG2UHU6tJXHB/2dsb2JhbABFDpd9jz53rhWeIYMigjlfBIdRkBiLYg
X-IronPort-AV: E=Sophos;i="4.65,525,1304294400";  d="scan'208";a="2514979"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 13 Jul 2011 12:52:18 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p6DCqIS8026919;  Wed, 13 Jul 2011 12:52:18 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 13 Jul 2011 07:52:17 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Jul 2011 07:52:16 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - Open Issue 12.14
Thread-Index: AcxAcisSZRUzanmdsk2o6MS8wxG5wAA57BKw
References: 
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Quittek" , "eman mailing list" 
X-OriginalArrivalTime: 13 Jul 2011 12:52:17.0492 (UTC) FILETIME=[B23AA940:01CC415B]
Subject: Re: [eman] new revision of eman requirements - Open Issue 12.14
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2011 12:52:23 -0000

I think the intent of requirement 5.1.1 should be simple.=20

There is an entity to be monitored; it is possible to identify the
device with a number/index.
Secondly, it is also possible to describe what the device is - user
defined string - along the lines of
RFC 4133 - entPhysicalDescr .=20

Grouping of entities is not related to this requirement, I think.=20

Thanks
Mouli



-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Juergen Quittek
Sent: Tuesday, July 12, 2011 2:31 PM
To: eman mailing list
Subject: [eman] new revision of eman requirements

Dear all,

I posted a new version of the eman requirements yesterday.
Please find it at=20
http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/

All changes applied are based on comments on the mailing list on the
previous version that was posted two weeks ago.


(12.14) Do we need entity types?
   Entity are requested by requirement 5.1.1. there were controversial
   opinions on the mailing list on whether or not the entity type
   should be removed from the requirements. The entity type would assign
   a type to a device or entity, such as "switch", "host", "display",
   "desktop phone", "light bulb", etc.


Thanks,

    Juergen

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

From ietf@quittek.at  Wed Jul 13 05:52:58 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C915B21F8906 for ; Wed, 13 Jul 2011 05:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.915
X-Spam-Level: 
X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.334,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkJxXNiMynoG for ; Wed, 13 Jul 2011 05:52:58 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0904321F855B for ; Wed, 13 Jul 2011 05:52:57 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lu0Dy-1RfzZA2pTa-011WZU; Wed, 13 Jul 2011 14:52:54 +0200
References:  
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <54ECD73F-B9A8-440F-970B-B9DD538CA186@quittek.at>
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Wed, 13 Jul 2011 14:52:54 +0200
To: "Mouli Chandramouli (moulchan)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:vEmA39YtrsugKMXC6IggbMNhUq10lt+pfXlDe9lzDZ2 dcYaba4+codqA34FpmAWIdNGpWP5B8sJYm7H2IB4LNu4tH4mnm Kh17pL8RiUQKW5lvVMF6j1WyMc9X5SYcPl+hzWVy3oEqXT/27k 6Sq+d5nQaUti5jcirw+r0xnj7WcPy4j0u7mszXVxHhqcb1efTm MXN1LNdNtQRarTvON4/gQ==
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - open issue 12.3: time series of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2011 12:52:58 -0000

Dear Mouli,

Thank you for commenting on this issue. I would like to have a look at =
the following point of view:

So far, storing time series of measurements on managed nodes is rarely =
standardized and rarely available as implementation.

Typically, it is the job of a network management system to collect time =
series and store them.

Take for example byte and packet counters at line cards. You see many =
curves showing time series of traffic rate/volume in the Internet, but =
almost all of them were collected at management stations or data =
collector modules, but not within MIB modules. (Please correct me if I'm =
wrong.)=20

Now the question is: Is energy management so much different from other =
network management tasks, that we need the rarely used mechanism of =
storing time series in MIB modules?

If not, it would be sufficient to just report the number of total energy =
consumed since the last re-start as you do it with packet and byte =
counters.
This would be just a single managed object to be specified and =
implemented.

Thanks,

    Juergen

Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):

> Regarding the Time Series debate - the crucial question - where is the
> data / measurements stored.=20
> It would not be possible for small devices to store such data for a
> sufficiently long time period.=20
>=20
> The NMS can store the values for a sufficiently long period of time, =
for
> trending analysis.=20
>=20
> In the case of demand measurement, since the maximum over a window is
> computed, it is important for the device store atleast a window length
> of measurements.=20
>=20
> I am not sure about that Requirement 5.4.10 - Time Series of Power
> Values - to be stored in the device
>=20
> Thanks
> Mouli
>=20
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of
> Juergen Quittek
> Sent: Tuesday, July 12, 2011 2:31 PM
> To: eman mailing list
> Subject: [eman] new revision of eman requirements
>=20
> Dear all,
>=20
> I posted a new version of the eman requirements yesterday.
> Please find it at=20
> http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/
>=20
>=20
> Of course, feel free to also comment on the other open issues or to
> raise
> new ones. All such contributions are highly appreciated.
>=20
> Thanks,
>=20
>    Juergen
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From ietf@quittek.at  Wed Jul 13 05:57:16 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D98221F8534 for ; Wed, 13 Jul 2011 05:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.564
X-Spam-Level: 
X-Spam-Status: No, score=0.564 tagged_above=-999 required=5 tests=[AWL=-2.187,  BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAhz7KH7c4LM for ; Wed, 13 Jul 2011 05:57:12 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8F58021F8533 for ; Wed, 13 Jul 2011 05:57:12 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0M5m7Z-1RQpUi2c1J-00xtAh; Wed, 13 Jul 2011 14:57:11 +0200
References: <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at> <1B997F36-808C-4EB7-94EA-514567340BA2@quittek.at> 
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: 
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Wed, 13 Jul 2011 14:57:09 +0200
To: Mouli Chandramouli (moulchan) 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:UD+dZUTkPz/4iyBawdKJaBLX/F6ru754ICrtxXBMEAk ITSNDT/StzxKCgeaZMoiski8VNDHaF3cMx0/yaXAhu4FeKsZ84 4zbcpJjOVOtbVcawgrHASjzeThgWp8dO8FcVM/Ue0Yeaf0ZEwi NEnuLzI80fck1+jNyZe87YGv7uMVsGME2fnMwaUIlxRGr2l/GA FBFw68P/yTijFFxlk7Mvg==
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2011 12:57:16 -0000

Mouli,

I fully agree. That's why in the terminology section of the last two =
drafts that I posted, you will find under "Power" and "Energy" not a =
definition but: "To be agreed on in the EMAN WG."

I will start a compilation of proposals we have for each of them. Then =
we can discuss which is the best candidate.

    Juergen

Am 13.07.2011 um 11:27 schrieb Mouli Chandramouli (moulchan):

> Hi Juergen,
>=20
> As evident in this email thread, there is a clear need for on =
consensus
> in terminology - which I had initially expressed=20
> http://www.ietf.org/mail-archive/web/eman/current/msg00554.html
>=20
> Power and Energy are not new concepts. A mathematical definition of
> Energy and Power should be available in standard Physics text books.
> Perhaps, in IETF EMAN WG drafts, it is possible to reuse a definition
> from other electrical standards - IEC, ISO or IEEE.
>=20
> For the benefit, it would be good to have the snippet (posted in the
> email list) of these definitions from these other standards and then =
we
> can converge on the definition soon.
>=20
> Thanks
> Mouli
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of
> Juergen Quittek
> Sent: Thursday, July 07, 2011 6:55 PM
> To: John Parello (jparello)
> Cc: eman mailing list
> Subject: Re: [eman] Comments on eman requirements
>=20
> Hi Paul,
>=20
> Am 07.07.2011 um 05:51 schrieb John Parello (jparello):
>=20
>> Hi,
>>=20
>>=20
>> In general we should not be making up terms that we mutually agree =
on.
> I
>=20
> I fully agree. But I would like to make the point that there we do not
> yet have an=20
> agreement on this issue. I like the terms from IEC as well as the ones
> from IEEE.
> Both are competent standards bodies in this area. But so far the
> discussions=20
> with contributions from many people have not converged. I see a clear
> trend=20
> towards adopting terms defined by other standards bodies and being in
> use=20
> for many years.
>=20
> Still, seeing Bruce's mail on this topic who , for example, gave us =
four
>=20
> commonly used definitions of demand, there are still choices to be =
made.
> I'll be glad seeing us reaching a final agreement on which terms to
> choose
> very soon.
>=20
>> agree with the other threads that taking definitions from well
>> established source is much better.
>>=20
>> For the basic things like Power and Energy etc there are well
>> established definition in IEC for utility meters and like devices,
>> ASHRAE, and IMO the new ISO50001 - which defines Energy Management =
and
>> constituent parts - has a concise normative reference for these.=20
>>=20
>> http://www.iso.org/iso/catalogue_detail?csnumber=3D51297
>>=20
>> You can also refer to the ODVA CIP presentation I did at IETF-80 =
which
>> discussed just this topic on Power Energy and Demand definitions etc
>>=20
>> For the discussion below on 'Energy' the definitions from the above
>> sources just say time (no need to add series, sequence or interval)
>> unless you are referring to Demand or taking Energy and Power reading
>> over time (which already have time in them). In fact adding those =
will
>> make Demand more confusing.
>=20
> The discussion on the requirement to store time series/sequences of=20
> measured values at the entity seems to be independent of our base
> terminology.
>=20
> The discussion over time intervals was very useful for me.
> Particularly, when I came to the point that I am not sure anymore
> that we want to have instantaneous power reported for AC power.
> As you know, the instantaneous power for AC is alternating and=20
> typically has a value of zero for 50 or 60 times a second. So we
> definitely
> want to have a power value that is not instantaneous, but at least
> averaged
> over half a period of alternation. Thus all power/demand values we are
> dealing with are average values.
>=20
>> Again there's quite some years of precedence for these values in
> utility
>> and industrial devices.
>=20
> That's great and highly appreciated.
>=20
> Thanks,
>=20
>    Juergen
>=20
>=20
>> Jp
>>=20
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
> Of
>> Juergen Quittek
>> Sent: Wednesday, July 06, 2011 8:40 PM
>> To: JinHyeock Choi
>> Cc: eman mailing list
>> Subject: Re: [eman] Comments on eman requirements
>>=20
>> Dear JinHyeock,
>>=20
>>>>>> 5.4. Power
>>>>>>=20
>>>>>> For some network management tasks, it is required to obtain time
>>>>>> series of power values (or energy consumption values).
>>>>>=20
>>>>> I assume energy consumption value measured by watt.
>>>>> Am I right?
>>>>=20
>>>> No here it is either or: power or energy time series. But I see =
this
>> is confusing.
>>>> What about removing "(or energy consumption values)"?
>>>=20
>>> ok. thanks for clarificaiton.
>>>=20
>>>>>> 5.5. Energy
>>>>>>=20
>> 
>>>>> Energy would be measured over time interval.
>>>>>=20
>>=20
>> Just "over time" no need to say series or interval.
>>=20
>> Jp
>>=20
>>=20
>>>>> Would time series of energy values be measured
>>>>> over the sequence of time intervals in 5.5.2?
>>>>=20
>>>> Yes. There are different ways to do so.
>>>>=20
>>>> A time series can contain values that give the total energy since
> the
>> last re-start
>>>> up to an indicated measurement time. Alternatively, you can have
> time
>> series of energy
>>>> consumption for consecutive time intervals, one value each. Or you
>> can have this for
>>>> overlapping time intervals. 5.5.2 shows all of them.
>>>=20
>>> ok.
>>>=20
>>> Please allow me to split hairs
>>> cocnerning the terms 'series' and 'sequence'
>>> which are currently both used in in 5.5.2 and 5.5.4.
>>>=20
>>> Precisely speaking, in mathematics,
>>> 'series' is the sum of the terms of 'sequence',
>>> so in our context, 'sequence' is better.
>>=20
>> I'd be fine with using sequence.
>> Would it be OK to say "time sequence of power values" instead of =
"time
>> series of power values"?
>>=20
>> Thanks,
>>=20
>>   Juergen
>>=20
>>> Bets regards
>>>=20
>>> JinHyeock
>>=20
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From ietf@quittek.at  Wed Jul 13 05:59:21 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904B611E80AF for ; Wed, 13 Jul 2011 05:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.692
X-Spam-Level: 
X-Spam-Status: No, score=0.692 tagged_above=-999 required=5 tests=[AWL=-2.059,  BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqsQrkuMsQmT for ; Wed, 13 Jul 2011 05:59:20 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5D99821F85AE for ; Wed, 13 Jul 2011 05:58:51 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0Lr6Nr-1RBtrl14Il-00edhg; Wed, 13 Jul 2011 14:58:50 +0200
References: <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at><9C329342B62B87498B92834DEC9FF51E0D238F6F@fig.raritan.com>  
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <507BECE6-EE1C-4120-8D3C-B2CEEECEC76A@quittek.at>
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Wed, 13 Jul 2011 14:58:49 +0200
To: "Mouli Chandramouli (moulchan)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:gC9yl7emG+VmMxel/p39Xg5L44IPjfmkgQAmLUt2nw8 h4ta+1n3FeVPpc1eVVa/mS+zLYQoPqN21ndiSNF095zdowWfgK eL/V6Lf01XjMdg7OFY/xJkZSevn0oaT5aEHBS1cQV/11ENnEW/ XtcAIOBL6R6PKtCf6HuqXJIe+PAGrDG1It8zKsUvQHetQ6T65I V0z78+q+0a1z4q3jDLTog==
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2011 12:59:21 -0000

Hi Mouli,

Let's come back to this after we have agreed on a definition for power.
Meanwhile I will look up how IEEE and IEC define "instantaneous power", =
particularly in case of AC.

Thanks,

    Juergen

Am 13.07.2011 um 12:09 schrieb Mouli Chandramouli (moulchan):

> Hi Juergen,
>=20
> I think there is some confusion on measurement - what is meant by
> instantaneous power measurement.=20
>=20
> For the sake of clarity, let us assume there is an external meter, =
which
> measures the power of the electrical device at a given time instant =
and
> it is possible to read the meter reading. The reported value is the
> power consumed by the device at that time - 100 watts...
>=20
> I do not think the intent is to measure Alternating Current at the
> granularity of 50 or 60 sinusoidal cycles per second. Not sure if =
there
> are even devices to measure current at that level.=20
>=20
> So, the meter does the averaging internally and reports the power
> consumed at a given time. =46rom a energy monitoring or planning
> perspective, that would seem to be adequate.=20
>=20
> Any thoughts.=20
>=20
> Thanks
> Mouli
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of
> Juergen Quittek
> Sent: Friday, July 08, 2011 2:17 PM
> To: Michael Suchoff
> Cc: eman mailing list
> Subject: Re: [eman] Comments on eman requirements
>=20
> Dear Michael,
>=20
> You are absolutely right.=20
> And I wrote the same story already in an earlier message:
>=20
> For AC power measurement there is always a reporting interval.
>=20
> Thanks,
>=20
>    Juergen
>=20
> Am 07.07.2011 um 17:14 schrieb Michael Suchoff:
>=20
>> AC power is not reported as an instantaneous value but as an average =
-
> the minimum averaging time being 1/2 AC cycle.
>>=20
>> A plot of the instantaneous AC power is a sinusoidal waveform at 2X
> the AC power frequency.  For example, assume V =3D 100V RMS, I =3D 1A =
RMS,
> F=3D60Hz with power factor 1.0.  The power waveform would be a 120Hz
> sinusoidal with amplitude 200 and average value 100.  The average =
value
> is the active (real) power.
>>=20
>> The power waveform can be explained mathematically using the product
> to sum formula we learned in high school trigonometry class....
>>=20
>> Sin(a) * sin(b) =3D .5 * (cos(a-b) - cos(a+b)
>>=20
>> "a" and "b" are frequency (phase term not shown for simplicity) which
> are identical.  Cos(a-b) =3D 0 which is the real component of power =
and
> whose average value is shown on a watt meter.  Cos(a+b) is the 2X
> frequency component whose average value is 0.
>>=20
>>=20
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
> Of JinHyeock Choi
>> Sent: Wednesday, July 06, 2011 11:09 PM
>> To: Juergen Quittek
>> Cc: eman mailing list
>> Subject: Re: [eman] Comments on eman requirements
>>=20
>> Dear Juergen
>>=20
>> thanks for kind and thoughtful reply.
>>=20
>>>> 1. Clarification of 'Power' and 'Energy'
>>>>=20
>>>> Energy management concerns both 'power' and 'energy' and
>>>> now the term 'energy consmption' is used for both,
>>>> and sometimes brings forth confusion.
>>>>=20
>>>> Maybe we can make it more clear
>>>> by attaching the unit to be measured (either watt or watthour).
>>>> For example such as
>>>> "amount of consumed energy measured by joule or watthour."
>>>=20
>>> I see your point. The alternative would be adding a clarification to
>>> the terminology section. What about appending
>>>=20
>>>  However, in this document the term "consumed energy" always refers
>>>  to an energy quantity and not to a power quantity.
>>>=20
>>> to section 2.1 Energy?
>>=20
>> fine with me.
>>=20
>> Sometimes people have trouble distinguishng 'power' and 'energy'
>> at least that's the case for me.
>> (it has been a long while since I pored over Physics textbook.)
>>=20
>> Though 'power' and 'energy' have different meanings
>> clearly defined in Physics,
>> their everyday usage can be intermingling
>> such as 'power efficiency' and 'energy efficiency'
>>=20
>>>> 2. Power/ Energy and Time
>>>> Both power and energy are time dependent parameter.
>>>>=20
>>>> When reporting 'power' or 'energy' value,
>>>> i) a specific moment or ii) a time interval
>>>> with which the measurement is made also should be provided.
>>>=20
>>> Yes, that's a good point. I think for energy measurements this is
> covered
>>> by requirement 5.5.2.  Time intervals, but for power monitoring this
> is missing.
>>>=20
>>> What about adding the following requirement?
>>> 5.4.2.  Power measurement interval
>>>=20
>>>  The energy management standard must provide means for reporting the
>>>  corresponding time interval for which a power value is reported.  A
>>>  time interval can be very short for reporting approximations of
>>>  instantaneous power or rather long for reporting demand values.
>>=20
>> In principle,
>> power itself is an instantateous value
>> and measured at a moment (not over interval).
>>=20
>> So how about rephrasing
>>=20
>>   The energy management standard must provide means for reporting the
>>   corresponding time or time interval for which a power value is
> reported.
>>   The power value can be measured at the corresponding time or
> averaged
>>   over the corresponding time interval.
>>=20
>>>> 3. Power state and Energy consumption
>>>>=20
>>>>> 5.5.3. Energy per power state
>>>>>=20
>>>>> The energy management standard must provide means for reporting =
the
>>>>> consumed energy individually for each power state.
>>>>=20
>>>> Energy consumption depends on
>>>> not only 'power state' but also 'traffic load'.
>>>>=20
>>>> To make sense out of the monitored 'power' or 'energy' value,
>>>> energy management system should also take into consideration
>>>> corresponding  'traffic rate (measured by bps)' or 'accumulated
>>>> traffic (measured by bits)'.
>>>>=20
>>>> Otherwise it can't determine
>>>> whether high power consumption is from low energy efficiency
>>>> or high data traffic.
>>>=20
>>> What would be the requirement?
>>=20
>> How about
>>=20
>>   The energy management standard must provide means for reporting the
>>   consumed energy individually for each power state,
>>   with which enegy management system can derive an average expected
>>   energy consumption for each power state.
>>=20
>> to clarify the reason behind per-power state reporting
>>> A comment on the issue:
>>> Proportionality between traffic and energy is a tricky thing.
>>> I read reports on measurements at low-end routers that show
>>> decreasing energy consumption with increasing traffic.
>>=20
>> Interesting.
>> Power consumption remaining the same irrespective of traffic load
>> is not unusual but power consumption inversely proportional
>> to traffic load is a novelty.
>> Can you give me a pointer?
>>=20
>>>> 4. Power profile of powered entity
>>>>=20
>>>> For the above purpose, it would be of help
>>>> for energy management system to be aware of
>>>> the energy efficiency of each powered device (or entity),
>>>> i.e. how much energy (joule) each device consumes per bit.
>>>>=20
>>>> Ideally energy efficiency would be provided as
>>>> a power profile (or power model), a function
>>>> which maps served traffic (bits or bps) into consumed energy =
(joule/
> watt).
>>>>=20
>>>> I recommend
>>>> energy efficiency or power profile
>>>> to be included to the required information in Sec 5.
>>>=20
>>> This would be a requirement for switches, routers, etc. only.
>>> For PCs, displays, light bulbs, it would not be applicable.
>>=20
>> I see.
>>=20
>>> Would it not be sufficient to just report the power and have the
> joule/bit
>>> be computed by a management system that reads the interface MIB
> modules
>>> if available?
>>=20
>> ok.
>>=20
>> For energy management,
>> power profile would be needed
>> but maybe better be acquired indirectly
>> via a kind of resolution scheme.
>>=20
>>>>> 4.2. Identifying components of powered devices
>>>>>=20
>>>>> The energy management standard must provide means for identifying
> not
>>>>> just entire devices as powered entities, but also individual
>>>>> components of powered devices.
>>>>=20
>>>> Shall we also identify (or represent) the (subordinate) =
relationship
>>>> between powered device and its individual components?
>>>=20
>>> There are already standards for this available.
>>> Shall we still make a requirement out of it in order to clarify that
> this is
>>> needed for energy management as well?
>>=20
>> Such representatin of subordinate relationship would be useful
>> but I'm not sure about making it a requirement.
>> If WG doesn't have a strong opinion about it,
>> let's leave it as it is. :-)
>>=20
>>>>> 5.2.6. Maximum and average power per power state
>>>>>=20
>>>>> The energy management standard must provide means for retrieving
> the
>>>>> maximum power and the average power as a typically static property
>>>>> for each supported power state.
>>>>=20
>>>> Average power in which sense?
>>>> Just a arithmetic mean value between maximum and minimum power?
>>>=20
>>> I was thinking about the average expected energy consumption in a
> particular power state.
>>> I admit that this may be difficult to predict.
>>=20
>> yes,
>> even at the same power state,
>> enrgy consumption can vary substantially depending on traffic load.
>>=20
>>> But before asking an entity to switch to another
>>> power state it would make sense to have information about the =
chances
> of saving power
>>> and for avoiding to bring the device into a state that even consumes
> more power.
>>=20
>> agree.
>>=20
>>>>> 5.4. Power
>>>>>=20
>>>>> For some network management tasks, it is required to obtain time
>>>>> series of power values (or energy consumption values).
>>>>=20
>>>> I assume energy consumption value measured by watt.
>>>> Am I right?
>>>=20
>>> No here it is either or: power or energy time series. But I see this
> is confusing.
>>> What about removing "(or energy consumption values)"?
>>=20
>> ok. thanks for clarificaiton.
>>=20
>>>>> 5.5. Energy
>>>>>=20
>>>>> In order to monitor energy consumption in different power states,
> it
>>>>> is useful if entities record their energy consumption per power
> state
>>>>> and report these quantities.
>>>>=20
>>>> Energy consumption varies according to power state and traffic =
load.
>>>> How do you take 'traffic load' into consideration?
>>>=20
>>> We do not have any generic term for load. If you can provide one,
> please send it.
>>=20
>> 'bps' or '(accumulated) bit' would do for network equipments
>> such as router or switich.
>>=20
>> However, for more generic work load,
>> I don't have a good idea.
>>=20
>>>> Energy would be measured over time interval.
>>>>=20
>>>> Would time series of energy values be measured
>>>> over the sequence of time intervals in 5.5.2?
>>>=20
>>> Yes. There are different ways to do so.
>>>=20
>>> A time series can contain values that give the total energy since =
the
> last re-start
>>> up to an indicated measurement time. Alternatively, you can have =
time
> series of energy
>>> consumption for consecutive time intervals, one value each. Or you
> can have this for
>>> overlapping time intervals. 5.5.2 shows all of them.
>>=20
>> ok.
>>=20
>> Please allow me to split hairs
>> cocnerning the terms 'series' and 'sequence'
>> which are currently both used in in 5.5.2 and 5.5.4.
>>=20
>> Precisely speaking, in mathematics,
>> 'series' is the sum of the terms of 'sequence',
>> so in our context, 'sequence' is better.
>>=20
>> Bets regards
>>=20
>> JinHyeock
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From moulchan@cisco.com  Wed Jul 13 06:06:43 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B6521F84F1 for ; Wed, 13 Jul 2011 06:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.622
X-Spam-Level: 
X-Spam-Status: No, score=-3.622 tagged_above=-999 required=5 tests=[AWL=-1.023, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjM74gd0GLJ8 for ; Wed, 13 Jul 2011 06:06:39 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E8BFC21F84FC for ; Wed, 13 Jul 2011 06:02:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=1194; q=dns/txt; s=iport; t=1310562132; x=1311771732; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ZLZzsl73SAvzq25M9SgUfErY25s+M0emaIe0IsXoS7c=; b=ltvzPn07EA8c7/TG4kFvDF1hjGRa6yilHKWb6LCWQwDn4Jo1UDRdxxMr z4QqEGvFX2fz6T7NjmmrWZxzPU7OThAbdZPNmraBTPG2P/P9wBRbRUR0C zmGlzqxNtcAr986YShgoTzb4ipp1Fed0o/wJzdBng/5fqN5JLwVPGMUAO c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvEAAAWXHU6tJV2b/2dsb2JhbABTl36PPneuP54hhVtfBIdRkBiLYg
X-IronPort-AV: E=Sophos;i="4.65,525,1304294400";  d="scan'208";a="2516918"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 13 Jul 2011 13:01:42 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6DD1Pwa013118;  Wed, 13 Jul 2011 13:01:42 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 13 Jul 2011 08:01:29 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Jul 2011 08:01:28 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - Open Issue - 12.16
Thread-Index: AcxAcisSZRUzanmdsk2o6MS8wxG5wAA6apSA
References: 
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Quittek" , "eman mailing list" 
X-OriginalArrivalTime: 13 Jul 2011 13:01:29.0847 (UTC) FILETIME=[FB755870:01CC415C]
Subject: Re: [eman] new revision of eman requirements - Open Issue - 12.16
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2011 13:06:43 -0000

Hi Juergen,

I think some of the requirements 5.4.9 (impendence) 5.4.8 (total
harmonic distortion) should be left as optional for implementation.=20

Whereas Total Power, Active Power, Reactive Power, Power Factor seem to
be of interest and thus requirements for those parameters.=20

Thanks
Mouli


-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Juergen Quittek
Sent: Tuesday, July 12, 2011 2:31 PM
To: eman mailing list
Subject: [eman] new revision of eman requirements

Dear all,

I posted a new version of the eman requirements yesterday.
Please find it at=20
http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/

All changes applied are based on comments on the mailing list on the
previous version that was posted two weeks ago.


(12.16) Is there a need for metering power supply impedance?
   currently we have a requirement for providing means to report the
   impedance of a power source (requirement 5.4.9). Do we really need
this?


Thanks,

    Juergen

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

From msuchoff@gmail.com  Wed Jul 13 07:18:47 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8955921F8893 for ; Wed, 13 Jul 2011 07:18:47 -0700 (PDT)
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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 eCVWJtONUavK for ; Wed, 13 Jul 2011 07:18:46 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEAA21F888A for ; Wed, 13 Jul 2011 07:18:44 -0700 (PDT)
Received: by ewy19 with SMTP id 19so2487651ewy.31 for ; Wed, 13 Jul 2011 07:18:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=h1s7XjTKOAz0HoBY6Lh8t2DUy9NYkP+9DnAAr52J9zM=; b=HFZXMHa9NeuKoAg153LCUinoF2v9D90Q+vfZbYe7/oDKNk/p8QCLGmlmIZ8GuQMsR2 qGpINMdUaMRuA476+e4I00Ym9dYISxF53hZV1Ob2ZcFV846CFr/6jk9YA5BJgna8T4PE eTfoVehnwm3C1e5K8RpAr7HkXEAirIvU4frDU=
MIME-Version: 1.0
Received: by 10.14.3.156 with SMTP id 28mr319645eeh.210.1310566722251; Wed, 13 Jul 2011 07:18:42 -0700 (PDT)
Sender: msuchoff@gmail.com
Received: by 10.14.119.11 with HTTP; Wed, 13 Jul 2011 07:18:41 -0700 (PDT)
In-Reply-To: <54ECD73F-B9A8-440F-970B-B9DD538CA186@quittek.at>
References:   <54ECD73F-B9A8-440F-970B-B9DD538CA186@quittek.at>
Date: Wed, 13 Jul 2011 10:18:41 -0400
X-Google-Sender-Auth: 5lYz3RRwEq23zvR6cW1bMVkZ-Jk
Message-ID: 
From: Michael Suchoff 
To: Juergen Quittek 
Content-Type: multipart/alternative; boundary=001636416b9fef2de004a7f41707
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - open issue 12.3: time series of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2011 14:18:47 -0000

--001636416b9fef2de004a7f41707
Content-Type: text/plain; charset=ISO-8859-1

Dear Juergen,

The larger manufacturers of managed power distribution equipment (APC,
Eaton, Raritan...) all provide circular buffers of time stamped power
measurements.  Certification of our products for use with IBM System
Director required this as well.

The better products allow the polling interval to be specified and provide
ability for events (under currents, circuit breaker trips, etc.) to be
reported as traps.

Our larger data center customers wanted this feature too as they realized
polling thousands of devices minute by minute was inefficient and can yield
unacceptable timing uncertainty.

Our products are able to report accurate measurements - accuracy being
defined as how close do two or more devices agree with a calibrated
reference meter when measuring the same quantity.  This cannot be achieved
without considering time.

On Wed, Jul 13, 2011 at 8:52 AM, Juergen Quittek  wrote:

> Dear Mouli,
>
> Thank you for commenting on this issue. I would like to have a look at the
> following point of view:
>
> So far, storing time series of measurements on managed nodes is rarely
> standardized and rarely available as implementation.
>
> Typically, it is the job of a network management system to collect time
> series and store them.
>
> Take for example byte and packet counters at line cards. You see many
> curves showing time series of traffic rate/volume in the Internet, but
> almost all of them were collected at management stations or data collector
> modules, but not within MIB modules. (Please correct me if I'm wrong.)
>
> Now the question is: Is energy management so much different from other
> network management tasks, that we need the rarely used mechanism of storing
> time series in MIB modules?
>
> If not, it would be sufficient to just report the number of total energy
> consumed since the last re-start as you do it with packet and byte counters.
> This would be just a single managed object to be specified and implemented.
>
> Thanks,
>
>    Juergen
>
> Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):
>
> > Regarding the Time Series debate - the crucial question - where is the
> > data / measurements stored.
> > It would not be possible for small devices to store such data for a
> > sufficiently long time period.
> >
> > The NMS can store the values for a sufficiently long period of time, for
> > trending analysis.
> >
> > In the case of demand measurement, since the maximum over a window is
> > computed, it is important for the device store atleast a window length
> > of measurements.
> >
> > I am not sure about that Requirement 5.4.10 - Time Series of Power
> > Values - to be stored in the device
> >
> > Thanks
> > Mouli
> >
> >
> > -----Original Message-----
> > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> > Juergen Quittek
> > Sent: Tuesday, July 12, 2011 2:31 PM
> > To: eman mailing list
> > Subject: [eman] new revision of eman requirements
> >
> > Dear all,
> >
> > I posted a new version of the eman requirements yesterday.
> > Please find it at
> > http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/
> >
> >
> > Of course, feel free to also comment on the other open issues or to
> > raise
> > new ones. All such contributions are highly appreciated.
> >
> > Thanks,
> >
> >    Juergen
> >
> > _______________________________________________
> > eman mailing list
> > eman@ietf.org
> > https://www.ietf.org/mailman/listinfo/eman
> > _______________________________________________
> > eman mailing list
> > eman@ietf.org
> > https://www.ietf.org/mailman/listinfo/eman
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>

--001636416b9fef2de004a7f41707
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dear Juergen,

The larger manufacturers of managed power distribution=
 equipment (APC, Eaton, Raritan...) all provide circular buffers of time st=
amped power measurements.=A0 Certification of our products for use with IBM=
 System Director required this as well.


The better products allow the polling interval to be specified and prov=
ide ability for events (under currents, circuit breaker trips, etc.) to be =
reported as traps.

Our larger data center customers wanted this feat=
ure too as they realized polling thousands of devices minute by minute was =
inefficient and can yield unacceptable timing uncertainty.


Our products are able to report accurate measurements - accuracy being =
defined as how close do two or more devices agree with a calibrated referen=
ce meter when measuring the same quantity.=A0 This cannot be achieved witho=
ut considering time.


On Wed, Jul 13, 2011 at 8:52 AM, Juergen Qui=
ttek <ietf@quittek.=
at> wrote:

Dear Mouli,



Thank you for commenting on this issue. I would like to have a look at the =
following point of view:



So far, storing time series of measurements on managed nodes is rarely stan=
dardized and rarely available as implementation.



Typically, it is the job of a network management system to collect time ser=
ies and store them.



Take for example byte and packet counters at line cards. You see many curve=
s showing time series of traffic rate/volume in the Internet, but almost al=
l of them were collected at management stations or data collector modules, =
but not within MIB modules. (Please correct me if I'm wrong.)




Now the question is: Is energy management so much different from other netw=
ork management tasks, that we need the rarely used mechanism of storing tim=
e series in MIB modules?



If not, it would be sufficient to just report the number of total energy co=
nsumed since the last re-start as you do it with packet and byte counters.<=
br>
This would be just a single managed object to be specified and implemented.=




Thanks,



 =A0 =A0Juergen



Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):



> Regarding the Time Series debate - the crucial question - where is the=


> data / measurements stored.

> It would not be possible for small devices to store such data for a
> sufficiently long time period.

>

> The NMS can store the values for a sufficiently long period of time, f=
or

> trending analysis.

>

> In the case of demand measurement, since the maximum over a window is<=
br>
> computed, it is important for the device store atleast a window length=


> of measurements.

>

> I am not sure about that Requirement 5.4.10 - Time Series of Power

> Values - to be stored in the device

>

> Thanks

> Mouli

>

>

> -----Original Message-----

> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of

> Juergen Quittek

> Sent: Tuesday, July 12, 2011 2:31 PM

> To: eman mailing list

> Subject: [eman] new revision of eman requirements

>

> Dear all,

>

> I posted a new version of the eman requirements yesterday.

> Please find it at

> http://datatracker.ietf.org/doc/draft-ietf-eman-requi=
rements/

>

>

> Of course, feel free to also comment on the other open issues or to
> raise

> new ones. All such contributions are highly appreciated.

>

> Thanks,

>

> =A0 =A0Juergen

>

> _______________________________________________

> 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

ht=
tps://www.ietf.org/mailman/listinfo/eman





--001636416b9fef2de004a7f41707--

From Michael.Suchoff@raritan.com  Wed Jul 13 08:39:29 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F5D11E8113 for ; Wed, 13 Jul 2011 08:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.401
X-Spam-Level: **
X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5]
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 XgKIU7HWOiWO for ; Wed, 13 Jul 2011 08:39:28 -0700 (PDT)
Received: from fig.raritan.com (fig.raritan.com [12.144.63.197]) by ietfa.amsl.com (Postfix) with ESMTP id 21E1621F8665 for ; Wed, 13 Jul 2011 08:39:27 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Jul 2011 11:39:19 -0400
Message-ID: <9C329342B62B87498B92834DEC9FF51E0D38491E@fig.raritan.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] Comments on eman requirements
Thread-Index: AcxBXJ8uTwG0U5IKSVqhn2mACbT/OQAFTl0g
References: <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at><9C329342B62B87498B92834DEC9FF51E0D238F6F@fig.raritan.com>   <507BECE6-EE1C-4120-8D3C-B2CEEECEC76A@quittek.at>
From: "Michael Suchoff" 
To: "Juergen Quittek" , "Mouli Chandramouli \(moulchan\)" 
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2011 15:39:29 -0000

A root cause for confusion may be WG's selection of IEC 61850 as power
quality standard.  61850 is used by power stations and utilities for
medium and high voltage systems - this is not appropriate for low
voltage AC systems where this group's work will be used.

A better choice would be IEC 61000-4-30 "Testing and Measuring
Techniques - Power Quality Measurement Methods".  An examination of
power quality meters will show this is the standard to which they are
designed.



-----Original Message-----
From: Juergen Quittek [mailto:ietf@quittek.at]=20
Sent: Wednesday, July 13, 2011 8:59 AM
To: Mouli Chandramouli (moulchan)
Cc: Michael Suchoff; eman mailing list
Subject: Re: [eman] Comments on eman requirements

Hi Mouli,

Let's come back to this after we have agreed on a definition for power.
Meanwhile I will look up how IEEE and IEC define "instantaneous power",
particularly in case of AC.

Thanks,

    Juergen

Am 13.07.2011 um 12:09 schrieb Mouli Chandramouli (moulchan):

> Hi Juergen,
>=20
> I think there is some confusion on measurement - what is meant by
> instantaneous power measurement.=20
>=20
> For the sake of clarity, let us assume there is an external meter,
which
> measures the power of the electrical device at a given time instant
and
> it is possible to read the meter reading. The reported value is the
> power consumed by the device at that time - 100 watts...
>=20
> I do not think the intent is to measure Alternating Current at the
> granularity of 50 or 60 sinusoidal cycles per second. Not sure if
there
> are even devices to measure current at that level.=20
>=20
> So, the meter does the averaging internally and reports the power
> consumed at a given time. From a energy monitoring or planning
> perspective, that would seem to be adequate.=20
>=20
> Any thoughts.=20
>=20
> Thanks
> Mouli
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
Of
> Juergen Quittek
> Sent: Friday, July 08, 2011 2:17 PM
> To: Michael Suchoff
> Cc: eman mailing list
> Subject: Re: [eman] Comments on eman requirements
>=20
> Dear Michael,
>=20
> You are absolutely right.=20
> And I wrote the same story already in an earlier message:
>=20
> For AC power measurement there is always a reporting interval.
>=20
> Thanks,
>=20
>    Juergen
>=20
> Am 07.07.2011 um 17:14 schrieb Michael Suchoff:
>=20
>> AC power is not reported as an instantaneous value but as an average
-
> the minimum averaging time being 1/2 AC cycle.
>>=20
>> A plot of the instantaneous AC power is a sinusoidal waveform at 2X
> the AC power frequency.  For example, assume V =3D 100V RMS, I =3D 1A =
RMS,
> F=3D60Hz with power factor 1.0.  The power waveform would be a 120Hz
> sinusoidal with amplitude 200 and average value 100.  The average
value
> is the active (real) power.
>>=20
>> The power waveform can be explained mathematically using the product
> to sum formula we learned in high school trigonometry class....
>>=20
>> Sin(a) * sin(b) =3D .5 * (cos(a-b) - cos(a+b)
>>=20
>> "a" and "b" are frequency (phase term not shown for simplicity) which
> are identical.  Cos(a-b) =3D 0 which is the real component of power =
and
> whose average value is shown on a watt meter.  Cos(a+b) is the 2X
> frequency component whose average value is 0.
>>=20
>>=20
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
> Of JinHyeock Choi
>> Sent: Wednesday, July 06, 2011 11:09 PM
>> To: Juergen Quittek
>> Cc: eman mailing list
>> Subject: Re: [eman] Comments on eman requirements
>>=20
>> Dear Juergen
>>=20
>> thanks for kind and thoughtful reply.
>>=20
>>>> 1. Clarification of 'Power' and 'Energy'
>>>>=20
>>>> Energy management concerns both 'power' and 'energy' and
>>>> now the term 'energy consmption' is used for both,
>>>> and sometimes brings forth confusion.
>>>>=20
>>>> Maybe we can make it more clear
>>>> by attaching the unit to be measured (either watt or watthour).
>>>> For example such as
>>>> "amount of consumed energy measured by joule or watthour."
>>>=20
>>> I see your point. The alternative would be adding a clarification to
>>> the terminology section. What about appending
>>>=20
>>>  However, in this document the term "consumed energy" always refers
>>>  to an energy quantity and not to a power quantity.
>>>=20
>>> to section 2.1 Energy?
>>=20
>> fine with me.
>>=20
>> Sometimes people have trouble distinguishng 'power' and 'energy'
>> at least that's the case for me.
>> (it has been a long while since I pored over Physics textbook.)
>>=20
>> Though 'power' and 'energy' have different meanings
>> clearly defined in Physics,
>> their everyday usage can be intermingling
>> such as 'power efficiency' and 'energy efficiency'
>>=20
>>>> 2. Power/ Energy and Time
>>>> Both power and energy are time dependent parameter.
>>>>=20
>>>> When reporting 'power' or 'energy' value,
>>>> i) a specific moment or ii) a time interval
>>>> with which the measurement is made also should be provided.
>>>=20
>>> Yes, that's a good point. I think for energy measurements this is
> covered
>>> by requirement 5.5.2.  Time intervals, but for power monitoring this
> is missing.
>>>=20
>>> What about adding the following requirement?
>>> 5.4.2.  Power measurement interval
>>>=20
>>>  The energy management standard must provide means for reporting the
>>>  corresponding time interval for which a power value is reported.  A
>>>  time interval can be very short for reporting approximations of
>>>  instantaneous power or rather long for reporting demand values.
>>=20
>> In principle,
>> power itself is an instantateous value
>> and measured at a moment (not over interval).
>>=20
>> So how about rephrasing
>>=20
>>   The energy management standard must provide means for reporting the
>>   corresponding time or time interval for which a power value is
> reported.
>>   The power value can be measured at the corresponding time or
> averaged
>>   over the corresponding time interval.
>>=20
>>>> 3. Power state and Energy consumption
>>>>=20
>>>>> 5.5.3. Energy per power state
>>>>>=20
>>>>> The energy management standard must provide means for reporting
the
>>>>> consumed energy individually for each power state.
>>>>=20
>>>> Energy consumption depends on
>>>> not only 'power state' but also 'traffic load'.
>>>>=20
>>>> To make sense out of the monitored 'power' or 'energy' value,
>>>> energy management system should also take into consideration
>>>> corresponding  'traffic rate (measured by bps)' or 'accumulated
>>>> traffic (measured by bits)'.
>>>>=20
>>>> Otherwise it can't determine
>>>> whether high power consumption is from low energy efficiency
>>>> or high data traffic.
>>>=20
>>> What would be the requirement?
>>=20
>> How about
>>=20
>>   The energy management standard must provide means for reporting the
>>   consumed energy individually for each power state,
>>   with which enegy management system can derive an average expected
>>   energy consumption for each power state.
>>=20
>> to clarify the reason behind per-power state reporting
>>> A comment on the issue:
>>> Proportionality between traffic and energy is a tricky thing.
>>> I read reports on measurements at low-end routers that show
>>> decreasing energy consumption with increasing traffic.
>>=20
>> Interesting.
>> Power consumption remaining the same irrespective of traffic load
>> is not unusual but power consumption inversely proportional
>> to traffic load is a novelty.
>> Can you give me a pointer?
>>=20
>>>> 4. Power profile of powered entity
>>>>=20
>>>> For the above purpose, it would be of help
>>>> for energy management system to be aware of
>>>> the energy efficiency of each powered device (or entity),
>>>> i.e. how much energy (joule) each device consumes per bit.
>>>>=20
>>>> Ideally energy efficiency would be provided as
>>>> a power profile (or power model), a function
>>>> which maps served traffic (bits or bps) into consumed energy
(joule/
> watt).
>>>>=20
>>>> I recommend
>>>> energy efficiency or power profile
>>>> to be included to the required information in Sec 5.
>>>=20
>>> This would be a requirement for switches, routers, etc. only.
>>> For PCs, displays, light bulbs, it would not be applicable.
>>=20
>> I see.
>>=20
>>> Would it not be sufficient to just report the power and have the
> joule/bit
>>> be computed by a management system that reads the interface MIB
> modules
>>> if available?
>>=20
>> ok.
>>=20
>> For energy management,
>> power profile would be needed
>> but maybe better be acquired indirectly
>> via a kind of resolution scheme.
>>=20
>>>>> 4.2. Identifying components of powered devices
>>>>>=20
>>>>> The energy management standard must provide means for identifying
> not
>>>>> just entire devices as powered entities, but also individual
>>>>> components of powered devices.
>>>>=20
>>>> Shall we also identify (or represent) the (subordinate)
relationship
>>>> between powered device and its individual components?
>>>=20
>>> There are already standards for this available.
>>> Shall we still make a requirement out of it in order to clarify that
> this is
>>> needed for energy management as well?
>>=20
>> Such representatin of subordinate relationship would be useful
>> but I'm not sure about making it a requirement.
>> If WG doesn't have a strong opinion about it,
>> let's leave it as it is. :-)
>>=20
>>>>> 5.2.6. Maximum and average power per power state
>>>>>=20
>>>>> The energy management standard must provide means for retrieving
> the
>>>>> maximum power and the average power as a typically static property
>>>>> for each supported power state.
>>>>=20
>>>> Average power in which sense?
>>>> Just a arithmetic mean value between maximum and minimum power?
>>>=20
>>> I was thinking about the average expected energy consumption in a
> particular power state.
>>> I admit that this may be difficult to predict.
>>=20
>> yes,
>> even at the same power state,
>> enrgy consumption can vary substantially depending on traffic load.
>>=20
>>> But before asking an entity to switch to another
>>> power state it would make sense to have information about the
chances
> of saving power
>>> and for avoiding to bring the device into a state that even consumes
> more power.
>>=20
>> agree.
>>=20
>>>>> 5.4. Power
>>>>>=20
>>>>> For some network management tasks, it is required to obtain time
>>>>> series of power values (or energy consumption values).
>>>>=20
>>>> I assume energy consumption value measured by watt.
>>>> Am I right?
>>>=20
>>> No here it is either or: power or energy time series. But I see this
> is confusing.
>>> What about removing "(or energy consumption values)"?
>>=20
>> ok. thanks for clarificaiton.
>>=20
>>>>> 5.5. Energy
>>>>>=20
>>>>> In order to monitor energy consumption in different power states,
> it
>>>>> is useful if entities record their energy consumption per power
> state
>>>>> and report these quantities.
>>>>=20
>>>> Energy consumption varies according to power state and traffic
load.
>>>> How do you take 'traffic load' into consideration?
>>>=20
>>> We do not have any generic term for load. If you can provide one,
> please send it.
>>=20
>> 'bps' or '(accumulated) bit' would do for network equipments
>> such as router or switich.
>>=20
>> However, for more generic work load,
>> I don't have a good idea.
>>=20
>>>> Energy would be measured over time interval.
>>>>=20
>>>> Would time series of energy values be measured
>>>> over the sequence of time intervals in 5.5.2?
>>>=20
>>> Yes. There are different ways to do so.
>>>=20
>>> A time series can contain values that give the total energy since
the
> last re-start
>>> up to an indicated measurement time. Alternatively, you can have
time
> series of energy
>>> consumption for consecutive time intervals, one value each. Or you
> can have this for
>>> overlapping time intervals. 5.5.2 shows all of them.
>>=20
>> ok.
>>=20
>> Please allow me to split hairs
>> cocnerning the terms 'series' and 'sequence'
>> which are currently both used in in 5.5.2 and 5.5.4.
>>=20
>> Precisely speaking, in mathematics,
>> 'series' is the sum of the terms of 'sequence',
>> so in our context, 'sequence' is better.
>>=20
>> Bets regards
>>=20
>> JinHyeock
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From Quittek@neclab.eu  Wed Jul 13 11:34:05 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD2C11E80C4 for ; Wed, 13 Jul 2011 11:34:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.188
X-Spam-Level: 
X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 RxjsWtca8czI for ; Wed, 13 Jul 2011 11:34:05 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C9FE011E80C3 for ; Wed, 13 Jul 2011 11:34:01 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 4A7C928000305; Wed, 13 Jul 2011 20:33:59 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1r5aovcQpyNz; Wed, 13 Jul 2011 20:33:59 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 2E11A28000198; Wed, 13 Jul 2011 20:33:49 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.22]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Wed, 13 Jul 2011 20:33:49 +0200
From: Juergen Quittek 
To: "Mouli Chandramouli (moulchan)" , eman mailing list 
Thread-Topic: [eman] new revision of eman requirements - Open Issue - 12.16
Thread-Index: AQHMQV0Y1eth9Qp7O0OGqae6WrC4kZTqlBOA
Date: Wed, 13 Jul 2011 18:33:47 +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-Entourage/13.10.0.110428
x-originating-ip: [10.7.0.92]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0087A4B69E424E4491E8B0A7E702793C@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [eman] new revision of eman requirements - Open Issue - 12.16
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2011 18:34:05 -0000

Hi Mouli,

As stated in the requirements abstract and introduction, the requirements
are about what needs to be covered by the standard, not what in the standar=
d
should be REQUIRED, RECOMMENDED or OPTIONAL to be implemented by compliant
implementations. We will have this discussion when we do the compliance
sections of the MIB modules.

Thanks,

    Juergen

Am 13.07.11 15:01 schrieb "Mouli Chandramouli (moulchan)" unter
:

> Hi Juergen,
>=20
> I think some of the requirements 5.4.9 (impendence) 5.4.8 (total
> harmonic distortion) should be left as optional for implementation.
>=20
> Whereas Total Power, Active Power, Reactive Power, Power Factor seem to
> be of interest and thus requirements for those parameters.
>=20
> Thanks
> Mouli
>=20
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> Juergen Quittek
> Sent: Tuesday, July 12, 2011 2:31 PM
> To: eman mailing list
> Subject: [eman] new revision of eman requirements
>=20
> Dear all,
>=20
> I posted a new version of the eman requirements yesterday.
> Please find it at
> http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/
>=20
> All changes applied are based on comments on the mailing list on the
> previous version that was posted two weeks ago.
>=20
>=20
> (12.16) Is there a need for metering power supply impedance?
>    currently we have a requirement for providing means to report the
>    impedance of a power source (requirement 5.4.9). Do we really need
> this?
>=20
>=20
> Thanks,
>=20
>     Juergen
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From Michael.Suchoff@raritan.com  Wed Jul 13 11:49:59 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE1B11E8144 for ; Wed, 13 Jul 2011 11:49:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level: 
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=2.500,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wekf6OOcsKCA for ; Wed, 13 Jul 2011 11:49:58 -0700 (PDT)
Received: from fig.raritan.com (fig.raritan.com [12.144.63.197]) by ietfa.amsl.com (Postfix) with ESMTP id 0145C11E8143 for ; Wed, 13 Jul 2011 11:49:57 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Jul 2011 14:49:50 -0400
Message-ID: <9C329342B62B87498B92834DEC9FF51E0D384BEA@fig.raritan.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - Open Issue - 12.16
Thread-Index: AQHMQV0Y1eth9Qp7O0OGqae6WrC4kZTqlBOAgAACmrA=
References: 
From: "Michael Suchoff" 
To: "Juergen Quittek" , "Mouli Chandramouli \(moulchan\)" , "eman mailing list" 
Subject: Re: [eman] new revision of eman requirements - Open Issue - 12.16
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2011 18:49:59 -0000

I'm not aware of any products that measure impedance of AC power line,
nor how a device could measure it, nor of what use it is for the
intended users of this MIB.

Why was this measurement chosen, as apposed to others more useful like
inrush current, displacement power factor, crest factor, sag, surge,
etc?



-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Juergen Quittek
Sent: Wednesday, July 13, 2011 2:34 PM
To: Mouli Chandramouli (moulchan); eman mailing list
Subject: Re: [eman] new revision of eman requirements - Open Issue -
12.16

Hi Mouli,

As stated in the requirements abstract and introduction, the
requirements
are about what needs to be covered by the standard, not what in the
standard
should be REQUIRED, RECOMMENDED or OPTIONAL to be implemented by
compliant
implementations. We will have this discussion when we do the compliance
sections of the MIB modules.

Thanks,

    Juergen

Am 13.07.11 15:01 schrieb "Mouli Chandramouli (moulchan)" unter
:

> Hi Juergen,
>=20
> I think some of the requirements 5.4.9 (impendence) 5.4.8 (total
> harmonic distortion) should be left as optional for implementation.
>=20
> Whereas Total Power, Active Power, Reactive Power, Power Factor seem
to
> be of interest and thus requirements for those parameters.
>=20
> Thanks
> Mouli
>=20
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
Of
> Juergen Quittek
> Sent: Tuesday, July 12, 2011 2:31 PM
> To: eman mailing list
> Subject: [eman] new revision of eman requirements
>=20
> Dear all,
>=20
> I posted a new version of the eman requirements yesterday.
> Please find it at
> http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/
>=20
> All changes applied are based on comments on the mailing list on the
> previous version that was posted two weeks ago.
>=20
>=20
> (12.16) Is there a need for metering power supply impedance?
>    currently we have a requirement for providing means to report the
>    impedance of a power source (requirement 5.4.9). Do we really need
> this?
>=20
>=20
> Thanks,
>=20
>     Juergen
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman

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

From ietf@quittek.at  Wed Jul 13 16:31:21 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D3421F8B4F for ; Wed, 13 Jul 2011 16:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahKcLR9OmMk8 for ; Wed, 13 Jul 2011 16:31:20 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB4721F8B4C for ; Wed, 13 Jul 2011 16:31:20 -0700 (PDT)
Received: from [192.168.1.102] (HSI-KBW-109-192-090-067.hsi6.kabel-badenwuerttemberg.de [109.192.90.67]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LkDdO-1RDiUn0uZm-00cKyo; Thu, 14 Jul 2011 01:31:19 +0200
References:  <9C329342B62B87498B92834DEC9FF51E0D384BEA@fig.raritan.com>
In-Reply-To: <9C329342B62B87498B92834DEC9FF51E0D384BEA@fig.raritan.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <5C6B9EE9-0CCE-4812-9221-CF16522D8DF2@quittek.at>
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Thu, 14 Jul 2011 01:31:18 +0200
To: Michael Suchoff 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:WbS5U75N2A3XojAS7auPhPBS0kjoqF235cdnMQkzOUh WwVIrnY55ubiAvLp+24C8xDE49yTrFvt3YkOAb67K2DX/LMTZq 5kIuAbZCrVtcIZlsJ+jS1D9NEz4V5EEFuxqa6//z8chMSChRj1 /Bmx0gwnQlNxg35ufB5XRrECAAPEX5M0eeRv+Xe4FE7VttZFK3 jUAI3DUE8wM2zlzfYYXlQ==
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - Open Issue - 12.16
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2011 23:31:21 -0000

Hi Michael,

I highly appreciate your contributions.
Please see comments inline.

Am 13.07.2011 um 20:49 schrieb Michael Suchoff:

> I'm not aware of any products that measure impedance of AC power line,
> nor how a device could measure it, nor of what use it is for the
> intended users of this MIB.

Well, I think it was taken from the IEC references used so far.
But I do not yet have a copy of them. If you convince the WG it is of no =
use in our scenarios=20
I will gladly remove it. Removing unnecessary complexity is a wonderful =
thing to do.

> Why was this measurement chosen, as apposed to others more useful like
> inrush current, displacement power factor, crest factor, sag, surge,
> etc?

Now you are going for increased complexity ;-)

Do you think of measuring inrush current or would you rather like to see =
a fixed value specified by the manufacturer?
I haven't been dealing much with inrush current, but as far as I =
remember it may vary significantly depending on the exact point in time =
you switch power on and it also depends significantly on the electric =
switch that you use.

We already have the power factor in requirement 5.4.5.

Is the crest factor really varying significantly in for AC powered =
systems?
It certainly varies if you use phase cutting. But then I wonder if the =
crest factor is what you want to measure.

Wouldn't sag be covered by voltage measurements? We have this in =
requirement 5.4.6.
The same would probably hold for surge. Or are you looking for recording =
sag or surge events?

Thanks,

    Juergen



>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of
> Juergen Quittek
> Sent: Wednesday, July 13, 2011 2:34 PM
> To: Mouli Chandramouli (moulchan); eman mailing list
> Subject: Re: [eman] new revision of eman requirements - Open Issue -
> 12.16
>=20
> Hi Mouli,
>=20
> As stated in the requirements abstract and introduction, the
> requirements
> are about what needs to be covered by the standard, not what in the
> standard
> should be REQUIRED, RECOMMENDED or OPTIONAL to be implemented by
> compliant
> implementations. We will have this discussion when we do the =
compliance
> sections of the MIB modules.
>=20
> Thanks,
>=20
>    Juergen
>=20
> Am 13.07.11 15:01 schrieb "Mouli Chandramouli (moulchan)" unter
> :
>=20
>> Hi Juergen,
>>=20
>> I think some of the requirements 5.4.9 (impendence) 5.4.8 (total
>> harmonic distortion) should be left as optional for implementation.
>>=20
>> Whereas Total Power, Active Power, Reactive Power, Power Factor seem
> to
>> be of interest and thus requirements for those parameters.
>>=20
>> Thanks
>> Mouli
>>=20
>>=20
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
> Of
>> Juergen Quittek
>> Sent: Tuesday, July 12, 2011 2:31 PM
>> To: eman mailing list
>> Subject: [eman] new revision of eman requirements
>>=20
>> Dear all,
>>=20
>> I posted a new version of the eman requirements yesterday.
>> Please find it at
>> http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/
>>=20
>> All changes applied are based on comments on the mailing list on the
>> previous version that was posted two weeks ago.
>>=20
>>=20
>> (12.16) Is there a need for metering power supply impedance?
>>   currently we have a requirement for providing means to report the
>>   impedance of a power source (requirement 5.4.9). Do we really need
>> this?
>>=20
>>=20
>> Thanks,
>>=20
>>    Juergen
>>=20
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From bnordman@lbl.gov  Wed Jul 13 21:44:08 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2B521F8B3A for ; Wed, 13 Jul 2011 21:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.87
X-Spam-Level: 
X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=0.106,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goeI+Mf6JlJ3 for ; Wed, 13 Jul 2011 21:44:05 -0700 (PDT)
Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABBB21F8B35 for ; Wed, 13 Jul 2011 21:44:04 -0700 (PDT)
X-Ironport-SBRS: 4.4
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkQCAK5zHk7RVdQ0kGdsb2JhbABNBoJTnGYBiA4IFAEBAQEJCQ0HFAQhiHqkb5xugzyCfgSHU4sRjDo8g3o
X-IronPort-AV: E=Sophos;i="4.65,527,1304319600"; d="scan'208";a="45953021"
Received: from mail-vw0-f52.google.com ([209.85.212.52]) by ironport4.lbl.gov with ESMTP; 13 Jul 2011 21:44:03 -0700
Received: by vws16 with SMTP id 16so8786138vws.39 for ; Wed, 13 Jul 2011 21:44:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.92.2 with SMTP id ci2mr1998543vdb.428.1310618643346; Wed, 13 Jul 2011 21:44:03 -0700 (PDT)
Received: by 10.52.161.8 with HTTP; Wed, 13 Jul 2011 21:44:03 -0700 (PDT)
In-Reply-To: <9C329342B62B87498B92834DEC9FF51E0D384BEA@fig.raritan.com>
References:  <9C329342B62B87498B92834DEC9FF51E0D384BEA@fig.raritan.com>
Date: Wed, 13 Jul 2011 21:44:03 -0700
Message-ID: 
From: Bruce Nordman 
To: Michael Suchoff 
Content-Type: multipart/alternative; boundary=bcaec5016535ac347f04a8002e9d
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - Open Issue - 12.16
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, 14 Jul 2011 04:44:09 -0000

--bcaec5016535ac347f04a8002e9d
Content-Type: text/plain; charset=ISO-8859-1

I can't speak for other domains, but for energy efficiency,
power factor covers the vast majority of interest in power
quality.  I agree that impedance seems unwarranted.
--Bruce

On Wed, Jul 13, 2011 at 11:49 AM, Michael Suchoff <
Michael.Suchoff@raritan.com> wrote:

> I'm not aware of any products that measure impedance of AC power line,
> nor how a device could measure it, nor of what use it is for the
> intended users of this MIB.
>
> Why was this measurement chosen, as apposed to others more useful like
> inrush current, displacement power factor, crest factor, sag, surge,
> etc?
>
>
> ...
>
-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--bcaec5016535ac347f04a8002e9d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I can't speak for other domains, but for energy efficiency,
power fa=
ctor covers the vast majority of interest in power
quality.=A0 I agree t=
hat impedance seems unwarranted.
--Bruce


On Wed, Jul 13, 2011 at 11:49 AM, Michael Suchoff <Michael.Suchoff@raritan.com=
> wrote:

I'm not aware of any products that measure impedance of AC power line,<=
br>
nor how a device could measure it, nor of what use it is for the

intended users of this MIB.



Why was this measurement chosen, as apposed to others more useful like

inrush current, displacement power factor, crest factor, sag, surge,

etc?





...
-- 
Bruce Nordman
Lawrence Berkeley National=
 Laboratory
eetd.lbl.gov/ea/nordman

BNordman@LBL.gov
510-486-7089
m: 510-501-7943



--bcaec5016535ac347f04a8002e9d--

From bnordman@lbl.gov  Wed Jul 13 21:59:16 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCABD21F8B75 for ; Wed, 13 Jul 2011 21:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.883
X-Spam-Level: 
X-Spam-Status: No, score=-5.883 tagged_above=-999 required=5 tests=[AWL=0.093,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THh2iVUwWywt for ; Wed, 13 Jul 2011 21:59:13 -0700 (PDT)
Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0408F21F8B6D for ; Wed, 13 Jul 2011 21:59:12 -0700 (PDT)
X-Ironport-SBRS: 5.2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoIBAM92Hk7RVdy0mGdsb2JhbABNBoJTnGYBiA4IFAEBAQEBCAkNBxQliHqkUJxrgzyCfgSHU4sRjDo8g3o
X-IronPort-AV: E=Sophos;i="4.65,527,1304319600"; d="scan'208";a="46505143"
Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport3.lbl.gov with ESMTP; 13 Jul 2011 21:59:11 -0700
Received: by vxd7 with SMTP id 7so8674172vxd.39 for ; Wed, 13 Jul 2011 21:59:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.92.2 with SMTP id ci2mr2008053vdb.428.1310619551451; Wed, 13 Jul 2011 21:59:11 -0700 (PDT)
Received: by 10.52.161.8 with HTTP; Wed, 13 Jul 2011 21:59:11 -0700 (PDT)
In-Reply-To: <9C329342B62B87498B92834DEC9FF51E0D38491E@fig.raritan.com>
References:  <4BBF4241-77FF-41BF-8925-2A8782C8DBDA@quittek.at>  <9C329342B62B87498B92834DEC9FF51E0D238F6F@fig.raritan.com>   <507BECE6-EE1C-4120-8D3C-B2CEEECEC76A@quittek.at> <9C329342B62B87498B92834DEC9FF51E0D38491E@fig.raritan.com>
Date: Wed, 13 Jul 2011 21:59:11 -0700
Message-ID: 
From: Bruce Nordman 
To: Michael Suchoff 
Content-Type: multipart/alternative; boundary=bcaec5016535ccc87e04a800645b
Cc: eman mailing list 
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2011 04:59:17 -0000

--bcaec5016535ccc87e04a800645b
Content-Type: text/plain; charset=ISO-8859-1

I have also had difficulty with the 61850 reference.
The 61000 standard sounds promising.

Also relevant is IEC 62301 (Ed 2) which is commonly
referenced in energy efficiency standards and test
procedures.  It is intended for products of the voltage
and power levels of those mentioned in the use cases
we have discussed.

I fully agree we should have good definitions for power
and energy, but I don't think we actually have a difference
of opinion in what we want these terms to mean in practice.
I do not think that we should be particularly specific about
details of the power meaning, e.g. how many cycles the
measurement covers.  Different products may have reasons
to reference fewer or more cycles in determining the power
level.  I think we need to trust the define mfr to determine
something that is useful in addition to being correct by some
reasonable definition.  One the other hand, energy should
not have any such uncertainty.

--Bruce

On Wed, Jul 13, 2011 at 8:39 AM, Michael Suchoff <
Michael.Suchoff@raritan.com> wrote:

> A root cause for confusion may be WG's selection of IEC 61850 as power
> quality standard.  61850 is used by power stations and utilities for
> medium and high voltage systems - this is not appropriate for low
> voltage AC systems where this group's work will be used.
>
> A better choice would be IEC 61000-4-30 "Testing and Measuring
> Techniques - Power Quality Measurement Methods".  An examination of
> power quality meters will show this is the standard to which they are
> designed.
>
> ...
>

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

--bcaec5016535ccc87e04a800645b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I have also had difficulty with the 61850 reference.
The 61000 standard =
sounds promising.

Also relevant is IEC 62301 (Ed 2) which is commonl=
y
referenced in energy efficiency standards and test
procedures.=A0 I=
t is intended for products of the voltage

and power levels of those mentioned in the use cases
we have discussed.<=
br>
I fully agree we should have good definitions for power
and energ=
y, but I don't think we actually have a difference
of opinion in wha=
t we want these terms to mean in practice.

I do not think that we should be particularly specific about
details of =
the power meaning, e.g. how many cycles the
measurement covers.=A0 Diffe=
rent products may have reasons
to reference fewer or more cycles in dete=
rmining the power

level.=A0 I think we need to trust the define mfr to determine
something=
 that is useful in addition to being correct by some
reasonable definiti=
on.=A0 One the other hand, energy should
not have any such uncertainty.<=
br>

--Bruce

On Wed, Jul 13, 2011 at 8:39 =
AM, Michael Suchoff <Michael.Suchoff@raritan.com> wrote:

A root cause for confusion may be WG's selection of IEC 61850 as power<=
br>
quality standard. =A061850 is used by power stations and utilities for

medium and high voltage systems - this is not appropriate for low

voltage AC systems where this group's work will be used.



A better choice would be IEC 61000-4-30 "Testing and Measuring

Techniques - Power Quality Measurement Methods". =A0An examination of<=
br>
power quality meters will show this is the standard to which they are

designed.



...

-- 
Bruce Nordman
Lawrence Berkeley National Laboratory

eetd.lbl.gov/e=
a/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943


--bcaec5016535ccc87e04a800645b--

From jinchoe@gmail.com  Thu Jul 14 00:02:23 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FDF21F8B8C for ; Thu, 14 Jul 2011 00:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.766
X-Spam-Level: 
X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=0.833,  BAYES_00=-2.599, 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 zQCUWjV7I1fH for ; Thu, 14 Jul 2011 00:02:23 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id DBBBF21F8B85 for ; Thu, 14 Jul 2011 00:02:22 -0700 (PDT)
Received: by pvh18 with SMTP id 18so7638353pvh.31 for ; Thu, 14 Jul 2011 00:02:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DLdRRmkjznLKxa2DnGCCuPBEDw37HZGDUabrQp2J1BU=; b=dEJDruE3/LKOSpPupZ5VvPuKYgllaD4LGk/pXOZtOZFlEGt0e59Wqv0gqFzrN1eA3L gDA/+TeXknVQvpk1PzEz6Rh9Bcs2cP8OfntOHtdnTqd2qJNq8JUPqg4PcmQSSk9SILDG VP/cdtDrdG3qKzUu5XU95V9kTI8doCLVWbpgI=
MIME-Version: 1.0
Received: by 10.68.33.138 with SMTP id r10mr1276744pbi.218.1310626942476; Thu, 14 Jul 2011 00:02:22 -0700 (PDT)
Received: by 10.68.63.230 with HTTP; Thu, 14 Jul 2011 00:02:22 -0700 (PDT)
Date: Thu, 14 Jul 2011 16:02:22 +0900
Message-ID: 
From: JinHyeock Choi 
To: "John Parello (jparello)" 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: eman mailing list 
Subject: [eman] Comments on eman framework-02
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, 14 Jul 2011 07:02:23 -0000

Dear John and all

thanks for the update and here are my comments.

1. Terminology
Currently eman documents (such as requirement & framework)
use different terminologies, for example =91powered entity=92 for requireme=
nt
and =91Energy Managed Object=92 for framework. I=92m worried that
inconsistent terminologies would bring forth misunderstanding.
(As we know, anything that can confuse will.)
I ask the authors would decide on some common terms.

2. Energy control protocol
What is the protocol of choice for energy control?
For energy monitoring, SNMP (and, maybe IPFIX) is the one.
Which protocol will we use for energy control
such as modifying power state? Also SNMP?

3. EnMS communication peer
It may be better to define an entity with which EnMS communicates
for energy monitoring (or energy control).

For example, when EnMS monitors an EMO=92s energy consumption,
from which entity will EnMO get the information (via SNMP)?
The communication peer may or may not be the EMO itself.

The entity should have access to the EMO=92s energy information
and be able to report the information to EnMS (i.e IP aware).
Currently it=92s described as if EnMO talks with EnMO=92s parent,
which may not have the above capacity.

Reference-01 defined the term =91Power monitor=92 as below

   A power monitor has access to energy-related information concerning
   powered devices and is able to report this information to energy
   management systems.

which may be useful.

4. The Parent for a Children=92s Energy management
Parent & Children relationship is determined by aggregation,
metering, power source, proxy and dependency capabilities.
So a Children may have multiple Parents.
Among them, which one would be involved in Energy management,
specifically energy monitoring & control?
A Parent with Proxy relationship?

Here are some more.

> 1. Introductioon
>
> The identified device can then be monitored for Energy

I propose to
sub =91monitored for enegy=92 with =91monitored directly or indirectly for =
Energy=92
for clarification.

> 3. Terminology
>
>
> Energy Management System (EnMS)

Is abbreviation for Energy Management System
EnMS or EMS?

In below, EMS is also used.

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

EnMS or EMS?

> =A0 =A0 =A0 =A0Energy Monitoring
>
> =A0 =A0 =A0 =A0Energy Monitoring is a part of Energy Management that deal=
s with
> =A0 =A0 =A0 =A0collecting or reading measurements from devices to aid in =
Energy
> =A0 =A0 =A0 =A0Management. =A0This could include Energy, Power, Demand, Q=
uality,
> =A0 =A0 =A0 =A0Context and/or Battery information.
> =A0 =A0 =A0 =A0Energy

The last =91Energy=92, typo?

> =A0 =A0 =A0 =A0Demand
>
> =A0 =A0 =A0 =A0Demand is an average of Power measurements over an interva=
l(s)
> =A0 =A0 =A0 =A0of time and typically expressed in kilowatt hours.

Is =91Demand=92 represented by kilowatt hours,
even when it=92s an average power value (represented by watt)?

> =A0 =A0 =A0 =A0Energy Aware Object
>
> =A0 =A0 =A0 =A0An Energy Managed Object may not have the capability to pr=
ovide
> =A0 =A0 =A0 =A0information necessary for Energy Management itself. If an =
Energy
> =A0 =A0 =A0 =A0Managed Object can provide Energy Management Context, Ener=
gy
> =A0 =A0 =A0 =A0Monitor and optionally Energy Control values for itself th=
en the
> =A0 =A0 =A0 =A0Energy Managed Object is said to be an Energy Aware Object

Does =91can provide=92 mean the EMO is able to communicate with EnMS?
What if an EMO can measure it=92s energy consumption but is not IP-aware?

Also does =91Energy Awareness=92 only concern about itself?

> =A0 =A0 4. Energy Management Reference Model
>
> =A0 =A0 =A0 =A0As displayed in the Figure 2, a more complex energy refere=
nce
> =A0 =A0 =A0 =A0model includes Energy Managed Object Parents and Children.=
 =A0The
> =A0 =A0 =A0 =A0Energy Managed Object Parent returns information for thems=
elves
> =A0 =A0 =A0 =A0as well as information according to the Energy Managed Obj=
ect
> =A0 =A0 =A0 =A0Relationships.

Not all Parent can return information for their Children.
Only a Parent with the Children=92s energy information and SNMP module can.
A power source may be a non-IP device.

> =A0 =A0 5.4. Energy Monitoring
>
> =A0 =A0 =A0 =A0Each Energy Managed Object will have information that desc=
ribes
> =A0 =A0 =A0 =A0Power and Energy information along with how that measureme=
nt was
> =A0 =A0 =A0 =A0obtained or derived.

Not all EMO has its own energy-related information.

With the term of =91power monitor=92, we may rephrase this as

    Each Power Monitor (possibly Proxy Parent)
    associated with an Energy Managed Object,
    will have the information of the EMO that describes.....

> =A0 =A0 =A0 =A0Power Measurement
>
> =A0 =A0 =A0 =A0In addition, the Energy Managed Object should describe how=
 it
> =A0 =A0 =A0 =A0intends to measure Power as one of consumer, producer or m=
eter
> =A0 =A0 =A0 =A0of usage. =A0Given the intent readings can be summarized o=
r
> =A0 =A0 =A0 =A0analyzed by an EMS. =A0For example metered usage reported =
by a
> =A0 =A0 =A0 =A0meter and consumption usage reported by a device connected=
 to
> =A0 =A0 =A0 =A0that meter may naturally measure the same usage. =A0With t=
he two
> =A0 =A0 =A0 =A0measurements identified by intent a proper summarization c=
an be
> =A0 =A0 =A0 =A0made by an EMS.

With this differentiated power measurement,
one EMO (such as PoE switch) can have multiple energy values,
for example one as a consumer and another as a provider.
The concept of =91power interface (inlet & outlet)=92
proposed in reference I-D may be of help.

> =A0 =A0 5.5. Energy Control
>
> =A0 =A0 =A0 =A0Energy Managed Objects can be controlled by setting it to =
a
> =A0 =A0 =A0 =A0Power State. Sets of Power States can be seen as an interf=
ace by
> =A0 =A0 =A0 =A0which an Energy Managed Object can be controlled.

With which protocol will EnMS set power state? SNMP?

> =A0 =A0 =A0 =A0When and individual Power State is configured from a speci=
fic

typo, sub =91and=92 with =91an=92

thanks for your kind consideration.

Best regards

JinHyeock

From bnordman@lbl.gov  Thu Jul 14 00:28:25 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21ADD21F8AEC for ; Thu, 14 Jul 2011 00:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.593
X-Spam-Level: 
X-Spam-Status: No, score=-4.593 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46g3+7cnxuAJ for ; Thu, 14 Jul 2011 00:28:21 -0700 (PDT)
Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id E4E9621F8B53 for ; Thu, 14 Jul 2011 00:28:20 -0700 (PDT)
X-Ironport-SBRS: 5.2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApUBADuZHk7RVdy0mGdsb2JhbABFAQcGglOWAAGGZQGIDwgUAQEBAQEICQ0HFCWtEJx0gyIBGYJ+BIdTixGMOjyDehw
X-IronPort-AV: E=Sophos;i="4.65,527,1304319600"; d="scan'208";a="45958665"
Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport4.lbl.gov with ESMTP; 14 Jul 2011 00:28:16 -0700
Received: by vxd7 with SMTP id 7so8773427vxd.39 for ; Thu, 14 Jul 2011 00:28:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.73.170 with SMTP id m10mr1692024vdv.160.1310628496461; Thu, 14 Jul 2011 00:28:16 -0700 (PDT)
Received: by 10.52.161.8 with HTTP; Thu, 14 Jul 2011 00:28:16 -0700 (PDT)
Date: Thu, 14 Jul 2011 00:28:16 -0700
Message-ID: 
From: Bruce Nordman 
To: eman mailing list 
Content-Type: multipart/alternative; boundary=bcaec5016643f6cefc04a802794a
Subject: [eman] Framework draft comments
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2011 07:28:25 -0000

--bcaec5016643f6cefc04a802794a
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

This is not an exhaustive list of my comments, but only major ones.



Issues beyond this draft



In some cases we speak to covering entire devices as well as arbitrary

components (entities) of devices.  However, the use cases and other

discussions/examples are overwhelmingly only about entire devices.

The perceived need to cover components in addition to devices has

led to terminology such as =93object=94 and =93entity=94.  I think EMAN is =
primarily

about entire devices and many features only applicable (well or at all)

to them and not to components.  I think we should recast the requirements

and framework to be device centric, and then add limited reporting of

information about components to this.  The component reporting does

seem legitimate in niche applications.   Note that devices such as a blade

server chassis can be reported as a set of devices, with each blade server

a separate device, even if they are DC-powered.  Each server has its own

basic network presence.  The chassis may also consume power, but this

is just like a PoE switch.



A critical need for effective energy management is for devices to report

basic information about their identity in a general sense (not their networ=
k

identify specifically).  This is data such as brand and model, as well as

a standard classification of device type.  This needs to be clearly stated

in the applicability statement, requirements, framework, and in a MIB.



Overall comments



In general, I believe that the approach outlined in the current version of

the =93reference model=94 draft (draft-quittek-eman-reference-model-02) has

significant advantages over that presented in the framework draft.

The reference model is more general, flexible, and ultimately simpler.

It enables exposing details of power distribution topology when needed,

and does not require this when not.



Some of the language in the draft seems more like requirements, and so

should be moved to that document (e.g. Section 5.4).  Some of the

discussion at the beginning of section 5 is really more appropriate to
Applicability.



There should be explicit mention of the possibility of multiple =93parents=
=94

and multiple EMSes.  Similarly, it should be clarified that there is no
limit

to the number of levels of devices that report on subsidiary devices,

and/or aggregate information about them.  All the examples show only

a single level of this.



Any support for demand or time-series data should be clearly identified

as optional and not burdened by complexity.  For example, only a single

series should be addressed (e.g. not consider multiple EMSes requesting

conflicting lengths of time periods).





Terminology



=93Energy Management Domain=94 =96 Section 6 uses the term =93Meter Domain=
=94

which seems much more appropriate for this concept since having a

meter at the root is at its core.  Also, the discussion should clarify how

=93nested=94 meter domains should be treated.



=93Power State=94.  A better definition can be found in IEEE 1621:

=933.1.7 power state: A condition or mode of a device that broadly

characterizes its capabilities, power consumption, power indicator

coding, and responsiveness to input.=94





Specifics



For aggregation, the rationale for summation seems much more solid than

for the other metrics mentioned under =93aggregation relationship=94 and th=
ese

others are readily calculable from the full data set and so not needed.



The definition of =93Proxy relationship=94 seems to combine two distinct

issues =96 one device reporting data for a second device, and translating

from non-IP/EMAN domains to EMAN.  Reporting on a second device is

useful regardless of whether the second device can directly report on

itself or not, so the two functions should be kept distinct.

In line with this, it is specified that the communication between a parent

and child is out of scope for EMAN.   Many devices will get information

from a subsidiary device with the EMAN protocol and then report that.

It seems unnecessary to have both the =93proxy=94 and =93parent/child=94 co=
ncepts;

the former seems a better choice.



It would be helpful if someone would write down the implications of using

IPFIX to transmit EMAN data.  Some or all of this would be helpful for the

Applicability statement to help those not well versed in IETF protocols to

know how it can be used.  Also, does enabling IPFIX to be used require any

content in our drafts?



The description of IEEE 1621 power states is not from 1621.  The definition=
s

in 1621 are not actually so useful or relevant here =96 the important point=
 is

that a device can categorize its states into the three basic power state

categories.



Section 5.5.2 =96 This section lists the full set of DMTF states then inclu=
des
a

table of only a subset.  It needs to be clarified which the standard is
intended

to cover.  Also, it should be noted that to date, products do not implement

either S1 or S2, so that the actual ACPI (and by extension DMTF) series is

smaller than the official listing suggests.



Section 5.5.3 =96 There is nothing specific to EMAN in this series so it
should

not be named this way.  For state details, one can only be =93awakened=94 f=
rom

a sleep state, not an off state.   IEEE 1621 maps hibernate to off, not
sleep.

The term =93standby=94 is inherently confusing and should not be included i=
n

EMAN documents.

Also, all of the divisions of states within the On state are completely
arbitrary,

and really reflect different levels of activity within the On state, and no=
t

different power states.  If level of activity is of interest, it should be
reported

as its own variable, not conflated with the distinct concept of power state=
.





--Bruce (as contributor;  note: I will be off email Mon-Sat / July 18-23)


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

--bcaec5016643f6cefc04a802794a
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


















<=
font size=3D"1">This is not an exhaustive list of my comments, but only
major ones.


=A0



Issues beyond this draft



=A0



In some cases we speak to covering entire d=
evices as well as
arbitrary



components (entities) of devices.=A0 =
However, the use cases and other



discussions/examples are overwhelmingly onl=
y about entire
devices.



The perceived need to cover components in a=
ddition to
devices has



led to terminology such as =93object=94 and=
 =93entity=94.=A0 I think EMAN is primarily



about entire devices and many features only=
 applicable (well
or at all)



to them and not to components.=A0 I think we should recast the requirements



and framework to be device centric, and the=
n add limited
reporting of



information about components to this.=
=A0 The component reporting does



seem legitimate in niche applications.=A0=A0 Note that devices such as a blade



server chassis can be reported as a set of =
devices, with
each blade server



a separate device, even if they are DC-powe=
red.=A0 Each server has its own



basic network presence.=A0 The=
 chassis may also consume power, but this



is just like a PoE switch.



=A0



A critical need for effective energy manage=
ment is for
devices to report



basic information about their identity in a=
 general sense
(not their network



identify specifically).=A0 Thi=
s is data such as brand and model, as well as



a standard classification of device type.=A0 This needs to be clearly stated
<=
span style=3D"font-family: arial,helvetica,sans-serif;">


in the applicability statement, requirement=
s, framework, and
in a MIB.



=A0



Overall comments



=A0



In general, I believe that the approach out=
lined in the
current version of 
the =93reference model=94=
 draft (draft-quittek-eman-reference-model-02)
has



significant advantages over that presented =
in the framework
draft.



The reference model is more general, flexib=
le, and
ultimately simpler.



It enables exposing details of power distri=
bution topology
when needed,



and does not require this when not.<=
/p>=A0



Some of the language in the draft seems mor=
e like
requirements, and so



should be moved to that document (e.g. Sect=
ion 5.4).=A0 Some of the 



discussion at the beginning of section 5 is=
 really more appropriate
to Applicability.



=A0



There should be explicit mention of the pos=
sibility of
multiple =93parents=94



and multiple EMSes.=A0
Similarly, it should be clarified that there is no limit
<=
font size=3D"1">


to the number of levels of devices that rep=
ort on subsidiary
devices,



and/or aggregate information about them.=A0 All the examples show only



a single level of this.



=A0



Any support for demand or time-series data =
should be clearly
identified



as optional and not burdened by complexity.=
=A0 For example, only a single



series should be addressed (e.g. not consid=
er multiple EMSes
requesting



conflicting lengths of time periods).



=A0



=A0



Terminology



=A0



=93Energy Management Domain=94 =96 Section =
6 uses the term =93Meter
Domain=94



which seems much more appropriate for this =
concept since
having a



meter at the root is at its core.=A0 =
Also, the discussion should clarify how
<=
span style=3D"font-family: arial,helvetica,sans-serif;">


=93nested=94 meter domains should be treate=
d.



=A0



=93Power State=94.=A0
A better definition can be found in IEEE 1621:



=933.1.7 power state: A condition or mode o=
f a device that
broadly 



characterizes its capabilities, power consu=
mption, power
indicator 



coding, and responsiveness to input.=94



=A0



=A0



Specifics



=A0



For aggregation, the rationale for summatio=
n seems much more
solid than



for the other metrics mentioned under =93ag=
gregation
relationship=94 and these



others are readily calculable from the full=
 data set and so
not needed.



=A0



The definition of =93Proxy relationship=94 =
seems to combine two
distinct 



issues =96 one device reporting data for a =
second device, and
translating



from non-IP/EMAN domains to EMAN.=A0 =
Reporting on a second device is



useful regardless of whether the second dev=
ice can directly
report on



itself or not, so the two functions should =
be kept distinct.



In line with this, it is specified that the=
 communication
between a parent



and child is out of scope for EMAN.=
=A0=A0 Many devices will get information
=



from a subsidiary device with the EMAN prot=
ocol and then
report that.



It seems unnecessary to have both the =93pr=
oxy=94 and
=93parent/child=94 concepts;



the former seems a better choice.


=A0



It would be helpful if someone would write =
down the
implications of using



IPFIX to transmit EMAN data.=A0 Some or all of this would be helpful for the
<=
span style=3D"font-family: arial,helvetica,sans-serif;">


Applicability statement to help those not w=
ell versed in
IETF protocols to



know how it can be used.=A0 Al=
so, does enabling IPFIX to be used require any
<=
span style=3D"font-family: arial,helvetica,sans-serif;">


content in our drafts?



=A0



The description of IEEE 1621 power states i=
s not from
1621.=A0 The definitions



in 1621 are not actually so useful or relev=
ant here =96 the
important point is



that a device can categorize its states int=
o the three basic
power state



categories.



=A0



Section 5.5.2 =96 This section lists the fu=
ll set of DMTF
states then includes a



table of only a subset.=A0 It =
needs to be clarified which the standard is intended



to cover.=A0 Also,
it should be noted that to date, products do not implement



either S1 or S2, so that the actual ACPI (a=
nd by extension
DMTF) series is



smaller than the official listing suggests.=




=A0



Section 5.5.3 =96 There is nothing specific=
 to EMAN in this
series so it should



not be named this way.=A0
For state details, one can only be =93awakened=94 from 



a sleep state, not an off state.=A0=
=A0 IEEE 1621 maps hibernate to off, not sleep.



The term =93standby=94 is inherently confus=
ing and should not be
included in



EMAN documents.
=



Also, all of the divisions of states within=
 the On state are
completely arbitrary,



and really reflect different levels of acti=
vity within the
On state, and not



different power states.=A0 If =
level of activity is of interest, it should be reported



as its own variable, not conflated with the=
 distinct concept
of power state.



=A0



=A0



--Bruce (as contributor;=A0 no=
te: I will be off email Mon-Sat / July 18-23)





-- 
Bruce NordmanLawrence Berkeley National Laborator=
y
ee=
td.lbl.gov/ea/nordman

BNordman@LBL.gov
510-486-7089
m: 510-501-7943



--bcaec5016643f6cefc04a802794a--

From jinchoe@gmail.com  Thu Jul 14 02:15:12 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5AE21F8AE1 for ; Thu, 14 Jul 2011 02:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.974
X-Spam-Level: 
X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=0.625,  BAYES_00=-2.599, 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 CJFQ7CP7M1sl for ; Thu, 14 Jul 2011 02:15:12 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id E802321F8AD8 for ; Thu, 14 Jul 2011 02:15:11 -0700 (PDT)
Received: by pvh18 with SMTP id 18so79771pvh.31 for ; Thu, 14 Jul 2011 02:15:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WsEt+3NCu0LqKP32rOm6xTH9A19XFle7nNaYIDi/Oqk=; b=OS9NoCsg/46m2T/fC5yntKoYQxP5JTvOPg0ud59QLCR4ZvpDNKmHmyRQwEi88GcecP Z2OMsFHbDlr86r33AwMv/7OBpANM7/FpxISklnmwKecRE/siSIDABWcNdxZOHscF6LQp oMpXPOVIcbNVzngBtXIIgUKPntW7x+bOCZ3r8=
MIME-Version: 1.0
Received: by 10.68.33.138 with SMTP id r10mr1416241pbi.218.1310634911474; Thu, 14 Jul 2011 02:15:11 -0700 (PDT)
Received: by 10.68.63.230 with HTTP; Thu, 14 Jul 2011 02:15:11 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 14 Jul 2011 18:15:11 +0900
Message-ID: 
From: JinHyeock Choi 
To: Juergen Quittek 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: eman mailing list 
Subject: Re: [eman] new reference model based on power interfaces
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, 14 Jul 2011 09:15:12 -0000

Juergen

thanks for your trouble for the update.

The concept of power interface is of interests and
make me see in a new perspective.

Here are some quick comments.

1. Power monitor

> We call a device with one or more power interfaces in inlet mode a powere=
d
> entity (PE), and a device with one or more power interfaces in outlet mod=
e a
> power source (PS). If there is metering capability, we call it a power me=
ter
> (PM). No more terms are needed!

We don=92t even need the term =91Power Monitor=92 defined as below?

  A power monitor has access to energy-related information concerning
  powered devices and is able to report this information to energy
  management systems.

For monitoring, we should be able to
i) measure energy value (such as power state) and
ii) report the value to Energy Management System (EMS).

The above two can be performed by separate entities,
for example, power value measured by power meter,
then reported by home gateway to EMS.

PM may have the the first capacity but not always the second.
IMO, the term =91power monitor=92 is of help.

We may define =91power controller=92 similarly for power control.

2. Required information
Requirement I-D defines required information in Sec 5
such as general information, power state, power & energy.

Is there an entity to
i) keep all required information &
ii) report to EMS?

In the current draft,
PM can measure (actual) power & energy consumption for a PE
but may have no idea about the PE=92s power state.
Which entity would collect energy consumption
& power state information to report to EMS?
Or the PM and PE make EMS a separate report?

Finally I wish this draft would be alighted with framework-02.
(I had assumed the I-D would be merged with the framework.)
Both I-Ds treat the same area (reference & information model)
but with substantial difference. For example, here
Energy Management Domain or Context is hardly mentioned
in information model.

Thanks for your kind consideration.

Best regards

JinHyeock



On Tue, Jul 12, 2011 at 11:28 PM, Juergen Quittek  wrote=
:
> Dear all,
>
> Just before the deadline Bruce and I posted a new version -02 of the
> reference model for energy management. Please find it at
> http://datatracker.ietf.org/doc/draft-quittek-eman-reference-model/
>
> The previous version -01 was based on boxes and functions. It was much ab=
out
> which service is provided where. The result was a long list of new terms
> such as power state monitor and power supply controller. The resulting mo=
del
> was usable for explaining the things we want to do in eman, but big and
> complex. Also the model in the framework document does not seem to be sim=
ple
> and Internet-style.
>
> That's why there is an entire new model in the new version -02 of the
> reference model draft which is much simpler and much closer to existing I=
ETF
> concepts.
>
> The new model is very short and is based on the concept of power interfac=
es.
> We see power interfaces as very similar to network interfaces. They conne=
ct
> a device to a shared (power) transmission medium, the power line. A power
> interface can be in mode inlet or outlet and it may have metering
> capabilities. Finally, it can (if available) provide information on other
> devices connected to the same medium. This is already almost all that is
> needed.
>
> We call a device with one or more power interfaces in inlet mode a powere=
d
> entity (PE), and a device with one or more power interfaces in outlet mod=
e a
> power source (PS). If there is metering capability, we call it a power me=
ter
> (PM). =A0No more terms are needed!
>
> The concept of a power interface has been adopted from the Power over
> Ethernet specification where powered devices (PDs) and power sourcing
> equipment (PSE) are connected to shared transmission media via power
> interfaces.
>
> Integration of energy management into existing NMS systems becomes much
> simpler than with models we discussed before, because the concept is very
> similar to the concept of network interfaces and thus similar structures =
in
> MIB modules and NMS systems can be used. Also a MIB module according to t=
he
> new model would become much simpler than the ones we already have.
>
> If you still want to compare it to the previous model, you will find it i=
n
> the Appendix of the new draft (that's why it is so long).
>
> Unfortunately, time was not enough to fully explain all details of the ne=
w
> model sufficiently. We will update the draft soon with full explanations.
>
> Of course, comments are highly appreciated.
>
> Thanks,
>
> =A0 =A0Juergen
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>

From moulchan@cisco.com  Thu Jul 14 04:25:07 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EA721F8ABB for ; Thu, 14 Jul 2011 04:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.558
X-Spam-Level: 
X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1sh1Rls2OHV for ; Thu, 14 Jul 2011 04:25:05 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB5321F87A5 for ; Thu, 14 Jul 2011 04:25:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=11491; q=dns/txt; s=iport; t=1310642705; x=1311852305; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=3atLQLdqKedgTwU7zzQ02ngJtnzTOR0+3ykSOvz8hPw=; b=JPuflo6OhOT9svfD6e8+j9dekOHaKxM9vXh5nRpEDoOsscKxs4zx2DW6 nntsyjkKQ5RQXf8gK398hz95cLYgVbqwWvXrTn8dPvGCVFM+zOd5grAYy RZsZndqx0R0/VoV0ZXPEhDlhg93NxjiFb8cE6JaWnmtlKvzG9/83WHLB1 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuIAAHnRHk6tJXHB/2dsb2JhbABTmBKPQHesGJ4YhVtfBIdTkBqLZg
X-IronPort-AV: E=Sophos;i="4.65,528,1304294400"; d="scan'208,217";a="2872109"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 14 Jul 2011 11:25:04 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p6EBP4N8025816;  Thu, 14 Jul 2011 11:25:04 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 14 Jul 2011 06:25:04 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4218.AD5BE881"
Date: Thu, 14 Jul 2011 06:25:02 -0500
Message-ID: 
In-Reply-To: <791AD3077F94194BB2BDD13565B6295D1CFBAF43@DAPHNIS.office.hd>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] updated version of the battery MIB
Thread-Index: Acw8nMCIvCGzz09FQg+FKwbZ9WYHGgFejXLA
References: <791AD3077F94194BB2BDD13565B6295D1CFBAF43@DAPHNIS.office.hd>
From: "Mouli Chandramouli (moulchan)" 
To: "Rolf Winter" , 
X-OriginalArrivalTime: 14 Jul 2011 11:25:04.0253 (UTC) FILETIME=[AD6382D0:01CC4218]
Subject: Re: [eman] updated version of the battery MIB
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2011 11:25:07 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4218.AD5BE881
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I had a quick look at the new battery MIB module=20
The first comment deals with the index and others are nits.=20


1.     Firstly,  given that the battery  provides backup power for a
device and there should be a reference (index) =20
       to the device  for which the battery is providing back-up power.
Otherwise, the MIB module seems as a standalone ?=20

       There is a link of the batteryIndex to the entPhysicalIndex ;
Where do you assume that the entityMIB is implemented ?  =20
       What is the device ? How is that device identified ? What if
entityMIB is not implemented ?=20


2.     is battery temperature - is this relevant for EMAN ?   +-- r-n
Integer32   batteryTemperature(14)=20

3.     the name of the object can be renamed - batteryCurrentCurrent  ?


4.     the notion of batteryType - primary (not  being rechargeable) is
confusing - and the secondary Is  only rechargeable ? =20

5.     The reference to be updated.   [I-D.ietf-eman-framework]
"Claise, B., Parello, J., and L. Silver, "Energy Management  Framework",
draft-ietf-eman-framework-01 (work in  progress), March 2011."
=20

Thanks
Mouli

PS: I had posted a review of the MIB module long back and most of my
comments still apply.=20

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


-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Rolf Winter
Sent: Thursday, July 07, 2011 5:25 PM
To: eman@ietf.org
Subject: [eman] updated version of the battery MIB

Hi,

we just posted a new version of the battery MIB. It contains the
following changes:

- we added objects for the maximum charging current, the recommended
current to be used for trickle charging and a notification for battery
- we adopted the cycle definition of the Smart Battery Data
Specification
- the former takes care of two open issues, we removed the one on
battery health as we e.g. have the cycle count as an approximate metric
for this and some other information in the MIB
- We added a new open issue asking how close we should align in general
to the Smart Battery Data Specification

These are the main changes in this version. I think we make very good
progress on this document. Thanks a lot for all the input received so
far. We would appreciate any further comments, so please keep them
coming.

Best,

Rolf


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014=20


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

------_=_NextPart_001_01CC4218.AD5BE881
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






RE: [eman] updated version of the battery MIB





Hi,



I had a quick =
look at the new battery MIB module 



The =
first comment deals with the index and others are nits. =










1.     Firstly,  given that the =
battery  provides backup power for a device and there should be a =
reference (index)  



       to the device  for which =
the battery is providing back-up power. Otherwise, the MIB module seems =
as a standalone ? 



       There is a link of the =
batteryIndex to the entPhysicalIndex ; Where do you assume that the =
entityMIB is implemented ?   



       What is the device ? How =
is that =
device =
identified ? What if entityMIB is not implemented =
? 





2.     is battery temperature =
– is this relevant for EMAN ?   +-- r-n =
Integer32   batteryTemperature(14) 



3.     the name of the object can =
be renamed - batteryCurrentCurrent  ?  



4.     the notion of batteryType – =
primary (not  being rechargeable) is confusing – and the =
secondary Is  only rechargeable ?  



5.     The reference to be =
updated.   [I-D.ietf-eman-framework]   =
“Claise, B., Parello, J., and L. =
Silver, "Energy Management  Framework", =
draft-ietf-eman-framework-01 (work in  progress), March =
2011.”



 



Thanks



Mouli






PS: I had posted a review of the MIB =
module long back and most of my comments still apply. 



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






-----Original =
Message-----

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] =
On Behalf Of Rolf Winter

Sent: Thursday, July 07, 2011 5:25 PM

To: eman@ietf.org

Subject: [eman] updated version of the battery MIB



Hi,



we just posted =
a new version of the battery MIB. It contains the following =
changes:



- we added =
objects for the maximum charging current, the recommended current to be =
used for trickle charging and a notification for =
battery



- we adopted =
the cycle definition of the Smart Battery Data =
Specification



- the former =
takes care of two open issues, we removed the one on battery health as =
we e.g. have the cycle count as an approximate metric for this and some =
other information in the MIB



- We added a =
new open issue asking how close we should align in general to the Smart =
Battery Data Specification



These are the =
main changes in this version. I think we make very good progress on this =
document. Thanks a lot for all the input received so far. We would =
appreciate any further comments, so please keep them =
coming.



Best,



Rolf





NEC Europe =
Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | =
Registered in England 2832014 





_______________________________________________<=
/SPAN>



eman mailing =
list



eman@ietf.org



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




------_=_NextPart_001_01CC4218.AD5BE881--

From Rolf.Winter@neclab.eu  Thu Jul 14 04:52:38 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEE121F8789 for ; Thu, 14 Jul 2011 04:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.141
X-Spam-Level: 
X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 54ZRZDvInmjX for ; Thu, 14 Jul 2011 04:52:37 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A9C9D21F8785 for ; Thu, 14 Jul 2011 04:52:37 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id E5BB728000328; Thu, 14 Jul 2011 13:52:36 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwiEwbC4G00n; Thu, 14 Jul 2011 13:52:36 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id CB66D28000305; Thu, 14 Jul 2011 13:52:26 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.22]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Thu, 14 Jul 2011 13:52:27 +0200
From: Rolf Winter 
To: "Mouli Chandramouli (moulchan)" , "eman@ietf.org" 
Thread-Topic: [eman] updated version of the battery MIB
Thread-Index: Acw8nMCIvCGzz09FQg+FKwbZ9WYHGgFejXLAAAEVM/A=
Date: Thu, 14 Jul 2011 11:52:25 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D1CFC707E@DAPHNIS.office.hd>
References: <791AD3077F94194BB2BDD13565B6295D1CFBAF43@DAPHNIS.office.hd> 
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.6.28]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [eman] updated version of the battery MIB
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2011 11:52:38 -0000

Hi Mouli,=20

thanks for your feedback. I was under the impression that many of the issue=
s that you raised were commented on and solved. See some comments inline. I=
'll dig through the other ones later.

>=20
> 2.     is battery temperature - is this relevant for EMAN ?   +-- r-n
> Integer32   batteryTemperature(14)

We think yes. The battery temperature is also part of UPS MIB e.g. Even on =
Android devices you can extract the battery temperature via Python e.g. So =
it seems implemented and relevant. Bill mentioned some time ago that he thi=
nks it is important for safety and battery lifetime. If you disagree please=
 justify.

=20
> 3.     the name of the object can be renamed - batteryCurrentCurrent  ?

What do you have in mind?

=20
> 4.     the notion of batteryType - primary (not  being rechargeable) is
> confusing - and the secondary Is  only rechargeable ?

Wikipedia: " There are two types of batteries: primary batteries (disposabl=
e batteries), which are designed to be used once and discarded, and seconda=
ry batteries (rechargeable batteries),". Could you please be more concrete =
about what causes the confusion. Is it the terms? Our text?=20

>=20
> 5.     The reference to be updated.   [I-D.ietf-eman-framework]
> "Claise, B., Parello, J., and L. Silver, "Energy Management  Framework",
> draft-ietf-eman-framework-01 (work in  progress), March 2011."
>=20

Easy one.

>=20
> Thanks
>=20
> Mouli
>=20
> PS: I had posted a review of the MIB module long back and most of my
> comments still apply.
>=20
> http://www.ietf.org/mail-archive/web/eman/current/msg00494.html
> 
>=20


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London =
W3 6BL | Registered in England 2832014

From ietf@quittek.at  Thu Jul 14 08:41:47 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4968221F8B06 for ; Thu, 14 Jul 2011 08:41:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=0.555,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 1NRkFYpdnYUJ for ; Thu, 14 Jul 2011 08:41:46 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id C295B21F8B33 for ; Thu, 14 Jul 2011 08:41:42 -0700 (PDT)
Received: from [195.37.70.172] ([195.37.70.172]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0LnpjI-1RA8Dm0gWm-00fwWq; Thu, 14 Jul 2011 17:41:34 +0200
References: <791AD3077F94194BB2BDD13565B6295D1CFBAF43@DAPHNIS.office.hd> 
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-2--509071480
Message-Id: 
From: Juergen Quittek 
Date: Thu, 14 Jul 2011 17:41:33 +0200
To: Mouli Chandramouli (moulchan) 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:mJe77X1qvQVaYR2tEzvADdbkklNnEevc7NtVO4j0Le8 PmNwwER59WdxEacvITuMBnH2O1GlAsVpdRGcsnssRZlisHvJ35 V63VnJ9rW1m7uLFNi2/05LdVFz1/b9p/vjndTUVRjQHkEyt8SO OUeOoNtq6h1zQpIceqaCk1dEWX0aKixp9Zmld+widXCol3Vt7o rVDvIVZBSj/m4Z3MtmVbw==
Cc: eman@ietf.org
Subject: Re: [eman] updated version of the battery MIB
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2011 15:41:47 -0000

--Apple-Mail-2--509071480
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi Mouli,

Thank you for your comments.

Am 14.07.2011 um 13:25 schrieb Mouli Chandramouli (moulchan):
> Hi,
>=20
> I had a quick look at the new battery MIB module
>=20
> The first comment deals with the index and others are nits.
>=20
> 1.     Firstly,  given that the battery  provides backup power for a =
device and there should be a reference (index)=20
>=20
>        to the device  for which the battery is providing back-up =
power. Otherwise, the MIB module seems as a standalone ?
>=20
>        There is a link of the batteryIndex to the entPhysicalIndex ; =
Where do you assume that the entityMIB is implemented ? =20
>=20
>        What is the device ? How is that device identified ? What if =
entityMIB is not implemented ?
>=20
I think the most common case is that the battery is contained in a =
device and the device reports about its battery.

You can see the battery as a component of a device such as a CPU or a =
line card.  If you write a MIB module for the line card or for the CPU, =
you woudn't have a pointer in your MIB module pointing to the device =
that the line card or CPU is contained in, would you? That is because =
the device hosting the line card or CPU is the same device hosing the =
implementation of the MIB module. I don't see a problem here. But maybe =
you envision other scenarios where this is a problem?


If the device hosting the battery implements the Entity MIB and has the =
battery listed as an entity, then of course can we support it.
> 2.     is battery temperature =96 is this relevant for EMAN ?   +-- =
r-n Integer32   batteryTemperature(14)
>=20
It is not necessary for energy management. But it is important for =
battery management.
> 3.     the name of the object can be renamed - batteryCurrentCurrent  =
?=20
>=20
You talk about renaming the name? This sounds almost like current =
current :-)
But seriously, what would be your proposal?
> 4.     the notion of batteryType =96 primary (not  being rechargeable) =
is confusing =96 and the secondary Is  only rechargeable ?=20
>=20
Well, if you are dealing with batteries, the technically correct terms =
for the two basic kinds are 'primary battery' and 'secondary battery'.
Secondary batteries are rechargeable, primary batteries are not.=20
> 5.     The reference to be updated.   [I-D.ietf-eman-framework]   =
=93Claise, B., Parello, J., and L. Silver, "Energy Management  =
Framework", draft-ietf-eman-framework-01 (work in  progress), March =
2011.=94
>=20
>=20
Yes. That's really strange. In the XML we reference the draft correctly. =
There must be a wrong entry in the database we use for generating the =
references. We'll check for the next version.
> Thanks
>=20
> Mouli
>=20
> PS: I had posted a review of the MIB module long back and most of my =
comments still apply.
>=20
> http://www.ietf.org/mail-archive/web/eman/current/msg00494.html
>=20
Yes, right. But all of them seem to be answered with what I wrote in the =
replies above.

Thanks,

    Juergen


--Apple-Mail-2--509071480
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Hi =
Mouli,

Thank you for your =
comments.

Am 14.07.2011 um 13:25 schrieb Mouli =
Chandramouli (moulchan):




Hi,
I had a quick =
look at the new battery MIB module 
The =
first comment deals with the index and others are =
nits.
1.     Firstly,  given that the =
battery  provides backup power for a device and there should be a =
reference (index)  
       to the device  for which =
the battery is providing back-up power.=
 Otherwise, the MIB module seems as a =
standalone ? 
       There is a link of the =
batteryIndex to the entPhysicalIndex ; =
Where do you assume that the =
entityMIB is implemented ?   
       What is the device ? How =
is that =
device =
identified ? What if entityMIB is not implemented =
? 
I =
think the most common case is that the battery is contained in a device =
and the device reports about its battery.

You =
can see the battery as a component of a device such as a CPU or a line =
card.  If you write a MIB module for the line card or for the CPU, =
you woudn't have a pointer in your MIB module pointing to the device =
that the line card or CPU is contained in, would you? That is because =
the device hosting the line card or CPU is the same device hosing the =
implementation of the MIB module. I don't see a problem here. But maybe =
you envision other scenarios where this is a =
problem?

If the device =
hosting the battery implements the Entity MIB and has the battery listed =
as an entity, then of course can we support it.
2.     is battery temperature =96 =
is this relevant for EMAN ?   +-- r-n Integer32   =
batteryTemperature(14) 
It is not =
necessary for energy management. But it is important for battery =
management.
3.     the =
name of the object can be renamed - batteryCurrentCurrent  ?  =

You talk about renaming the name? =
This sounds almost like current current :-)
But seriously, =
what would be your proposal?
4.     the notion of batteryType =96 =
primary (not  being rechargeable) is confusing =96 and the =
secondary Is  only rechargeable ?  =

Well, if you are dealing with =
batteries, the technically correct terms for the two basic kinds are =
'primary battery' and 'secondary battery'.
Secondary batteries =
are rechargeable, primary batteries are not. 
5.     The reference to be =
updated.   [I-D.ietf-eman-framework]   =93Claise, =
B., Parello, J., and L. Silver, "Energy Management  =
Framework", draft-ietf-eman-framework-01 (work in  progress), March =
2011.=94

Yes. That's =
really strange. In the XML we reference the draft correctly. There must =
be a wrong entry in the database we use for generating the references. =
We'll check for the next version.
Thanks
Mouli
PS: I had posted a review of the MIB =
module long back and most of my comments still apply. =

<=
span lang=3D"en-us">http://www.ietf.org/mail-archive/web/eman/current/msg004=
94.html
Yes, right. But all of =
them seem to be answered with what I wrote in the replies =
above.

Thanks,

&nbs=
p;   Juergen

=

--Apple-Mail-2--509071480--

From bnordman@lbl.gov  Thu Jul 14 23:07:55 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE0422800D for ; Thu, 14 Jul 2011 23:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.772
X-Spam-Level: 
X-Spam-Status: No, score=-5.772 tagged_above=-999 required=5 tests=[AWL=0.204,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6KDlX+v-ZkC for ; Thu, 14 Jul 2011 23:07:54 -0700 (PDT)
Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE63228010 for ; Thu, 14 Jul 2011 23:07:54 -0700 (PDT)
X-Ironport-SBRS: 4.4
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkMCAKvYH07RVdQ0kGdsb2JhbABHBwaCU5YQAY5xCBQBAQEBCQkNBxQEIaxqglKcZoMjGYJ+BIdUixKMPDyDew
X-IronPort-AV: E=Sophos;i="4.65,533,1304319600"; d="scan'208";a="46640181"
Received: from mail-vw0-f52.google.com ([209.85.212.52]) by ironport3.lbl.gov with ESMTP; 14 Jul 2011 23:07:41 -0700
Received: by vws16 with SMTP id 16so1181454vws.39 for ; Thu, 14 Jul 2011 23:07:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.92.2 with SMTP id ci2mr3270447vdb.428.1310710061228; Thu, 14 Jul 2011 23:07:41 -0700 (PDT)
Received: by 10.52.161.8 with HTTP; Thu, 14 Jul 2011 23:07:41 -0700 (PDT)
Date: Thu, 14 Jul 2011 23:07:41 -0700
Message-ID: 
From: Bruce Nordman 
To: eman mailing list 
Content-Type: multipart/alternative; boundary=bcaec50165359a639504a815778b
Subject: [eman] Applicability comments
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 06:07:56 -0000

--bcaec50165359a639504a815778b
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

In March I drafted content that I felt was useful and/or necessary for an

applicability statement.  This was done from the perspective of what is

needed for understanding and improving energy use in IT networks and

buildings.  That content can be seen at

draft-nordman-eman-energy-perspective-01

It did not attempt to cover content already in the current version of the
other

draft.



The current other draft is: draft-tychon-eman-applicability-statement-02.

There has been some convergence in content since the previous draft.

It seems possible and desirable to merge the two drafts.



A few of these points are covered in the current other draft, though with

different language and emphasis, such as the importance of reporting

=93identity=94 and classification, and the relevance and status of the Ecma

Smart Data Centre project.



Many other points from energy-perspective are not covered in the other
draft:



-At least one document published by EMAN should be readily accessible to a

   wide range of audiences, particularly those focused on energy use, most
of who

   have little or no knowledge of network technology.  The Applicability
Statement

   seems to be the only suitable one in our charter.

-At the core of EMAN is simple reporting of power/energy about a simple
device.

-The EMAN protocol can be used in =93series=94 relaying up information thro=
ugh

   any number of intermediate devices to an EMS, collecting and/or
aggregating.

-The NMS is out of scope.

-Any energy-using device is in scope (traditional IT, other IP devices,
non-IP

   devices).

-The management system begins with a discovery process, to understand

   what devices are in the building, and which implement EMAN.  This needs

   to be redone periodically.

  -Further details on how discovery may be implemented.

-Devices may report intermittently due to being in a low-power state,

   being portable, or leaving the building permanently.

-Ultimately, one key outlet for EMAN information is presentation (via an

   application) to people.

-A later version of EMAN should consider extension to forms of energy

  other than electricity.

-The Use Cases for EMAN can be viewed along three primary axes:

  -Management context: loosely, highly, or hybrid.

  -Building type: residential, commercial, data center, vehicle, other.

  -Device type: IT, other electronic, non-electronic.

-Power distribution domains are becoming more varied and complex.

-For measurement standards, IEC 62301 is widely used and relevant.

-IANA may need to establish an enumeration of device types.

-There are security issues related to control functions in changing

  what services a device provides, and potentially perturbing the

  power system with widely coordinated changes in energy demand.



All of these points seem suitable and appropriate to be in a working

group draft for Applicability.



A few detailed comments on draft-tychon-eman-applicability-statement-02

follow.

1.1

=96it seems unnecessary to define energy here =96 other drafts will do that=
.

-proxying and aggregation are mixed. They are distinct functions and

  one device can implement one, the other, or both.

2.

-the =93Scenarios and Target Devices=94 section mixes specific device types=
,

  with methods of powering devices.  It would be helpful to separate

  these as well as to include the =93use contexts=94 from the energy draft.

  There is also some redundancy in this section.

4.

-other standards should be divided into measurement standards,

   reporting standards, and other standards.



It may be that it would be helpful to create another document

as output from the working group that is the primary document

intended to be accessible to many readers, and to include detailed

discussions of implementation scenarios.  This would pull out some

of the content described above and add to it.



--Bruce (as contributor; I am off email Monday->Saturday)


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

--bcaec50165359a639504a815778b
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


















<=
font size=3D"2">In March I drafted content that I felt was useful and/or ne=
cessary
for an 



applicability statement.=A0 Th=
is was done from the perspective of what is 



needed for understanding and improving ener=
gy use in IT
networks and 



buildings.=A0 That
content can be seen at



draft-nordman-eman-energy-perspective-01



It did not attempt to cover content already=
 in the current
version of the other



draft.



=A0



The current other draft is: draft-tychon-em=
an-applicability-statement-02.



There has been some convergence in content =
since the
previous draft.



It seems possible and desirable to merge th=
e two drafts.



=A0



A few of these points are covered in the cu=
rrent other
draft, though with



different language and emphasis, such as th=
e importance of
reporting 



=93identity=94 and classification, and the =
relevance and status
of the Ecma 



Smart Data Centre project.



=A0



Many other points from energy-perspective a=
re not covered in
the other draft:



=A0



-At least one document published by EMAN sh=
ould be readily
accessible to a



=A0=A0 wide range=
 of audiences, particularly
those focused on energy use, most of who



=A0=A0 have littl=
e or no knowledge of network
technology.=A0 The Applicability
Statement



=A0=A0 seems to b=
e the only suitable one in
our charter.



-At the core of EMAN is simple reporting of=
 power/energy
about a simple device.



-The EMAN protocol can be used in =93series=
=94 relaying up
information through



=A0=A0 any number=
 of intermediate devices to
an EMS, collecting and/or aggregating.



-The NMS is out of scope.



-Any energy-using device is in scope (tradi=
tional IT, other
IP devices, non-IP



=A0=A0 devices).<=
/font>



-The management system begins with a discov=
ery process, to
understand



=A0=A0 what devic=
es are in the building, and
which implement EMAN.=A0 This needs



=A0=A0 to be redo=
ne periodically.



=A0 -Further
details on how discovery may be implemented.



-Devices may report intermittently due to b=
eing in a
low-power state,



=A0=A0 being port=
able, or leaving the building
permanently.



-Ultimately, one key outlet for EMAN inform=
ation is
presentation (via an



=A0=A0 applicatio=
n) to people.



-A later version of EMAN should consider ex=
tension to forms
of energy



=A0=A0other than =
electricity. 



-The Use Cases for EMAN can be viewed along=
 three primary
axes:



=A0 -Management
context: loosely, highly, or hybrid.



=A0 -Building
type: residential, commercial, data center, vehicle, other.



=A0 -Device type:
IT, other electronic, non-electronic.



-Power distribution domains are becoming mo=
re varied and
complex.



-For measurement standards, IEC 62301 is wi=
dely used and
relevant.



-IANA may need to establish an enumeration =
of device types.



-There are security issues related to contr=
ol functions in
changing



=A0 what services
a device provides, and potentially perturbing the



=A0 power system
with widely coordinated changes in energy demand.



=A0



All of these points seem suitable and appro=
priate to be in a
working



group draft for Applicability.



=A0



A few detailed comments on draft-tychon-ema=
n-applicability-statement-02



follow.=A0 



1.1



=96it seems unnecessary to define energy he=
re =96 other drafts
will do that.



-proxying and aggregation are mixed. They a=
re distinct
functions and



=A0 one device can
implement one, the other, or both.



2.



-the =93Scenarios and Target Devices=94 sec=
tion mixes specific
device types,



=A0 with methods
of powering devices.=A0 It would be
helpful to separate



=A0 these as well
as to include the =93use contexts=94 from the energy draft.



=A0 There is also
some redundancy in this section.



4.



-other standards should be divided into mea=
surement
standards,



=A0=A0
reporting standards, and other standards.



=A0



It may be that it would be helpful to creat=
e another
document



as output from the working group that is th=
e primary
document



intended to be accessible to many readers, =
and to include
detailed



discussions of implementation scenarios.=A0 This would pull out some



of the content described above and add to i=
t.



=A0



--Bruce (as contributor; I am off email Mon=
day->Saturday)





-- 

=
Bruce Nordman
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
BNordman@LBL.gov

510-486-7089
m: 510-501-7943




--bcaec50165359a639504a815778b--

From moulchan@cisco.com  Fri Jul 15 04:10:12 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494CA21F8672 for ; Fri, 15 Jul 2011 04:10:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.501
X-Spam-Level: 
X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=-0.903, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cB5xy-fj4vD6 for ; Fri, 15 Jul 2011 04:10:09 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 59A5C21F8661 for ; Fri, 15 Jul 2011 04:10:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=16185; q=dns/txt; s=iport; t=1310728209; x=1311937809; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=PqPqnJgpuEYKWZByl+bXZJ/WFY6VxOsj7qITQEFNnNw=; b=MzqjhJ4ekGLG//CXC7h6Jy4obODJA1PMoVOSTnJMKVWqd+G3ltf/MQAo 0ZbAWTvFaYpe1obbIhFpbgs0ZAZKCJfDYILL65kzGIZwp8/2ItCd7R4UZ ny6yYdMFzYIJOEJ236LdMGQ8Zkq4ZvDMNX/z3wR3JzFO/V4cvTVY0srzq k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvUAALYeIE6tJV2Y/2dsb2JhbABUglOVUo88d64JniiFW18Eh1SQHItn
X-IronPort-AV: E=Sophos;i="4.65,534,1304294400"; d="scan'208,217";a="3247992"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 15 Jul 2011 11:09:41 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6FB9fET017352;  Fri, 15 Jul 2011 11:09:41 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 15 Jul 2011 06:09:41 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC42DF.B1E202D9"
Date: Fri, 15 Jul 2011 06:09:38 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] updated version of the battery MIB
Thread-Index: AcxCPIRlyuubG7xgQQ+J7OwL1C8k/QAmkbKw
References: <791AD3077F94194BB2BDD13565B6295D1CFBAF43@DAPHNIS.office.hd>  
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Quittek" 
X-OriginalArrivalTime: 15 Jul 2011 11:09:41.0238 (UTC) FILETIME=[B1A45960:01CC42DF]
Cc: eman@ietf.org
Subject: Re: [eman] updated version of the battery MIB
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 11:10:12 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC42DF.B1E202D9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Juergen,

=20

Replies inline.=20


Thanks

Mouli

=20

From: Juergen Quittek [mailto:ietf@quittek.at]=20
Sent: Thursday, July 14, 2011 9:12 PM
To: Mouli Chandramouli (moulchan)
Cc: Rolf Winter; eman@ietf.org
Subject: Re: [eman] updated version of the battery MIB

=20

Hi Mouli,

=20

Thank you for your comments.

=20

Am 14.07.2011 um 13:25 schrieb Mouli Chandramouli (moulchan):

	Hi,

	I had a quick look at the new battery MIB module=20

	The first comment deals with the index and others are nits.

	1.     Firstly,  given that the battery  provides backup power
for a device and there should be a reference (index) =20

	       to the device  for which the battery is providing back-up
power. Otherwise, the MIB module seems as a standalone ?=20

	       There is a link of the batteryIndex to the
entPhysicalIndex ; Where do you assume that the entityMIB is implemented
?  =20

	       What is the device ? How is that device identified ? What
if entityMIB is not implemented ?=20

I think the most common case is that the battery is contained in a
device and the device reports about its battery.

=20

You can see the battery as a component of a device such as a CPU or a
line card.  If you write a MIB module for the line card or for the CPU,
you woudn't have a pointer in your MIB module pointing to the device
that the line card or CPU is contained in, would you? That is because
the device hosting the line card or CPU is the same device hosing the
implementation of the MIB module. I don't see a problem here. But maybe
you envision other scenarios where this is a problem?

=20

If the device hosting the battery implements the Entity MIB and has the
battery listed as an entity, then of course can we support it.

=20

Mouli>>  Thanks for an excellent description. =20

Mouli>> My point is - wouldn't you want to refer to the device that
contains the battery and such a linkage (association) would provide a
context for the battery ? - the battery is for this  device.=20

	2.     is battery temperature - is this relevant for EMAN ?
+-- r-n Integer32   batteryTemperature(14)=20

It is not necessary for energy management. But it is important for
battery management.

	3.     the name of the object can be renamed -
batteryCurrentCurrent  ? =20

You talk about renaming the name? This sounds almost like current
current :-)

But seriously, what would be your proposal?

=20

Mouli>  how about batteryPresentCharge





4.     the notion of batteryType - primary (not  being rechargeable) is
confusing - and the secondary Is  only rechargeable ? =20

Well, if you are dealing with batteries, the technically correct terms
for the two basic kinds are 'primary battery' and 'secondary battery'.

Secondary batteries are rechargeable, primary batteries are not.=20

	5.     The reference to be updated.   [I-D.ietf-eman-framework]
"Claise, B., Parello, J., and L. Silver, "Energy Management  Framework",
draft-ietf-eman-framework-01 (work in  progress), March 2011."

	=20

Yes. That's really strange. In the XML we reference the draft correctly.
There must be a wrong entry in the database we use for generating the
references. We'll check for the next version.

	Thanks

	Mouli

	PS: I had posted a review of the MIB module long back and most
of my comments still apply.=20

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

Yes, right. But all of them seem to be answered with what I wrote in the
replies above.

=20

Thanks,

=20

    Juergen

=20


------_=_NextPart_001_01CC42DF.B1E202D9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi Juergen,



 



Replies inline. 





Thanks



Mouli



 









From:=
 Juergen =
Quittek
[mailto:ietf@quittek.at] 

Sent: Thursday, July 14, 2011 9:12 PM

To: Mouli Chandramouli (moulchan)

Cc: Rolf Winter; eman@ietf.org

Subject: Re: [eman] updated version of the battery =
MIB









 



Hi Mouli,






 









Thank you for your comments.









 









Am 14.07.2011 um 13:25 schrieb Mouli Chandramouli
(moulchan):












Hi,



I had a quick look at the new =
battery MIB
module 



The first comment deals with the index and others are =
nits.



1.     Firstly,  given that the =
battery 
provides backup power for a device and there should be a reference
(index)  



      
to the device  for which the =
battery is
providing back-up power. Otherwise,
the MIB module seems as a standalone ?




      
There is a link of the batteryIndex =
to the
entPhysicalIndex ; Where do =
you
assume that the entityMIB is implemented ?   =




      
What is the device ? How is =
that device identified ? What if entityMIB is not implemented =
? 









I think the most common case is that the battery is
contained in a device and the device reports about its =
battery.









 









You can see the battery as a component of a device =
such as a
CPU or a line card.  If you write a MIB module for the line card or =
for
the CPU, you woudn't have a pointer in your MIB module pointing to the =
device
that the line card or CPU is contained in, would you? That is because =
the
device hosting the line card or CPU is the same device hosing the
implementation of the MIB module. I don't see a problem here. But maybe =
you
envision other scenarios where this is a problem?









 









If the device hosting the battery implements the =
Entity MIB
and has the battery listed as an entity, then of course can we support =
it.



 



Mouli>>  Thanks for an excellent =
description.  



Mouli>> My point is – wouldn’t you want =
to
refer to the device that contains the battery and such a linkage =
(association) would
provide a context for the battery ? – the battery is for this =
 device.
















2.     is =
battery
temperature – is this relevant for EMAN ?   +-- r-n
Integer32   batteryTemperature(14) 









It is not necessary for energy management. But it =
is
important for battery management.















3.     the =
name of
the object can be renamed - batteryCurrentCurrent  ?  =










You talk about renaming the name? This sounds =
almost like
current current :-)









But seriously, what would be your proposal?



 



Mouli>  how about =
batteryPresentCharge














4.     the notion of batteryType – primary
(not  being rechargeable) is confusing – and the secondary =
Is 
only rechargeable ?  






Well, if you are dealing with batteries, the =
technically
correct terms for the two basic kinds are 'primary battery' and =
'secondary
battery'.









Secondary batteries are rechargeable, primary =
batteries are
not. 















5.     The reference to be updated.  
[I-D.ietf-eman-framework]   “Claise, B., Parello, =
J.,
and L. =
Silver, "Energy Management  =
Framework",
draft-ietf-eman-framework-01 (work in  progress), March =
2011.”






 












Yes. That's really strange. In the XML we reference =
the
draft correctly. There must be a wrong entry in the database we use for
generating the references. We'll check for the next =
version.















Thanks



Mouli



PS: I
had posted a review of the MIB module long
back and most of my comments =
still apply. 



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









Yes, right. But all of them seem to be answered =
with what I
wrote in the replies above.









 












Thanks,









 









    Juergen









 


















------_=_NextPart_001_01CC42DF.B1E202D9--

From SChew@bren-tronics.com  Fri Jul 15 04:46:39 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7073221F8702 for ; Fri, 15 Jul 2011 04:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level: 
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HV+MuEbO35vh for ; Fri, 15 Jul 2011 04:46:35 -0700 (PDT)
Received: from EXHUB018-2.exch018.msoutlookonline.net (exhub018-2.exch018.msoutlookonline.net [64.78.17.17]) by ietfa.amsl.com (Postfix) with ESMTP id 96DC821F8701 for ; Fri, 15 Jul 2011 04:46:35 -0700 (PDT)
Received: from EXVMBX018-1.exch018.msoutlookonline.net ([64.78.17.47]) by EXHUB018-2.exch018.msoutlookonline.net ([64.78.17.17]) with mapi; Fri, 15 Jul 2011 04:46:35 -0700
From: Steven Chew 
To: Rolf Winter , "eman@ietf.org" 
Date: Fri, 15 Jul 2011 04:46:33 -0700
Thread-Topic: updated version of the battery MIB
Thread-Index: Acw8nMCIvCGzz09FQg+FKwbZ9WYHGgDKgCAQ
Message-ID: <0BB24042CB683840B986F84BC859CFB569F0CB1FA4@EXVMBX018-1.exch018.msoutlookonline.net>
References: <791AD3077F94194BB2BDD13565B6295D1CFBAF43@DAPHNIS.office.hd>
In-Reply-To: <791AD3077F94194BB2BDD13565B6295D1CFBAF43@DAPHNIS.office.hd>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed; boundary="_002_0BB24042CB683840B986F84BC859CFB569F0CB1FA4EXVMBX0181exc_"
MIME-Version: 1.0
Subject: Re: [eman] updated version of the battery MIB
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 11:46:39 -0000

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

1) The use of the word "current" is double loaded (e.g. batteryCurrentCurre=
nt). I suggest use "current" for electrical current and use "present" to me=
an instantaneous.

2) It seems more natural to give batteryTechnology(5) a SYNTAX of Integer o=
r Enumeration. Am I right that Unsigned32 is normally given to quantitative=
 values?

3) I only know of the standards from sbs-forum.org that come close to the b=
attery MIB specification. I made an attempt to match the objects from the S=
mart Battery Data Specification v1.10 (SBD) and those in this MIB. Please s=
ee attachment. Some of the SBD objects are only suitable as data exchanges =
between the battery and the battery charger (e.g. a laptop, or standalone c=
harger). I think those are inappropriate for this MIB. For this reason, I d=
o not think there should be a complete alignment between the two specs.

I think the current model is implementing the MIB support in a UPS, in whic=
h the battery is part of the "fixed" power source. However, I am hoping to =
exert sufficient influence in the MIB definition, such that we will find it=
 useful to implement the MIB support in networked standalone battery charge=
rs that will see different batteries from one use to another. The applicati=
on I am envisioning is an asset management system that will track the usage=
s of a pool of rechargeable batteries, and those batteries are for mobile a=
ppliances. This may not have been inside the scope originally.

Below are my thoughts and are, of course, subjective:

3.1) Objects in MIB, but not in SBD Spec:

3.1.1) batteryFirmwareVersion(3) - OK to keep in MIB, but there is no stand=
ard way to convey this from battery manufacturers
3.1.2) batteryType(7) - OK to keep in MIB
3.1.3) batteryNumberOfCells(7) - not sure of the usefulness, and not should=
 how to get this information from a charger in general
3.1.4) batteryLastChargingCycleTime(13) - good to have in MIB
3.1.5) batteryLowAlarmVoltage(20) - OK to have, not really applicable to th=
e charger scenario
3.1.6) batteryReplacementAlarmCapacity(21) - good to have in MIB
3.1.7) batteryReplacementAlarmCycles(22) - good to have in MIB
3.1.8) batteryHighAlarmTemperature (23) - good to have in MIB

3.2) Objects in not MIB, but in SBD Spec:
3.2.1) ManufacturerAccess() (0x00) - not applicable in MIB
3.2.2) RemainingTimeAlarm() (0x02) - important to have in MIB, seems fundam=
ental
3.2.3) BatteryMode() (0x03) - not applicable in MIB
3.2.4) AtRate() (0x04) - this "AtRate..." group of objects is interesting -=
 allows querying a battery performance at a projected current level
3.2.5) AtRateTimeToFull() (0x05) - see above
3.2.6) AtRateTimeToEmpty() (0x06) - see above
3.2.7) AtRateOK() (0x07) - see above
3.2.8) AverageCurrent() (0x0b) - important to have in MIB; potentially more=
 meaningful than batteryCurrentCurrent(17), as current tend to vary greatly=
 instantaneously
3.2.9) MaxError() (0x0c) - not important to have in MIB
3.2.10) RunTimeToEmpty() (0x11) - important to have in MIB, seems fundament=
al
3.2.11) AverageTimeToEmpty() (0x12) - important to have in MIB, seems funda=
mental
3.2.12) AverageTimeToFull() (0x13) - important to have in MIB, seems fundam=
ental
3.2.13) SpecificationInfo() (0x1a) - not important to have in MIB
3.2.14) ManufacturerData() (0x23) - not important to have in MIB

Someone else please check me. My hats off to the authors of the Battery MIB=
. There are lots of details...

Regards
Steven Chew.

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Rol=
f Winter
Sent: Thursday, July 07, 2011 7:55 AM
To: eman@ietf.org
Subject: [eman] updated version of the battery MIB

Hi,

we just posted a new version of the battery MIB. It contains the following =
changes:

- we added objects for the maximum charging current, the recommended curren=
t to be used for trickle charging and a notification for battery
- we adopted the cycle definition of the Smart Battery Data Specification
- the former takes care of two open issues, we removed the one on battery h=
ealth as we e.g. have the cycle count as an approximate metric for this and=
 some other information in the MIB
- We added a new open issue asking how close we should align in general to =
the Smart Battery Data Specification

These are the main changes in this version. I think we make very good progr=
ess on this document. Thanks a lot for all the input received so far. We wo=
uld appreciate any further comments, so please keep them coming.

Best,

Rolf


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London =
W3 6BL | Registered in England 2832014=20


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

--_002_0BB24042CB683840B986F84BC859CFB569F0CB1FA4EXVMBX0181exc_
Content-Type: application/vnd.ms-excel; name="MIB-SBD Compare 02.xls"
Content-Description: MIB-SBD Compare 02.xls
Content-Disposition: attachment; filename="MIB-SBD Compare 02.xls";
	size=51200; creation-date="Mon, 11 Jul 2011 05:42:24 GMT";
	modification-date="Tue, 12 Jul 2011 08:34:19 GMT"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA
EAAATQAAAAIAAAD+////AAAAAAAAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////9
////TAAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A
AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA
AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA
LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6
AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgA
AABJAAAASgAAAEsAAAD+////VgAAAGAAAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVwAA
AF8AAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAYQAAAP7////+////YgAAAP7/////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////1IA
bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAWAAUA//////////8CAAAAIAgCAAAAAADAAAAAAAAARgAAAADYDQL8xz/MAfCmvsXiQswB
TgAAAEAiAAAAAAAAVwBvAHIAawBiAG8AbwBrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAABIAAgEOAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAACAAAA55MAAAAAAABfAFYAQgBBAF8AUABSAE8ASgBFAEMAVABfAEMAVQBS
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgABAQEAAAAMAAAACwAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAMEJ+KqlAzAGA/pQqqUDMAQAAAAAAAAAAAAAAAFYAQgBBAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAEA////////
//8GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwen8qqUDMAUCeiiqpQMwBAAAAAAAAAAAAAAAACQgQ
AAAGBQBmMs0HyYABAAYGAADhAAIAsATBAAIAAADiAAAAXABwAAsAAFN0ZXZlbiBDaGV3ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCAAIAsARhAQIAAADAAQAAPQEGAAQA
AgADALoBDwAMAABUaGlzV29ya2Jvb2ucAAIAEQAZAAIAAAASAAIAAAATAAIAAACvAQIAAAC8AQIA
AAA9ABIA4AF4ANNZMyc4AAAAAAABAFgCQAACAAAAjQACAAAAIgACAAAADgACAAEAtwECAAAA2gAC
AAAAMQAeANwAAAAIAJABAAAAAgCCBwFDAGEAbABpAGIAcgBpADEAHgDcAAAACACQAQAAAAIAggcB
QwBhAGwAaQBiAHIAaQAxAB4A3AAAAAgAkAEAAAACAIIHAUMAYQBsAGkAYgByAGkAMQAeANwAAAAI
AJABAAAAAgCCBwFDAGEAbABpAGIAcgBpADEAHgDcAAAACACQAQAAAAIAggcBQwBhAGwAaQBiAHIA
aQAxAB4A3AAAAAkAkAEAAAACAIIHAUMAYQBsAGkAYgByAGkAMQAeANwAAAAUAJABAAAAAgCCBwFD
AGEAbABpAGIAcgBpADEAHgDcAAEANAC8AgAAAAIAggcBQwBhAGwAaQBiAHIAaQAxAB4A3AABAAkA
vAIAAAACAIIHAUMAYQBsAGkAYgByAGkAMQAeANwAAgAXAJABAAAAAgCCBwFDAGEAbABpAGIAcgBp
ADEAHgDcAAAAEQCQAQAAAAIAggcBQwBhAGwAaQBiAHIAaQAxAB4ALAEBADgAvAIAAAACAIIHAUMA
YQBsAGkAYgByAGkAMQAeAAQBAQA4ALwCAAAAAgCCBwFDAGEAbABpAGIAcgBpADEAHgDcAAEAOAC8
AgAAAAIAggcBQwBhAGwAaQBiAHIAaQAxAB4A3AAAAD4AkAEAAAACAIIHAUMAYQBsAGkAYgByAGkA
MQAeANwAAAA0AJABAAAAAgCCBwFDAGEAbABpAGIAcgBpADEAHgDcAAAAPACQAQAAAAIAggcBQwBh
AGwAaQBiAHIAaQAxAB4A3AABAD8AvAIAAAACAIIHAUMAYQBsAGkAYgByAGkAMQAeAGgBAQA4ALwC
AAAAAgCCBwFDAGEAbQBiAHIAaQBhADEAHgDcAAEACAC8AgAAAAIAggcBQwBhAGwAaQBiAHIAaQAx
AB4A3AAAAAoAkAEAAAACAIIHAUMAYQBsAGkAYgByAGkAMQAeANwABAAMAJABAAABAgCCBwFDAGEA
bABpAGIAcgBpADEAHgDcAAQAFACQAQAAAQIAggcBQwBhAGwAaQBiAHIAaQAeBBwABQAXAAAiJCIj
LCMjMF8pO1woIiQiIywjIzBcKR4EIQAGABwAACIkIiMsIyMwXyk7W1JlZF1cKCIkIiMsIyMwXCke
BCIABwAdAAAiJCIjLCMjMC4wMF8pO1woIiQiIywjIzAuMDBcKR4EJwAIACIAACIkIiMsIyMwLjAw
Xyk7W1JlZF1cKCIkIiMsIyMwLjAwXCkeBDcAKgAyAABfKCIkIiogIywjIzBfKTtfKCIkIiogXCgj
LCMjMFwpO18oIiQiKiAiLSJfKTtfKEBfKR4ELgApACkAAF8oKiAjLCMjMF8pO18oKiBcKCMsIyMw
XCk7XygqICItIl8pO18oQF8pHgQ/ACwAOgAAXygiJCIqICMsIyMwLjAwXyk7XygiJCIqIFwoIywj
IzAuMDBcKTtfKCIkIiogIi0iPz9fKTtfKEBfKR4ENgArADEAAF8oKiAjLCMjMC4wMF8pO18oKiBc
KCMsIyMwLjAwXCk7XygqICItIj8/Xyk7XyhAXykeBBUApAAQAAAiWWVzIjsiWWVzIjsiTm8iHgQa
AKUAFQAAIlRydWUiOyJUcnVlIjsiRmFsc2UiHgQUAKYADwAAIk9uIjsiT24iOyJPZmYiHgRdAKcA
LAABWwAkAKwgLQAyAF0AXAAgACMALAAjACMAMAAuADAAMABfACkAOwBbAFIAZQBkAF0AXAAoAFsA
JACsIC0AMgBdAFwAIAAjACwAIwAjADAALgAwADAAXAApAOAAFAAAAAAA9f8gAAAAAAAAAAAAAADA
IOAAFAAFAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAFAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAFAAAA
9f8gAAD0AAAAAAAAAADAIOAAFAAFAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAFAAAA9f8gAAD0AAAA
AAAAAADAIOAAFAAFAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAFAAAA9f8gAAD0AAAAAAAAAADAIOAA
FAAFAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAFAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAFAAAA9f8g
AAD0AAAAAAAAAADAIOAAFAAFAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAFAAAA9f8gAAD0AAAAAAAA
AADAIOAAFAAFAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAFAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAA
AAAAAQAgAAAAAAAAAAAAAALAIOAAFAAFAAAA9f8gAAC0AAAAAAAAAASfIOAAFAAFAAAA9f8gAAC0
AAAAAAAAAAStIOAAFAAFAAAA9f8gAAC0AAAAAAAAAASqIOAAFAAFAAAA9f8gAAC0AAAAAAAAAASu
IOAAFAAFAAAA9f8gAAC0AAAAAAAAAASbIOAAFAAFAAAA9f8gAAC0AAAAAAAAAASvIOAAFAAFAAAA
9f8gAAC0AAAAAAAAAASsIOAAFAAFAAAA9f8gAAC0AAAAAAAAAASdIOAAFAAFAAAA9f8gAAC0AAAA
AAAAAASLIOAAFAAFAAAA9f8gAAC0AAAAAAAAAASuIOAAFAAFAAAA9f8gAAC0AAAAAAAAAASsIOAA
FAAFAAAA9f8gAAC0AAAAAAAAAASzIOAAFAAGAAAA9f8gAAC0AAAAAAAAAASeIOAAFAAGAAAA9f8g
AAC0AAAAAAAAAASdIOAAFAAGAAAA9f8gAAC0AAAAAAAAAASLIOAAFAAGAAAA9f8gAAC0AAAAAAAA
AASkIOAAFAAGAAAA9f8gAAC0AAAAAAAAAASxIOAAFAAGAAAA9f8gAAC0AAAAAAAAAAS0IOAAFAAG
AAAA9f8gAAC0AAAAAAAAAAS+IOAAFAAGAAAA9f8gAAC0AAAAAAAAAASKIOAAFAAGAAAA9f8gAAC0
AAAAAAAAAAS5IOAAFAAGAAAA9f8gAAC0AAAAAAAAAASkIOAAFAAGAAAA9f8gAAC0AAAAAAAAAASx
IOAAFAAGAAAA9f8gAAC0AAAAAAAAAAS1IOAAFAAHAAAA9f8gAAC0AAAAAAAAAAStIOAAFAAIAAAA
9f8gAACUERGXC5cLAASWIOAAFAAJAAAA9f8gAACUZma/H78fAAS3IOAAFAAFACsA9f8gAAD4AAAA
AAAAAADAIOAAFAAFACkA9f8gAAD4AAAAAAAAAADAIOAAFAAFACwA9f8gAAD4AAAAAAAAAADAIOAA
FAAFACoA9f8gAAD4AAAAAAAAAADAIOAAFAAKAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAXAAAA9f8g
AAD0AAAAAAAAAADAIOAAFAALAAAA9f8gAAC0AAAAAAAAAASqIOAAFAAMAAAA9f8gAADUAFAAAAAf
AADAIOAAFAANAAAA9f8gAADUAFAAAAALAADAIOAAFAAOAAAA9f8gAADUACAAAAAPAADAIOAAFAAO
AAAA9f8gAAD0AAAAAAAAAADAIOAAFAAWAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAPAAAA9f8gAACU
ERGXC5cLAASvIOAAFAAQAAAA9f8gAADUAGAAAAAaAADAIOAAFAARAAAA9f8gAAC0AAAAAAAAAASr
IOAAFAAFAAAA9f8gAACcEREWCxYLAASaIOAAFAASAAAA9f8gAACUERG/H78fAASWIOAAFAAFAAkA
9f8gAAD4AAAAAAAAAADAIOAAFAATAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAUAAAA9f8gAADUAGEA
AD4fAADAIOAAFAAVAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAADEAAQAgAAAEAAAAAAAAAALAIOAA
FAAAAAAAAQAAAAAQAAAAAAAAAALAIOAAFAAAAAAAAQAgAAAgERFAIEAgAALAIOAAFAAAAAAAAQAA
AAAwERFAIEAgAALAIOAAFAAAAAAAAQAIAAAwERFAIEAgAALAIOAAFAAUAAAAAQAgAABoERFAIEAg
AAYNIHwIFAB8CAAAAAAAAAAAAAAAAEYADrV9Kn0ILQB9CAAAAAAAAAAAAAAAAAAAAAACAA0AFAAD
AAAAAQAAAAAwADAAXwApDgAFAAJ9CC0AfQgAAAAAAAAAAAAAAAABAAAAAgANABQAAwAAAAEAAAAA
MAAwAF8AKQ4ABQACfQgtAH0IAAAAAAAAAAAAAAAAAgAAAAIADQAUAAMAAAABAAAAADAAMABfACkO
AAUAAn0ILQB9CAAAAAAAAAAAAAAAAAMAAAACAA0AFAADAAAAAQAAAAAwADAAXwApDgAFAAJ9CC0A
fQgAAAAAAAAAAAAAAAAEAAAAAgANABQAAwAAAAEAAAAAMAAwAF8AKQ4ABQACfQgtAH0IAAAAAAAA
AAAAAAAABQAAAAIADQAUAAMAAAABAAAAADAAMABfACkOAAUAAn0ILQB9CAAAAAAAAAAAAAAAAAYA
AAACAA0AFAADAAAAAQAAAAAwADAAXwApDgAFAAJ9CC0AfQgAAAAAAAAAAAAAAAAHAAAAAgANABQA
AwAAAAEAAAAAMAAwAF8AKQ4ABQACfQgtAH0IAAAAAAAAAAAAAAAACAAAAAIADQAUAAMAAAABAAAA
ADAAMABfACkOAAUAAn0ILQB9CAAAAAAAAAAAAAAAAAkAAAACAA0AFAADAAAAAQAAAAAwADAAXwAp
DgAFAAJ9CC0AfQgAAAAAAAAAAAAAAAAKAAAAAgANABQAAwAAAAEAAAAAMAAwAF8AKQ4ABQACfQgt
AH0IAAAAAAAAAAAAAAAACwAAAAIADQAUAAMAAAABAAAAADAAMABfACkOAAUAAn0ILQB9CAAAAAAA
AAAAAAAAAAwAAAACAA0AFAADAAAAAQAAAAAwADAAXwApDgAFAAJ9CC0AfQgAAAAAAAAAAAAAAAAN
AAAAAgANABQAAwAAAAEAAAAAMAAwAF8AKQ4ABQACfQgtAH0IAAAAAAAAAAAAAAAADgAAAAIADQAU
AAMAAAABAAAAADAAMABfACkOAAUAAn0ILQB9CAAAAAAAAAAAAAAAAA8AAAACAA0AFAADAAAAAQAA
AAAwADAAXwApDgAFAAJ9CEEAfQgAAAAAAAAAAAAAAAAQAAAAAwANABQAAwAAAAEAAAAAMAAwAF8A
KQ4ABQACBAAUAAMAZWYEAAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAAAAARAAAAAwANABQAAwAA
AAEAAAAAMAAwAF8AKQ4ABQACBAAUAAMAZWYFAAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAAAAAS
AAAAAwANABQAAwAAAAEAAAAAMAAwAF8AKQ4ABQACBAAUAAMAZWYGAAAAWwAkAKwgLQB9CEEAfQgA
AAAAAAAAAAAAAAATAAAAAwANABQAAwAAAAEAAAAAMAAwAF8AKQ4ABQACBAAUAAMAZWYHAAAAWwAk
AKwgLQB9CEEAfQgAAAAAAAAAAAAAAAAUAAAAAwANABQAAwAAAAEAAAAAMAAwAF8AKQ4ABQACBAAU
AAMAZWYIAAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAAAAAVAAAAAwANABQAAwAAAAEAAAAAMAAw
AF8AKQ4ABQACBAAUAAMAZWYJAAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAAAAAWAAAAAwANABQA
AwAAAAEAAAAAMAAwAF8AKQ4ABQACBAAUAAMAzEwEAAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAA
AAAXAAAAAwANABQAAwAAAAEAAAAAMAAwAF8AKQ4ABQACBAAUAAMAzEwFAAAAWwAkAKwgLQB9CEEA
fQgAAAAAAAAAAAAAAAAYAAAAAwANABQAAwAAAAEAAAAAMAAwAF8AKQ4ABQACBAAUAAMAzEwGAAAA
WwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAAAAAZAAAAAwANABQAAwAAAAEAAAAAMAAwAF8AKQ4ABQAC
BAAUAAMAzEwHAAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAAAAAaAAAAAwANABQAAwAAAAEAAAAA
MAAwAF8AKQ4ABQACBAAUAAMAzEwIAAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAAAAAbAAAAAwAN
ABQAAwAAAAEAAAAAMAAwAF8AKQ4ABQACBAAUAAMAzEwJAAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAA
AAAAAAAcAAAAAwANABQAAwAAAAAAAAAAMAAwAF8AKQ4ABQACBAAUAAMAMjMEAAAAWwAkAKwgLQB9
CEEAfQgAAAAAAAAAAAAAAAAdAAAAAwANABQAAwAAAAAAAAAAMAAwAF8AKQ4ABQACBAAUAAMAMjMF
AAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAAAAAeAAAAAwANABQAAwAAAAAAAAAAMAAwAF8AKQ4A
BQACBAAUAAMAMjMGAAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAAAAAfAAAAAwANABQAAwAAAAAA
AAAAMAAwAF8AKQ4ABQACBAAUAAMAMjMHAAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAAAAAgAAAA
AwANABQAAwAAAAAAAAAAMAAwAF8AKQ4ABQACBAAUAAMAMjMIAAAAWwAkAKwgLQB9CEEAfQgAAAAA
AAAAAAAAAAAhAAAAAwANABQAAwAAAAAAAAAAMAAwAF8AKQ4ABQACBAAUAAMAMjMJAAAAWwAkAKwg
LQB9CEEAfQgAAAAAAAAAAAAAAAAiAAAAAwANABQAAwAAAAAAAAAAMAAwAF8AKQ4ABQACBAAUAAMA
AAAEAAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAAAAAjAAAAAwANABQAAwAAAAAAAAAAMAAwAF8A
KQ4ABQACBAAUAAMAAAAFAAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAAAAAkAAAAAwANABQAAwAA
AAAAAAAAMAAwAF8AKQ4ABQACBAAUAAMAAAAGAAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAAAAAl
AAAAAwANABQAAwAAAAAAAAAAMAAwAF8AKQ4ABQACBAAUAAMAAAAHAAAAWwAkAKwgLQB9CEEAfQgA
AAAAAAAAAAAAAAAmAAAAAwANABQAAwAAAAAAAAAAMAAwAF8AKQ4ABQACBAAUAAMAAAAIAAAAWwAk
AKwgLQB9CEEAfQgAAAAAAAAAAAAAAAAnAAAAAwANABQAAwAAAAAAAAAAMAAwAF8AKQ4ABQACBAAU
AAMAAAAJAAAAWwAkAKwgLQB9CEEAfQgAAAAAAAAAAAAAAAAoAAAAAwANABQAAgAAAJwABv8AMAAw
AF8AKQ4ABQACBAAUAAIAAAD/x87/WwAkAKwgLQB9CJEAfQgAAAAAAAAAAAAAAAApAAAABwANABQA
AgAAAPp9AP8AMAAwAF8AKQ4ABQACBAAUAAIAAADy8vL/WwAkAKwgLQAHABQAAgAAAH9/f/8jACMA
MAAuAAgAFAACAAAAf39//yAgICAgICAgCQAUAAIAAAB/f3//AAAAAAAAAAAKABQAAgAAAH9/f/8A
AAAAAAAAAH0IkQB9CAAAAAAAAAAAAAAAACoAAAAHAA0AFAADAAAAAAAAAAAwADAAXwApDgAFAAIE
ABQAAgAAAKWlpf9bACQArCAtAAcAFAACAAAAPz8//yMAIwAwAC4ACAAUAAIAAAA/Pz//ICAgICAg
ICAJABQAAgAAAD8/P/8AAAAAAAAAAAoAFAACAAAAPz8//wAAAAAAAAAAfQgtAH0IAAAAAAAAAAAA
AAAAKwAAAAIADQAUAAMAAAABAAAAADAAMABfACkOAAUAAn0ILQB9CAAAAAAAAAAAAAAAACwAAAAC
AA0AFAADAAAAAQAAAAAwADAAXwApDgAFAAJ9CC0AfQgAAAAAAAAAAAAAAAAtAAAAAgANABQAAwAA
AAEAAAAAMAAwAF8AKQ4ABQACfQgtAH0IAAAAAAAAAAAAAAAALgAAAAIADQAUAAMAAAABAAAAADAA
MABfACkOAAUAAn0ILQB9CAAAAAAAAAAAAAAAAC8AAAACAA0AFAACAAAAf39//wAwADAAXwApDgAF
AAJ9CC0AfQgAAAAAAAAAAAAAAAAwAAAAAgANABQAAwAAAAsAAAAAMAAwAF8AKQ4ABQACfQhBAH0I
AAAAAAAAAAAAAAAAMQAAAAMADQAUAAIAAAAAYQD/ADAAMABfACkOAAUAAgQAFAACAAAAxu/O/1sA
JACsIC0AfQhBAH0IAAAAAAAAAAAAAAAAMgAAAAMADQAUAAMAAAADAAAAADAAMABfACkOAAUAAggA
FAADAAAABAAAAFsAJACsIC0AfQhBAH0IAAAAAAAAAAAAAAAAMwAAAAMADQAUAAMAAAADAAAAADAA
MABfACkOAAUAAggAFAADAP8/BAAAAFsAJACsIC0AfQhBAH0IAAAAAAAAAAAAAAAANAAAAAMADQAU
AAMAAAADAAAAADAAMABfACkOAAUAAggAFAADADIzBAAAAFsAJACsIC0AfQgtAH0IAAAAAAAAAAAA
AAAANQAAAAIADQAUAAMAAAADAAAAADAAMABfACkOAAUAAn0ILQB9CAAAAAAAAAAAAAAAADYAAAAC
AA0AFAADAAAACgAAAAAwADAAXwApDgAFAAJ9CJEAfQgAAAAAAAAAAAAAAAA3AAAABwANABQAAgAA
AD8/dv8AMAAwAF8AKQ4ABQACBAAUAAIAAAD/zJn/WwAkAKwgLQAHABQAAgAAAH9/f/8jACMAMAAu
AAgAFAACAAAAf39//yAgICAgICAgCQAUAAIAAAB/f3//AAAAAAAAAAAKABQAAgAAAH9/f/8AAAAA
AAAAAH0IQQB9CAAAAAAAAAAAAAAAADgAAAADAA0AFAACAAAA+n0A/wAwADAAXwApDgAFAAIIABQA
AgAAAP+AAf9bACQArCAtAH0IQQB9CAAAAAAAAAAAAAAAADkAAAADAA0AFAACAAAAnGUA/wAwADAA
XwApDgAFAAIEABQAAgAAAP/rnP9bACQArCAtAH0IkQB9CAAAAAAAAAAAAAAAADoAAAAHAA0AFAAD
AAAAAQAAAAAwADAAXwApDgAFAAIEABQAAgAAAP//zP9bACQArCAtAAcAFAACAAAAsrKy/yMAIwAw
AC4ACAAUAAIAAACysrL/ICAgICAgICAJABQAAgAAALKysv8AAAAAAAAAAAoAFAACAAAAsrKy/wAA
AAAAAAAAfQiRAH0IAAAAAAAAAAAAAAAAOwAAAAcADQAUAAIAAAA/Pz//ADAAMABfACkOAAUAAgQA
FAACAAAA8vLy/1sAJACsIC0ABwAUAAIAAAA/Pz//IwAjADAALgAIABQAAgAAAD8/P/8gICAgICAg
IAkAFAACAAAAPz8//wAAAAAAAAAACgAUAAIAAAA/Pz//AAAAAAAAAAB9CC0AfQgAAAAAAAAAAAAA
AAA8AAAAAgANABQAAwAAAAEAAAAAMAAwAF8AKQ4ABQACfQgtAH0IAAAAAAAAAAAAAAAAPQAAAAIA
DQAUAAMAAAADAAAAADAAMABfACkOAAUAAX0IVQB9CAAAAAAAAAAAAAAAAD4AAAAEAA0AFAADAAAA
AQAAAAAwADAAXwApDgAFAAIHABQAAwAAAAQAAABbACQArCAtAAgAFAADAAAABAAAACMAIwAwAC4A
fQgtAH0IAAAAAAAAAAAAAAAAPwAAAAIADQAUAAIAAAD/AAD/ADAAMABfACkOAAUAAn0ILQB9CAAA
AAAAAAAAAAAAAEAAAAACAA0AFAADAAAAAQAAAAAwADAAXwApDgAFAAJ9CC0AfQgAAAAAAAAAAAAA
AABBAAAAAgANABQAAwAAAAEAAAAAMAAwAF8AKQ4ABQACfQgtAH0IAAAAAAAAAAAAAAAAQgAAAAIA
DQAUAAMAAAABAAAAADAAMABfACkOAAUAAn0ILQB9CAAAAAAAAAAAAAAAAEMAAAACAA0AFAADAAAA
AQAAAAAwADAAXwApDgAFAAJ9CC0AfQgAAAAAAAAAAAAAAABEAAAAAgANABQAAwAAAAEAAAAAMAAw
AF8AKQ4ABQACfQhBAH0IAAAAAAAAAAAAAAAARQAAAAMADQAUAAMAAAABAAAAADAAMABfACkOAAUA
AgQAFAACAAAA//8A/1sAJACsIC0AkwISABAADQAAMjAlIC0gQWNjZW50MZIITQCSCAAAAAAAAAAA
AAABBB7/DQAyADAAJQAgAC0AIABBAGMAYwBlAG4AdAAxAAAAAwABAAwABwRlZtzm8f8FAAwABwEA
AAAAAP8lAAUAApMCEgARAA0AADIwJSAtIEFjY2VudDKSCE0AkggAAAAAAAAAAAAAAQQi/w0AMgAw
ACUAIAAtACAAQQBjAGMAZQBuAHQAMgAAAAMAAQAMAAcFZWby3Nv/BQAMAAcBAAAAAAD/JQAFAAKT
AhIAEgANAAAyMCUgLSBBY2NlbnQzkghNAJIIAAAAAAAAAAAAAAEEJv8NADIAMAAlACAALQAgAEEA
YwBjAGUAbgB0ADMAAAADAAEADAAHBmVm6/He/wUADAAHAQAAAAAA/yUABQACkwISABMADQAAMjAl
IC0gQWNjZW50NJIITQCSCAAAAAAAAAAAAAABBCr/DQAyADAAJQAgAC0AIABBAGMAYwBlAG4AdAA0
AAAAAwABAAwABwdlZuTf7P8FAAwABwEAAAAAAP8lAAUAApMCEgAUAA0AADIwJSAtIEFjY2VudDWS
CE0AkggAAAAAAAAAAAAAAQQu/w0AMgAwACUAIAAtACAAQQBjAGMAZQBuAHQANQAAAAMAAQAMAAcI
ZWba7vP/BQAMAAcBAAAAAAD/JQAFAAKTAhIAFQANAAAyMCUgLSBBY2NlbnQ2kghNAJIIAAAAAAAA
AAAAAAEEMv8NADIAMAAlACAALQAgAEEAYwBjAGUAbgB0ADYAAAADAAEADAAHCWVm/enZ/wUADAAH
AQAAAAAA/yUABQACkwISABYADQAANDAlIC0gQWNjZW50MZIITQCSCAAAAAAAAAAAAAABBB//DQA0
ADAAJQAgAC0AIABBAGMAYwBlAG4AdAAxAAAAAwABAAwABwTMTLjM5P8FAAwABwEAAAAAAP8lAAUA
ApMCEgAXAA0AADQwJSAtIEFjY2VudDKSCE0AkggAAAAAAAAAAAAAAQQj/w0ANAAwACUAIAAtACAA
QQBjAGMAZQBuAHQAMgAAAAMAAQAMAAcFzEzmuLf/BQAMAAcBAAAAAAD/JQAFAAKTAhIAGAANAAA0
MCUgLSBBY2NlbnQzkghNAJIIAAAAAAAAAAAAAAEEJ/8NADQAMAAlACAALQAgAEEAYwBjAGUAbgB0
ADMAAAADAAEADAAHBsxM2OS8/wUADAAHAQAAAAAA/yUABQACkwISABkADQAANDAlIC0gQWNjZW50
NJIITQCSCAAAAAAAAAAAAAABBCv/DQA0ADAAJQAgAC0AIABBAGMAYwBlAG4AdAA0AAAAAwABAAwA
BwfMTMzA2v8FAAwABwEAAAAAAP8lAAUAApMCEgAaAA0AADQwJSAtIEFjY2VudDWSCE0AkggAAAAA
AAAAAAAAAQQv/w0ANAAwACUAIAAtACAAQQBjAGMAZQBuAHQANQAAAAMAAQAMAAcIzEy33uj/BQAM
AAcBAAAAAAD/JQAFAAKTAhIAGwANAAA0MCUgLSBBY2NlbnQ2kghNAJIIAAAAAAAAAAAAAAEEM/8N
ADQAMAAlACAALQAgAEEAYwBjAGUAbgB0ADYAAAADAAEADAAHCcxM/NW0/wUADAAHAQAAAAAA/yUA
BQACkwISABwADQAANjAlIC0gQWNjZW50MZIITQCSCAAAAAAAAAAAAAABBCD/DQA2ADAAJQAgAC0A
IABBAGMAYwBlAG4AdAAxAAAAAwABAAwABwQyM5Wz1/8FAAwABwAAAP////8lAAUAApMCEgAdAA0A
ADYwJSAtIEFjY2VudDKSCE0AkggAAAAAAAAAAAAAAQQk/w0ANgAwACUAIAAtACAAQQBjAGMAZQBu
AHQAMgAAAAMAAQAMAAcFMjPalpT/BQAMAAcAAAD/////JQAFAAKTAhIAHgANAAA2MCUgLSBBY2Nl
bnQzkghNAJIIAAAAAAAAAAAAAAEEKP8NADYAMAAlACAALQAgAEEAYwBjAGUAbgB0ADMAAAADAAEA
DAAHBjIzxNeb/wUADAAHAAAA/////yUABQACkwISAB8ADQAANjAlIC0gQWNjZW50NJIITQCSCAAA
AAAAAAAAAAABBCz/DQA2ADAAJQAgAC0AIABBAGMAYwBlAG4AdAA0AAAAAwABAAwABwcyM7Ggx/8F
AAwABwAAAP////8lAAUAApMCEgAgAA0AADYwJSAtIEFjY2VudDWSCE0AkggAAAAAAAAAAAAAAQQw
/w0ANgAwACUAIAAtACAAQQBjAGMAZQBuAHQANQAAAAMAAQAMAAcIMjOSzdz/BQAMAAcAAAD/////
JQAFAAKTAhIAIQANAAA2MCUgLSBBY2NlbnQ2kghNAJIIAAAAAAAAAAAAAAEENP8NADYAMAAlACAA
LQAgAEEAYwBjAGUAbgB0ADYAAAADAAEADAAHCTIz+r+P/wUADAAHAAAA/////yUABQACkwIMACIA
BwAAQWNjZW50MZIIQQCSCAAAAAAAAAAAAAABBB3/BwBBAGMAYwBlAG4AdAAxAAAAAwABAAwABwQA
AE+Bvf8FAAwABwAAAP////8lAAUAApMCDAAjAAcAAEFjY2VudDKSCEEAkggAAAAAAAAAAAAAAQQh
/wcAQQBjAGMAZQBuAHQAMgAAAAMAAQAMAAcFAADAUE3/BQAMAAcAAAD/////JQAFAAKTAgwAJAAH
AABBY2NlbnQzkghBAJIIAAAAAAAAAAAAAAEEJf8HAEEAYwBjAGUAbgB0ADMAAAADAAEADAAHBgAA
m7tZ/wUADAAHAAAA/////yUABQACkwIMACUABwAAQWNjZW50NJIIQQCSCAAAAAAAAAAAAAABBCn/
BwBBAGMAYwBlAG4AdAA0AAAAAwABAAwABwcAAIBkov8FAAwABwAAAP////8lAAUAApMCDAAmAAcA
AEFjY2VudDWSCEEAkggAAAAAAAAAAAAAAQQt/wcAQQBjAGMAZQBuAHQANQAAAAMAAQAMAAcIAABL
rMb/BQAMAAcAAAD/////JQAFAAKTAgwAJwAHAABBY2NlbnQ2kghBAJIIAAAAAAAAAAAAAAEEMf8H
AEEAYwBjAGUAbgB0ADYAAAADAAEADAAHCQAA95ZG/wUADAAHAAAA/////yUABQACkwIIACgAAwAA
QmFkkgg5AJIIAAAAAAAAAAAAAAEBG/8DAEIAYQBkAAAAAwABAAwABf8AAP/Hzv8FAAwABf8AAJwA
Bv8lAAUAApMCEAApAAsAAENhbGN1bGF0aW9ukgiBAJIIAAAAAAAAAAAAAAECFv8LAEMAYQBsAGMA
dQBsAGEAdABpAG8AbgAAAAcAAQAMAAX/AADy8vL/BQAMAAX/AAD6fQD/JQAFAAIGAA4ABf8AAH9/
f/8BAAcADgAF/wAAf39//wEACAAOAAX/AAB/f3//AQAJAA4ABf8AAH9/f/8BAJMCDwAqAAoAAENo
ZWNrIENlbGySCH8AkggAAAAAAAAAAAAAAQIX/woAQwBoAGUAYwBrACAAQwBlAGwAbAAAAAcAAQAM
AAX/AAClpaX/BQAMAAcAAAD/////JQAFAAIGAA4ABf8AAD8/P/8GAAcADgAF/wAAPz8//wYACAAO
AAX/AAA/Pz//BgAJAA4ABf8AAD8/P/8GAJMCBAArgAP/kgggAJIIAAAAAAAAAAAAAAEFA/8FAEMA
bwBtAG0AYQAAAAAAkwIEACyABv+SCCgAkggAAAAAAAAAAAAAAQUG/wkAQwBvAG0AbQBhACAAWwAw
AF0AAAAAAJMCBAAtgAT/kggmAJIIAAAAAAAAAAAAAAEFBP8IAEMAdQByAHIAZQBuAGMAeQAAAAAA
kwIEAC6AB/+SCC4AkggAAAAAAAAAAAAAAQUH/wwAQwB1AHIAcgBlAG4AYwB5ACAAWwAwAF0AAAAA
AJMCFQAvABAAAEV4cGxhbmF0b3J5IFRleHSSCEcAkggAAAAAAAAAAAAAAQI1/xAARQB4AHAAbABh
AG4AYQB0AG8AcgB5ACAAVABlAHgAdAAAAAIABQAMAAX/AAB/f3//JQAFAAKTAgQAMIAJ/5IISwCS
CAAAAAAAAAAAAAABAgn/EgBGAG8AbABsAG8AdwBlAGQAIABIAHkAcABlAHIAbABpAG4AawAAAAIA
BQAMAAcLAACAAID/JQAFAAKTAgkAMQAEAABHb29kkgg7AJIIAAAAAAAAAAAAAAEBGv8EAEcAbwBv
AGQAAAADAAEADAAF/wAAxu/O/wUADAAF/wAAAGEA/yUABQACkwIOADIACQAASGVhZGluZyAxkghH
AJIIAAAAAAAAAAAAAAEDEP8JAEgAZQBhAGQAaQBuAGcAIAAxAAAAAwAFAAwABwMAAB9Jff8lAAUA
AgcADgAHBAAAT4G9/wUAkwIOADMACQAASGVhZGluZyAykghHAJIIAAAAAAAAAAAAAAEDEf8JAEgA
ZQBhAGQAaQBuAGcAIAAyAAAAAwAFAAwABwMAAB9Jff8lAAUAAgcADgAHBP8/p7/e/wUAkwIOADQA
CQAASGVhZGluZyAzkghHAJIIAAAAAAAAAAAAAAEDEv8JAEgAZQBhAGQAaQBuAGcAIAAzAAAAAwAF
AAwABwMAAB9Jff8lAAUAAgcADgAHBDIzlbPX/wIAkwIOADUACQAASGVhZGluZyA0kgg5AJIIAAAA
AAAAAAAAAAEDE/8JAEgAZQBhAGQAaQBuAGcAIAA0AAAAAgAFAAwABwMAAB9Jff8lAAUAApMCBAA2
gAj/kgg5AJIIAAAAAAAAAAAAAAECCP8JAEgAeQBwAGUAcgBsAGkAbgBrAAAAAgAFAAwABwoAAAAA
//8lAAUAApMCCgA3AAUAAElucHV0kgh1AJIIAAAAAAAAAAAAAAECFP8FAEkAbgBwAHUAdAAAAAcA
AQAMAAX/AAD/zJn/BQAMAAX/AAA/P3b/JQAFAAIGAA4ABf8AAH9/f/8BAAcADgAF/wAAf39//wEA
CAAOAAX/AAB/f3//AQAJAA4ABf8AAH9/f/8BAJMCEAA4AAsAAExpbmtlZCBDZWxskghLAJIIAAAA
AAAAAAAAAAECGP8LAEwAaQBuAGsAZQBkACAAQwBlAGwAbAAAAAMABQAMAAX/AAD6fQD/JQAFAAIH
AA4ABf8AAP+AAf8GAJMCDAA5AAcAAE5ldXRyYWySCEEAkggAAAAAAAAAAAAAAQEc/wcATgBlAHUA
dAByAGEAbAAAAAMAAQAMAAX/AAD/65z/BQAMAAX/AACcZQD/JQAFAAKTAgQAAIAA/5IIMwCSCAAA
AAAAAAAAAAABAQD/BgBOAG8AcgBtAGEAbAAAAAIABQAMAAcBAAAAAAD/JQAFAAKTAgkAOgAEAABO
b3RlkghiAJIIAAAAAAAAAAAAAAECCv8EAE4AbwB0AGUAAAAFAAEADAAF/wAA///M/wYADgAF/wAA
srKy/wEABwAOAAX/AACysrL/AQAIAA4ABf8AALKysv8BAAkADgAF/wAAsrKy/wEAkwILADsABgAA
T3V0cHV0kgh3AJIIAAAAAAAAAAAAAAECFf8GAE8AdQB0AHAAdQB0AAAABwABAAwABf8AAPLy8v8F
AAwABf8AAD8/P/8lAAUAAgYADgAF/wAAPz8//wEABwAOAAX/AAA/Pz//AQAIAA4ABf8AAD8/P/8B
AAkADgAF/wAAPz8//wEAkwIEADyABf+SCCQAkggAAAAAAAAAAAAAAQUF/wcAUABlAHIAYwBlAG4A
dAAAAAAAkwIKAD0ABQAAVGl0bGWSCDEAkggAAAAAAAAAAAAAAQMP/wUAVABpAHQAbABlAAAAAgAF
AAwABwMAAB9Jff8lAAUAAZMCCgA+AAUAAFRvdGFskghNAJIIAAAAAAAAAAAAAAEDGf8FAFQAbwB0
AGEAbAAAAAQABQAMAAcBAAAAAAD/JQAFAAIGAA4ABwQAAE+Bvf8BAAcADgAHBAAAT4G9/wYAkwIR
AD8ADAAAV2FybmluZyBUZXh0kgg/AJIIAAAAAAAAAAAAAAECC/8MAFcAYQByAG4AaQBuAGcAIABU
AGUAeAB0AAAAAgAFAAwABf8AAP8AAP8lAAUAAo4IWACOCAAAAAAAAAAAAACQAAAAEQARAFQAYQBi
AGwAZQBTAHQAeQBsAGUATQBlAGQAaQB1AG0AMgBQAGkAdgBvAHQAUwB0AHkAbABlAEwAaQBnAGgA
dAAxADYAYAECAAAAhQAPAGQ7AAAAAAcAQ29tcGFyZYUAGgBdZQAAAAASAFNtYXJ0IEJhdHRlcnkg
RGF0YYUAEwA6bQAAAAALAEJhdHRlcnkgTUlCmggYAJoIAAAAAAAAAAAAAAEAAAAAAAAABAAAAKMI
EACjCAAAAAAAAAAAAAAAAAAAjAAEAAEAAQCuAQQAAwABBBcACAABAAAAAAAAABgAGwAgAAABCwAA
AAEAAAAAAAAGOwAAAwAoAAAAAwDBAQgAwQEAAI00AgD8AHUI5AAAAGIAAAADAAAtLS0JAABJbnRl
Z2VyMzIPAABiYXR0ZXJ5SW5kZXgoMSkDAAByLW4PAABTbm1wQWRtaW5TdHJpbmcUAABiYXR0ZXJ5
SWRlbnRpZmllcigyKRkAAGJhdHRlcnlGaXJtd2FyZVZlcnNpb24oMykLAABFbnVtZXJhdGlvbg4A
AGJhdHRlcnlUeXBlKDQpCgAAVW5zaWduZWQzMhQAAGJhdHRlcnlUZWNobm9sb2d5KDUpGAAAYmF0
dGVyeU5vbWluYWxWb2x0YWdlKDYpFwAAYmF0dGVyeU51bWJlck9mQ2VsbHMoNykZAABiYXR0ZXJ5
Tm9taW5hbENhcGFjaXR5KDgpCwAARGF0ZUFuZFRpbWUDAAByd24GAAA1LjEuMS4GAAA1LjEuMi4G
AAA1LjEuMy4GAAA1LjEuNC4GAAA1LjEuNS4GAAA1LjEuNi4GAAA1LjEuNy4GAAA1LjEuOC4GAAA1
LjEuOS4HAAA1LjEuMTAuBwAANS4xLjExLgcAADUuMS4xMi4HAAA1LjEuMTMuBwAANS4xLjE0LgcA
ADUuMS4xNS4HAAA1LjEuMTYuBwAANS4xLjE3LgcAADUuMS4xOC4HAAA1LjEuMTkuBwAANS4xLjIw
LgcAADUuMS4yMS4HAAA1LjEuMjIuBwAANS4xLjIzLgcAADUuMS4yNC4HAAA1LjEuMjUuBwAANS4x
LjI2LgcAADUuMS4yNy4HAAA1LjEuMjguBwAANS4xLjI5LgcAADUuMS4zMC4HAAA1LjEuMzEuGwAA
TWFudWZhY3R1cmVyQWNjZXNzKCkgKDB4MDApHwAAUmVtYWluaW5nQ2FwYWNpdHlBbGFybSgpICgw
eDAxKRsAAFJlbWFpbmluZ1RpbWVBbGFybSgpICgweDAyKRQAAEJhdHRlcnlNb2RlKCkgKDB4MDMp
DwAAQXRSYXRlKCkgKDB4MDQpGQAAQXRSYXRlVGltZVRvRnVsbCgpICgweDA1KRoAAEF0UmF0ZVRp
bWVUb0VtcHR5KCkgKDB4MDYpEQAAQXRSYXRlT0soKSAoMHgwNykUAABUZW1wZXJhdHVyZSgpICgw
eDA4KRAAAFZvbHRhZ2UoKSAoMHgwOSkQAABDdXJyZW50KCkgKDB4MGEpFwAAQXZlcmFnZUN1cnJl
bnQoKSAoMHgwYikRAABNYXhFcnJvcigpICgweDBjKR4AAFJlbGF0aXZlU3RhdGVPZkNoYXJnZSgp
ICgweDBkKR4AAEFic29sdXRlU3RhdGVPZkNoYXJnZSgpICgweDBlKRoAAFJlbWFpbmluZ0NhcGFj
aXR5KCkgKDB4MGYpGwAARnVsbENoYXJnZUNhcGFjaXR5KCkgKDB4MTApFwAAUnVuVGltZVRvRW1w
dHkoKSAoMHgxMSkbAABBdmVyYWdlVGltZVRvRW1wdHkoKSAoMHgxMikaAABBdmVyYWdlVGltZVRv
RnVsbCgpICgweDEzKRYAAEJhdHRlcnlTdGF0dXMoKSAoMHgxNikTAABDeWNsZUNvdW50KCkgKDB4
MTcpGAAARGVzaWduQ2FwYWNpdHkoKSAoMHgxOCkgFgAARGVzaWduVm9sdGFnZSgpICgweDE5KRoA
AFNwZWNpZmljYXRpb25JbmZvKCkgKDB4MWEpGAAATWFudWZhY3R1cmVEYXRlKCkgKDB4MWIpFQAA
U2VyaWFsTnVtYmVyKCkgKDB4MWMpGQAATWFudWZhY3R1cmVyTmFtZSgpICgweDIwKRMAAERldmlj
ZU5hbWUoKSAoMHgyMSkYAABEZXZpY2VDaGVtaXN0cnkoKSAoMHgyMikZAABNYW51ZmFjdHVyZXJE
YXRhKCkgKDB4MjMpXwAATWFudWZhY3R1cmVyTmFtZSgpICgweDIwKSwgRGV2aWNlTmFtZSgpICgw
eDIxKSwgTWFudWZhY3R1cmVEYXRlKCkgKDB4MWIpLCBTZXJpYWxOdW1iZXIoKSAoMHgxYykQAABJ
bnRlZ2VyMzIgICAgICAgHQAAYmF0dGVyeU1heENoYXJnaW5nQ3VycmVudCAoOSkiAABiYXR0ZXJ5
VHJpY2tsZUNoYXJnaW5nQ3VycmVudCAoMTApHQAAYmF0dGVyeUNoYXJnaW5nQ3ljbGVDb3VudCgx
MikgAABiYXR0ZXJ5TGFzdENoYXJnaW5nQ3ljbGVUaW1lKDEzKRgAAGJhdHRlcnlDaGFyZ2luZ1N0
YXRlKDE0KRgAAGJhdHRlcnlDdXJyZW50Q2hhcmdlKDE1KRkAAGJhdHRlcnlDdXJyZW50Vm9sdGFn
ZSgxNikZAABiYXR0ZXJ5Q3VycmVudEN1cnJlbnQoMTcpFgAAYmF0dGVyeVRlbXBlcmF0dXJlKDE4
KR0AAGJhdHRlcnlMb3dBbGFybVBlcmNlbnRhZ2UoMTkpGgAAYmF0dGVyeUxvd0FsYXJtVm9sdGFn
ZSgyMCkjAABiYXR0ZXJ5UmVwbGFjZW1lbnRBbGFybUNhcGFjaXR5KDIxKSEAAGJhdHRlcnlSZXBs
YWNlbWVudEFsYXJtQ3ljbGVzKDIyKSAAAGJhdHRlcnlIaWdoQWxhcm1UZW1wZXJhdHVyZSAoMjMp
EgAAU21hcnQgQmF0dGVyeSBEYXRhGQAAYmF0dGVyeUFjdHVhbENhcGFjaXR5KDExKYcAAEFic29s
dXRlU3RhdGVPZkNoYXJnZSgpICgweDBlKSAqIERlc2lnbkNhcGFjaXR5KCkgKDB4MTgpIC8xMDAg
b3IgKD8pClJlbGF0aXZlU3RhdGVPZkNoYXJnZSgpICgweDBkKSAqIEZ1bGxDaGFyZ2VDYXBhY2l0
eSgpICgweDEwKSAvIDEwMBAAAEJhdHRlcnkgTUlCICgwMin/AGoACAAPMgAADAAAAIwyAACJAAAA
JjMAACMBAABuMwAAawEAAL0zAAC6AQAADTQAAAoCAABxNAAAbgIAAD41AAA7AwAADzYAAAwEAADk
NgAA4QQAAPU3AADyBQAA6zgAAOgGAADfOQAA3AcAAGMIFgBjCAAAAAAAAAAAAAAWAAAAAAAAAAIA
lggQAJYIAAAAAAAAAAAAAELlAQCbCBAAmwgAAAAAAAAAAAAAAQAAAIwIEACMCAAAAAAAAAAAAAAA
AAAAlwgcAJcIAAAAAAAAAAAAAJAcT4zrBVVqXwkJwktVrAsKAAAACQgQAAAGEABmMs0HyYABAAYG
AAALAhgAAAAAAAMAAAApAAAAjFsAAMxjAADgZAAADQACAAEADAACAGQADwACAAEAEQACAAAAEAAI
APyp8dJNYlA/XwACAAEAKgACAAAAKwACAAAAggACAAEAgAAIAAAAAAAAAAAAJQIEAAAALAGBAAIA
wQUUAAAAFQAAAIMAAgAAAIQAAgAAACYACABmZmZmZmbmPycACABmZmZmZmbmPygACAAAAAAAAADo
PykACAAAAAAAAADoP00ACh8AAEgAUAAgAEwASgAgADUANQA1ADAATgAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBAAG3AAsHkP/gAcBAAEA6gpvCGQAAQAPAFgCAgAC
AFgCAwABAEwAZQB0AHQAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAQAAAAIAAAAdAQAA/////wAAAAAA
AAAAAAAAAAAAAABESU5VIgAICEQK6BMK4SenAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQA
AAAAAAAAAAAAAAAAAAAIAAAABQACAAMABAADAAMABAADAAQABAADAAAAAAABAAAAAAAAAAAAAQAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAEAAAAAAAAAAAAAAAgIAABTTVRKAAAAABAA+AdIAFAAIABVAG4AaQB2AGUAcgBzAGEAbAAgAFAA
cgBpAG4AdABpAG4AZwAgAFAAQwBMACAANgAAAElucHV0QmluAEZPUk1TT1VSQ0UAUkVTRExMAFVu
aXJlc0RMTABIUERvY1VJU1VJAFRydWUARVNQUklUU3VwcG9ydGVkAFRydWUARmFzdFJlcwAxYnBw
AFJlc29sdXRpb24ANjAwZHBpAFByaW50UXVhbGl0eUdyb3VwAFBRR3JvdXBfMgBIUENvbG9yU21h
cnQAQXV0b21hdGljAEhQQ29sb3JTbWFydF9Db2xvck9wdGlvbnNfRWRnZUNvbnRyb2wATm9ybWFs
AEhQQ29sb3JTbWFydF9Db2xvck9wdGlvbnNfSGFsZnRvbmUATm9DbWQASFBDb2xvclNtYXJ0X1Rl
eHRfTmV1dHJhbEdyYXlzAEJsYWNrT25seQBIUENvbG9yU21hcnRfVGV4dF9IYWxmdG9uZQBEZXRh
aWwASFBDb2xvclNtYXJ0X1RleHRfUkdCQ29sb3IARGVmYXVsdChzUkdCKQBIUENvbG9yU21hcnRf
R3JhcGhpY3NfTmV1dHJhbEdyYXlzAEJsYWNrT25seQBIUENvbG9yU21hcnRfR3JhcGhpY3NfSGFs
ZnRvbmUARGV0YWlsAEhQQ29sb3JTbWFydF9HcmFwaGljc19SR0JDb2xvcgBEZWZhdWx0KHNSR0Ip
AEhQQ29sb3JTbWFydF9QaG90b19OZXV0cmFsR3JheXMANC1Db2xvcgBIUENvbG9yU21hcnRfUGhv
dG9fSGFsZnRvbmUARGV0YWlsAEhQQ29sb3JTbWFydF9QaG90b19SR0JDb2xvcgBEZWZhdWx0KHNS
R0IpAE9yaWVudGF0aW9uAFBPUlRSQUlUAEhQT3JpZW50Um90YXRlMTgwAEZhbHNlAER1cGxleABW
RVJUSUNBTABIUFByaW50T25Cb3RoU2lkZXNNYW51YWxseQBGYWxzZQBQYXBlclNpemUATEVUVEVS
AEhQQ29uc3VtZXJDdXN0b21QYXBlcgBUcnVlAE1lZGlhVHlwZQBBVVRPAENvbGxhdGUAT04ASFBO
VXNlRGlmZkZpcnN0UGFnZUNob2ljZQBUUlVFAEhQUGFnZUV4Y2VwdGlvbnNGaWxlAEhQQ1BFMTEy
AEhQUGFnZUV4Y2VwdGlvbnNJbnRlcmZhY2UAU2hvd1BhZ2VFeGNlcHRpb25zAEhQUGFnZUV4Y2Vw
dGlvbnNMb3dFbmQASFBQYWdlRXhjZXB0aW9uc0xvd0VuZFZlcgBIUFBhZ2VFeGNlcHRpb25zAENv
dmVySW5zZXJ0aW9uAEhQT3V0cHV0QmluT3JpZW50YXRpb24ARkFDRURPV04AUHVuY2hpbmcATm9u
ZQBTdGFwbGluZwBOb25lAEhQU3RhcGxpbmdPcHBvc2VkAEZhbHNlAEVjb25vbW9kZQBGYWxzZQBU
ZXh0QXNCbGFjawBGYWxzZQBBbHRlcm5hdGVMZXR0ZXJIZWFkAEZhbHNlAEhQU21hcnRIdWIASW5l
dF9TSURfMjYzX0JJRF81MTRfSElEXzI2NQBPdXRwdXRCaW4AQXV0bwBIUERvY1Byb3BSZXNvdXJj
ZURhdGEAaHBjaGwxMTIuY2FiAEhQTHBpU2VsZWN0aW9uAE5vbmUASlBFR0VuYWJsZQBBdXRvAEhQ
RWFzeUNvbG9yAE9uAEhQTUhETExOYW1lAEhQRklFMTEyAEhQX0RJQlN0aXRjaF9UaW50VGVzdABE
aXNhYmxlZABIUE1lZGlhVHlwZVRyZWV2aWV3UG9wdXAAVHJ1ZQBIUENvbG9yTW9kZQBDT0xPUl9N
T0RFAENvbG9yTW9kZQAyNGJwcABUVEFzQml0bWFwc1NldHRpbmcAVFRNb2RlT3V0bGluZQBIUFBE
TFR5cGUAUERMX1BDTDYASFBQSkxFbmNvZGluZwBVVEY4AEhQSm9iQWNjb3VudGluZwBIUEpPQkFD
Q1RfSk9CQUNOVF9HUk9VUE5BTUUASFBCb3JuT25EYXRlAEhQQk9EAEhQQ29sb3JQbGFuZQBIUENQ
AEhQSm9iQnlKb2JPdmVycmlkZQBKQkpPAEhQSm9iQWNjV29QaW4AVHJ1ZQBIUFhNTEZpbGVVc2Vk
AGhwY3UxMTI2LnhtbABIUFNtYXJ0RHVwbGV4U2luZ2xlUGFnZUpvYgBUcnVlAEhQRHVwbGljYXRl
Sm9iTmFtZU92ZXJyaWRlAFNXRlcASFBFbmFibGVSQVdTcG9vbGluZwBUcnVlAFJHQkNvbG9yAE5v
Q21kAEpSQ29uc3RyYWludHMASlJDSERGdWxsAEpSSERJbnN0YWxsZWQASlJIRE9mZgBKUkhETm90
SW5zdGFsbGVkAEpSSERPZmYASFBCZXN0R2xvc3MARGVmYXVsdABQU0FsaWdubWVudEZpbGUASFBD
TFMxMTIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAADoEwAASVVQSBkAAQB4nO2Zy27TQBSGfycIRWxA6goKkjewa4XAioCi
ItdxSQQCk1TKgrIotQuVSh2lF4ddWSDEK/AI8BJZ8gBsEduqT8AOzvgiTR3SgNQ2NP4/62TOHM/Y
k8z1nOxPATXXq1+GAUUplSSXUE5TI5YSfPk0xJqVU+ljBNiWK0AXwzBwcCGsAL80VP3zQ2v8PUYu
HYZ6p0pNPMcmQpEAL47h/eRswf4npLhYIl6qZ3tGv98/lOoYqfgDd/YejHpXfk8qiaFsHF2mBQd1
uGiPejiZUO7Dxo6cqEK8wYqk61jF/LgbRc4A+llYyR4Ory9GTvQ6F0WuGYN6Rauf2fX7OlYlkYwq
bsrloyNjmBSTaRknV0Y5Z4SQwpHtI+rM+1r88WjcDSJkAlHbryM+xVbqVZjiAXflTLYpeVNmXxLB
VflXUoZMIv9yBPPT8voo8WN9N47zm7Jah/FoMrEmmrLcxi28lBLKtiIn/s4JfQ9CyOmwKDN5Nd4z
ungr87oms39NbDvYEGsxdgr1H+dMGdjqbERhVLVmg16g7PlYyklIPt5yVPzlqp4vnUPWRgf3sIx2
vI770pOR9NuySEf6MIrzVViYlZ7tITi2X438f9DLKjYLaMLFE8xgSbSnojVkRLTG3SxyyjAYSxIa
nu3Umu1a66G95NheY3ruy+IHa9999+3Hnalnc48GKqx/+v7+xk/34/WDu58v9b563kLddpveHx5N
CCGEEEIIIYQQMpLfNydvqQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKEAIgABAEcAAQABAAEAAgBY
AlgCMzMzMzMz0z8zMzMzMzPTPwEAnAgmAJwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8MwAA
AAAAAAAAVQACAAgAfQAMAAAAAABJCA8AAgAAAH0ADAABAAEA2xEPAAIAAAB9AAwAAgACACQkDwAC
AAAAfQAMAAMAAwBtQA8AAgAAAAACDgADAAAAKQAAAAAABAAAAAgCEAADAAAABAAsAQAAAAAAAQ8A
CAIQAAQAAAAEACwBAAAAAAABDwAIAhAABQAAAAQAWAIAAAAAAAEPAAgCEAAGAAAABAAsAQAAAAAA
AQ8ACAIQAAcAAAAEACwBAAAAAAABDwAIAhAACAAAAAQALAEAAAAAAAEPAAgCEAAJAAAABAAsAQAA
AAAAAQ8ACAIQAAoAAAAEACwBAAAAAAABDwAIAhAACwAAAAQALAEAAAAAAAEPAAgCEAAMAAAABAAs
AQAAAAAAAQ8ACAIQAA0AAAAEACwBAAAAAAABDwAIAhAADgAAAAQALAEAAAAAAAEPAAgCEAAPAAAA
BAAsAQAAAAAAAQ8ACAIQABAAAAAEACwBAAAAAAABDwAIAhAAEQAAAAQALAEAAAAAAAEPAAgCEAAS
AAAABACjAgAAAADAAUEACAIQABMAAAAEACwBAAAAAAABDwAIAhAAFAAAAAQALAEAAAAAAAEPAAgC
EAAVAAAABAAsAQAAAAAAAQ8ACAIQABYAAAAEACwBAAAAAAABDwAIAhAAFwAAAAQALAEAAAAAAAEP
AAgCEAAYAAAABAAsAQAAAAAAAQ8ACAIQABkAAAAEACwBAAAAAAABDwAIAhAAGgAAAAQALAEAAAAA
AAEPAAgCEAAbAAAABAAsAQAAAAAAAQ8ACAIQABwAAAAEACwBAAAAAAABDwAIAhAAHQAAAAQALAEA
AAAAAAEPAAgCEAAeAAAABAAsAQAAAAAAAQ8ACAIQAB8AAAAEACwBAAAAAAABDwAIAhAAIAADAAQA
LAEAAAAAAAEPAAgCEAAhAAMABAAsAQAAAAAAAQ8ACAIQACIAAwAEACwBAAAAAAABDwD9AAoAAwAC
AEUAYQAAAP0ACgADAAMARQBeAAAA/QAKAAQAAABCAAAAAAD9AAoABAABAEIAAQAAAP0ACgAEAAIA
QgACAAAAAQIGAAQAAwBCAP0ACgAFAAAAQwADAAAA/QAKAAUAAQBDAAQAAAD9AAoABQACAEMABQAA
AP0ACgAFAAMARABOAAAA/QAKAAYAAABCAAMAAAD9AAoABgABAEIABAAAAP0ACgAGAAIAQgAGAAAA
AQIGAAYAAwBCAP0ACgAHAAAAQgADAAAA/QAKAAcAAQBCAAcAAAD9AAoABwACAEIACAAAAAECBgAH
AAMAQgD9AAoACAAAAEIAAwAAAP0ACgAIAAEAQgAJAAAA/QAKAAgAAgBCAAoAAAD9AAoACAADAEIA
TAAAAP0ACgAJAAAAQgADAAAA/QAKAAkAAQBCAAkAAAD9AAoACQACAEIACwAAAP0ACgAJAAMAQgBG
AAAA/QAKAAoAAABCAAMAAAD9AAoACgABAEIACQAAAP0ACgAKAAIAQgAMAAAAAQIGAAoAAwBCAP0A
CgALAAAAQgADAAAA/QAKAAsAAQBCAAkAAAD9AAoACwACAEIADQAAAP0ACgALAAMAQgBFAAAA/QAK
AAwAAABCAAMAAAD9AAoADAABAEIACQAAAP0ACgAMAAIAQgBQAAAAAQIGAAwAAwBCAP0ACgANAAAA
QgADAAAA/QAKAA0AAQBCAAkAAAD9AAoADQACAEIAUQAAAAECBgANAAMAQgD9AAoADgAAAEIAAwAA
AP0ACgAOAAEAQgAJAAAA/QAKAA4AAgBCAF8AAAD9AAoADgADAEIAPgAAAP0ACgAPAAAAQgADAAAA
/QAKAA8AAQBCAAkAAAD9AAoADwACAEIAUgAAAP0ACgAPAAMAQgBEAAAA/QAKABAAAABCAAMAAAD9
AAoAEAABAEIADgAAAP0ACgAQAAIAQgBTAAAAAQIGABAAAwBCAP0ACgARAAAAQgADAAAA/QAKABEA
AQBCAAcAAAD9AAoAEQACAEIAVAAAAP0ACgARAAMAQgBDAAAA/QAKABIAAABDAAMAAAD9AAoAEgAB
AEMACQAAAP0ACgASAAIAQwBVAAAA/QAKABIAAwBEAGAAAAD9AAoAEwAAAEIAAwAAAP0ACgATAAEA
QgAJAAAA/QAKABMAAgBCAFYAAAD9AAoAEwADAEIAOAAAAP0ACgAUAAAAQgADAAAA/QAKABQAAQBC
AAEAAAD9AAoAFAACAEIAVwAAAP0ACgAUAAMAQgA5AAAA/QAKABUAAABCAAMAAAD9AAoAFQABAEIA
AQAAAP0ACgAVAAIAQgBYAAAA/QAKABUAAwBCADcAAAD9AAoAFgAAAEIADwAAAP0ACgAWAAEAQgAJ
AAAA/QAKABYAAgBCAFkAAAD9AAoAFgADAEIAMAAAAP0ACgAXAAAAQgAPAAAA/QAKABcAAQBCAAkA
AAD9AAoAFwACAEIAWgAAAAECBgAXAAMAQgD9AAoAGAAAAEIADwAAAP0ACgAYAAEAQgAJAAAA/QAK
ABgAAgBCAFsAAAABAgYAGAADAEIA/QAKABkAAABCAA8AAAD9AAoAGQABAEIACQAAAP0ACgAZAAIA
QgBcAAAAAQIGABkAAwBCAP0ACgAaAAAAQgADAAAA/QAKABoAAQBCAE8AAAD9AAoAGgACAEIAXQAA
AAECBgAaAAMAQgD9AAoAGwADAEIALwAAAP0ACgAcAAMAQgAxAAAA/QAKAB0AAwBCADIAAAD9AAoA
HgADAEIAMwAAAP0ACgAfAAMAQgA0AAAA/QAKACAAAwBCADUAAAD9AAoAIQADAEMANgAAAP0ACgAi
AAMAQgA6AAAA1wBEAOgHAABsAhwANAA4ADQANAA4ADgANAA4ADQANAA4ADgANAA4ADgAOAA4ADgA
OAA0ADQANAA0AA4ADgAOAA4ADgAOAA4ACAIQACMAAwAEACwBAAAAAAABDwAIAhAAJAADAAQALAEA
AAAAAAEPAAgCEAAlAAMABAAsAQAAAAAAAQ8ACAIQACYAAwAEACwBAAAAAAABDwAIAhAAJwADAAQA
LAEAAAAAAAEPAAgCEAAoAAMABAAsAQAAAAAAAQ8A/QAKACMAAwBCADsAAAD9AAoAJAADAEIAQAAA
AP0ACgAlAAMAQgBBAAAA/QAKACYAAwBCAEIAAAD9AAoAJwADAEIARwAAAP0ACgAoAAMAQgBNAAAA
1wAQAMwAAABkAA4ADgAOAA4ADgA+AhIAtgYMAAAAQAAAAAAAAAAAAAAAiwgQAIsIAAAAAAAAAAAA
AAAAAgAdAA8AAyIAAwAAAAEAIgAiAAMDugEJAAYAAFNoZWV0MWcIFwBnCAAAAAAAAAAAAAACAAH/
////A0QAAAoAAAAJCBAAAAYQAGYyzQfJgAEABgYAAAsCFAAAAAAAAAAAAB8AAABzZgAAi2wAAA0A
AgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHSTWJQP18AAgABACoAAgAAACsAAgAAAIIAAgAB
AIAACAAAAAAAAAAAACUCBAAAACwBgQACAMEEFAAAABUAAACDAAIAAACEAAIAAAAmAAgAZmZmZmZm
5j8nAAgAZmZmZmZm5j8oAAgAAAAAAAAA6D8pAAgAAAAAAAAA6D+hACIAAAAsAQEAAQABAAQAAgAB
/zMzMzMzM9M/MzMzMzMz0z8AAJwIJgCcCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPDMAAAAA
AAAAAFUAAgAIAH0ADAAAAAAA2wgPAAIAAAB9AAwAAQABACQkDwACAAAAfQAMAAIAAgCSEw8AAgAA
AAACDgAAAAAAHwAAAAAAAgAAAAgCEAAAAAAAAgAsAQAAAAAAAQ8ACAIQAAEAAAACACwBAAAAAAAB
DwAIAhAAAgAAAAIALAEAAAAAAAEPAAgCEAADAAAAAgAsAQAAAAAAAQ8ACAIQAAQAAAACACwBAAAA
AAABDwAIAhAABQAAAAIALAEAAAAAAAEPAAgCEAAGAAAAAgAsAQAAAAAAAQ8ACAIQAAcAAAACACwB
AAAAAAABDwAIAhAACAAAAAIALAEAAAAAAAEPAAgCEAAJAAAAAgAsAQAAAAAAAQ8ACAIQAAoAAAAC
ACwBAAAAAAABDwAIAhAACwAAAAIALAEAAAAAAAEPAAgCEAAMAAAAAgAsAQAAAAAAAQ8ACAIQAA0A
AAACACwBAAAAAAABDwAIAhAADgAAAAIALAEAAAAAAAEPAAgCEAAPAAAAAgAsAQAAAAAAAQ8ACAIQ
ABAAAAACACwBAAAAAAABDwAIAhAAEQAAAAIALAEAAAAAAAEPAAgCEAASAAAAAgAsAQAAAAAAAQ8A
CAIQABMAAAACACwBAAAAAAABDwAIAhAAFAAAAAIALAEAAAAAAAEPAAgCEAAVAAAAAgAsAQAAAAAA
AQ8ACAIQABYAAAACACwBAAAAAAABDwAIAhAAFwAAAAIALAEAAAAAAAEPAAgCEAAYAAAAAgAsAQAA
AAAAAQ8ACAIQABkAAAACACwBAAAAAAABDwAIAhAAGgAAAAIALAEAAAAAAAEPAAgCEAAbAAAAAgAs
AQAAAAAAAQ8ACAIQABwAAAACACwBAAAAAAABDwAIAhAAHQAAAAIALAEAAAAAAAEPAAgCEAAeAAAA
AgAsAQAAAAAAAQ8A/QAKAAAAAABAABAAAAD9AAoAAAABAA8ALwAAAP0ACgABAAAAQAARAAAA/QAK
AAEAAQAPADAAAAD9AAoAAgAAAEAAEgAAAP0ACgACAAEADwAxAAAA/QAKAAMAAABAABMAAAD9AAoA
AwABAA8AMgAAAP0ACgAEAAAAQAAUAAAA/QAKAAQAAQAPADMAAAD9AAoABQAAAEAAFQAAAP0ACgAF
AAEADwA0AAAA/QAKAAYAAABAABYAAAD9AAoABgABAA8ANQAAAP0ACgAHAAAAQAAXAAAA/QAKAAcA
AQAPADYAAAD9AAoACAAAAEAAGAAAAP0ACgAIAAEADwA3AAAA/QAKAAkAAABAABkAAAD9AAoACQAB
AA8AOAAAAP0ACgAKAAAAQAAaAAAA/QAKAAoAAQAPADkAAAD9AAoACwAAAEAAGwAAAP0ACgALAAEA
DwA6AAAA/QAKAAwAAABAABwAAAD9AAoADAABAA8AOwAAAP0ACgANAAAAQAAdAAAA/QAKAA0AAQAP
ADwAAAD9AAoADgAAAEAAHgAAAP0ACgAOAAEADwA9AAAA/QAKAA8AAABAAB8AAAD9AAoADwABAA8A
PgAAAP0ACgAQAAAAQAAgAAAA/QAKABAAAQAPAD8AAAD9AAoAEQAAAEAAIQAAAP0ACgARAAEADwBA
AAAA/QAKABIAAABAACIAAAD9AAoAEgABAA8AQQAAAP0ACgATAAAAQAAjAAAA/QAKABMAAQAPAEIA
AAD9AAoAFAAAAEAAJAAAAP0ACgAUAAEADwBDAAAA/QAKABUAAABAACUAAAD9AAoAFQABAA8ARAAA
AP0ACgAWAAAAQAAmAAAA/QAKABYAAQAPAEUAAAD9AAoAFwAAAEAAJwAAAP0ACgAXAAEADwBGAAAA
/QAKABgAAABAACgAAAD9AAoAGAABAA8ARwAAAP0ACgAZAAAAQAApAAAA/QAKABkAAQAPAEgAAAD9
AAoAGgAAAEAAKgAAAP0ACgAaAAEADwBJAAAA/QAKABsAAABAACsAAAD9AAoAGwABAA8ASgAAAP0A
CgAcAAAAQAAsAAAA/QAKABwAAQAPAEsAAAD9AAoAHQAAAEAALQAAAP0ACgAdAAEADwBMAAAA/QAK
AB4AAABAAC4AAAD9AAoAHgABAA8ATQAAANcAQgDQBQAAWAIcABwAHAAcABwAHAAcABwAHAAcABwA
HAAcABwAHAAcABwAHAAcABwAHAAcABwAHAAcABwAHAAcABwAHAA+AhIAtgAAAAAAQAAAAAAAAAAA
AAAAiwgQAIsIAAAAAAAAAAAAAAAAAgAdAA8AAwMAAQAAAAEAAwADAAEBugEJAAYAAFNoZWV0MmcI
FwBnCAAAAAAAAAAAAAACAAH/////A0QAAAoAAAAJCBAAAAYQAGYyzQfJgAEABgYAAAsCFAAAAAAA
BAAAABsAAABejQAASJMAAA0AAgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHSTWJQP18AAgAB
ACoAAgAAACsAAgAAAIIAAgABAIAACAAAAAAAAAAAACUCBAAAACwBgQACAMEEFAAAABUAAACDAAIA
AACEAAIAAAAmAAgAZmZmZmZm5j8nAAgAZmZmZmZm5j8oAAgAAAAAAAAA6D8pAAgAAAAAAAAA6D9N
AAofAABIAFAAIABMAEoAIAA1ADUANQAwAE4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAQQABtwALB5D/4AHAQABAOoKbwhkAAEADwBYAgIAAgBYAgMAAQBMAGUAdAB0
AGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAABAAAAAAAAAAEAAAACAAAAHQEAAP////8AAAAAAAAAAAAAAAAAAAAARElO
VSIACAhECugTCuEnpwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAAAAAAAAAAAAAAAAAAAA
CAAAAAUAAgADAAQAAwADAAQAAwAEAAQAAwAAAAAAAQAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAI
CAAAU01USgAAAAAQAPgHSABQACAAVQBuAGkAdgBlAHIAcwBhAGwAIABQAHIAaQBuAHQAaQBuAGcA
IABQAEMATAAgADYAAABJbnB1dEJpbgBGT1JNU09VUkNFAFJFU0RMTABVbmlyZXNETEwASFBEb2NV
SVNVSQBUcnVlAEVTUFJJVFN1cHBvcnRlZABUcnVlAEZhc3RSZXMAMWJwcABSZXNvbHV0aW9uADYw
MGRwaQBQcmludFF1YWxpdHlHcm91cABQUUdyb3VwXzIASFBDb2xvclNtYXJ0AEF1dG9tYXRpYwBI
UENvbG9yU21hcnRfQ29sb3JPcHRpb25zX0VkZ2VDb250cm9sAE5vcm1hbABIUENvbG9yU21hcnRf
Q29sb3JPcHRpb25zX0hhbGZ0b25lAE5vQ21kAEhQQ29sb3JTbWFydF9UZXh0X05ldXRyYWxHcmF5
cwBCbGFja09ubHkASFBDb2xvclNtYXJ0X1RleHRfSGFsZnRvbmUARGV0YWlsAEhQQ29sb3JTbWFy
dF9UZXh0X1JHQkNvbG9yAERlZmF1bHQoc1JHQikASFBDb2xvclNtYXJ0X0dyYXBoaWNzX05ldXRy
YWxHcmF5cwBCbGFja09ubHkASFBDb2xvclNtYXJ0X0dyYXBoaWNzX0hhbGZ0b25lAERldGFpbABI
UENvbG9yU21hcnRfR3JhcGhpY3NfUkdCQ29sb3IARGVmYXVsdChzUkdCKQBIUENvbG9yU21hcnRf
UGhvdG9fTmV1dHJhbEdyYXlzADQtQ29sb3IASFBDb2xvclNtYXJ0X1Bob3RvX0hhbGZ0b25lAERl
dGFpbABIUENvbG9yU21hcnRfUGhvdG9fUkdCQ29sb3IARGVmYXVsdChzUkdCKQBPcmllbnRhdGlv
bgBQT1JUUkFJVABIUE9yaWVudFJvdGF0ZTE4MABGYWxzZQBEdXBsZXgAVkVSVElDQUwASFBQcmlu
dE9uQm90aFNpZGVzTWFudWFsbHkARmFsc2UAUGFwZXJTaXplAExFVFRFUgBIUENvbnN1bWVyQ3Vz
dG9tUGFwZXIAVHJ1ZQBNZWRpYVR5cGUAQVVUTwBDb2xsYXRlAE9OAEhQTlVzZURpZmZGaXJzdFBh
Z2VDaG9pY2UAVFJVRQBIUFBhZ2VFeGNlcHRpb25zRmlsZQBIUENQRTExMgBIUFBhZ2VFeGNlcHRp
b25zSW50ZXJmYWNlAFNob3dQYWdlRXhjZXB0aW9ucwBIUFBhZ2VFeGNlcHRpb25zTG93RW5kAEhQ
UGFnZUV4Y2VwdGlvbnNMb3dFbmRWZXIASFBQYWdlRXhjZXB0aW9ucwBDb3Zlckluc2VydGlvbgBI
UE91dHB1dEJpbk9yaWVudGF0aW9uAEZBQ0VET1dOAFB1bmNoaW5nAE5vbmUAU3RhcGxpbmcATm9u
ZQBIUFN0YXBsaW5nT3Bwb3NlZABGYWxzZQBFY29ub21vZGUARmFsc2UAVGV4dEFzQmxhY2sARmFs
c2UAQWx0ZXJuYXRlTGV0dGVySGVhZABGYWxzZQBIUFNtYXJ0SHViAEluZXRfU0lEXzI2M19CSURf
NTE0X0hJRF8yNjUAT3V0cHV0QmluAEF1dG8ASFBEb2NQcm9wUmVzb3VyY2VEYXRhAGhwY2hsMTEy
LmNhYgBIUExwaVNlbGVjdGlvbgBOb25lAEpQRUdFbmFibGUAQXV0bwBIUEVhc3lDb2xvcgBPbgBI
UE1IRExMTmFtZQBIUEZJRTExMgBIUF9ESUJTdGl0Y2hfVGludFRlc3QARGlzYWJsZWQASFBNZWRp
YVR5cGVUcmVldmlld1BvcHVwAFRydWUASFBDb2xvck1vZGUAQ09MT1JfTU9ERQBDb2xvck1vZGUA
MjRicHAAVFRBc0JpdG1hcHNTZXR0aW5nAFRUTW9kZU91dGxpbmUASFBQRExUeXBlAFBETF9QQ0w2
AEhQUEpMRW5jb2RpbmcAVVRGOABIUEpvYkFjY291bnRpbmcASFBKT0JBQ0NUX0pPQkFDTlRfR1JP
VVBOQU1FAEhQQm9ybk9uRGF0ZQBIUEJPRABIUENvbG9yUGxhbmUASFBDUABIUEpvYkJ5Sm9iT3Zl
cnJpZGUASkJKTwBIUEpvYkFjY1dvUGluAFRydWUASFBYTUxGaWxlVXNlZABocGN1MTEyNi54bWwA
SFBTbWFydER1cGxleFNpbmdsZVBhZ2VKb2IAVHJ1ZQBIUER1cGxpY2F0ZUpvYk5hbWVPdmVycmlk
ZQBTV0ZXAEhQRW5hYmxlUkFXU3Bvb2xpbmcAVHJ1ZQBSR0JDb2xvcgBOb0NtZABKUkNvbnN0cmFp
bnRzAEpSQ0hERnVsbABKUkhESW5zdGFsbGVkAEpSSERPZmYASlJIRE5vdEluc3RhbGxlZABKUkhE
T2ZmAEhQQmVzdEdsb3NzAERlZmF1bHQAUFNBbGlnbm1lbnRGaWxlAEhQQ0xTMTEyAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA6BMAAElVUEgZAAEAeJztmctu00AUhn8nCEVsQOoKCpI3sGuFwIqAoiLXcUkEApNUyoKyKLUL
lUodpReHXVkgxCvwCPASWfIAbBHbqk/ADs74Ik0d0oDUNjT+P+tkzhzP2JPM9ZzsTwE116tfhgFF
KZUkl1BOUyOWEnz5NMSalVPpYwTYlitAF8MwcHAhrAC/NFT980Nr/D1GLh2GeqdKTTzHJkKRAC+O
4f3kbMH+J6S4WCJeqmd7Rr/fP5TqGKn4A3f2Hox6V35PKomhbBxdpgUHdbhoj3o4mVDuw8aOnKhC
vMGKpOtYxfy4G0XOAPpZWMkeDq8vRk70OhdFrhmDekWrn9n1+zpWJZGMKm7K5aMjY5gUk2kZJ1dG
OWeEkMKR7SPqzPta/PFo3A0iZAJR268jPsVW6lWY4gF35Uy2KXlTZl8SwVX5V1KGTCL/cgTz0/L6
KPFjfTeO85uyWofxaDKxJpqy3MYtvJQSyrYiJ/7OCX0PQsjpsCgzeTXeM7p4K/O6JrN/TWw72BBr
MXYK9R/nTBnY6mxEYVS1ZoNeoOz5WMpJSD7eclT85aqeL51D1kYH97CMdryO+9KTkfTbskhH+jCK
81VYmJWe7SE4tl+N/H/Qyyo2C2jCxRPMYEm0p6I1ZES0xt0scsowGEsSGp7t1JrtWuuhveTYXmN6
7sviB2vfffftx52pZ3OPBiqsf/r+/sZP9+P1g7ufL/W+et5C3Xab3h8eTQghhBBCCCGEEDKS3zcn
b6kAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAChACIAAQBkAAEAAQABAAIAWAJYAjMzMzMzM9M/MzMz
MzMz0z8BAJwIJgCcCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPDMAAAAAAAAAAFUAAgAIAH0A
DAAAAAAASQgPAAIAAAB9AAwAAQABANsRDwACAAAAfQAMAAIAAgAkJA8AAgAAAH0ADAADAAMAkjwP
AAIAAAAAAg4ABAAAABsAAAAAAAMAAAAIAhAABAAAAAMALAEAAAAAAAEPAAgCEAAFAAAAAwAsAQAA
AAAAAQ8ACAIQAAYAAAADACwBAAAAAAABDwAIAhAABwAAAAMALAEAAAAAAAEPAAgCEAAIAAAAAwAs
AQAAAAAAAQ8ACAIQAAkAAAADACwBAAAAAAABDwAIAhAACgAAAAMALAEAAAAAAAEPAAgCEAALAAAA
AwAsAQAAAAAAAQ8ACAIQAAwAAAADACwBAAAAAAABDwAIAhAADQAAAAMALAEAAAAAAAEPAAgCEAAO
AAAAAwAsAQAAAAAAAQ8ACAIQAA8AAAADACwBAAAAAAABDwAIAhAAEAAAAAMALAEAAAAAAAEPAAgC
EAARAAAAAwAsAQAAAAAAAQ8ACAIQABIAAAADACwBAAAAAAABDwAIAhAAEwAAAAMALAEAAAAAAAEP
AAgCEAAUAAAAAwAsAQAAAAAAAQ8ACAIQABUAAAADACwBAAAAAAABDwAIAhAAFgAAAAMALAEAAAAA
AAEPAAgCEAAXAAAAAwAsAQAAAAAAAQ8ACAIQABgAAAADACwBAAAAAAABDwAIAhAAGQAAAAMALAEA
AAAAAAEPAAgCEAAaAAAAAwAsAQAAAAAAAQ8A/QAKAAQAAAAPAAAAAAD9AAoABAABAA8AAQAAAP0A
CgAEAAIADwACAAAA/QAKAAUAAABBAAMAAAD9AAoABQABAEEABAAAAP0ACgAFAAIAQQAFAAAA/QAK
AAYAAAAPAAMAAAD9AAoABgABAA8ABAAAAP0ACgAGAAIADwAGAAAA/QAKAAcAAAAPAAMAAAD9AAoA
BwABAA8ABwAAAP0ACgAHAAIADwAIAAAA/QAKAAgAAAAPAAMAAAD9AAoACAABAA8ACQAAAP0ACgAI
AAIADwAKAAAA/QAKAAkAAAAPAAMAAAD9AAoACQABAA8ACQAAAP0ACgAJAAIADwALAAAA/QAKAAoA
AAAPAAMAAAD9AAoACgABAA8ACQAAAP0ACgAKAAIADwAMAAAA/QAKAAsAAAAPAAMAAAD9AAoACwAB
AA8ACQAAAP0ACgALAAIADwANAAAA/QAKAAwAAAAPAAMAAAD9AAoADAABAA8ACQAAAP0ACgAMAAIA
DwBQAAAA/QAKAA0AAAAPAAMAAAD9AAoADQABAA8ACQAAAP0ACgANAAIADwBRAAAA/QAKAA4AAAAP
AAMAAAD9AAoADgABAA8ACQAAAP0ACgAOAAIADwBfAAAA/QAKAA8AAAAPAAMAAAD9AAoADwABAA8A
CQAAAP0ACgAPAAIADwBSAAAA/QAKABAAAAAPAAMAAAD9AAoAEAABAA8ADgAAAP0ACgAQAAIADwBT
AAAA/QAKABEAAAAPAAMAAAD9AAoAEQABAA8ABwAAAP0ACgARAAIADwBUAAAA/QAKABIAAABBAAMA
AAD9AAoAEgABAEEACQAAAP0ACgASAAIAQQBVAAAA/QAKABMAAAAPAAMAAAD9AAoAEwABAA8ACQAA
AP0ACgATAAIADwBWAAAA/QAKABQAAAAPAAMAAAD9AAoAFAABAA8AAQAAAP0ACgAUAAIADwBXAAAA
/QAKABUAAAAPAAMAAAD9AAoAFQABAA8AAQAAAP0ACgAVAAIADwBYAAAA/QAKABYAAAAPAA8AAAD9
AAoAFgABAA8ACQAAAP0ACgAWAAIADwBZAAAA/QAKABcAAAAPAA8AAAD9AAoAFwABAA8ACQAAAP0A
CgAXAAIADwBaAAAA/QAKABgAAAAPAA8AAAD9AAoAGAABAA8ACQAAAP0ACgAYAAIADwBbAAAA/QAK
ABkAAAAPAA8AAAD9AAoAGQABAA8ACQAAAP0ACgAZAAIADwBcAAAA/QAKABoAAAAPAAMAAAD9AAoA
GgABAA8ATwAAAP0ACgAaAAIADwBdAAAA1wAyAJIFAAC4ASoAKgAqACoAKgAqACoAKgAqACoAKgAq
ACoAKgAqACoAKgAqACoAKgAqACoAPgISALYAAwAAAEAAAAAAAAAAAAAAAIsIEACLCAAAAAAAAAAA
AAAAAAIAHQAPAAMAAAAAAAABAAAAAAAAALoBCQAGAABTaGVldDNnCBcAZwgAAAAAAAAAAAAAAgAB
/////wNEAAAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFQAaABpAHMAVwBvAHIAawBiAG8A
bwBrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBBwAAAAgAAAD/
////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANkDAAAAAAAAUwBoAGUA
ZQB0ADEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AA4AAgEJAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAA
0QMAAAAAAABTAGgAZQBlAHQAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAADgACAQUAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAACAAAADRAwAAAAAAAFMAaABlAGUAdAAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAANEDAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAG
AAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA/v///xEAAAASAAAAEwAAABQA
AAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAAP7///8hAAAAIgAA
ACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAD+////
MQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/
AAAA/v///0EAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0A
AABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAAWwAA
AFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUAAABmAAAAZwAAAGgAAABpAAAA
/v///2sAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAA/v///3QAAAD+////dgAAAHcAAAB4
AAAAeQAAAHoAAAB7AAAAfAAAAH0AAAD+////fwAAAIAAAAABFgEAAPAAAADEAgAA1AAAAAACAAD/
////ywIAAB8DAAAAAAAAAQAAAPdqRMQAAP//IwEAAIgAAAC2AP//AQEAAAAA/////wAAAAD/////
//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ
AAAAAwAAAAUAAAAHAAAA//////////8BAQgAAAD/////eAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAP//AAAAAE1FAAD///////8AAAAA//8AAAAA//8BAQAAAADfAP//AAAAAAwA
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////8oAAAAAgBTTP////8AAAEAUxD/////AAABAFOU/////wAAAAACPP////8A
AP//AQEAAAAAAQBOADAAewAwADAAMAAyADAAOAAxADkALQAwADAAMAAwAC0AMAAwADAAMAAtAEMA
MAAwADAALQAwADAAMAAwADAAMAAwADAAMAAwADQANgB9AAAAAAD/////AQE4AAAAAoD+//////8Q
AP//KAAAAAIB//8AAAAAAAAAAP//////////AAAAAB0AAAAlAAAA/////0gAAAAAAP//AAABAAAA
AAAAAAAA////////////////AAAAAP//////////////////////////AAAAAP//////////////
////////////AAAAAAAAAAD//////////wAAAAD/////////////////////////////////////
//8AAAAAAADfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA/soBAAAA/////wEBCAAAAP////94AAAA/////wAAAbCwAEF0dHJpYnV0AGUg
VkJfTmFtAGUgPSAiVGhpAHNXb3JrYm9vEGsiDQoKjEJhcwECjDB7MDAwMjBQODE5LQAQMAMIQwcA
FAISASQwMDQ2fYENfEdsb2JhbAHQEFNwYWMBkkZhbARzZQxkQ3JlYXQIYWJsFR9QcmVkkGVjbGEA
BklkALEIVHJ1DUJFeHBvBHNlFBxUZW1wbABhdGVEZXJpdgMCEpJCdXN0b21pBnoERAMyAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARYBAADwAAAAxAIAANQAAAAAAgAA////
/8sCAAAfAwAAAAAAAAEAAAD3arjaAAD//yMBAACIAAAAtgD//wEBAAAAAP////8AAAAA////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAA
AAMAAAAFAAAABwAAAP//////////AQEIAAAA/////3gAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAD//wAAAABNRQAA////////AAAAAP//AAAAAP//AQEAAAAA3wD//wAAAAAMAP//
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////KAAAAAIAU0z/////AAABAFMQ/////wAAAQBTlP////8AAAAAAjz/////AAD/
/wEBAAAAAAEATgAwAHsAMAAwADAAMgAwADgAMgAwAC0AMAAwADAAMAAtADAAMAAwADAALQBDADAA
MAAwAC0AMAAwADAAMAAwADAAMAAwADAAMAA0ADYAfQAAAAAA/////wEBOAAAAAKA/v//////EAD/
/ygAAAACAf//AAAAAAAAAAD//////////wAAAAAdAAAAJQAAAP////9IAAAAAAD//wAAAQAAAAAA
AAAAAP///////////////wAAAAD//////////////////////////wAAAAD/////////////////
/////////wAAAAAAAAAA//////////8AAAAA////////////////////////////////////////
AAAAAAAA3wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAP7KAQAAAP////8BAQgAAAD/////eAAAAP////8AAAGosABBdHRyaWJ1dABlIFZC
X05hbQBlID0gIlNoZUBldDEiDQoK6EIEYXMCdDB7MDAwwDIwODIwLQAgBAgOQwAUAhwBJDAwNDYC
fQ18R2xvYmFsIQHEU3BhYwGSRmEIbHNlDGRDcmVhEHRhYmwVH1ByZSBkZWNsYQAGSWQRAKtUcnUN
QkV4cAhvc2UUHFRlbXAAbGF0ZURlcmkGdgIkkkJ1c3RvbQxpegREAzIAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWAQAA8AAAAMQCAADUAAAAAAIAAP/////L
AgAAHwMAAAAAAAABAAAA92pUgAAA//8jAQAAiAAAALYA//8BAQAAAAD/////AAAAAP///////wAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAD
AAAABQAAAAcAAAD//////////wEBCAAAAP////94AAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAA//8AAAAATUUAAP///////wAAAAD//wAAAAD//wEBAAAAAN8A//8AAAAADAD/////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////ygAAAACAFNM/////wAAAQBTEP////8AAAEAU5T/////AAAAAAI8/////wAA//8B
AQAAAAABAE4AMAB7ADAAMAAwADIAMAA4ADIAMAAtADAAMAAwADAALQAwADAAMAAwAC0AQwAwADAA
MAAtADAAMAAwADAAMAAwADAAMAAwADAANAA2AH0AAAAAAP////8BATgAAAACgP7//////xAA//8o
AAAAAgH//wAAAAAAAAAA//////////8AAAAAHQAAACUAAAD/////SAAAAAAA//8AAAEAAAAAAAAA
AAD///////////////8AAAAA//////////////////////////8AAAAA////////////////////
//////8AAAAAAAAAAP//////////AAAAAP///////////////////////////////////////wAA
AAAAAN8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAD+ygEAAAD/////AQEIAAAA/////3gAAAD/////AAABqLAAQXR0cmlidXQAZSBWQl9O
YW0AZSA9ICJTaGVAZXQyIg0KCuhCBGFzAnQwezAwMMAyMDgyMC0AIAQIDkMAFAIcASQwMDQ2An0N
fEdsb2JhbCEBxFNwYWMBkkZhCGxzZQxkQ3JlYRB0YWJsFR9QcmUgZGVjbGEABklkEQCrVHJ1DUJF
eHAIb3NlFBxUZW1wAGxhdGVEZXJpBnYCJJJCdXN0b20MaXoERAMyAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFgEAAPAAAADEAgAA1AAAAAACAAD/////ywIA
AB8DAAAAAAAAAQAAAPdqCEoAAP//IwEAAIgAAAC2AP//AQEAAAAA/////wAAAAD///////8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAwAA
AAUAAAAHAAAA//////////8BAQgAAAD/////eAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAP//AAAAAE1FAAD///////8AAAAA//8AAAAA//8BAQAAAADfAP//AAAAAAwA////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////8oAAAAAgBTTP////8AAAEAUxD/////AAABAFOU/////wAAAAACPP////8AAP//AQEA
AAAAAQBOADAAewAwADAAMAAyADAAOAAyADAALQAwADAAMAAwAC0AMAAwADAAMAAtAEMAMAAwADAA
LQAwADAAMAAwADAAMAAwADAAMAAwADQANgB9AAAAAAD/////AQE4AAAAAoD+//////8QAP//KAAA
AAIB//8AAAAAAAAAAP//////////AAAAAB0AAAAlAAAA/////0gAAAAAAP//AAABAAAAAAAAAAAA
////////////////AAAAAP//////////////////////////AAAAAP//////////////////////
////AAAAAAAAAAD//////////wAAAAD///////////////////////////////////////8AAAAA
AADfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAA/soBAAAA/////wEBCAAAAP////94AAAA/////wAAAaiwAEF0dHJpYnV0AGUgVkJfTmFt
AGUgPSAiU2hlQGV0MyINCgroQgRhcwJ0MHswMDDAMjA4MjAtACAECA5DABQCHAEkMDA0NgJ9DXxH
bG9iYWwhAcRTcGFjAZJGYQhsc2UMZENyZWEQdGFibBUfUHJlIGRlY2xhAAZJZBEAq1RydQ1CRXhw
CG9zZRQcVGVtcABsYXRlRGVyaQZ2AiSSQnVzdG9tDGl6BEQDMgAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXwBWAEIAQQBfAFAAUgBPAEoARQBDAFQAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgD///////////////8AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAYgoAAAAAAABkAGkAcgAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAACAP//////
/////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAArAgAAAAAAAFAA
UgBPAEoARQBDAFQAdwBtAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAUAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
cwAAAGgAAAAAAAAAUABSAE8ASgBFAEMAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAABAAAgEDAAAACgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAB1AAAADgIAAAAAAADMYZcAAAEA/wkEAAAJBAAA5AQBAAAAAAAAAAAAAQAE
AAIA+gAqAFwARwB7ADAAMAAwADIAMAA0AEUARgAtADAAMAAwADAALQAwADAAMAAwAC0AQwAwADAA
MAAtADAAMAAwADAAMAAwADAAMAAwADAANAA2AH0AIwA0AC4AMQAjADkAIwBDADoAXABQAFIATwBH
AFIAQQB+ADIAXABDAE8ATQBNAE8ATgB+ADEAXABNAEkAQwBSAE8AUwB+ADEAXABWAEIAQQBcAFYA
QgBBADcAXABWAEIARQA3AC4ARABMAEwAIwBWAGkAcwB1AGEAbAAgAEIAYQBzAGkAYwAgAEYAbwBy
ACAAQQBwAHAAbABpAGMAYQB0AGkAbwBuAHMAAAAAAAAAAAAAAAAAHAEqAFwARwB7ADAAMAAwADIA
MAA4ADEAMwAtADAAMAAwADAALQAwADAAMAAwAC0AQwAwADAAMAAtADAAMAAwADAAMAAwADAAMAAw
ADAANAA2AH0AIwAxAC4ANwAjADAAIwBDADoAXABQAHIAbwBnAHIAYQBtACAARgBpAGwAZQBzACAA
KAB4ADgANgApAFwATQBpAGMAcgBvAHMAbwBmAHQAIABPAGYAZgBpAGMAZQBcAE8AZgBmAGkAYwBl
ADEANABcAEUAWABDAEUATAAuAEUAWABFACMATQBpAGMAcgBvAHMAbwBmAHQAIABFAHgAYwBlAGwA
IAAxADQALgAwACAATwBiAGoAZQBjAHQAIABMAGkAYgByAGEAcgB5AAAAAAAAAAAAAAAAALwAKgBc
AEcAewAwADAAMAAyADAANAAzADAALQAwADAAMAAwAC0AMAAwADAAMAAtAEMAMAAwADAALQAwADAA
MAAwADAAMAAwADAAMAAwADQANgB9ACMAMgAuADAAIwAwACMAQwA6AFwAVwBpAG4AZABvAHcAcwBc
AFMAeQBzAFcATwBXADYANABcAHMAdABkAG8AbABlADIALgB0AGwAYgAjAE8ATABFACAAQQB1AHQA
bwBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAA0ASoAXABHAHsAMgBEAEYAOABEADAANABDAC0ANQBC
AEYAQQAtADEAMAAxAEIALQBCAEQARQA1AC0AMAAwAEEAQQAwADAANAA0AEQARQA1ADIAfQAjADIA
LgA1ACMAMAAjAEMAOgBcAFAAcgBvAGcAcgBhAG0AIABGAGkAbABlAHMAIAAoAHgAOAA2ACkAXABD
AG8AbQBtAG8AbgAgAEYAaQBsAGUAcwBcAE0AaQBjAHIAbwBzAG8AZgB0ACAAUwBoAGEAcgBlAGQA
XABPAEYARgBJAEMARQAxADQAXABNAFMATwAuAEQATABMACMATQBpAGMAcgBvAHMAbwBmAHQAIABP
AGYAZgBpAGMAZQAgADEANAAuADAAIABPAGIAagBlAGMAdAAgAEwAaQBiAHIAYQByAHkAAAAAAAAA
AAAAAAAABAACAAIAAgACAAYADAIAAA4CAQAQAgAAEgIAABQCAQAWAgEAHAL///////8AAAAA//8A
AKb7uU8FAP////8AAP//////////////////////////////////////////////////////////
////////AgABAP//AwABAAAAAAAAAAAAAAAAAAAAAAAAAPdqBAAYAFQAaABpAHMAVwBvAHIAawBi
AG8AbwBrABQAMAA3ADQAZgBiADkAZgBiAGEANgD//yECGABUAGgAaQBzAFcAbwByAGsAYgBvAG8A
awD//0TEAAAAAAAAAAIAAAAlAwAA//8MAFMAaABlAGUAdAAxABQAMAA4ADQAZgBiADkAZgBiAGEA
NgD//yUCDABTAGgAZQBlAHQAMQD//7jaAAAAAAAAGAIAAAAlAwAA//8MAFMAaABlAGUAdAAyABQA
MAA5ADQAZgBiADkAZgBiAGEANgD//ycCDABTAGgAZQBlAHQAMgD//1SAAAAAAAAAMAIAAAAlAwAA
//8MAFMAaABlAGUAdAAzABQAMAA6ADQAZgBiADkAZgBiAGEANgD//ykCDABTAGgAZQBlAHQAMwD/
/whKAAAAAAAASAIAAAAlAwAA////////AQFoAgAA////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////MAIAAP//////////SAIAAP///////////////////////////////wACAAD/////
////////////////////////////////////////////////GAIAAP//////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////9cqs/t4uhQTIh4D6RMJqbc/////wEAAAA7dNsv
ZjbYTqaR8mwMeFFR/////wEAAACa05ChCwbjTbmJWQIu3m4S/////wEAAABjYAISVb4lT4GYbimC
nzki/////wEAAAD/////GAAAAIAAAAAAABUBEgADAfQmAAAFBEV4Y2VsgCsQAAMEVkJB9+IQAAUE
V2luMTbBfhAABQRXaW4zMgd/EAAFBFdpbjY0eH8QAAMETWFjs7IQAAQEVkJBNq0jEAAEBFZCQTeu
IxAACARQcm9qZWN0MQoXEAAGBHN0ZG9sZZNgEAAKBFZCQVByb2plY3S+vxAABgRPZmZpY2UVdRAA
DARUaGlzV29ya2Jvb2t84xAACYAAAP8DAQBfRXZhbHVhdGUY2RAABgRTaGVldDHoGhAABgRTaGVl
dDLpGhAABgRTaGVldDPqGhAACARXb3JrYm9va2sYEAAC//8BAWwAAAAcAv////8eAgMA//8hAgAA
AgD///////8lAgEAAgAnAgIABAApAgMABQD///////8IAgEA//8KAgAA////////////////////
//////////////////////////////////////8aAgIA//8GABIAAAABAEgAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJ7KAAQAEAAAAAQAwKgICkAkAcBQG
SAMAggIAZOQEBAAKABwAVkJBUHJvamWIY3QFADQAAEACFGoGAgo9AgoHAnIBFAgFBhIJAhKm+7lP
BZQADAJKPAIKFgABcoBzdGRvbGU+AhkAcwB0AGQAbwCAbABlAA0AaAAlAl4AAypcR3swMIAwMjA0
MzAtAAgdBARDAAoCDgESMDA0ADZ9IzIuMCMwACNDOlxXaW5kAG93c1xTeXNXIE9XNjRcA2UyLgB0
bGIjT0xFIABBdXRvbWF0aRxvbgBgAAGDRU9mZkRpY4RFTwBmgABp1ABjgkWkgBGagAGBRQAyREY4
RDA0QwAtNUJGQS0xMIAxQi1CREU1gEXUQUGAQzSABTKIRYCYAGdyYW0gRmlsAGVzICh4ODYpgFxD
b21tb24DCQBcTWljcm9zbwBmdCBTaGFyZQBkXE9GRklDRQAxNFxNU08uRBhMTCOHEINQIDE0IC4w
IE9igcQgTMBpYnJhcnkATgABIg+C1wQAE4ID92oCGYKrVGhpc1dvAHJrYm9va0cAChiAE1SArmkA
cwCCV4C2cgBrAGLAAapvwAEazgsy2gscwBIoAABIQgExwnklA1gAAB5CAgEFLMIhRFTEIkIIK0IB
GcJ9U0BoZWV0MUfCG1MFQCNlwFl0ADEAGk1IBzJOB+MbuNrUGzKVzRsyyRsyzRsyAOMbVFSA1Bsz
zRszyRszpc0bM+QbCErJGxBCVQAAAAAAAAAAAAAAAAAAAAAAAAAAAABUaGlzV29ya2Jvb2sAVABo
AGkAcwBXAG8AcgBrAGIAbwBvAGsAAABTaGVldDEAUwBoAGUAZQB0ADEAAABTaGVldDIAUwBoAGUA
ZQB0ADIAAABTaGVldDMAUwBoAGUAZQB0ADMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAElE
PSJ7Q0Y1RDIzRkUtNzBDMy00RDZBLTg0OEUtNjdGMjMzRjJEMEY0fSINCkRvY3VtZW50PVRoaXNX
b3JrYm9vay8mSDAwMDAwMDAwDQpEb2N1bWVudD1TaGVldDEvJkgwMDAwMDAwMA0KRG9jdW1lbnQ9
U2hlZXQyLyZIMDAwMDAwMDANCkRvY3VtZW50PVNoZWV0My8mSDAwMDAwMDAwDQpOYW1lPSJWQkFQ
cm9qZWN0Ig0KSGVscENvbnRleHRJRD0iMCINClZlcnNpb25Db21wYXRpYmxlMzI9IjM5MzIyMjAw
MCINCkNNRz0iRTdFNUUzRkVFRDAyMDAwNjAwMDYwMDA2MDAwNiINCkRQQj0iRkVGQ0ZBMTcwNjM5
MUMzQTFDM0ExQyINCkdDPSIxNTE3MTEwQzNGMjI0MDIyNDBERCINCg0KW0hvc3QgRXh0ZW5kZXIg
SW5mb10NCiZIMDAwMDAwMDE9ezM4MzJENjQwLUNGOTAtMTFDRi04RTQzLTAwQTBDOTExMDA1QX07
VkJFOyZIMDAwMDAwMDANCg0KW1dvcmtzcGFjZV0NClRoaXNXb3JrYm9vaz0wLCAwLCAwLCAwLCBD
DQpTaGVldDE9MCwgMCwgMCwgMCwgQw0KU2hlZXQyPTAsIDAsIDAsIDAsIEMNClNoZWV0Mz0wLCAw
LCAwLCAwLCBDDQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAP7/AAAGAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAALwAAAAI
AAAAAQAAAEgAAAAEAAAAUAAAAAgAAABkAAAAEgAAAHgAAAALAAAAkAAAAAwAAACcAAAADQAAAKgA
AAATAAAAtAAAAAIAAADkBAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH/////DQAAAP////8AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAB+AAAA7AAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBt
AGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAP///////////////wAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIIAAAA8AQAAAAAAAAEAQwBvAG0AcABP
AGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA
////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhwAAAGsAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAACBAAAA/v///4MAAACEAAAAhQAAAIYAAAD+////iAAAAP7/////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////x4AAAAMAAAAU3RldmVuIENoZXcAHgAAAAwAAABTdGV2ZW4gQ2hldwAe
AAAAEAAAAE1pY3Jvc29mdCBFeGNlbABAAAAAAOPpNNw/zAFAAAAAAIIR81Y2zAFAAAAAgE9JKqlA
zAEDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAYBAgAAAAAAAAAAAAAAAAAAAAAAAQAA
AALVzdWcLhsQk5cIACss+a4wAAAADAEAAAgAAAABAAAASAAAABcAAABQAAAACwAAAFgAAAAQAAAA
YAAAABMAAABoAAAAFgAAAHAAAAANAAAAeAAAAAwAAADKAAAAAgAAAOQEAAADAAAAAAAOAAsAAAAA
AAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAQAAAAIAAAAQ29tcGFyZQATAAAAU21hcnQg
QmF0dGVyeSBEYXRhAAwAAABCYXR0ZXJ5IE1JQgATAAAAQ29tcGFyZSFQcmludF9BcmVhAAwQAAAE
AAAAHgAAAAsAAABXb3Jrc2hlZXRzAAMAAAADAAAAHgAAAA0AAABOYW1lZCBSYW5nZXMAAwAAAAEA
AAAAAAAAAAABAP7/AwoAAP////8gCAIAAAAAAMAAAAAAAABGHwAAAE1pY3Jvc29mdCBFeGNlbCAy
MDAzIFdvcmtzaGVldAAGAAAAQmlmZjgADgAAAEV4Y2VsLlNoZWV0LjgA9DmycQAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAA=

--_002_0BB24042CB683840B986F84BC859CFB569F0CB1FA4EXVMBX0181exc_--

From moulchan@cisco.com  Fri Jul 15 04:48:49 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA7121F872E for ; Fri, 15 Jul 2011 04:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.451
X-Spam-Level: 
X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=-0.853, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF+nWbNt-9ol for ; Fri, 15 Jul 2011 04:48:44 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5058C21F873E for ; Fri, 15 Jul 2011 04:48:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=35375; q=dns/txt; s=iport; t=1310730524; x=1311940124; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=3QyPDVM7oJm5vU3Q9w65gPuXl7zzbdypDHm48KvHoQM=; b=lQB//Vmf7uqZ/aoJAAvrc0Xw8+4mzbdwW5m5jPUCb2DnIdMu4YmTE6J6 WvcIjxyHw60qbf6AkUmvks2TDbv+d8HIe/LGc8Ac5ta3cOAp5y8t76y0A 2iUvc8ds8XIr/FaGu4xmN7Ub06z+jdsX+TqY5vX7zd5fRtOayTyCz4fEP g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvUAABYoIE6tJXG+/2dsb2JhbABHBwaCU5VTjzx3rWmeKIMjGYIfXwSHVJAci2c
X-IronPort-AV: E=Sophos;i="4.65,535,1304294400"; d="scan'208,217";a="3258523"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 15 Jul 2011 11:48:43 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6FBmhPx011462;  Fri, 15 Jul 2011 11:48:43 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 15 Jul 2011 06:48:43 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC42E5.25B3779B"
Date: Fri, 15 Jul 2011 06:48:40 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] Applicability comments
Thread-Index: AcxCtYx+RXdCjg6cThiogN1qXnxJ9AAKoagg
References: 
From: "Mouli Chandramouli (moulchan)" 
To: "Bruce Nordman" , "eman mailing list" 
X-OriginalArrivalTime: 15 Jul 2011 11:48:43.0559 (UTC) FILETIME=[25C62B70:01CC42E5]
Subject: Re: [eman] Applicability comments
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 11:48:49 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC42E5.25B3779B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Bruce,

=20

Thanks for your comments. =20

Most of it seem to concern what should be in an "Applicability
Statement" draft.=20

=20

Looking at the EMAN WG Charter

=20

6. Applicability statement
The EMAN WG will develop an applicability statement, describing the
variety of applications that can use the energy framework and associated
MIB modules. Potential examples are building networks, home energy
gateway, etc. Finally, the document will also discuss relationships of
the framework to other architectures and frameworks (such as smartgrid).
The applicability statement will explain the relationship between the
work in this WG and the other existing standards such as those from the
IEC, ANSI, DMTF, and others.

=20

The Applicability Statement draft is based on the scope given in the WG
Charter.=20

While I think an intro to EMAN or Energy issues would be quite useful, I
am not sure  the WG Charter does not seem to call for such a draft.=20

=20

In our version of the Applicability Statement draft, the first part is
an introduction which attempts to set the context and some minimal
terminology so that this is a self contained document.

=20

Section 2 is the Use cases which consists of several network scenarios
where Energy Monitoring can be applied with concrete examples:=20

=20

Network devices

Attached devices

Smart PDUs=20

Building networks

Home Energy gateways=20

Data centers=20

....

It is possible to add new use cases or scenarios where Energy Monitoring
can be applied. =20

I think these are illustrative network examples and should be accessible
to all readers.=20

BTW, I do have figures (network diagrams for each scenario).  I have
left those figures In the interest of brevity.

=20

Secondly, there was a discussion in EMAN WG meeting @ Prague on the
possible use of Entity MIB  and there was a need to list the network use
cases of Energy monitoring.

The use cases are listed with sufficient detail, so that it is possible
to check if we use Entity MIB for these use cases.  We can add those
figures if it would help in the modeling work.=20

=20

Use case patterns section is an abstraction of the network examples - to
distill the unique patterns in the network scenarios.=20

=20

Finally, some of the Standards section consists of the relevant
standards that are used in EMAN WG drafts. =20

I agree with your comment, we can improve the Standards section.

=20

If there are new IEC standards that need to be considered (also Michael
Suchoff's comment)  we shall review those IEC  standards and revise the
draft.=20

=20

You raise a good point on Security issues related to Energy control.
Some of that is discussed in the Monitoring MIB draft, which has a
section on Security for Read/Write variables.=20

=20

Thanks

Mouli

=20

=20

=20

=20

=20

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Bruce Nordman
Sent: Friday, July 15, 2011 11:38 AM
To: eman mailing list
Subject: [eman] Applicability comments

=20

In March I drafted content that I felt was useful and/or necessary for
an=20

applicability statement.  This was done from the perspective of what is=20

needed for understanding and improving energy use in IT networks and=20

buildings.  That content can be seen at

draft-nordman-eman-energy-perspective-01

It did not attempt to cover content already in the current version of
the other

draft.

=20

The current other draft is:
draft-tychon-eman-applicability-statement-02.

There has been some convergence in content since the previous draft.

It seems possible and desirable to merge the two drafts.

=20

A few of these points are covered in the current other draft, though
with

different language and emphasis, such as the importance of reporting=20

"identity" and classification, and the relevance and status of the Ecma=20

Smart Data Centre project.

=20

Many other points from energy-perspective are not covered in the other
draft:

=20

-At least one document published by EMAN should be readily accessible to
a

   wide range of audiences, particularly those focused on energy use,
most of who

   have little or no knowledge of network technology.  The Applicability
Statement

   seems to be the only suitable one in our charter.

-At the core of EMAN is simple reporting of power/energy about a simple
device.

-The EMAN protocol can be used in "series" relaying up information
through

   any number of intermediate devices to an EMS, collecting and/or
aggregating.

-The NMS is out of scope.

-Any energy-using device is in scope (traditional IT, other IP devices,
non-IP

   devices).

-The management system begins with a discovery process, to understand

   what devices are in the building, and which implement EMAN.  This
needs

   to be redone periodically.

  -Further details on how discovery may be implemented.

-Devices may report intermittently due to being in a low-power state,

   being portable, or leaving the building permanently.

-Ultimately, one key outlet for EMAN information is presentation (via an

   application) to people.

-A later version of EMAN should consider extension to forms of energy

  other than electricity.=20

-The Use Cases for EMAN can be viewed along three primary axes:

  -Management context: loosely, highly, or hybrid.

  -Building type: residential, commercial, data center, vehicle, other.

  -Device type: IT, other electronic, non-electronic.

-Power distribution domains are becoming more varied and complex.

-For measurement standards, IEC 62301 is widely used and relevant.

-IANA may need to establish an enumeration of device types.

-There are security issues related to control functions in changing

  what services a device provides, and potentially perturbing the

  power system with widely coordinated changes in energy demand.

=20

All of these points seem suitable and appropriate to be in a working

group draft for Applicability.

=20

A few detailed comments on draft-tychon-eman-applicability-statement-02

follow. =20

1.1

-it seems unnecessary to define energy here - other drafts will do that.

-proxying and aggregation are mixed. They are distinct functions and

  one device can implement one, the other, or both.

2.

-the "Scenarios and Target Devices" section mixes specific device types,

  with methods of powering devices.  It would be helpful to separate

  these as well as to include the "use contexts" from the energy draft.

  There is also some redundancy in this section.

4.

-other standards should be divided into measurement standards,

   reporting standards, and other standards.

=20

It may be that it would be helpful to create another document

as output from the working group that is the primary document

intended to be accessible to many readers, and to include detailed

discussions of implementation scenarios.  This would pull out some

of the content described above and add to it.

=20

--Bruce (as contributor; I am off email Monday->Saturday)



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


------_=_NextPart_001_01CC42E5.25B3779B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi =
Bruce,



 



Thanks for your
comments.  



Most =
of it seem
to concern what should be in an “Applicability Statement” =
draft. 



 



Looking at the
EMAN WG Charter



 



6. Applicability statement

The EMAN WG will develop an applicability statement, describing the

variety of applications that can use the energy framework and =
associated

MIB modules. Potential examples are building networks, home energy

gateway, etc. Finally, the document will also discuss relationships =
of

the framework to other architectures and frameworks (such as =
smartgrid).

The applicability statement will explain the relationship between =
the

work in this WG and the other existing standards such as those from =
the

IEC, ANSI, DMTF, and others.



 



The =
Applicability
Statement draft is based on the scope given in the WG Charter. =




While I think
an intro to EMAN or Energy issues would be quite useful, I am not sure =
 the
WG Charter does not seem to call for such a draft. =




 



In =
our version
of the Applicability Statement draft, the first part is an introduction =
which
attempts to set the context and some minimal terminology so that this is =
a self
contained document.



 



Section 2 is
the Use cases which consists of several network scenarios where Energy
Monitoring can be applied with concrete examples: 



 



Network =
devices



Attached
devices



Smart PDUs =




Building
networks



Home =
Energy
gateways 



Data =
centers 



….



It =
is possible
to add new use cases or scenarios where Energy Monitoring can be =
applied.  



I =
think these are
illustrative network examples and should be accessible to all readers. =




BTW, =
I do have
figures (network diagrams for each scenario).  I have left those =
figures In
the interest of brevity.



 



Secondly, there
was a discussion in EMAN WG meeting @ Prague on the possible use of =
Entity MIB  and
there was a need to list the network use cases of Energy =
monitoring.



The =
use cases
are listed with sufficient detail, so that it is possible to check if we =
use
Entity MIB for these use cases.  We can add those figures if it =
would help
in the modeling work. 



 



Use =
case patterns
section is an abstraction of the network examples – to distill the =
unique
patterns in the network scenarios. 



 



Finally, some
of the Standards section consists of the relevant standards that are =
used in
EMAN WG drafts.  



I =
agree with
your comment, we can improve the Standards =
section.



 



If =
there are
new IEC standards that need to be considered (also Michael =
Suchoff’s
comment)  we shall review those IEC  standards and revise the =
draft. 



 



You =
raise a
good point on Security issues related to Energy control.  Some of =
that is
discussed in the Monitoring MIB draft, which has a section on Security =
for
Read/Write variables. 



 



Thanks



Mouli



 



 



 



 



 






From:=
 =
eman-bounces@ietf.org
[mailto:eman-bounces@ietf.org] On Behalf Of Bruce Nordman

Sent: Friday, July 15, 2011 11:38 AM

To: eman mailing list

Subject: [eman] Applicability comments






 



In
March I drafted content that I felt was useful and/or necessary for an =




applicability=

statement.  This was done from the perspective of what is =




needed
for understanding and improving energy use in IT networks and =




buildings.&nb=
sp;
That content can be seen at



draft-nordman=
-eman-energy-perspective-01



It
did not attempt to cover content already in the current version of the =
other



draft.=




 =




The
current other draft is: =
draft-tychon-eman-applicability-statement-02.



There
has been some convergence in content since the previous =
draft.



It
seems possible and desirable to merge the two drafts.



 =




A
few of these points are covered in the current other draft, though =
with



different
language and emphasis, such as the importance of reporting 



“identi=
ty”
and classification, and the relevance and status of the Ecma =




Smart
Data Centre project.



 =




Many
other points from energy-perspective are not covered in the other =
draft:



 =




-At
least one document published by EMAN should be readily accessible to =
a



  
wide range of audiences, particularly those focused on energy use, most =
of who



  
have little or no knowledge of network technology.  The =
Applicability
Statement



  
seems to be the only suitable one in our charter.



-At
the core of EMAN is simple reporting of power/energy about a simple =
device.



-The
EMAN protocol can be used in “series” relaying up =
information
through



  
any number of intermediate devices to an EMS, collecting and/or =
aggregating.



-The
NMS is out of scope.



-Any
energy-using device is in scope (traditional IT, other IP devices, =
non-IP



  
devices).



-The
management system begins with a discovery process, to =
understand



  
what devices are in the building, and which implement EMAN.  This =
needs



  
to be redone periodically.



 
-Further details on how discovery may be implemented.



-Devices
may report intermittently due to being in a low-power state,



  
being portable, or leaving the building permanently.



-Ultimately,
one key outlet for EMAN information is presentation (via an



  
application) to people.



-A
later version of EMAN should consider extension to forms of =
energy



  o=
ther
than electricity. 



-The
Use Cases for EMAN can be viewed along three primary axes:



 
-Management context: loosely, highly, or hybrid.



 
-Building type: residential, commercial, data center, vehicle, =
other.



 
-Device type: IT, other electronic, non-electronic.



-Power
distribution domains are becoming more varied and complex.



-For
measurement standards, IEC 62301 is widely used and =
relevant.



-IANA
may need to establish an enumeration of device types.



-There
are security issues related to control functions in changing



 
what services a device provides, and potentially perturbing =
the



 
power system with widely coordinated changes in energy =
demand.



 =




All
of these points seem suitable and appropriate to be in a =
working



group
draft for Applicability.



 =




A
few detailed comments on =
draft-tychon-eman-applicability-statement-02



follow. =





1.1



–it
seems unnecessary to define energy here – other drafts will do =
that.



-proxying
and aggregation are mixed. They are distinct functions and



 
one device can implement one, the other, or both.



2.



-the
“Scenarios and Target Devices” section mixes specific device =
types,



 
with methods of powering devices.  It would be helpful to =
separate



 
these as well as to include the “use contexts” from the =
energy
draft.



 
There is also some redundancy in this section.



4.



-other
standards should be divided into measurement standards,



  
reporting standards, and other standards.



 =




It
may be that it would be helpful to create another document



as
output from the working group that is the primary document



intended
to be accessible to many readers, and to include detailed



discussions
of implementation scenarios.  This would pull out some



of
the content described above and add to it.



 =




--Bruce
(as contributor; I am off email Monday->Saturday)







-- 

Bruce Nordman

Lawrence Berkeley National =
Laboratory

eetd.lbl.gov/ea/nordman

BNordman@LBL.gov

510-486-7089

m: 510-501-7943









------_=_NextPart_001_01CC42E5.25B3779B--

From ietf@quittek.at  Fri Jul 15 06:08:41 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672E821F86FD for ; Fri, 15 Jul 2011 06:08:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.722
X-Spam-Level: 
X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.526,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Q2XudQg47h7A for ; Fri, 15 Jul 2011 06:08:40 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE3021F86FB for ; Fri, 15 Jul 2011 06:08:40 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0Lh5r5-1REWJi2bPb-00oZgf; Fri, 15 Jul 2011 15:08:33 +0200
References: <791AD3077F94194BB2BDD13565B6295D1CFBAF43@DAPHNIS.office.hd>   
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-6--431852141
Message-Id: 
From: Juergen Quittek 
Date: Fri, 15 Jul 2011 15:08:33 +0200
To: Mouli Chandramouli (moulchan) 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:1vWQP+nnA3Goj/WUOH4kzjCH738imWVwQeDNunWNp9i qqScxhz9HVS3TRh+K3trAZDaeJcskz1U2yMJaLgndY9tRoNldH fSXOgYsSBO407yjUbxT8Nycb5ywg5HK60+W4XAyNrhyJicdPPQ GkU837pXIUJG4vC+zoOVPOAHR78ZgzXjPoNOJMPAhOn85SAwYV /3R160iT3lmc+rPTReWHA==
Cc: eman@ietf.org
Subject: Re: [eman] updated version of the battery MIB
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 13:08:41 -0000

--Apple-Mail-6--431852141
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi Mouli,

Am 15.07.2011 um 13:09 schrieb Mouli Chandramouli (moulchan):

> Hi Juergen,
> =20
> Replies inline.
>=20
> Thanks
> Mouli
> =20
> From: Juergen Quittek [mailto:ietf@quittek.at]=20
> Sent: Thursday, July 14, 2011 9:12 PM
> To: Mouli Chandramouli (moulchan)
> Cc: Rolf Winter; eman@ietf.org
> Subject: Re: [eman] updated version of the battery MIB
> =20
> Hi Mouli,
> =20
> Thank you for your comments.
> =20
> Am 14.07.2011 um 13:25 schrieb Mouli Chandramouli (moulchan):
> Hi,
>=20
> I had a quick look at the new battery MIB module
>=20
> The first comment deals with the index and others are nits.
>=20
> 1.     Firstly,  given that the battery  provides backup power for a =
device and there should be a reference (index)=20
>=20
>        to the device  for which the battery is providing back-up =
power. Otherwise, the MIB module seems as a standalone ?
>=20
>        There is a link of the batteryIndex to the entPhysicalIndex ; =
Where do you assume that the entityMIB is implemented ? =20
>=20
>        What is the device ? How is that device identified ? What if =
entityMIB is not implemented ?
>=20
> I think the most common case is that the battery is contained in a =
device and the device reports about its battery.
> =20
> You can see the battery as a component of a device such as a CPU or a =
line card.  If you write a MIB module for the line card or for the CPU, =
you woudn't have a pointer in your MIB module pointing to the device =
that the line card or CPU is contained in, would you? That is because =
the device hosting the line card or CPU is the same device hosing the =
implementation of the MIB module. I don't see a problem here. But maybe =
you envision other scenarios where this is a problem?
> =20
> If the device hosting the battery implements the Entity MIB and has =
the battery listed as an entity, then of course can we support it.
> =20
> Mouli>>  Thanks for an excellent description.=20
> Mouli>> My point is =96 wouldn=92t you want to refer to the device =
that contains the battery and such a linkage (association) would provide =
a context for the battery ? =96 the battery is for this  device.

Yes, I got your point. But in almost all cases, the device hosting the =
MIB module and answering on SNMP requests IS the device that contains =
the battery.=20
Why would it need to point to itself?
=20
> 2.     is battery temperature =96 is this relevant for EMAN ?   +-- =
r-n Integer32   batteryTemperature(14)
>=20
> It is not necessary for energy management. But it is important for =
battery management.
> 3.     the name of the object can be renamed - batteryCurrentCurrent  =
?=20
>=20
> You talk about renaming the name? This sounds almost like current =
current :-)
> But seriously, what would be your proposal?
> =20
> Mouli>  how about batteryPresentCharge

I assume you are aware of the difference between charge and current.
Currently, we have
          batteryCurrentCharge
          batteryCurrentVoltage
          batteryCurrentCurrent
and you propose to change ist to
          batteryCurrentCharge
          batteryCurrentVoltage
          batteryCurrentCurrent
Is this a correct understanding?

Thanks,

    Juergen
>=20



--Apple-Mail-6--431852141
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Hi Mouli,

Am 15.07.2011 um 13:09 =
schrieb Mouli Chandramouli (moulchan):

Hi =
Juergen,
 
Replies =
inline.

Thanks
Mouli
From: Juergen Quittek =
[mailto:ietf@quittek.at] 
Sent: Thursday, July 14, 2011 =
9:12 PM
To: Mouli Chandramouli =
(moulchan)
Cc: Rolf Winter; eman@ietf.org
Subject: Re: [eman] updated version =
of the battery MIB
 
Hi =
Mouli,
Thank you for your =
comments.
Am 14.07.2011 um =
13:25 schrieb Mouli Chandramouli =
(moulchan):
Hi,
I had a quick look at the new battery MIB =
module
The first comment deals with the index and others are =
nits.
1.     Firstly,  given that the battery  provides backup =
power for a device and there should be a reference =
(index) 
 to the device  for which the battery is providing =
back-up power. Otherwise, the MIB module seems as a standalone ?
 There is a link of the batteryIndex to the entPhysicalIndex =
; Where do you assume that the =
entityMIB is implemented ?  
       What is the device ? How is that device identified ? What if entityMIB is not implemented =
?
I think the most =
common case is that the battery is contained in a device and the device =
reports about its battery.
 
You can see the =
battery as a component of a device such as a CPU or a line card. =
 If you write a MIB module for the line card or for the CPU, you =
woudn't have a pointer in your MIB module pointing to the device that =
the line card or CPU is contained in, would you? That is because the =
device hosting the line card or CPU is the same device hosing the =
implementation of the MIB module. I don't see a problem here. But maybe =
you envision other scenarios where this is a =
problem?
If the device hosting =
the battery implements the Entity MIB and has the battery listed as an =
entity, then of course can we support it.
Mouli>>  Thanks for an excellent =
description. 
Mouli>> My point is =96 wouldn=92t you want to =
refer to the device that contains the battery and such a linkage =
(association) would provide a context for the battery ? =96 the battery =
is for this =
 device.

Yes, I got your point. But in almost all cases, the device =
hosting the MIB module and answering on SNMP requests IS the device that =
contains the battery. 
Why would it need to point to =
itself?
 
It is not necessary for energy management. But it is =
important for battery management.
3.     the name of the object can be =
renamed - batteryCurrentCurrent  =
? 
You talk about renaming the name? This sounds almost like =
current current :-)
But seriously, what =
would be your proposal?Mouli> =
 how about =
batteryPresentCharge

I assume you are aware of the difference between charge and =
current.
Currently, we have
          batteryCurrentCharge
          =
batteryCurrentVoltage
          batteryCurrentCurrent
and you propose to =
change ist to
          =
batteryCurrentCharge
          batteryCurrentVoltage
          =
batteryCurrentCurrent
Is this a correct =
understanding?

Thanks,

   =
 Juergen

=

--Apple-Mail-6--431852141--

From ietf@quittek.at  Fri Jul 15 07:05:20 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4792321F879F for ; Fri, 15 Jul 2011 07:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level: 
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 VIt8lUD709cN for ; Fri, 15 Jul 2011 07:05:16 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0745421F8794 for ; Fri, 15 Jul 2011 07:05:16 -0700 (PDT)
Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MNLx3-1QobhI1fQn-0070K8; Fri, 15 Jul 2011 16:05:13 +0200
References: <791AD3077F94194BB2BDD13565B6295D1CFBAF43@DAPHNIS.office.hd> <0BB24042CB683840B986F84BC859CFB569F0CB1FA4@EXVMBX018-1.exch018.msoutlookonline.net>
In-Reply-To: <0BB24042CB683840B986F84BC859CFB569F0CB1FA4@EXVMBX018-1.exch018.msoutlookonline.net>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-7--428452240
Message-Id: <2831BF9A-121B-45B8-A174-7071B58A0302@quittek.at>
From: Juergen Quittek 
Date: Fri, 15 Jul 2011 16:05:13 +0200
To: Steven Chew 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:HL/uMRt7McZQHIzr0IeeJifvJDUqvLHjt1bXZJxeldA m0fBXF19uuoPBXRtJ07f4kl4GNkeXsxTIrXjyo2ReCQ4xExFHR i1njH6NOOmwv/Al1IiWi8HtB5mZsf66UyRsdZG4p3qX1Xmv0/X Q2PIAH+Czv/yyfWl08SKCKnT6gwG6yx/Ksey5NkIEAmuVlwwIa CDiJVYmwDNpW+Ll4FUb7A==
Cc: "eman@ietf.org" 
Subject: Re: [eman] updated version of the battery MIB
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 14:05:20 -0000

--Apple-Mail-7--428452240
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Steven,

thanks for sending your very helpful comments.

Am 15.07.2011 um 13:46 schrieb Steven Chew:

> 1) The use of the word "current" is double loaded (e.g. =
batteryCurrentCurrent). I suggest use "current" for electrical current =
and use "present" to mean instantaneous.

Yes. This is what also Mouli proposed. We will find something that =
circumvents current current.
What about "actual" instead of "present"?

> 2) It seems more natural to give batteryTechnology(5) a SYNTAX of =
Integer or Enumeration. Am I right that Unsigned32 is normally given to =
quantitative values?

Agreed. A type of Integer32 (1 .. 2147483647) may be the better choice.=20=

In the end I would leave this to the MIB doctor to decide.=20

> 3) I only know of the standards from sbs-forum.org that come close to =
the battery MIB specification. I made an attempt to match the objects =
from the Smart Battery Data Specification v1.10 (SBD) and those in this =
MIB. Please see attachment. Some of the SBD objects are only suitable as =
data exchanges between the battery and the battery charger (e.g. a =
laptop, or standalone charger). I think those are inappropriate for this =
MIB. For this reason, I do not think there should be a complete =
alignment between the two specs.

Thanks for the table.

We (the authors) also made this comparison.
We are tending towards aligning names better in the next version, such =
as replacing "NominalVoltage" with "DesignVoltage" or "ActualCapacity" =
with "RemainingCapacity".
But actually we started with "RemainingCapacity" and decided to change =
to "actualCapacity" in an earlier version. Nothing decided yet.

> I think the current model is implementing the MIB support in a UPS, in =
which the battery is part of the "fixed" power source. However, I am =
hoping to exert sufficient influence in the MIB definition, such that we =
will find it useful to implement the MIB support in networked standalone =
battery chargers that will see different batteries from one use to =
another. The application I am envisioning is an asset management system =
that will track the usages of a pool of rechargeable batteries, and =
those batteries are for mobile appliances. This may not have been inside =
the scope originally.

Indeed it has not. But please tell us what you are missing for this =
application.
Particularly, what would you need as identifier?
As you know, SBD has ManufacturerName() (0x20), DeviceName() (0x21), =
ManufactureDate() (0x1b), SerialNumber() (0x1c).
the Battery MIB just has the batteryIdentifier. What would you need?=20

> Below are my thoughts and are, of course, subjective:
>=20
> 3.1) Objects in MIB, but not in SBD Spec:
>=20
> 3.1.1) batteryFirmwareVersion(3) - OK to keep in MIB, but there is no =
standard way to convey this from battery manufacturers
> 3.1.2) batteryType(7) - OK to keep in MIB
> 3.1.3) batteryNumberOfCells(7) - not sure of the usefulness, and not =
should how to get this information from a charger in general

Right, the same holds for the firmware version. However, many notebook =
PCs provide this information for their batteries. Then they can also =
make this info visible in a MIB module.

> 3.1.4) batteryLastChargingCycleTime(13) - good to have in MIB
> 3.1.5) batteryLowAlarmVoltage(20) - OK to have, not really applicable =
to the charger scenario
> 3.1.6) batteryReplacementAlarmCapacity(21) - good to have in MIB
> 3.1.7) batteryReplacementAlarmCycles(22) - good to have in MIB
> 3.1.8) batteryHighAlarmTemperature (23) - good to have in MIB
>=20
> 3.2) Objects in not MIB, but in SBD Spec:
> 3.2.1) ManufacturerAccess() (0x00) - not applicable in MIB
> 3.2.2) RemainingTimeAlarm() (0x02) - important to have in MIB, seems =
fundamental

We had many discussions about this and decided not to include it. Maybe =
we are too much used to get reliable numbers.
As far as I understand it, this number is a rough prediction and may be =
completely wrong. But maybe even such a heuristic is worth being =
supported in the MIB?

> 3.2.3) BatteryMode() (0x03) - not applicable in MIB
> 3.2.4) AtRate() (0x04) - this "AtRate..." group of objects is =
interesting - allows querying a battery performance at a projected =
current level
> 3.2.5) AtRateTimeToFull() (0x05) - see above
> 3.2.6) AtRateTimeToEmpty() (0x06) - see above
> 3.2.7) AtRateOK() (0x07) - see above

Seems to be complex to implement.=20
Would require setting a rate.

> 3.2.8) AverageCurrent() (0x0b) - important to have in MIB; potentially =
more meaningful than batteryCurrentCurrent(17), as current tend to vary =
greatly instantaneously

What would be the interval for computing the average value?

> 3.2.9) MaxError() (0x0c) - not important to have in MIB
> 3.2.10) RunTimeToEmpty() (0x11) - important to have in MIB, seems =
fundamental

See above. This is a rough estimate. Why not reading current and charge =
from the MIB and do the estimation in the management system is needed?
But I fully agree that in many cases this is exactly what a management =
system would like to know.
=20
> 3.2.11) AverageTimeToEmpty() (0x12) - important to have in MIB, seems =
fundamental
> 3.2.12) AverageTimeToFull() (0x13) - important to have in MIB, seems =
fundamental
> 3.2.13) SpecificationInfo() (0x1a) - not important to have in MIB
> 3.2.14) ManufacturerData() (0x23) - not important to have in MIB

Looks like we can easily agree. The only issue to be discussed is the =
support for timeToEmpty/timeToFull for the MIB module.
Let's add this to the list of open issues and discuss it further on this =
list and at the session in Quebec.

> Someone else please check me. My hats off to the authors of the =
Battery MIB. There are lots of details...

Thanks,

    Juergen

> Regards
> Steven Chew.
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of Rolf Winter
> Sent: Thursday, July 07, 2011 7:55 AM
> To: eman@ietf.org
> Subject: [eman] updated version of the battery MIB
>=20
> Hi,
>=20
> we just posted a new version of the battery MIB. It contains the =
following changes:
>=20
> - we added objects for the maximum charging current, the recommended =
current to be used for trickle charging and a notification for battery
> - we adopted the cycle definition of the Smart Battery Data =
Specification
> - the former takes care of two open issues, we removed the one on =
battery health as we e.g. have the cycle count as an approximate metric =
for this and some other information in the MIB
> - We added a new open issue asking how close we should align in =
general to the Smart Battery Data Specification
>=20
> These are the main changes in this version. I think we make very good =
progress on this document. Thanks a lot for all the input received so =
far. We would appreciate any further comments, so please keep them =
coming.
>=20
> Best,
>=20
> Rolf
>=20
>=20
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, =
London W3 6BL | Registered in England 2832014=20
>=20
>=20
> _______________________________________________
> 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


--Apple-Mail-7--428452240
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
Steven,

thanks for sending your very helpful =
comments.

Am 15.07.2011 um 13:46 schrieb Steven =
Chew:

1) The use of the word "current" is double loaded =
(e.g. batteryCurrentCurrent). I suggest use "current" for electrical =
current and use "present" to mean =
instantaneous.

Yes. This is what =
also Mouli proposed. We will find something that circumvents current =
current.
What about "actual" instead of =
"present"?

2) It seems more =
natural to give batteryTechnology(5) a SYNTAX of Integer or Enumeration. =
Am I right that Unsigned32 is normally given to quantitative =
values?

Agreed. A type =
of Integer32 (1 .. 2147483647) may be the better =
choice. 
In the end I would leave this to the MIB doctor =
to decide. 

3) I only =
know of the standards from sbs-forum.org that come close to the =
battery MIB specification. I made an attempt to match the objects from =
the Smart Battery Data Specification v1.10 (SBD) and those in this MIB. =
Please see attachment. Some of the SBD objects are only suitable as data =
exchanges between the battery and the battery charger (e.g. a laptop, or =
standalone charger). I think those are inappropriate for this MIB. For =
this reason, I do not think there should be a complete alignment between =
the two specs.

Thanks for the =
table.

We (the authors) also made this =
comparison.
We are tending towards aligning names better in =
the next version, such as replacing "NominalVoltage" with =
"DesignVoltage" or "ActualCapacity" with =
"RemainingCapacity".
But actually we started with =
"RemainingCapacity" and decided to change to "actualCapacity" in an =
earlier version. Nothing decided =
yet.

I think the =
current model is implementing the MIB support in a UPS, in which the =
battery is part of the "fixed" power source. However, I am hoping to =
exert sufficient influence in the MIB definition, such that we will find =
it useful to implement the MIB support in networked standalone battery =
chargers that will see different batteries from one use to another. The =
application I am envisioning is an asset management system that will =
track the usages of a pool of rechargeable batteries, and those =
batteries are for mobile appliances. This may not have been inside the =
scope originally.

Indeed it has =
not. But please tell us what you are missing for this =
application.
Particularly, what would you need as =
identifier?
As you know, SBD has ManufacturerName() =
(0x20), DeviceName() (0x21), ManufactureDate() (0x1b), SerialNumber() =
(0x1c).
the Battery MIB just has the batteryIdentifier. What =
would you need? 

Below =
are my thoughts and are, of course, subjective:

3.1) Objects in =
MIB, but not in SBD Spec:

3.1.1) batteryFirmwareVersion(3) - OK =
to keep in MIB, but there is no standard way to convey this from battery =
manufacturers
3.1.2) batteryType(7) - OK to keep in MIB
3.1.3) =
batteryNumberOfCells(7) - not sure of the usefulness, and not should how =
to get this information from a charger in =
general

Right, the same holds for =
the firmware version. However, many notebook PCs provide this =
information for their batteries. Then they can also make this info =
visible in a MIB module.

3.1.4) batteryLastChargingCycleTime(13) - good to =
have in MIB
3.1.5) batteryLowAlarmVoltage(20) - OK to have, not =
really applicable to the charger scenario
3.1.6) =
batteryReplacementAlarmCapacity(21) - good to have in MIB
3.1.7) =
batteryReplacementAlarmCycles(22) - good to have in MIB
3.1.8) =
batteryHighAlarmTemperature (23) - good to have in MIB

3.2) =
Objects in not MIB, but in SBD Spec:
3.2.1) ManufacturerAccess() =
(0x00) - not applicable in MIB
3.2.2) RemainingTimeAlarm() (0x02) - =
important to have in MIB, seems =
fundamental

We had many discussions =
about this and decided not to include it. Maybe we are too much used to =
get reliable numbers.
As far as I understand it, this number =
is a rough prediction and may be completely wrong. But maybe even such a =
heuristic is worth being supported in the =
MIB?

3.2.3) =
BatteryMode() (0x03) - not applicable in MIB
3.2.4) AtRate() (0x04) - =
this "AtRate..." group of objects is interesting - allows querying a =
battery performance at a projected current level
3.2.5) =
AtRateTimeToFull() (0x05) - see above
3.2.6) AtRateTimeToEmpty() =
(0x06) - see above
3.2.7) AtRateOK() (0x07) - see =
above

Seems to be complex to =
implement. 
Would require setting a =
rate.

3.2.8) =
AverageCurrent() (0x0b) - important to have in MIB; potentially more =
meaningful than batteryCurrentCurrent(17), as current tend to vary =
greatly instantaneously

What would =
be the interval for computing the average =
value?

3.2.9) MaxError() =
(0x0c) - not important to have in MIB
3.2.10) RunTimeToEmpty() (0x11) =
- important to have in MIB, seems =
fundamental

See above. This is a =
rough estimate. Why not reading current and charge from the MIB and do =
the estimation in the management system is needed?
But I fully =
agree that in many cases this is exactly what a management system would =
like to know.
 
3.2.11) =
AverageTimeToEmpty() (0x12) - important to have in MIB, seems =
fundamental
3.2.12) AverageTimeToFull() (0x13) - important to have in =
MIB, seems fundamental
3.2.13) SpecificationInfo() (0x1a) - not =
important to have in MIB
3.2.14) ManufacturerData() (0x23) - not =
important to have in MIB

Looks like we can =
easily agree. The only issue to be discussed is the support for =
timeToEmpty/timeToFull for the MIB module.
Let's add this to =
the list of open issues and discuss it further on this list and at the =
session in Quebec.

Someone =
else please check me. My hats off to the authors of the Battery MIB. =
There are lots of =
details...

Thanks,

    Juergen

Regards
Steven Chew.

-----Original =
Message-----
From: eman-bounces@ietf.org =
[mailto:eman-bounces@ietf.org] On Behalf Of Rolf Winter
Sent: =
Thursday, July 07, 2011 7:55 AM
To: eman@ietf.org
Subject: [eman] =
updated version of the battery MIB

Hi,

we just posted a =
new version of the battery MIB. It contains the following =
changes:

- we added objects for the maximum charging current, the =
recommended current to be used for trickle charging and a notification =
for battery
- we adopted the cycle definition of the Smart Battery =
Data Specification
- the former takes care of two open issues, we =
removed the one on battery health as we e.g. have the cycle count as an =
approximate metric for this and some other information in the MIB
- =
We added a new open issue asking how close we should align in general to =
the Smart Battery Data Specification

These are the main changes =
in this version. I think we make very good progress on this document. =
Thanks a lot for all the input received so far. We would appreciate any =
further comments, so please keep them =
coming.

Best,

Rolf


NEC Europe Limited | =
Registered Office: NEC House, 1 Victoria Road, London W3 6BL | =
Registered in England 2832014 =



_______________________________________________
eman =
mailing list
eman@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/eman
<MIB-SBD Compare =
02.xls>_______________________________________________
eman =
mailing =
list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman

=

--Apple-Mail-7--428452240--

From SChew@bren-tronics.com  Fri Jul 15 12:41:45 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DE921F8B48 for ; Fri, 15 Jul 2011 12:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.57
X-Spam-Level: 
X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.028,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVMxGfs+oQKh for ; Fri, 15 Jul 2011 12:41:40 -0700 (PDT)
Received: from EXHUB018-1.exch018.msoutlookonline.net (exhub018-1.exch018.msoutlookonline.net [64.78.17.16]) by ietfa.amsl.com (Postfix) with ESMTP id C30E821F8C4F for ; Fri, 15 Jul 2011 12:41:37 -0700 (PDT)
Received: from EXVMBX018-1.exch018.msoutlookonline.net ([64.78.17.47]) by EXHUB018-1.exch018.msoutlookonline.net ([64.78.17.16]) with mapi; Fri, 15 Jul 2011 12:41:37 -0700
From: Steven Chew 
To: Juergen Quittek 
Date: Fri, 15 Jul 2011 12:41:35 -0700
Thread-Topic: [eman] updated version of the battery MIB
Thread-Index: AcxC+D4PtkOrTEGXRJ6Qs9Ac0SxWdQALJVZQ
Message-ID: <0BB24042CB683840B986F84BC859CFB569F0CB21BC@EXVMBX018-1.exch018.msoutlookonline.net>
References: <791AD3077F94194BB2BDD13565B6295D1CFBAF43@DAPHNIS.office.hd> <0BB24042CB683840B986F84BC859CFB569F0CB1FA4@EXVMBX018-1.exch018.msoutlookonline.net> <2831BF9A-121B-45B8-A174-7071B58A0302@quittek.at>
In-Reply-To: <2831BF9A-121B-45B8-A174-7071B58A0302@quittek.at>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_0BB24042CB683840B986F84BC859CFB569F0CB21BCEXVMBX0181exc_"
MIME-Version: 1.0
Cc: "eman@ietf.org" 
Subject: Re: [eman] updated version of the battery MIB
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 19:41:45 -0000

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

Hi Juergen,

Please see my comments inline below in red. Thanks for your attention.

Regards,
Steven.

From: Juergen Quittek [mailto:ietf@quittek.at]
Sent: Friday, July 15, 2011 10:05 AM
To: Steven Chew
Cc: Rolf Winter; eman@ietf.org
Subject: Re: [eman] updated version of the battery MIB

Hi Steven,

thanks for sending your very helpful comments.

Am 15.07.2011 um 13:46 schrieb Steven Chew:


1) The use of the word "current" is double loaded (e.g. batteryCurrentCurre=
nt). I suggest use "current" for electrical current and use "present" to me=
an instantaneous.

Yes. This is what also Mouli proposed. We will find something that circumve=
nts current current.
What about "actual" instead of "present"?

Steven> I think "actual" is fine.


2) It seems more natural to give batteryTechnology(5) a SYNTAX of Integer o=
r Enumeration. Am I right that Unsigned32 is normally given to quantitative=
 values?

Agreed. A type of Integer32 (1 .. 2147483647) may be the better choice.
In the end I would leave this to the MIB doctor to decide.


3) I only know of the standards from sbs-forum.org th=
at come close to the battery MIB specification. I made an attempt to match =
the objects from the Smart Battery Data Specification v1.10 (SBD) and those=
 in this MIB. Please see attachment. Some of the SBD objects are only suita=
ble as data exchanges between the battery and the battery charger (e.g. a l=
aptop, or standalone charger). I think those are inappropriate for this MIB=
. For this reason, I do not think there should be a complete alignment betw=
een the two specs.

Thanks for the table.

We (the authors) also made this comparison.
We are tending towards aligning names better in the next version, such as r=
eplacing "NominalVoltage" with "DesignVoltage" or "ActualCapacity" with "Re=
mainingCapacity".
But actually we started with "RemainingCapacity" and decided to change to "=
actualCapacity" in an earlier version. Nothing decided yet.

Steven> Yes, aligning names would be a great thing.

I think the current model is implementing the MIB support in a UPS, in whic=
h the battery is part of the "fixed" power source. However, I am hoping to =
exert sufficient influence in the MIB definition, such that we will find it=
 useful to implement the MIB support in networked standalone battery charge=
rs that will see different batteries from one use to another. The applicati=
on I am envisioning is an asset management system that will track the usage=
s of a pool of rechargeable batteries, and those batteries are for mobile a=
ppliances. This may not have been inside the scope originally.

Indeed it has not. But please tell us what you are missing for this applica=
tion.
Particularly, what would you need as identifier?
As you know, SBD has ManufacturerName() (0x20), DeviceName() (0x21), Manufa=
ctureDate() (0x1b), SerialNumber() (0x1c).
the Battery MIB just has the batteryIdentifier. What would you need?

Steven> I think batteryIdentifier is fine. I was planning to aggregate the =
SBD objects you mention above to build the a unique value for batteryIdenti=
fier for each battery.


Below are my thoughts and are, of course, subjective:

3.1) Objects in MIB, but not in SBD Spec:

3.1.1) batteryFirmwareVersion(3) - OK to keep in MIB, but there is no stand=
ard way to convey this from battery manufacturers
3.1.2) batteryType(7) - OK to keep in MIB
3.1.3) batteryNumberOfCells(7) - not sure of the usefulness, and not should=
 how to get this information from a charger in general

Right, the same holds for the firmware version. However, many notebook PCs =
provide this information for their batteries. Then they can also make this =
info visible in a MIB module.

Steven> Sure. We can keep it.


3.1.4) batteryLastChargingCycleTime(13) - good to have in MIB
3.1.5) batteryLowAlarmVoltage(20) - OK to have, not really applicable to th=
e charger scenario
3.1.6) batteryReplacementAlarmCapacity(21) - good to have in MIB
3.1.7) batteryReplacementAlarmCycles(22) - good to have in MIB
3.1.8) batteryHighAlarmTemperature (23) - good to have in MIB

3.2) Objects in not MIB, but in SBD Spec:
3.2.1) ManufacturerAccess() (0x00) - not applicable in MIB
3.2.2) RemainingTimeAlarm() (0x02) - important to have in MIB, seems fundam=
ental

We had many discussions about this and decided not to include it. Maybe we =
are too much used to get reliable numbers.
As far as I understand it, this number is a rough prediction and may be com=
pletely wrong. But maybe even such a heuristic is worth being supported in =
the MIB?

Steven> I think it's worth being supported. They are constantly improving o=
n the battery gas gauging techniques.

3.2.3) BatteryMode() (0x03) - not applicable in MIB
3.2.4) AtRate() (0x04) - this "AtRate..." group of objects is interesting -=
 allows querying a battery performance at a projected current level
3.2.5) AtRateTimeToFull() (0x05) - see above
3.2.6) AtRateTimeToEmpty() (0x06) - see above
3.2.7) AtRateOK() (0x07) - see above

Seems to be complex to implement.
Would require setting a rate.

Steven> I agree.


3.2.8) AverageCurrent() (0x0b) - important to have in MIB; potentially more=
 meaningful than batteryCurrentCurrent(17), as current tend to vary greatly=
 instantaneously

What would be the interval for computing the average value?

Steven> SBD specifies the interval as 1 minute.


3.2.9) MaxError() (0x0c) - not important to have in MIB
3.2.10) RunTimeToEmpty() (0x11) - important to have in MIB, seems fundament=
al

See above. This is a rough estimate. Why not reading current and charge fro=
m the MIB and do the estimation in the management system is needed?
But I fully agree that in many cases this is exactly what a management syst=
em would like to know.

Steven> I agree that RunTimeToEmpty() (0x11)  seems to be derivable from ot=
her values. However, the battery can estimate it better. The time is not ex=
actly linear in relation to charge and current. For example, the battery's =
algorithm is highly dependent on the cell chemistry. I would vote to keep t=
his in the MIB.

3.2.11) AverageTimeToEmpty() (0x12) - important to have in MIB, seems funda=
mental
3.2.12) AverageTimeToFull() (0x13) - important to have in MIB, seems fundam=
ental
3.2.13) SpecificationInfo() (0x1a) - not important to have in MIB
3.2.14) ManufacturerData() (0x23) - not important to have in MIB

Looks like we can easily agree. The only issue to be discussed is the suppo=
rt for timeToEmpty/timeToFull for the MIB module.
Let's add this to the list of open issues and discuss it further on this li=
st and at the session in Quebec.


Someone else please check me. My hats off to the authors of the Battery MIB=
. There are lots of details...

Thanks,

    Juergen


Regards
Steven Chew.

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-boun=
ces@ietf.org] On Behalf Of Rolf Winter
Sent: Thursday, July 07, 2011 7:55 AM
To: eman@ietf.org
Subject: [eman] updated version of the battery MIB

Hi,

we just posted a new version of the battery MIB. It contains the following =
changes:

- we added objects for the maximum charging current, the recommended curren=
t to be used for trickle charging and a notification for battery
- we adopted the cycle definition of the Smart Battery Data Specification
- the former takes care of two open issues, we removed the one on battery h=
ealth as we e.g. have the cycle count as an approximate metric for this and=
 some other information in the MIB
- We added a new open issue asking how close we should align in general to =
the Smart Battery Data Specification

These are the main changes in this version. I think we make very good progr=
ess on this document. Thanks a lot for all the input received so far. We wo=
uld appreciate any further comments, so please keep them coming.

Best,

Rolf


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London =
W3 6BL | Registered in England 2832014


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


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


Hi Juerge=
n,
 
Please see my comments =
inline below in red. Thanks for your attenti=
on.
 
Regards,
Steven.
<=
o:p> 
From: Juergen Q=
uittek [mailto:ietf@quittek.at] 
Sent: Friday, July 15, 2011 10:0=
5 AM
To: Steven Chew
Cc: Rolf Winter; eman@ietf.org
=
Subject: Re: [eman] updated version of the battery MIB
 
Hi Steven,
 
thanks for sending your very helpful c=
omments.
 
Am 15.07.2011 um 13:46 schrieb Steven Chew:=



1) The use of the word "current" is double loaded=
 (e.g. batteryCurrentCurrent). I suggest use "current" for electr=
ical current and use "present" to mean instantaneous.<=
/p>
 
Yes. This is what also Mouli proposed. We will find something that =
circumvents current current.
=
What about "actual" instead of "present"?
 
Steven> I think “actual” is fine.


2) It seems more natural to give batteryTechnology(5) a SYNTAX of In=
teger or Enumeration. Am I right that Unsigned32 is normally given to quant=
itative values?
 
Agreed. A type of Integer32 (1 .. 2147483647) may be the=
 better choice. 
In the =
end I would leave this to the MIB doctor to decide. 


3) I only know of the standards from sb=
s-forum.org that come close to the battery MIB specification. I made an=
 attempt to match the objects from the Smart Battery Data Specification v1.=
10 (SBD) and those in this MIB. Please see attachment. Some of the SBD obje=
cts are only suitable as data exchanges between the battery and the battery=
 charger (e.g. a laptop, or standalone charger). I think those are inapprop=
riate for this MIB. For this reason, I do not think there should be a compl=
ete alignment between the two specs.
 
Thanks for the tabl=
e.
 
We (the authors) also made this comparison.=

We are tending towards aligning n=
ames better in the next version, such as replacing "NominalVoltage&quo=
t; with "DesignVoltage" or "ActualCapacity" with "=
RemainingCapacity".
But =
actually we started with "RemainingCapacity" and decided to chang=
e to "actualCapacity" in an earlier version. Nothing decided yet.=

 
Steven> Yes, aligning names would be a great thing.<=
o:p>
 
<=
/div>
<=
p class=3DMsoNormal>I think the current model is implementing the MIB suppo=
rt in a UPS, in which the battery is part of the "fixed" power so=
urce. However, I am hoping to exert sufficient influence in the MIB definit=
ion, such that we will find it useful to implement the MIB support in netwo=
rked standalone battery chargers that will see different batteries from one=
 use to another. The application I am envisioning is an asset management sy=
stem that will track the usages of a pool of rechargeable batteries, and th=
ose batteries are for mobile appliances. This may not have been inside the =
scope originally.
 
Indeed it has not. But pl=
ease tell us what you are missing for this application.
Particularly, what would you need as identifier?=

As you know, SBD has Ma=
nufacturerName() (0x20), DeviceName() (0x21), ManufactureDate() (0x1b), Ser=
ialNumber() (0x1c).
the Batte=
ry MIB just has the batteryIdentifier. What would you need? 
&nb=
sp;
Steven> I think batteryIdent=
ifier is fine. I was planning to aggregate the SBD objects you mention abov=
e to build the a unique value for batteryIdentifier for each battery.<=
/o:p>


Below are my thoughts and are, of course, subjective:

3=
.1) Objects in MIB, but not in SBD Spec:

3.1.1) batteryFirmwareVersi=
on(3) - OK to keep in MIB, but there is no standard way to convey this from=
 battery manufacturers
3.1.2) batteryType(7) - OK to keep in MIB
3.1.=
3) batteryNumberOfCells(7) - not sure of the usefulness, and not should how=
 to get this information from a charger in general
 
Right=
, the same holds for the firmware version. However, many notebook PCs provi=
de this information for their batteries. Then they can also make this info =
visible in a MIB module.
 
Steven> Sure. We can keep it.


3.1.4) ba=
tteryLastChargingCycleTime(13) - good to have in MIB
3.1.5) batteryLowAl=
armVoltage(20) - OK to have, not really applicable to the charger scenario<=
br>3.1.6) batteryReplacementAlarmCapacity(21) - good to have in MIB
3.1.=
7) batteryReplacementAlarmCycles(22) - good to have in MIB
3.1.8) batter=
yHighAlarmTemperature (23) - good to have in MIB

3.2) Objects in not=
 MIB, but in SBD Spec:
3.2.1) ManufacturerAccess() (0x00) - not applicab=
le in MIB
3.2.2) RemainingTimeAlarm() (0x02) - important to have in MIB,=
 seems fundamental
 =
;
We had many discussions about this an=
d decided not to include it. Maybe we are too much used to get reliable num=
bers.
As far as I understand =
it, this number is a rough prediction and may be completely wrong. But mayb=
e even such a heuristic is worth being supported in the MIB?
=

 
Steven> I think it’s worth being supported. They are constant=
ly improving on the battery gas gauging techniques.
 
3.2=
.3) BatteryMode() (0x03) - not applicable in MIB
3.2.4) AtRate() (0x04) =
- this "AtRate..." group of objects is interesting - allows query=
ing a battery performance at a projected current level
3.2.5) AtRateTime=
ToFull() (0x05) - see above
3.2.6) AtRateTimeToEmpty() (0x06) - see abov=
e
3.2.7) AtRateOK() (0x07) - see above
=

 
S=
eems to be complex to implement. 
Would require setting a rate.
=
 
Steven> I agr=
ee.


3.2.8) AverageCurrent() (0x0b) - important t=
o have in MIB; potentially more meaningful than batteryCurrentCurrent(17), =
as current tend to vary greatly instantaneously
 
What wou=
ld be the interval for computing the average value?
 
Ste=
ven> SBD specifies the interval as 1 minute.
=



=
3.2.9) MaxError() (0x0c) - not important to have in MIB
3.2.10) RunTimeT=
oEmpty() (0x11) - important to have in MIB, seems fundamental
 
See above. This is a rough estimate. Why not reading current and char=
ge from the MIB and do the estimation in the management system is needed?
But I fully agree that in many=
 cases this is exactly what a management system would like to know.
 
<=
p class=3DMsoNormal>Steven> I agree that RunTimeToEmpty() (0x11) &nbs=
p;seems to be derivable from other values. However, the battery can estimat=
e it better. The time is not exactly linear in relation to charge and curre=
nt. For example, the battery’s algorithm is highly dependent on the c=
ell chemistry. I would vote to keep this in the MIB. 

3.2.11) AverageTimeToEmpty() (0x12) =
- important to have in MIB, seems fundamental
3.2.12) AverageTimeToFull(=
) (0x13) - important to have in MIB, seems fundamental
3.2.13) Specifica=
tionInfo() (0x1a) - not important to have in MIB
3.2.14) ManufacturerDat=
a() (0x23) - not important to have in MIB

Looks like we can easily agree. The only issue to be discussed =
is the support for timeToEmpty/timeToFull for the MIB module.
Let's add this to the list of open issues =
and discuss it further on this list and at the session in Quebec.


Someone else please check me. My hats off to the authors of th=
e Battery MIB. There are lots of details...
 
Thanks,=

 
<=
p class=3DMsoNormal>    Juergen


Regards<=
br>Steven Chew.

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@iet=
f.org] On Behalf Of Rolf Winter
Sent: Thursday, July 07, 2011 7:55 AMTo: eman@ietf.org
Subject: [eman] =
updated version of the battery MIB

Hi,

we just posted a new v=
ersion of the battery MIB. It contains the following changes:

- we a=
dded objects for the maximum charging current, the recommended current to b=
e used for trickle charging and a notification for battery
- we adopted =
the cycle definition of the Smart Battery Data Specification
- the forme=
r takes care of two open issues, we removed the one on battery health as we=
 e.g. have the cycle count as an approximate metric for this and some other=
 information in the MIB
- We added a new open issue asking how close we =
should align in general to the Smart Battery Data Specification

Thes=
e are the main changes in this version. I think we make very good progress =
on this document. Thanks a lot for all the input received so far. We would =
appreciate any further comments, so please keep them coming.

Best,
Rolf


NEC Europe Limited | Registered Office: NEC House, 1 =
Victoria Road, London W3 6BL | Registered in England 2832014 


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

<MIB-SBD Compare 02.xls>_________________________________________=
______
eman mailing list
eman@ietf.o=
rg
https://ww=
w.ietf.org/mailman/listinfo/eman
 
=

--_000_0BB24042CB683840B986F84BC859CFB569F0CB21BCEXVMBX0181exc_--

From bclaise@cisco.com  Wed Jul 20 08:06:07 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A63721F8548 for ; Wed, 20 Jul 2011 08:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id No4BqUJ-kegw for ; Wed, 20 Jul 2011 08:06:06 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 12C5E21F8892 for ; Wed, 20 Jul 2011 08:06:05 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6KF65x6023765 for ; Wed, 20 Jul 2011 17:06:05 +0200 (CEST)
Received: from [128.107.114.14] (dhcp-128-107-114-14.cisco.com [128.107.114.14]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6KF60EQ021087 for ; Wed, 20 Jul 2011 17:06:00 +0200 (CEST)
Message-ID: <4E26EED8.7070306@cisco.com>
Date: Wed, 20 Jul 2011 08:06:00 -0700
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: eman mailing list 
Content-Type: multipart/mixed; boundary="------------060601060602090301010501"
Subject: [eman] Fwd: FW: IETF 81 Audio Streaming
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 15:06:07 -0000

This is a multi-part message in MIME format.
--------------060601060602090301010501
Content-Type: multipart/alternative;
 boundary="------------070207000903090605000004"


--------------070207000903090605000004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

FYI.

-------- Original Message --------
Subject: 	FW: IETF 81 Audio Streaming
Date: 	Sat, 16 Jul 2011 11:39:14 +0200
From: 	Romascanu, Dan (Dan) 
To: 	



Hi,

I suggest that you forward this information to your WG lists, for the 
benefit of people attending IETF-81 on site or remotely.


Thanks and Regards,

Dan

*From:*ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] *On Behalf 
Of *Nick Kukich
*Sent:* Saturday, July 16, 2011 12:53 AM
*To:* ietf@ietf.org
*Subject:* IETF 81 Audio Streaming

Greetings!

We're two weeks out from the beginning of meeting streaming. For those 
interested in monitoring sessions or participating remotely the 
following information may prove useful.

- -Audio Streaming-

All 8 parallel tracks at the IETF 81 meeting will be broadcast starting 
with the commencement of working group sessions on Monday, July 25, 2011 
at 0900 EDT (GMT-4) and continue until Friday, July 29 at 1515 EDT.

Because we have been asked several times in the past, note that if you 
wish to use the rooms that are being recorded for impromptu meeting 
during unscheduled sessions or lunch breaks that you can invite remote 
participants to tune in to the appropriate stream. Recording cannot be 
guaranteed for unscheduled sessions. Conversely, it should never be 
assumed that recording or observation is not occurring on open 
microphones, they are after all connected to the Internet.

The links for streaming sources and the schedule are best retrieved from 
the IETF tools agenda, which as per Standard operating procedure will be 
located here:

http://tools.ietf.org/agenda/81/ 

- -Jabber/XMPP-

For information on IETF Jabber participation see:

http://www.ietf.org/jabber/index.html 


or click on the Jabber links in the tools team agenda once you have a 
properly configured jabber/xmpp messaging client.

- -Webex-

Webex screen sharing participation is possible for a limited number of 
sessions. Consult with your working-group chair or the secretariat for 
more information.

- -Ticketing-

For prompt access to the meeting trouble desk, the email address is:

mtd@ietf.org 

For streaming related issues please send email to 
ietf-streaming@verilan.com  with info 
including the current time and affected streaming channel.

Regards,

Nick Kukich

Network Engineer
Verilan Event Services, Inc.

503.710.5115


--------------070207000903090605000004
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
    
    
  
  
    FYI.

    

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

      
        

          Subject: 
          FW: IETF 81 Audio Streaming
        

        

          Date: 
          Sat, 16 Jul 2011 11:39:14 +0200
        

        

          From: 
          Romascanu, Dan (Dan) <dromasca@avaya.com>
        

        

          To: 
          <ops-chairs@ietf.org>
        

      
    

    

    

    
    
    
    

      
 

      
 

      
Hi,

          

          I suggest that you forward this information to your WG lists,
          for the benefit of people attending IETF-81 on site or
          remotely.

      
 

          Thanks and Regards,

          

          Dan

      

        
From:
            ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On
              Behalf Of Nick Kukich

            Sent: Saturday, July 16, 2011 12:53 AM

            To: ietf@ietf.org

            Subject: IETF 81 Audio Streaming

      

      
 

      
Greetings!

          

          We're two weeks out from the
            beginning of meeting streaming. For those interested in
            monitoring sessions or participating remotely the following
            information may prove useful.

          

          - -Audio Streaming-

          

          All 8 parallel tracks at the IETF 81 meeting will be broadcast
            starting with the commencement of working group sessions on
            Monday, July 25, 2011 at 0900 EDT (GMT-4) and continue until
            Friday, July 29 at 1515 EDT.

          

          Because we have been asked
            several times in the past, note that if you wish to use the
            rooms that are being recorded for impromptu meeting during
            unscheduled sessions or lunch breaks that you can invite
            remote participants to tune in to the appropriate stream.
            Recording cannot be guaranteed for unscheduled sessions.
            Conversely, it should never be assumed that recording or
            observation is not occurring on open microphones, they are
            after all connected to the Internet.

          

          The links for streaming sources and the schedule are best
            retrieved from the IETF tools agenda, which as per
            Standard operating procedure will be located here:

          

          http://tools.ietf.org/agenda/81/

          

          - -Jabber/XMPP-

          

          For information on IETF Jabber participation see:

          

          http://www.ietf.org/jabber/index.html

          

          or click on the Jabber links in
            the tools team agenda once you have a properly configured
            jabber/xmpp messaging client.

          

          - -Webex-

          

          Webex screen sharing
            participation is possible for a limited number of sessions.
            Consult with your working-group chair or the secretariat for
            more information.

          

          - -Ticketing-

          

          For prompt access to the
            meeting trouble desk, the email address is:

          

          mtd@ietf.org

          

          For streaming related issues please send email
            to ietf-streaming@verilan.com with
            info including the current time and affected streaming channel.

          

          Regards,

      

        
 

      

      
Nick Kukich

      

        
 

        

          
Network
            Engineer

            Verilan Event Services, Inc.

        

        

          

            
503.710.5115

          

        

      

      
 

    

  


--------------070207000903090605000004--

--------------060601060602090301010501
Content-Type: text/plain;
 name="ATT4812602.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="ATT4812602.txt"

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

--------------060601060602090301010501--

From ramorgan@ra.rockwell.com  Thu Jul 21 07:48:49 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB9221F8B32 for ; Thu, 21 Jul 2011 07:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.402
X-Spam-Level: **
X-Spam-Status: No, score=2.402 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, 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 DKnNVKPGV1Uy for ; Thu, 21 Jul 2011 07:48:48 -0700 (PDT)
Received: from ramilwsmtp01.ra.rockwell.com (ramkesd003-e.ra.rockwell.com [205.175.240.251]) by ietfa.amsl.com (Postfix) with ESMTP id B0AEA21F8B0A for ; Thu, 21 Jul 2011 07:48:48 -0700 (PDT)
In-Reply-To: <4E25FCF1.6000504@cisco.com>
To: Benoit Claise 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5  CCH1 March 07, 2006
From: Rich A Morgan 
Message-ID: 
Date: Thu, 21 Jul 2011 09:48:47 -0500
X-MIMETrack: Serialize by Router on RAMilwSMTP01/Milwaukee/RA/Rockwell(Release 8.5.2FP2|March 22, 2011) at 07/21/2011 09:48:48 AM, Serialize complete at 07/21/2011 09:48:48 AM
Content-Type: multipart/alternative; boundary="=_alternative 00515E91862578D4_="
Cc: John P Caspers , eman@ietf.org
Subject: Re: [eman] ODVA <-> IETF EMAN
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, 21 Jul 2011 14:48:49 -0000

This is a multipart message in MIME format.
--=_alternative 00515E91862578D4_=
Content-Type: text/plain; charset="US-ASCII"

Hello, Benoit,

Thank you for the opportunity to review the draft IETF EMAN requirements 
03 document.

The EMAN effort and the ODVA Energy Initiative clearly have many similar 
goals. ODVA is an association of vendors that operates at the device level 
in the industrial manuafacturing ecosystem within the overall framework of 
the Common Industrial Protocol, or CIP.. The Energy Initiative is in its 
first phase: developing standardized communication methods for 
energy-aware industrial devices to report power, energy and other 
associated data. The ODVA Energy special interest group (SIG) is 
completing work on phase 1 and moving into the next phase: developing 
standardized methods for commanding industrial devices to thates that use 
energy more efficiently.

The CIP Energy phase 1 effort includes a number of concepts that may be 
useful within EMAN. 
Support of all types of energy with normalized reporting in kilo-Watthours
Support of energy-aware devices with varying capabilities
Those that measure energy
Those that derive power and energy from measurement and/or other data such 
as device states
Those that act as proxy for an external device or load
Those that aggregate energy use of child devices
Those that simply report a fixed power value or zero depending on the 
device state
Standardized reporting of energy data using "odometer" structures 
(consumed energy, generated energy and net energy). Each odometer is an 
array of 5 INTs scaled by powers of 10
Definition of the operation of an aggregation device. The aggregator 
periodically polls data from its children, assesses the incremental energy 
consumption (generation) of each child and presents the sum of the child 
devices' incremental usage in the aggregator's own set of odometers.

A reason for the use of an odometer as a 5-INT array is that many CIP 
enabled devices are simple devices that do not support data types such as 
INT64 or F64. An energy counter needs to be precise but with a large 
enough maximum value that a value rollover is a rare event.

The EMAN draft appears to create a valuable standardized framework for not 
only energy management but also asset management of the network 
infrastructure. 

Thank you again for sharing this work with ODVA. 

Regards,

Rich Morgan
Rockwell Automation
Power and Energy Products
Office:  (+1) 414 382 0329
Mobile: (+1) 414 517 9071

##
--=_alternative 00515E91862578D4_=
Content-Type: text/html; charset="US-ASCII"



Hello, Benoit,



Thank you for the opportunity to review
the draft IETF EMAN requirements 03 document.



The EMAN effort and the ODVA Energy
Initiative clearly have many similar goals. ODVA is an association of vendors
that operates at the device level in the industrial manuafacturing ecosystem
within the overall framework of the Common Industrial Protocol, or CIP..
The Energy Initiative is in its first phase: developing standardized communication
methods for energy-aware industrial devices to report power, energy and
other associated data. The ODVA Energy special interest group (SIG) is
completing work on phase 1 and moving into the next phase: developing standardized
methods for commanding industrial devices to thates that use energy more
efficiently.



The CIP Energy phase 1 effort includes
a number of concepts that may be useful within EMAN. 

    

  • Support of all types of energy with
normalized reporting in kilo-Watthours

  • Support of energy-aware devices with
varying capabilities

      

    • Those that measure energy

    • Those that derive power and energy from
measurement and/or other data such as device states

    • Those that act as proxy for an external
device or load

    • Those that aggregate energy use of child
devices

    • Those that simply report a fixed power
value or zero depending on the device state
    

      

    • Standardized reporting of energy data
using "odometer" structures (consumed energy, generated energy
and net energy). Each odometer is an array of 5 INTs scaled by powers of
10

    • Definition of the operation of an aggregation
device. The aggregator periodically polls data from its children, assesses
the incremental energy consumption (generation) of each child and presents
the sum of the child devices' incremental usage in the aggregator's own
set of odometers.
    

    A reason for the use of an odometer
as a 5-INT array is that many CIP enabled devices are simple devices that
do not support data types such as INT64 or F64. An energy counter needs
to be precise but with a large enough maximum value that a value rollover
is a rare event.

    

    The EMAN draft appears to create a valuable
standardized framework for not only energy management but also asset management
of the network infrastructure. 

    

    Thank you again for sharing this work
with ODVA. 


    
Regards,
    

    
Rich Morgan
    
Rockwell Automation
    
Power and Energy Products
    
Office:  (+1) 414 382 0329
    
Mobile: (+1) 414 517 9071
    

    
##

--=_alternative 00515E91862578D4_=--

From david.prantl@joulex.net  Fri Jul 22 14:13:02 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F2221F8B32 for ; Fri, 22 Jul 2011 14:13:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.708
X-Spam-Level: *
X-Spam-Status: No, score=1.708 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_ILLEGAL_IP=1.908]
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 175cDL+C1Yp0 for ; Fri, 22 Jul 2011 14:12:59 -0700 (PDT)
Received: from qhexrelay2.hosting.inetserver.de (fw1.hostedoffice.ag [81.20.90.82]) by ietfa.amsl.com (Postfix) with ESMTP id 86BC021F8B03 for ; Fri, 22 Jul 2011 14:12:57 -0700 (PDT)
Received: from qhexhub5.hosting.inetserver.de (unknown [10.20.10.24]) by qhexrelay2.hosting.inetserver.de (Postfix) with ESMTP id 542F8187460; Fri, 22 Jul 2011 22:54:27 +0200 (CEST)
Received: from QHEXMBOX2.hosting.inetserver.de ([fe80:0000:0000:0000:d926:a88f:242.116.230.85]) by qhexhub5.hosting.inetserver.de ([10.20.10.225]) with mapi; Fri, 22 Jul 2011 22:54:27 +0200
From: David Prantl 
To: "eman@ietf.org" 
Date: Fri, 22 Jul 2011 22:54:27 +0200
Thread-Topic: Feedback on Framework Draft
Thread-Index: AcxH+LKmWKbSec3VQ6OixI9JpyOlRQAcVf/wAAmyXPAAAqqMEAAFNQxgAAA/HzA=
Message-ID: <7B9BC0FC24CECF4A840DB64B5C5B77850975CCD93B@QHEXMBOX2.hosting.inetserver.de>
References: <7B9BC0FC24CECF4A840DB64B5C5B77850975CCD8A3@QHEXMBOX2.hosting.inetserver.de>  <7B9BC0FC24CECF4A840DB64B5C5B77850975CCD934@QHEXMBOX2.hosting.inetserver.de> 
In-Reply-To: 
Accept-Language: de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_7B9BC0FC24CECF4A840DB64B5C5B77850975CCD93BQHEXMBOX2host_"
MIME-Version: 1.0
Subject: [eman] Feedback on Framework Draft
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2011 21:13:02 -0000

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

Hello All,

my name is David Prantl, working for JouleX as a Solution Architect. I am s=
ummarizing
comments from myself and my colleagues Martin Paatz and Rene Seeber. We hav=
e an
Enterprise Energy Management Product and would like to comment on the lates=
t
draft of the Energy Management Framework Draft - which we think is a great =
foundation
for a standardized approach to Energy Management.
Comments as bullet points below:

Energy Monitoring

*         We are Glad that Energy Quality and Demand are available as optio=
nal Values as this permits
us - if available from Energy Managed Objects - to deliver high accuracy Re=
adings (based on
demand/total Energy delivered and not point measurements)

*         The Integration of Battery Information is crucial for shaving off=
 energy during peak demand periods-
it is good to know this is already integrated, peak-demand handling is cruc=
ial in e.g. Japan.

Energy Managed Object Identification and Context
Today there are specifications for role/keyword/importance/category

*         The Keyword Concept for Grouping is extremely useful and has been=
 integrated into our
Software for arbitrary Objects.

*         The Context Role (5.2.5) must specify more examples or rules on h=
ow the roles-tring should be populated,

e.g. contain standard definitions, otherwise they are only one more keyword=
.

However, we appreciate this additional Information field, and would in fact=
 encourage more of these - but
with clearly defined recommendations in regards to content, see below.

*         There should be additional identification fields for at least ven=
dor and product, e.g.
Cisco, WS-C2960G-48TC-L or Lenovo, W500
Otherwise there is no way to uniquely identify Energy Managed Objects (in r=
espect to what kind of device
is behind it) - this becomes important when additional Information must be =
retrieved or presented.
E.g. when an outside mgmt-station maps Manufacturer Power States based on p=
re-known states for a
certain device-type

Energy Managed Object Relationships

*         energy topology information - the draft supports the concept of p=
arent<->child mappings, but does not allow
for more complex energy topologies,

e.g. 2 circuits <-> 4 outlets <-> 4 Power Supplies <->
blade-chassis(info about chassis-draw, ps-draw)<->8 blades(info about blade=
/cpu-draw)
It is also not possible to "populate" the domain with information about the=
se mappings, e.g. I cannot tell

the domain that server1 is powered by pdu1, plugA and pud2, plugB.

Energy Control

*         non-discrete power-states are not supported -> Section 5.5. speci=
fies the possibility of mapping
"Manufacturer" Power States to the 12 Eman Power states, where there can be=
 more than 12 Manufacturer
Power States. However, in the context of power-capping of Servers we have a=
 "non-discrete" floating cap corresponding
to the Manufacturer Power State.
The Problem is that different Servers will have completely different ranges=
 of supported cap-values, e.g. Server 1 has a dynamic range of 300-500Watt,=
 Server2 has a range of 70-270Watts. Now let's assume Powerstate 9=3D400 Wa=
tts for Server1, but would be 170Watts for Server2. Which would mean I have=
 to specify a Mapping for each Server-Model.
It would be far more practical if it would be possible to supply a key-valu=
e-pair with a certain power-state in Case the
State needs context such as a power-cap, I would then specify a state of e.=
g. 7 and supply the desired Cap in the kvp-field.

General Stuff.

*         (Page 6) 3. Terminology
Energy Management System is introduced as EnMS later EMS is used (e.g. Page=
 7).

*         Generally
parent child relationship can lead to a delayed measurement, especially wit=
h multiple generations
e.g.  1. child measures every 5 minutes -> parent every 4 minutes, this wil=
l lead to different offsets in the readings

Best Regards,
David

JouleX
David Prantl
Solution Architect
(M) +49 172 5835887
www.jouleX.net

ENTERPRISE GREEN IT

Follow us:
Twitter @JouleXnet
JouleX on Facebook
LinkedIn Profile



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


Hello All,
 
my name i=
s David Prantl, working for JouleX as a Solution Architect. I am summarizin=
g
comments fro=
m myself and my colleagues Martin Paatz and Rene Seeber. We have an
Enterprise Energy Management Product and would like to comm=
ent on the latest
draft of the Energy Management Framework Draft – which we think i=
s a great foundation
for a standardized approach to Energy Management.
Comments as bullet points belo=
w:
 =

Energy Monitoring<=
o:p>
·       =
;  We are Glad that =
Energy Quality and Demand are available as optional Values as this permits<=
br>us – if available from Energy Managed Objects – to deliver h=
igh accuracy Readings (based on 
demand/total Energy delivered and not p=
oint measurements)
=
·   &nbs=
p;     The Integration of Battery Information is crucial for shaving off energy =
during peak demand periods-
it is good to know this is already integrate=
d, peak-demand handling is crucial in e.g. Japan.
 
Energy Managed Object Identification and Conte=
xt
Today there=
 are specifications for role/keyword/importance/category<=
/p>
·         The Keyword Concept for Grouping is e=
xtremely useful and has been integrated into our 
Software for arbitrary=
 Objects.
·     &nb=
sp;   The Conte=
xt Role (5.2.5) must specify more examples or rules on how the roles-tring =
should be populated,
e.g. contain standard definitions, otherwise they are only on=
e more keyword.
However, we appreciate this additional Information field, and woul=
d in fact encourage more of these – but
with clearly defined recom=
mendations in regards to content, see below.
<=
![if !supportLists]>·         energy topology information =
211; the draft supports the concept of parent<->child mappings, but d=
oes not allow
for more complex energy topologies, 
=

e.g. 2 circuits <-> 4 =
outlets <-> 4 Power Supplies <-> 
blade-chassis(info about c=
hassis-draw, ps-draw)<->8 blades(info about blade/cpu-draw)
It is =
also not possible to “populate” the domain with information abo=
ut these mappings, e.g. I cannot tell
the domain that server1 is powered by pdu1, =
plugA and pud2, plugB.
 
Energy Control
&mid=
dot;    &n=
bsp;    no=
n-discrete power-states are not supported -> Section 5.5. specifies the =
possibility of mapping 
“Manufacturer” Power States to the 1=
2 Eman Power states, where there can be more than 12 Manufacturer
Power =
States. However, in the context of power-capping of Servers we have a ̶=
0;non-discrete” floating cap corresponding
to the Manufacturer Pow=
er State.
The Problem is that different Servers will have completely dif=
ferent ranges of supported cap-values, e.g. Server 1 has a dynamic range of=
 300-500Watt, Server2 has a range of 70-270Watts. Now let’s assume Po=
werstate 9=3D400 Watts for Server1, but would be 170Watts for Server2. Whic=
h would mean I have to specify a Mapping for each Server-Model.
It would=
 be far more practical if it would be possible to supply a key-value-pair w=
ith a certain power-state in Case the 
State needs context such as a pow=
er-cap, I would then specify a state of e.g. 7 and supply the desired Cap i=
n the kvp-field.
 
Gene=
ral Stuff.
·     &n=
bsp;   (Page 6)=
 3. Terminology
Energy Management System is introduced as En=
MS later EMS is used (e.g. Page 7).
· &=
nbsp;       Generally
parent child relationship can le=
ad to a delayed measurement, especially with multiple generations
e.g.  1. child measures every 5 minutes -> parent every 4 min=
utes, this will lead to different offsets in the readings=

 
Best Regards,
David
 
JouleX<=
/span>
David Prantl
Solution Architect
(M) +49 172 5835887
www.jou=
leX.net
 
ENTERPRISE GREEN IT
 
Follow us:=

Twitter @JouleXnet
=
JouleX on Facebook
LinkedIn Profile<=
/span>
 
 
=

--_000_7B9BC0FC24CECF4A840DB64B5C5B77850975CCD93BQHEXMBOX2host_--

From bclaise@cisco.com  Sat Jul 23 15:18:05 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78C021F8BB5 for ; Sat, 23 Jul 2011 15:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.498
X-Spam-Level: 
X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8m1ebpmYg2z for ; Sat, 23 Jul 2011 15:18:05 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0626F21F8B97 for ; Sat, 23 Jul 2011 15:18:04 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6NM7QMK024655 for ; Sun, 24 Jul 2011 00:07:26 +0200 (CEST)
Received: from [10.82.212.16] (rtp-vpn4-1040.cisco.com [10.82.212.16]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6NM7Nux010479 for ; Sun, 24 Jul 2011 00:07:24 +0200 (CEST)
Message-ID: <4E2B461C.1020807@cisco.com>
Date: Sat, 23 Jul 2011 18:07:24 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: eman mailing list 
References: <4E1B3E98.5060902@cisco.com>
In-Reply-To: <4E1B3E98.5060902@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [eman] webex request?
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jul 2011 22:18:05 -0000

Dear all,

We haven't seen any requests for webex.
Hence no webex this time.

Regards, Benoit.
> Dear all,
>
> Does anybody plan to attend remotely the coming EMAN WG meeting?
> Note that jabber and the audio channel are available by default.
> Do you need more interactivity, i.e. a webex meeting, to be set up for 
> this meeting?
>
> Regards, Bruce and Benoit
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From bclaise@cisco.com  Sun Jul 24 12:08:15 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0875121F8ABE for ; Sun, 24 Jul 2011 12:08:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.504
X-Spam-Level: 
X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.094,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRSo59rpbHn6 for ; Sun, 24 Jul 2011 12:08:14 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 890A121F8A7E for ; Sun, 24 Jul 2011 12:08:13 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6OJ89VF027487 for ; Sun, 24 Jul 2011 21:08:09 +0200 (CEST)
Received: from [10.82.211.190] (rtp-vpn4-958.cisco.com [10.82.211.190]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6OJ854q020801; Sun, 24 Jul 2011 21:08:06 +0200 (CEST)
Message-ID: <4E2C6D95.3020806@cisco.com>
Date: Sun, 24 Jul 2011 15:08:05 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Patrick Grossetete 
References: <32987825.7.1299160553893.JavaMail.pgrosset@rcdn-vpn-client-10-89-5-119.cisco.com>
In-Reply-To: <32987825.7.1299160553893.JavaMail.pgrosset@rcdn-vpn-client-10-89-5-119.cisco.com>
Content-Type: multipart/alternative; boundary="------------010202080704020502000506"
Cc: eman@ietf.org
Subject: Re: [eman] draft-ietf-eman-requirements-00 review -> applicability statement draft
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jul 2011 19:08:15 -0000

This is a multi-part message in MIME format.
--------------010202080704020502000506
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear applicability draft authors,

Reading back the old EMAN email, I believe that Load shedding or 
Demand/Response should be mentioned in the EMAN applicability statement. 
Not specifically as use cases that EMAN should solve, but as use cases 
where EMAN could help.

Regards, Benoit (as a contributor)
> Benoit,
>
> I would say that services such as Load shedding or Demand/Response 
> should go as examples in the appropriate section such as
> Home Energy, Data Center,...
>
> Patrick
>
> ------------------------------------------------------------------------
> *From: *"Benoit Claise" 
> *To: *"Patrick Grossetete" 
> *Cc: *eman@ietf.org
> *Sent: *Thursday, March 3, 2011 2:22:22 PM
> *Subject: *Re: draft-ietf-eman-requirements-00 review
>
> Hi Patrick,
>
> Thanks for a lot for your review.
> See inline for one particular point.
>
>
>         Benoit,
>
>         Please, find my comments regarding
>         draft-ietf-eman-requirements-00. I wrote them while reading
>         the doc, so there is no priority order.
>
>         Best Regards
>         Patrick
>
>
>         - page 4-5, it should be added that environmental conditions
>         may also impact the potential reduction of power consumption.
>         There is often a link between
>         temperature/RH and power...for example, see ASHRAE
>         specifications for DataCenter (PUE and DCIE metrics). It may
>         also be noticed that side effects may occur.
>         For example, I have seen people increasing the temperature in
>         their datacenter to comply with PUE metric but in fact getting
>         fan speed increase on their servers
>         and leading to false conclusion of metrics since the power
>         consumption was seen as "good" for PUE computation. Clearly,
>         the capability to monitor
>         energy consumption of servers would have indicated that.
>
>         - page 5, monitoring energy consumption can also help to check
>         compliancy with mandates/regulations/recommendations such as
>         ASHRAE or NTIA
>
>         - page 6, I would have split this category as "servers and
>         hosts" already implement some power consumption metrics such
>         as IPMI on servers,
>
>         and new generation CPU offers different power state level .
>         Section 2 is incomplete if we don't introduce in the scenario,
>         services such as Demand/Response and Load Shedding which may
>         apply to different 2.x sections
>
> Right, we could add them as they will _influence _the different use 
> cases in
>       2.1  .  Scenario 1: Routers, switches, middleboxes, and hosts  . .6  
>       2.2.  Scenario 2: PoE sourcing equipment and PoE powered
>             devices  . . . . . . . . . . . . . . . . . . . . . . . . .7  
>       2.3  .  Scenario 3: Power probes and Smart meters  . . . . . . . .7  
>       2.4  .  Scenario 4: Mid-level managers . . . . . . . . . . . . . .7  
>       2.5  .  Scenario 5: Gateways to building networks  . . . . . . . .7  
>       2.6  .  Scenario 6: Home energy gateways . . . . . . . . . . . . .8  
>       2.7  .  Scenario 7: Data center devices  . . . . . . . . . . . . .8  
>       2.8  .  Scenario 8: Battery powered devices  . . . . . . . . . . .8  
>
> By influencing, I mean that the demand/response for policies in these use cases .
> However, I would not list demand/response at the same level as these use cases, as the section 2 introduction explains:
>
>
>     2. Scenarios and target devices
>
>
>     This section describes a selection of scenarios for the application
>     of energy management.  For each scenario a list of target devices is
>     given in the headline, for which IETF energy management standards are
>     needed.
>
> And the EMAN WG will not be solving the demand/response problem: it 
> will "just" produce one piece of the puzzle
>
> Regards, Benoit.
>
>
>         - page 8, section 2.7 - obviously not mentioning ASHRAE
>         recommendations (PUE/DCIE) is not acknowledging industry
>         standards for energy monitoring
>         in datacenters.
>
>         - page 9, section 3.2 - aggregation of energy data is really
>         what helps facility managers to understand where they could
>         save money.
>         in fact, there would be a need to discuss how aggregation can
>         be done. It could be as simple as monitoring all physical
>         distribution circuits
>         but could also be aggregated by categories such as
>         engineering/sales/marketing departments or
>         heating/cooling/IT/lights,...
>         To fully understand the consumption, you also need to define
>         the "aggregation point" to consider what is counted downstream
>         and upstream.
>         For example, data retrieved on a server or router will be a
>         portion of data retrieved on a smart plug connecting all these
>         devices which will be a portion
>         of data retrieved at a smart circuit breaker level, and so on.
>
>         - page 11, section 3.4.2, you could also indicate: line
>         frequency, power factor, apparent power, reactive power,... as
>         metrics being available on certain
>         category of devices.
>
>         - page 12, section 3.4.4, you may want to compare with
>         existing MIB such as UPS vendor's MIBs
>
>
>


--------------010202080704020502000506
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Dear applicability draft authors,

    

    Reading back the old EMAN email, I believe that Load shedding or
    Demand/Response should be mentioned in the EMAN applicability
    statement. Not specifically as use cases that EMAN should solve, but
    as use cases where EMAN could help.

    

    Regards, Benoit (as a contributor)

    

      
      
Benoit,

        

        I would say that services such as Load shedding or
        Demand/Response should go as examples in the appropriate section
        such as

        Home Energy, Data Center,...

        

        Patrick

        

        
From: "Benoit Claise"
        <bclaise@cisco.com>

        To: "Patrick Grossetete" <pgrosset@cisco.com>

        Cc: eman@ietf.org

        Sent: Thursday, March 3, 2011 2:22:22 PM

        Subject: Re: draft-ietf-eman-requirements-00 review

        

        Hi Patrick,

        

        Thanks for a lot for your review.

        See inline for one particular point.

        

          
          
          


            

               
              
              

                 
                
                
Benoit,

                  

                  Please, find my comments regarding
                  draft-ietf-eman-requirements-00. I wrote them while
                  reading the doc, so there is no priority order.

                  

                  Best Regards

                  Patrick

                   

                  

                  - page 4-5, it should be added that environmental
                  conditions may also impact the potential reduction of
                  power consumption. There is often a link between

                  temperature/RH and power...for example, see ASHRAE
                  specifications for DataCenter (PUE and DCIE metrics).
                  It may also be noticed that side effects may occur.

                  For example, I have seen people increasing the
                  temperature in their datacenter to comply with PUE
                  metric but in fact getting fan speed increase on their
                  servers

                  and leading to false conclusion of metrics since the
                  power consumption was seen as "good" for PUE
                  computation. Clearly, the capability to monitor

                  energy consumption of servers would have indicated
                  that.

                  

                  - page 5, monitoring energy consumption can also help
                  to check compliancy with
                  mandates/regulations/recommendations such as ASHRAE or
                  NTIA

                  

                  - page 6, I would have split this category as "servers
                  and hosts" already implement some power consumption
                  metrics such as IPMI on servers, 

              

            

            

              

                
and new generation CPU offers
                  different power state level .

                  Section 2 is incomplete if we don't introduce in the
                  scenario, services such as Demand/Response and Load
                  Shedding which may apply to different 2.x sections

                

              

            

          

        

        Right, we could add them as they will influence the
        different use cases in 

        
     2.1.  Scenario 1: Routers, switches, middleboxes, and hosts  . .  6
     2.2.  Scenario 2: PoE sourcing equipment and PoE powered
           devices  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Scenario 3: Power probes and Smart meters  . . . . . . . .  7
     2.4.  Scenario 4: Mid-level managers . . . . . . . . . . . . . .  7
     2.5.  Scenario 5: Gateways to building networks  . . . . . . . .  7
     2.6.  Scenario 6: Home energy gateways . . . . . . . . . . . . .  8
     2.7.  Scenario 7: Data center devices  . . . . . . . . . . . . .  8
     2.8.  Scenario 8: Battery powered devices  . . . . . . . . . . .  8



        
By influencing, I mean that the demand/response for policies in these use cases .
However, I would not list demand/response at the same level as these use cases, as the section 2 introduction explains:

2.  Scenarios and target devices

   This section describes a selection of scenarios for the application
   of energy management.  For each scenario a list of target devices is
   given in the headline, for which IETF energy management standards are
   needed.


        

        And the EMAN WG will not be solving the demand/response problem:
        it will "just" produce one piece of the puzzle

        

        Regards, Benoit.

        

          

            

              

                
 

              

            

            

              

                


                  - page 8, section 2.7 - obviously not mentioning
                  ASHRAE recommendations (PUE/DCIE) is not acknowledging
                  industry standards for energy monitoring

                  in datacenters.

                  

                  - page 9, section 3.2 - aggregation of energy data is
                  really what helps facility managers to understand
                  where they could save money.

                  in fact, there would be a need to discuss how
                  aggregation can be done. It could be as simple as
                  monitoring all physical distribution circuits

                  but could also be aggregated by categories such as
                  engineering/sales/marketing departments or
                  heating/cooling/IT/lights,...

                  To fully understand the consumption, you also need to
                  define the "aggregation point" to consider what is
                  counted downstream and upstream.

                  For example, data retrieved on a server or router will
                  be a portion of data retrieved on a smart plug
                  connecting all these devices which will be a portion

                  of data retrieved at a smart circuit breaker level,
                  and so on.

                  

                  - page 11, section 3.4.2, you could also indicate:
                  line frequency, power factor, apparent power, reactive
                  power,... as metrics being available on certain

                  category of devices.

                  

                  - page 12, section 3.4.4, you may want to compare with
                  existing MIB such as UPS vendor's MIBs

                

              

            

            

          

        

        

      

    

    

  


--------------010202080704020502000506--

From bclaise@cisco.com  Sun Jul 24 12:46:50 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F303521F88A1 for ; Sun, 24 Jul 2011 12:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.507
X-Spam-Level: 
X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoglDNvzaLO9 for ; Sun, 24 Jul 2011 12:46:49 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 31DEE21F8879 for ; Sun, 24 Jul 2011 12:46:49 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6OJkmY1002019 for ; Sun, 24 Jul 2011 21:46:48 +0200 (CEST)
Received: from [10.82.211.190] (rtp-vpn4-958.cisco.com [10.82.211.190]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6OJkh3x006849 for ; Sun, 24 Jul 2011 21:46:43 +0200 (CEST)
Message-ID: <4E2C76A3.90203@cisco.com>
Date: Sun, 24 Jul 2011 15:46:43 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: eman mailing list 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [eman] Meeting + Agenda + presentation
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, 24 Jul 2011 19:46:50 -0000

Dear all,

The meeting is Thursday at 17h40, in the ROOM 204B.
The agenda is posted at http://www.ietf.org/proceedings/81/agenda/eman.txt
Presenters, please send your ppt by Wednesday.

Regards, Benoit.

From bclaise@cisco.com  Sun Jul 24 13:20:32 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2F421F8785 for ; Sun, 24 Jul 2011 13:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.509
X-Spam-Level: 
X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTlly1VhvDzo for ; Sun, 24 Jul 2011 13:20:31 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 909B021F8783 for ; Sun, 24 Jul 2011 13:20:29 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6OKKRoR006239; Sun, 24 Jul 2011 22:20:28 +0200 (CEST)
Received: from [10.82.211.190] (rtp-vpn4-958.cisco.com [10.82.211.190]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6OKKO6r019888; Sun, 24 Jul 2011 22:20:25 +0200 (CEST)
Message-ID: <4E2C7E87.6060505@cisco.com>
Date: Sun, 24 Jul 2011 16:20:23 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Juergen Quittek 
References: <0131AC21C657A3418A5B6CA168C4C57E0A813EA6@USA7061MS04.na.xerox.net> <23E19EBD-1A1E-47AB-BA8F-47B8E919A2DE@quittek.at>
In-Reply-To: <23E19EBD-1A1E-47AB-BA8F-47B8E919A2DE@quittek.at>
Content-Type: multipart/alternative; boundary="------------090100010302080800070009"
Cc: eman@ietf.org, "Ebner, Fritz" 
Subject: Re: [eman] IETF EMAN request to address printers... -> draft-ietf-eman-requirements-04
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jul 2011 20:20:32 -0000

This is a multi-part message in MIME format.
--------------090100010302080800070009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Juergen,

Reading this old email, I believe that we should mention "printer" 
somewhere in the requirements draft, as a device type addressed by the 
EMAN WG, and not only in the appendix.

Regards, Benoit.
> Hi Fritz,
>
> Thank you for your input.
>
> We will consider printers and the document your referred to in the 
> next revision of the requirements.
> I don't think many changes will need to be made here.
>
> But for the MIB documents, we now have another set of PWG 
> power/functional states next to DMTF and ACPI states.
>
> Thanks,
>
>     Juergen
>
>
> Am 18.03.2011 um 19:11 schrieb Ebner, Fritz:
>
>> Hello,
>> Please make sure that any power control or monitoring MIBs or drafts 
>> that the EMAN WG produces can cover the use cases, power controls, 
>> and power monitoring features provided in the printer working group.  
>> Details are below:
>> The IEEE/ISTO Printer Working Group has published their Candidate 
>> Standard for Power Management and the associate protocol binding for 
>> SNMP.  Below are the links to the abstract model and MIB.
>> PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0:
>> The PWG Power Management Model for Imaging Systems 1.0 specification was
>> recently approved as a PWGCandidateStandardand is now available at:
>>
>> http://www.pwg.org/standards.html
>>
>> and
>>
>> ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf/ 
>> doc
>> PWG 5106-5 - PWG Imaging System Power MIB v1.0
>> The PWG Imaging System Power MIB v1.0 specification was recently approved
>> as a PWGCandidateStandardand is now available at:
>>
>> http://www.pwg.org/standards.html
>>
>> and
>>
>> ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf/ 
>> doc / mib
>>  - PDF, MS Word, and ASN.1 source in plaintext
>>
>> ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.pdf
>>  - ASN.1 source in color highlighted PDF
>> Thanks,
>> Fritz Ebner
>> _______________________________________________
>> 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


--------------090100010302080800070009
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Juergen,

    

    Reading this old email, I believe that we should mention "printer"
    somewhere in the requirements draft, as a device type addressed by
    the EMAN WG, and not only in the appendix.

    

    Regards, Benoit.

    
Hi Fritz,
      


      

      
Thank you for your input.

      


      

      
We will consider printers and the document your referred to
        in the next revision of the requirements.

      
I don't think many changes will need to be made here.

      


      

      
But for the MIB documents, we now have another set of PWG
        power/functional states next to DMTF and ACPI states.

      


      

      
Thanks,

      


      

      
    Juergen

      


      

      


        

          
Am 18.03.2011 um 19:11 schrieb Ebner, Fritz:

          

          

              

                

                  
Hello,

                  
Please
                    make sure that any power control or monitoring MIBs
                    or drafts that the EMAN WG produces can cover the
                    use cases, power controls, and power monitoring
                    features provided in the printer working group. 
                    Details are below:

                  
 

                  
The
                    IEEE/ISTO Printer Working Group has published their
                    Candidate Standard for Power Management and the
                    associate protocol binding for SNMP.  Below are the
                    links to the abstract model and MIB.

                  

                    
 

                  

                  
PWG 5106.4 - PWG
                      Power Management Model for Imaging Systems 1.0:

                  
 

                  

                    
The PWG
                      Power Management Model for Imaging Systems 1.0
                      specification was 

                      recently approved as a PWG Candidate Standard and is now
                      available at:

                      

                       http://www.pwg.org/standards.html

                      

                      and

                      

                       ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf / doc

                    
 

                  

                  
PWG 5106-5 - PWG
                      Imaging System Power MIB v1.0

                  
 

                  

                    
The PWG
                      Imaging System Power MIB v1.0 specification was
                      recently approved

                      as a PWG Candidate Standard and is now
                      available at:

                      

                       http://www.pwg.org/standards.html

                      

                      and

                      

                       ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf / doc /
                      mib

                       - PDF, MS Word, and ASN.1 source in plaintext

                      

                       ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.pdf

                       - ASN.1 source in color highlighted PDF

                  

                  
 

                  
Thanks,

                  
Fritz
                    Ebner

                

                _______________________________________________

                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


    

    

  


--------------090100010302080800070009--

From bclaise@cisco.com  Sun Jul 24 20:31:09 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709FC21F850B for ; Sun, 24 Jul 2011 20:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.511
X-Spam-Level: 
X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.087,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1LUAQ7SnohC for ; Sun, 24 Jul 2011 20:31:08 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 79C6721F84F6 for ; Sun, 24 Jul 2011 20:31:08 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6P3V7BI028553; Mon, 25 Jul 2011 05:31:07 +0200 (CEST)
Received: from [10.82.252.166] (rtp-vpn6-1186.cisco.com [10.82.252.166]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6P3V2Pa010473; Mon, 25 Jul 2011 05:31:03 +0200 (CEST)
Message-ID: <4E2CE376.8050504@cisco.com>
Date: Sun, 24 Jul 2011 23:31:02 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Juergen Quittek 
References: <4D9DE17D.5090606@cisco.com> <4D9F12FE.3080409@cisco.com> <20110408142048.GA81222@elstar.local> <4D9F1A5F.1030107@cisco.com> <20110408143107.GA81369@elstar.local> <4D9F26A0.20407@cisco.com> <20110408154839.GA81729@elstar.local> <4DA5BDDE.9060607@cisco.com> <20110413151728.GA32536@elstar.local> <4DA5BF04.8030204@cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040703020206020300000703"
Cc: "eman@ietf.org" 
Subject: Re: [eman] Do we need power state transition count and time in state?
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2011 03:31:09 -0000

This is a multi-part message in MIME format.
--------------040703020206020300000703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

I'm not sure what is the conclusion regarding this old email about "Do 
we need power state transition count and time in state?"
Currently, the EMAN requirements draft contains:


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

Is this the consensus on the mailing list?

Regards, Benoit.
> Am 13.04.2011 um 17:19 schrieb Russ White:
>>>>> I assume people find it important to know the percentage of time a
>>>>> device spends in a certain power state. Approximating this by active
>>>>> polling of the current state is pretty inefficient and inaccurate
>>>>> since you can miss state changes. If the device records the time spent
>>>>> in each state, you get a precise breakdown of the time spend in each
>>>>> power state between each poll, which means you can safely poll at a
>>>>> much lower frequency.
>>>> It seems like this should be put into an extension, rather than in the
>>>> base spec... Or as a device specific option (given we build the branches
>>>> of information we had discussed on list before).
>>> And the reason is?
>> Because this doesn't seem to be useful for all devices... And because we
>> should try and keep the MIB size down, with extensions, rather than
>> trying to bundle everything possible into the base MIB.
> What about having it in the same MIB, but making it optional to implement?
>
>      Juergen
>
>
>> :-)
>>
>> Russ
>>
>>
>>
>> -- 
>> riw@cisco.com :: CCIE :: CCDE ::<><  Grace Alone
>>
>> Belief is a wise wager. Granted that faith cannot be proved, what harm
>> will come to you if you gamble on its truth and it proves false? If you
>> gain, you gain all; if you lose, you lose nothing. Wager, then, without
>> hesitation, that He exists. Blaise Pascal
>>
>>
>> _______________________________________________
>> 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


--------------040703020206020300000703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Dear all,

    

    I'm not sure what is the conclusion regarding this old email about
    "Do we need power state transition count and time in state?"

    Currently, the EMAN requirements draft contains:

    

    
5.2.7.  Power state statistics

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

    Is this the consensus on the mailing list?

    

    Regards, Benoit.

    

      
Am 13.04.2011 um 17:19 schrieb Russ White:


      

        

        

          

            

              
I assume people find it important to know the percentage of time a
device spends in a certain power state. Approximating this by active
polling of the current state is pretty inefficient and inaccurate
since you can miss state changes. If the device records the time spent
in each state, you get a precise breakdown of the time spend in each
power state between each poll, which means you can safely poll at a
much lower frequency.


            

            
It seems like this should be put into an extension, rather than in the
base spec... Or as a device specific option (given we build the branches
of information we had discussed on list before).


          

          
And the reason is?


        

        
Because this doesn't seem to be useful for all devices... And because we
should try and keep the MIB size down, with extensions, rather than
trying to bundle everything possible into the base MIB.


      

      
What about having it in the same MIB, but making it optional to implement?

    Juergen




      

        
:-)

Russ



-- 
riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone

Belief is a wise wager. Granted that faith cannot be proved, what harm
will come to you if you gamble on its truth and it proves false? If you
gain, you gain all; if you lose, you lose nothing. Wager, then, without
hesitation, that He exists. Blaise Pascal


_______________________________________________
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


    

    

  


--------------040703020206020300000703--

From bclaise@cisco.com  Sun Jul 24 20:37:08 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B2C21F865E for ; Sun, 24 Jul 2011 20:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Level: 
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.084,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3maQgk0r9pBV for ; Sun, 24 Jul 2011 20:37:06 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2814421F8610 for ; Sun, 24 Jul 2011 20:37:06 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6P3b5TD029243 for ; Mon, 25 Jul 2011 05:37:05 +0200 (CEST)
Received: from [10.82.252.166] (rtp-vpn6-1186.cisco.com [10.82.252.166]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6P3b44Z012982 for ; Mon, 25 Jul 2011 05:37:04 +0200 (CEST)
Message-ID: <4E2CE4DF.3030207@cisco.com>
Date: Sun, 24 Jul 2011 23:37:03 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: eman mailing list 
References: <4DD55310.7050904@cisco.com>
In-Reply-To: <4DD55310.7050904@cisco.com>
X-Forwarded-Message-Id: <4DD55310.7050904@cisco.com>
Content-Type: multipart/mixed; boundary="------------050306090404010808040502"
Subject: [eman] Fwd: ODVA feedback on the requirements draft -> applicability statement
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, 25 Jul 2011 03:37:08 -0000

This is a multi-part message in MIME format.
--------------050306090404010808040502
Content-Type: multipart/alternative;
 boundary="------------040704010508030902050606"


--------------040704010508030902050606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Applicability Statement Authors,

Can you please make sure that you include some "Industrial Automation" 
in the scenarios and/or target devices

Regards, Benoit.
-------- Original Message --------
Subject: 	[eman] ODVA feedback on the requirements draft
Date: 	Thu, 19 May 2011 19:27:44 +0200
From: 	Benoit Claise 
To: 	eman mailing list 
CC: 	Katherine Voss 



Dear all,

With permission from the authors, I'm forwarding feedback on the 
"Requirements for Energy Management (draft-ietf-eman-requirements-01)." 
from the two ODVA SIG co-chairs.

Regards, Benoit.

_Overall _

A very good effort. We mutually believe that the efforts of ODVA CIP 
Energy SIG and the IETF are parallel and touch each other at important 
points. It

would be beneficial to each party to cross-pollinate.

_In Specific_

1.Introduction: The addition of a bullet point enumerating "Industrial 
Networks" as a network type that the IETF EMAN standards could be 
applied to would be appropriate.

2.Section 2:  Perhaps the IETF might consider an additional scenario for 
industrial control systems and EMS.Industrial EMS tend to be more unique 
and customized to an application than commercial building EMS, which 
tends to be pretty standardized and configurable. A bi-directional 
gateway would allow coordination so that, for instance, a network EMS 
would not reduce network data rates when an industrial control system is 
doing a lot of hi-speed I/O comms. An industrial system could 
communicate low energy stets (breaks, downtimes, system restorations) to 
the network EMS to optimize energy usage without inadvertently 
constraining otherwise independent systems. I believe the best results 
will be obtained with independent but collaborative systems to manage 
energy in the network, building and industrial control domains. Sharing 
best practices between the domains is always a good thing.

3.Section 2.2, line 3:  (nitpicky comment) I think they meant PoE rather 
than PoW in line 3 of 2.2.

4.Section 2.5, scenario 5:  I see value in a bi-directional link between 
a network EMS and a building EMS. There may be times the building mgmt 
system needs the network at high performance. There may be times when 
the network infrastructure needs the BMS at high functionality. I see 
less call for building EMS functions to be performed by a network EMS.

5.Section 3.4.3: a more current standard for power quality is EN 50160.

6.The recommendation to use the accuracy classes in IEC 61850 is of 
interest. (But) It doesn't really apply to the industrial domain.


--------------040704010508030902050606
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
    
    
  
  
    Dear Applicability Statement Authors,

    

    Can you please make sure that you include some "Industrial
    Automation" in the scenarios and/or target devices

    

    Regards, Benoit.

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

      
        

          Subject: 
          [eman] ODVA feedback on the requirements draft
        

        

          Date: 
          Thu, 19 May 2011 19:27:44 +0200
        

        

          From: 
          Benoit Claise <bclaise@cisco.com>
        

        

          To: 
          eman mailing list <eman@ietf.org>
        

        

          CC: 
          Katherine Voss <kvoss@odva.org>
        

      
    

    

    

    
    
     Dear all,

    

    With permission from the authors, I'm forwarding feedback on the
    "Requirements for Energy Management
    (draft-ietf-eman-requirements-01).” from the two ODVA SIG co-chairs.

    

    Regards, Benoit.

    

      

      
 

      
      
Overall  

      
A very good effort. We mutually believe
        that the efforts of ODVA CIP Energy SIG and the IETF are
        parallel and touch each other at important points. It

      
would be beneficial to each party to
        cross-pollinate.

      
In Specific

      
1.  Introduction:

        The addition of a bullet point enumerating "Industrial Networks"
        as a network type that the IETF EMAN standards could be applied
        to would be appropriate.

      
2.  Section

        2:  Perhaps the IETF might consider an additional scenario for
        industrial control systems and EMS.Industrial EMS tend to be
        more unique and customized to an application than commercial
        building EMS, which tends to be pretty standardized and
        configurable. A bi-directional gateway would allow coordination
        so that, for instance, a network EMS would not reduce network
        data rates when an industrial control system is doing a lot of
        hi-speed I/O comms. An industrial system could communicate low
        energy stets (breaks, downtimes, system restorations) to the
        network EMS to optimize energy usage without inadvertently
        constraining otherwise independent systems. I believe the best
        results will be obtained with independent but collaborative
        systems to manage energy in the network, building and industrial
        control domains. Sharing best practices between the domains is
        always a good thing.

      
3.  Section

        2.2, line 3:  (nitpicky comment) I think they meant PoE rather
        than PoW in line 3 of 2.2.

      
4.  Section

        2.5, scenario 5:  I see value in a bi-directional link between a
        network EMS and a building EMS. There may be times the building
        mgmt system needs the network at high performance. There may be
        times when the network infrastructure needs the BMS at high
        functionality. I see less call for building EMS functions to be
        performed by a network EMS.

      
5.  Section

        3.4.3: a more current standard for power quality is EN 50160.

      
6.  The

        recommendation to use the accuracy classes in IEC 61850 is of
        interest. (But) It doesn't really apply to the industrial
        domain.

      
 

    

  


--------------040704010508030902050606--

--------------050306090404010808040502
Content-Type: text/plain;
 name="Attached Message Part"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Attached Message Part"

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


--------------050306090404010808040502--

From ietf@quittek.at  Sun Jul 24 21:11:40 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6393921F853A for ; Sun, 24 Jul 2011 21:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.752
X-Spam-Level: 
X-Spam-Status: No, score=0.752 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, GB_SUMOF=5, HELO_EQ_DE=0.35, 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 jrHCALeD8TSR for ; Sun, 24 Jul 2011 21:11:36 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id E490F21F852C for ; Sun, 24 Jul 2011 21:11:34 -0700 (PDT)
Received: from [172.16.53.213] ([207.96.251.20]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Mg2LJ-1R6JrY2qZR-00NI8g; Mon, 25 Jul 2011 06:11:33 +0200
From: Juergen Quittek 
Content-Type: multipart/alternative; boundary=Apple-Mail-2-399922643
Message-Id: 
Date: Mon, 25 Jul 2011 00:11:27 -0400
To: "eman@ietf.org list" 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:ZynzmCMUo4KVNnxKbILihRw+4vX69F1r7SE6RNDEJ/J jpawT9rM57KLrUb5rIYtcl8zq1U3kvB/etHNy2orOFEFA2hcC7 kHU+bF1goY2TjdsQ8uImph7+2gjn/NQY3HuZx6ucoyOiJ0oz+E y5xM7lAr2aryPXnDl81TgYqJVywivh4+HIAy9RLoROhIxYJ7+S rdLSMRrjjLi/Nu3I3a+QsvUBZBUGNvg+dXsezYSeVM=
Subject: [eman] comments on draft-ietf-eman-framework-02, part 1
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, 25 Jul 2011 04:11:40 -0000

--Apple-Mail-2-399922643
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Dear all,

Attached please find my comments on sections 1-3 of the framework draft =
version -02.=20
Comments on the remaining sections will follow in separate emails.

 [snip]
>                          Energy Management Framework=20
>                         draft-ietf-eman-framework-02=20
 [snip]
>      Abstract=20
>=20
>         This document defines a framework for providing Energy=20
>         Management for devices within or connected to communication=20
>         networks.  The framework defines a domain of Energy Management=20=

>         devices that is a logical unit of Energy Management. Within a=20=


This is difficult to parse: "A domain of devices is a unit of energy =
management"?

>         domain each device is identified, classified and given =
context.  =20
>         Devices can be monitored and/or controlled with respect to=20
>         power, power state, energy, demand, electrical quality, and=20
>         battery.  Additionally the framework models relationships and=20=

>         capabilities between devices in a domain.  =20
>         =20
>         =20
>         TO DO/OPEN ISSUE=20
>         - IPFIX or not? Initially IPFIX was mentioned in [EMAN-REQ],=20=

>         then we see now: "A solution for this is that the concerned=20
>         entity or another entity closely interacting with the =
concerned=20
>         entity collect time series of power values and make them=20
>         available via push or pull mechanisms to receivers of the=20
>         information.". So, the questions are: Is IPFIX a requirement? =20=

>         What other mechanism do we have to PUSH time series of power=20=

>         values (no, SNMP notifications are not suitable)? So should we=20=

>         or not include IPFIX in this document?=20

PUSH mode is a requirement for time series of measurements.=20
Whether IPFIX is the only protocol that can do so in the right way
is not a question of requirements. If the framework brings arguments
why IPFIX is the best choice, it should include IPFIX as solution.=20
Otherwise, it still may include IPFIX as candidate protocol for PUSH =
mode.

>         - Power Monitor has been renamed to Energy Managed Object. Get

I don't think that this is a good choice.
"Managed Object" is the term specified to be used for objects defined in =
MIB modules.
"Energy Managed Objects" sounds like a kind of MIB objects.
 =20
>           consensus on the terminology. Another example is Power=20
>           Quality=20

I think the term power quality is the right term and we should easily =
find an agreed definition.=20
We just should avoid applying it to things that are not related to power =
quality.
        =20
>      1. Introduction=20
>=20
>         Network management is divided into the five main areas defined=20=

>         in the ISO Telecommunications Management Network model: Fault,=20=

>         Configuration, Accounting, Performance, and Security =
Management=20
>         (FCAPS).   Absent from this management model is any=20

I would add ITU X.700 as reference for FCAPS.

>         consideration of Energy Management, which is now becoming a=20
>         critical area of concern worldwide as seen in [ISO50001]. =20
>         =20
>         This document defines a framework for providing Energy=20
>         Management for devices within or connected to communication=20
>         networks.  The framework describes how to identity, classify =
and=20

identity -> identify

>         provide context for a device in a communications network from=20=

>         the point of view of Energy Management.  =20
>         =20
>         The identified device can then be monitored for Energy=20
>         Management by obtaining measurements for power, energy, demand=20=

>         and electrical quality.  If a device contains a battery(s) the=20=

>         characteristics and performance of the battery(s) can also be=20=

>         managed.  A device's state can be monitored or controlled by=20=

>         providing an interface expressed as one or more Power State=20
>         Sets.  The most basic example of energy management is a single=20=

>         device reporting information about itself.  However, in many=20=

>         cases, energy is not measured by the device itself, but by a=20=

>         meter located upstream in the power distribution tree.  An=20
>         example is a power distribution unit (PDU) that measures =
energy=20
>         consumption of attached devices and may report this to an =
Energy=20
>         Management System.  Therefore, devices are recognized as =
having=20
>         relationships to other devices in the network from the point =
of=20
>         view of Energy Management.  These relationships include=20
>         Aggregation, Metering, Power Source(s), Proxy, and Dependency. =
=20
>      =20
>                             =20
>      1.1. Energy Management Document Overview=20
>=20
>      =20
>         The EMAN standard provides a set of specifications that =
together=20
>         provide Energy Management.  This document specifies the=20

Specifications do no never provide energy management.

>         framework, per the Energy Management requirements specified in=20=

>         [EMAN-REQ]=20
>         =20
>         The applicability statement document [EMAN-AS] provides a list=20=

>         of use cases, cross-reference between existing standards and =
the=20
>         EMAN standard, and shows how the this relates to other=20
>         frameworks.=20
>         =20
>         The [EMAN-AWARE-MIB] provides objects for addressing=20

provides -> specifies or defines

>         identification, classification, context information, and=20
>         relationships form the point of view of Energy Management.=20
>                           =20
>         The Power and Energy Monitoring MIB [EMAN-MON-MIB] contains =20=

>         objects for monitoring of Power, Energy, Demand, Electrical=20
>         Quality and Power State Sets.=20
>         =20
>         Definition of Managed Objects for Battery Monitoring [EMAN-
>         BATTERY-MIB] defines managed objects that provide information =
on=20
>         the status of batteries in managed devices.=20
>      =20
>         EDITOR'S NOTE: [EMAN-MON-MIB] and [EMAN-AS] are not EMAN =
working=20
>         group documents.  Hence, these references will be changed in =
the=20
>         future.=20
>         =20
>      2. Requirements & Use Cases =20
>=20
>         Requirements for power and energy monitoring for networking=20
>         devices are specified in [EMAN-REQ].  The Energy Management =
use=20
>         cases covered by this framework are covered in the EMAN=20
>         applicability statement document in [EMAN-AS].  Typically=20
>         requirements and use cases for communication networks cover =
the=20
>         devices that make up the communication network and endpoints. =20=

>         =20
>         With Energy Management, there exists a wide variety of devices=20=

>         that may be contained in the same deployments as a =
communication=20
>         network but comprise a separate facility, home, or power=20
>         distribution network. =20
>         =20
>         For example, target devices for this specification can include=20=

>         (but are not limited to):

I am not sure it makes sure having this list.=20
It is always incomplete. I would rather state that
"Target devices for the energy management framework are all devices that =
can directly or indirectly be monitored or controlled by an energy =
management system using the Internet protocol."

> =20
>             - Simple electrical appliances / fixtures =20
>             - Hosts, such as a PC or a datacenter server=20

"a PC or a datacenter server"
--> a PC, a datacenter server, or a printer"

>             - Routers =20
>             - Switches=20
>             - Switches with line card components =20
>             - Power over Ethernet (PoE) endpoints,=20
>             - Power Distribution Units (PDU) =20
>             - Protocol gateways devices for Building Management =
Systems=20
>         (BMS)=20
>             - Electrical Meters=20
>             - Sensor controllers with subtended sensors=20
>      =20
>         There may also exist varying protocols deployed among these=20
>         parallel networks. =20

To what does "these parallel networks" refer?

>         For an Energy Management framework to be useful, it should =
also=20
>         apply to these types of separate networks as they connect and=20=

>         interact with a communications network. =20
>         =20
>      =20
>         =20
>      3. Terminology=20

There is a section 4 titled "Energy Management Reference Model". But =
actually, most of the model's fundamentals are only explained in this =
terminology section. I don't think this is a good structure and I don't =
think this is sufficient. Basic concepts, such as the Energy Managed =
Object, the EMO relationships should be elaborated in section 4.

>=20
>         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL=20=

>         NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and=20
>         "OPTIONAL" in this document are to be interpreted as described=20=

>         in RFC 2119 [RFC2119].=20
>         =20
>         This section contains definitions of terms used throughout =
this=20
>         specification. Defined terms have their first letter=20
>         capitalized.  Entities, relationships and or capabilities are=20=


I am not in favor of the capitalization of terms.
Particularly for terms such as "energy", "power", "demand" which we are =
using fully in line with their common meaning it appears to be very =
confusing for a reader when (s)he needs to think: "Is capitalized =
"Energy" anyhow different from lower case "energy"?

>         defined with respect to well known software patterns as=20
>         described in [GAMMA] and [EIPATT]=20

Why this? IMHO definitions for entities and relationships are better =
taken from standards (for example UML) than from books written by =
individual authors. The books referred to above may be useful when =
design patterns are used. But I do not see any of their design patterns =
being relevant for a standards on energy management, at least not more =
that for standards for IP traffic management and control where these =
books hardly appear as references in standards documents.
     =20
>=20
>         Energy Management System (EnMS)=20
>         =20
>         An EnMS is a set of systems or procedures upon which=20
>         organizations can develop and implement an energy policy, set=20=

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

>         related to energy use.  An EnMS allows organizations to =
improve=20
>         energy performance and demonstrate conformity to requirements,=20=

>         standards and/or legal requirements.  This definition is in =
line=20
>         with the definition of "Energy management systems - =
Requirements=20
>         with guidance for use" [ISO50001].=20

Wouldn't it be better to explicitly mention monitoring and control of =
energy consumption?
        =20
>=20
>         With respect to communication networks these same goals will=20=

>         apply to the communications networks and attached devices =
within=20
>         an organization.=20

I would remove this paragraph. Either the first paragraph obviously =
applies already to communications networks or we need to change it.
>         =20
>         Energy Management=20
>         =20
>         Energy Management is a set of functions for measuring, =
modeling,=20
>         planning, and optimizing networks to ensure that the network=20=

>         elements and attached devices use energy efficiently and is=20

I disagree. Even if I don't like it, I would not limit energy management =
systems to the ones that ensure energy efficiency. Energy management =
deals with assessing and influencing the consumption of energy. This is =
independent from an objective of ensuring energy efficiency.
=20
>=20
>         appropriate for the nature of the application and the cost=20
>         Management is a system congruent to any of FCAPS area of=20
>         management in the ISO/OSI Network Management Model [TMN] =
Energy=20
>         Management for communication networks and attached devices is =
a=20

"is a" --> "may be"

>         subset or part of an organization's greater EnMS.=20

This is confusing, because it is completely different from the =
definition of EnMS
Why is energy management not
    "developing and implementing an energy policy,=20
     setting targets, action plans and taking into account=20
     legal requirements related to energy use."
?
This would be consistent with the EnMS definition above.
>         Energy Management Systems =20

This is confusing. The same term with different acronym was already =
defined above.=20
        =20
>         An Energy Management System (EMS) is congruent to a Network=20

EMS --> EnMS

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

>         software used to administer a network with the primarily =
purpose=20
>         being Energy Management.=20

This paragraph needs to be merged with the previous definition of the =
term.=20

>         =20
>         Energy Monitoring=20
>         =20
>         Energy Monitoring is a part of Energy Management that deals =
with=20
>         collecting or reading measurements from devices to aid in =
Energy=20
>         Management.  This could include Energy, Power, Demand, =
Quality,=20
>         Context and/or Battery information.=20
>         Energy=20
line to be deleted

>         Energy =20
>         =20
>         Energy is the capacity of a system to produce external =
activity=20
>         or perform work and can be electricity, fuels, steam, heat,=20
>         compressed air, and other like media. Energy is typically=20

This is certainly not taken from an IEEE or IEC dictionary:=20
Energy is not steam, it is not fuel, it is not compressed air.
Let's take text from a dictionary.

>         expressed in watt hours or joules. =20

can we restrict EMAN to electrical energy and power?
        =20
>         Power=20
>         =20
>         Power is a rate of energy conversion.  As the unit of time=20
>         approaches zero a power measurement is called an instantaneous=20=

>         power reading.  Typically when implementing Power monitoring =
in=20
>         hardware, a measuring device may have to compute an average=20
>         value per some unit of time to express a reading to =
approximate=20
>         an instantaneous power measurement.=20

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

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


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

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

>         of time and typically expressed in kilowatt hours.  This=20
>         measurement is significant because some utilities or energy=20

remove "This measurement is significant because"

>         providers bill by Demand measurements as well as for maximum=20=

>         Demand per billing periods.  Power values may spike during=20
>         short-terms by devices, but Demand measurements recognize that=20=

>         maximum Demand does not equal maximum Power during an =
interval.=20
>         =20
>         Power Quality=20
>         =20
>         EDITOR'S NOTE: This may be rephrased as Electrical=20
>         Characteristics.=20

Electrical characteristics seems to better match what the term has been =
used for in some drafts.
But the term power quality should still be here to refer to properties =
that are usually called so.

>         Power Quality is defined as a set of values to describe the=20
>         electrical characteristics of Power as provided by an =
electrical=20
>         source as seen by the Energy Managed Object.  For example: AC=20=

>         phase, apparent and reactive power, etc.=20

Yes. Phase, apparent and reactive power are not typical power quality =
issues. Power quality issues include the deviation of actual voltage =
from nominal/design voltage, the deviation of AC frequency from the =
nominal frequency, harmonic distortions, etc.
>         =20
>         Energy Control=20
>         =20
>         Energy Control is a part of Energy Management that deals with=20=

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

>         order to optimize or ensure its efficiency.=20

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

What woud be the difference between modifying and setting a state? I =
don't make a suggestion for an alternative here. We should put ALL terms =
on the mailing list and discuss them until we reach something that comes =
closer to a reasonable definition.

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

>         attached to a communications network that is monitored,=20
>         controlled, or aids in the management of another device for=20
>         Energy Management. =20

Two issues:=20
1. the term "managed object" is already in common use for the objects =
defined in a MIB module. Since we are also defining MIB modules, we will =
run into ambiguities and risk confusion of readers if we re-use the term =
here.
2. The attribute "managed" is confusing, because the term refers also to =
"unmanaged" objects that are neither monitored or controlled, but just =
"aid" in the management of other devices. These seem to be rather =
"managing" objects than "managed" objects.

>         Energy Aware Object =20
>         =20
>         An Energy Managed Object may not have the capability to =
provide=20
>         information necessary for Energy Management itself. If an =
Energy=20
>         Managed Object can provide Energy Management Context, Energy=20=

>         Monitor and optionally Energy Control values for itself then =
the=20

Monitor --> Monitoring

>         Energy Managed Object is said to be an Energy Aware Object=20

I don't see good reasons for using the term energy awareness. IPFIX did =
all its specifications well without ever needing the term flow-awareness =
and the SNMP Interface MIB module never needed the term packet-awareness =
for interfaces that meter bytes and packets.

BTW, I wonder why a device that only reports its energy consumption is =
not called energy-aware.
It is only called energy-aware if it can also report its energy context. =
Why is this so?

My strongest concern is the following. What I would call energy aware =
would be a device that not just reports on its energy consumption, but =
rather tries to optimize its energy consumption by its own control =
logic, for example a TV sets that switches of the screen when its =
sensors indicates that the last watchers has left the room. If this TV =
should be called energy-aware even if it does not report anything to any =
management system.

I strongly suggest either to replace the term "energy aware" by "energy =
reporting" or something similar, or better, not to use the term at all. =
We don't need it.

>         For example: as the most simplistic example, a set of light=20
>         bulbs where all values are provided by an EMS through =
estimation=20
>         and or catalogue information are not Energy Aware. In contrast =
a=20
>         set of network switches that can report the same information=20=

>         based upon hardware sensing is said to be Energy Aware.=20

Would you also call it energy aware if the device can report its energy =
information only using a non-IP protocol?
        =20
>         Energy Managed Object Identification=20
>         =20
>         Energy Managed Object Identification is a set of attributes =
that=20
>         enable an Energy Managed Object to be: uniquely identified =
among=20
>         all Energy Management Domains; linked to other systems;=20

Among all domains?=20
This means globally unique.=20
Do you really mean this?=20
Do we need this?

What means "linked to other systems"?=20

>         classified as to type model and or manufacturer.=20

I do think it is impossible to invent a type of identifier that enables =
all kinds of energy managed objects to derive their type model and =
manufacturer from it. This is particularly difficult for devices that do =
not have a particular or model type model or manufacturer that is =
registered somewhere.

>         RFC EDITOR'S: the uniqueness must be clarified in [EMAN-REQ]=20=

>          =20
>         Energy Managed Object Context=20
>         =20
>         Energy Managed Object Context is a set of attributes that =
allow=20
>         an Energy Management system to classify the use of the Energy=20=

>         Managed Object within an organization.  The classification=20
>         contains use and/or ranking of the Energy Managed Object as=20
>         compared to other Energy Managed Objects in the Energy=20
>         Management Domain.=20

Just questions:=20
Are there already standards defining contexts of devices?
Or is this something new?=20
Is IANA maintaining a list of standardized contexts?
Are we planning to establish one?=20
Or is a context just a string with arbitrary content?
         =20
>=20
>         Energy Management Domain=20
>         =20
>         An Energy Management Domain is a name or name space that=20

If a domain were a name, we could call it name.
A domain is not a name. It may have one.

>         logically groups Energy Managed Objects into a zone of Energy=20=

>         Management.  Typically, this zone will have as members all=20

What is a zone of energy management?=20
Is it different in any way from a domain?

>         Energy Managed Objects that are powered from the same =
electrical=20
>         panel(s) for which there is a meter or sub meter.

What is a sub meter?=20
What would be the difference between having a meter or a sub meter at a =
panel?
 =20
>=20
>         For example: All Energy Managed Objects drawing power from the=20=

>         same distribution panel with the same AC voltage within a=20
>         building, or all Energy Managed Objects in a building for =
which=20
>         there is one main meter, would comprise an Energy Management=20=

>         Domain. =20

I would not use this example over five lines of text in the definition. =
It should be rather mentioned when the trem is explained in the =
description of the reference model.
> =20
>         =46rom the standpoint of Energy Management, it is useful to =
report=20
>         Energy as the sum of the Energy of all the Energy Managed=20
>         Objects within an Energy Management Domain and then correlate=20=

>         that value with metered values. =20

The same for this use case: It belongs to the description of the =
reference model.
        =20
>=20
>         Energy Managed Object Relationships=20
>         =20
>         Energy Managed Objects may have functional relationships to =
each=20
>         other within an Energy Management Domain.  The functional=20

Can't this be cross domain?
In our company, we have fuse cabinets equipped with power meters that =
have up to eight current claps and measure power for up to eight power =
distribution trees. Is the meter than member of all eight domains
at the same time because it measures in them. Note that the meter is =
powered by just one of the distribution trees or be neither of them.
Another case would be an energy management system that uses different =
domains for servers, PCs, phones, and switches. Still, a switch should =
be able to power a phone cross domain using PoE.

>         relationships include Aggregation, Metering, Power Source(s),=20=

>         Proxy, and Dependency.  One device will provide a capability =
or=20
>         functional value in the relationship and another will be the=20=

>         receiver of the capability.  These capabilities include

I do not understand why a PDU metering its output provides a capability?
Even less do I understand why a device (host, switch, light bulb) for =
which power is measured would receive any capability when this is done.

>         Aggregation, Metering, Power Source, Proxy and Dependency. =20

Which capability is provided in the dependency relationship?

>         Aggregation Relationship=20
>      =20
>         An Energy Managed Object may aggregate the Energy Management=20=

>         information of one or more Energy Managed Objects and is=20
>         referred to as an Aggregation Relationship.  An Energy Managed=20=


The previous paragraph stated that objects may HAVE relations ships. =
This paragraph states that an object IS REFERRED TO  as relationship. =
This is not consistent.
=20
>         Object may be aggregated by another Energy Managed Object(s). =20=

>         Aggregate values are obtained by reading values from multiple=20=

>         Energy Managed Objects and producing a single value of more=20

I think it does not need to be just a single value. It can be multiple.
The definition should not focus on the number of values. A good =
indicator for an aggregation action is the presence of operations on =
multiple given values. Whether the operation(s) produce one or more =
values is not highly relevant for the definition.

>         significant meaning such as average, count, maximum, median,=20=


I would not limit aggregation to operations generating values with more =
significant meanings. Even if the meaning is less significant, it still =
should be called aggregation.

>         minimum, mode and most commonly sum. =20
>         =20
>         Metering Relationship=20
>         =20
>         An Energy Managed Object may measure the Energy of another=20
>         Energy Managed Object(s) and is referred to as a Metering=20

I think it is important for the EnMS to distinguish two cases: A meter =
measures the energy of individual EMOs separately, or it measures just =
the accumulated energy and power for these devices, for example in the =
fuse cabinet.In the latter case, information on individual EMOs would =
not be available. This is a significant qualitative difference and =
should be modeled.

>         Relationship.  An Energy Managed Object may be metered by=20

Again, "the EMO is referred to as metering relationship" does not seem =
to be what is intended to b said.

>         another Energy Managed Object(s).  Example: a PoE port on a=20

Remove second sentence. It is redundant. Or use the following =
replacement:
"another Energy Managed Object(s)" --> "multiple Energy Management =
Objects and a single EMO may meter multiple other EMOs."


>         switch measure the Power it provides to the connected Energy=20=

>         Managed Object.=20

Why is this "providing a service to the powered EMO"?
It is providing a service to the EnMS and obviously not to the EMO that =
may not even have an information on whether or not the measurement is =
performed. The powered EMO does not ask for such a service. The EnMS =
does. In my view. The PoE switch measures at its output and provides =
this information to the EnMS. The EMS is the free to use this =
information also as power information for the powered EMO.

>         Power Source Relationship=20
>         =20
>         An Energy Managed Object may be the source of or distributor =
of=20
>         power to another Energy Managed Object(s) and is referred to =
as=20
>         a Power Source Relationship.  An Energy Managed Object may be=20=

>         powered by another Energy Managed Object(s).  Example: a PDU=20=


"another Energy Managed Object(s)" --> "multiple Energy Management =
Objects and a single EMO may power multiple other EMOs."

>         provides power for a connected host.=20
>         =20
>         Proxy Relationship=20
>         =20
>         An Energy Managed Object that provides Energy Management=20
>         capabilities on behalf of another Energy Managed Object so =
that=20
>         is appears to be Energy Aware is referred to a Proxy=20

What sense would it make to have another object appear to be energy =
aware? Fooling the EnMS?
Whether or not an EMO is energy aware should be completely independent =
from whether or not there is a proxy for it. And it should be possible =
to have a proxy relationship without pretending an unaware device to be =
aware.

>         Relationship.  An Energy Managed Object may be proxied by=20
>         another Energy Managed Object(s).  Example: a protocol =
gateways=20

"another Energy Managed Object(s)" --> "multiple Energy Management =
Objects and a single EMO may proxy multiple other EMOs."

>         device for Building Management Systems (BMS) with subtended=20
>         devices. =20
>                   =20
>         Dependency Relationship=20
>         =20
>         An Energy Managed Object may be a component of or rely=20
>         completely upon another Energy Managed Object to operate and =
is=20
>         referred to as a Dependency Relationship.  An Energy Managed=20=

>         Object may be dependent on another Energy Managed Object(s). =20=

>         Example: A Switch chassis with multiple line cards=20

This is very foggy.=20
What is the meaning of "rely completely upon another EMO to operate"?
Is a server in a datacenter completely dependent on the firewall(s) that =
connect the datacenter with the Internet? With a switched off firewall, =
the server cannot provide any service thus not operate.
How shall we detect all those dependencies. Wouldn't they be subject to =
dynamic changes?

>         =20
>         Energy Managed Object Parent=20
>      =20
>         An Energy Managed Object Parent is an Energy Managed Object =
that=20
>         provides one or more of the Energy Managed Object =
Relationships=20
>         capabilities.=20

I don't think that in the case of dependency, a capability is provided =
to a EMO.=20
Neither in the case of metering.
>         =20
>         Energy Managed Object Child=20
>         =20
>         An Energy Managed Object Child is an Energy Managed Object =
that=20
>         has at least one Energy Managed Object Relationship capability=20=

>         provided by another Energy Managed Object.  =20

see previous comment.
>         =20
>         Power State=20
>         =20
>         A Power State is a way to classify a Power setting on an =
Energy=20

A power state is not a way.

>         Managed Object (e.g., on, off, or sleep).  A Power State can =
be=20
>         viewed as a method for Energy Control=20

A power state should not be viewed as a method for power control. It is =
a state, not a method.
        =20
>         Manufacturer Power State=20
>         =20
>         A Manufacturer Power State is a device-specific way to =
classify=20
>         a Power setting implemented on an Energy Managed Object.

See power state.
>   =20
>         Power State Set=20
>         =20
>         A collection of Power States that comprise one named or =
logical=20
>         grouping of control is a Power State Set.  For example, the=20
>         states {on, off, and sleep} as defined in [IEEE1621], or the =
16=20
>         power states as defined by the [DMTF] can be considered two=20
>         different Power State Sets.=20

We should add that a power state set implemented on a device MUST at all =
times have exactly one=20
state that the device is in.

>         Nameplate Power=20
>         =20
>         The Nameplate Power is the maximal (nominal) Power that a =
device=20
>         can support.  This is typically determined via load testing =
and=20

remove "specified via load testing and is"

>         is specified by the manufacturer as the maximum value required=20=

>         to operate the device.  This is sometimes referred to as the=20=

>         worst-case Power.  The actual or average Power may be lower. =20=

>         The Nameplate Power is typically used for provisioning and=20
>         capacity planning.=20

Thanks,

    Juergen



--Apple-Mail-2-399922643
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Dear =
all,

Attached please find my comments on sections 1-3 =
of the framework draft version -02. 
Comments on the =
remaining sections will follow in separate =
emails.

 [snip]
                =
         Energy Management =
Framework 
          =
              =
draft-ietf-eman-framework-02 
 [snip]
    =
 Abstract 

  =
      This document defines a framework for providing =
Energy 
        =
Management for devices within or connected to =
communication 
        networks. =
 The framework defines a domain of Energy =
Management 
        devices =
that is a logical unit of Energy Management. Within =
a 

This is difficult to =
parse: "A domain of devices is a unit of energy =
management"?

  =
      domain each device is identified, classified and =
given context.   
  =
      Devices can be monitored and/or controlled with =
respect to 
        power, =
power state, energy, demand, electrical quality, =
and 
        battery. =
 Additionally the framework models relationships =
and 
        =
capabilities between devices in a domain. =
  
        =
 
        =
 
        TO DO/OPEN =
ISSUE 
        - IPFIX =
or not? Initially IPFIX was mentioned in =
[EMAN-REQ], 
        then we =
see now: "A solution for this is that the =
concerned 
        entity or =
another entity closely interacting with the =
concerned 
        entity =
collect time series of power values and make =
them 
        available =
via push or pull mechanisms to receivers of =
the 
        =
information.". So, the questions are: Is IPFIX a requirement? =
 
        What other mechanism do we =
have to PUSH time series of power 
        =
values (no, SNMP notifications are not suitable)? So should =
we 
        or not =
include IPFIX in this =
document? 

PUSH mode is a =
requirement for time series of measurements. 
Whether =
IPFIX is the only protocol that can do so in the right way
is =
not a question of requirements. If the framework brings =
arguments
why IPFIX is the best choice, it should include =
IPFIX as solution. 
Otherwise, it still may include IPFIX =
as candidate protocol for PUSH mode.

        - Power Monitor has been =
renamed to Energy Managed Object. =
Get

I don't think that this is a =
good choice.
"Managed Object" is the term specified to be used =
for objects defined in MIB modules.
"Energy Managed Objects" =
sounds like a kind of MIB objects.
  
          consensus on the =
terminology. Another example is Power 
  =
        =
Quality 

I think the term =
power quality is the right term and we should easily find an agreed =
definition. 
We just should avoid applying it to things =
that are not related to power quality.
  =
       
     1. =
Introduction 

  =
      Network management is divided into the five main =
areas defined 
        in the =
ISO Telecommunications Management Network model: =
Fault, 
        =
Configuration, Accounting, Performance, and Security =
Management 
        (FCAPS). =
  Absent from this management model is =
any 

I would add ITU X.700 =
as reference for FCAPS.

  =
      consideration of Energy Management, which is now =
becoming a 
        critical =
area of concern worldwide as seen in [ISO50001]. =
 
        =
 
        This document defines a =
framework for providing Energy 
  =
      Management for devices within or connected to =
communication 
        networks. =
 The framework describes how to identity, classify =
and 

identity -> =
identify

  =
      provide context for a device in a communications =
network from 
        the point =
of view of Energy Management.   
  =
       
  =
      The identified device can then be monitored for =
Energy 
        =
Management by obtaining measurements for power, energy, =
demand 
        and =
electrical quality.  If a device contains a battery(s) =
the 
        =
characteristics and performance of the battery(s) can also =
be 
        managed. =
 A device's state can be monitored or controlled =
by 
        providing =
an interface expressed as one or more Power =
State 
        Sets. =
 The most basic example of energy management is a =
single 
        device =
reporting information about itself.  However, in =
many 
        cases, =
energy is not measured by the device itself, but by =
a 
        meter =
located upstream in the power distribution tree. =
 An 
        example =
is a power distribution unit (PDU) that measures =
energy 
        =
consumption of attached devices and may report this to an =
Energy 
        =
Management System.  Therefore, devices are recognized as =
having 
        =
relationships to other devices in the network from the point =
of 
        view of =
Energy Management.  These relationships =
include 
        =
Aggregation, Metering, Power Source(s), Proxy, and Dependency. =
 
      
  =
                    =
       
  =
   1.1. Energy Management Document =
Overview 

  =
    
        The EMAN =
standard provides a set of specifications that =
together 
        provide =
Energy Management.  This document specifies =
the 

Specifications do no =
never provide energy management.

        framework, per the Energy =
Management requirements specified in 
  =
      [EMAN-REQ] 
  =
       
  =
      The applicability statement document [EMAN-AS] =
provides a list 
        of use =
cases, cross-reference between existing standards and =
the 
        EMAN =
standard, and shows how the this relates to =
other 
        =
frameworks. 
        =
 
        The [EMAN-AWARE-MIB] =
provides objects for =
addressing 

provides -> =
specifies or defines

  =
      identification, classification, context =
information, and 
        =
relationships form the point of view of Energy =
Management. 
          =
                =
 
        The Power and Energy =
Monitoring MIB [EMAN-MON-MIB] contains  
  =
      objects for monitoring of Power, Energy, Demand, =
Electrical 
        Quality =
and Power State Sets. 
  =
       
  =
      Definition of Managed Objects for Battery =
Monitoring [EMAN-
        =
BATTERY-MIB] defines managed objects that provide information =
on 
        the =
status of batteries in managed devices. 
  =
    
        EDITOR'S =
NOTE: [EMAN-MON-MIB] and [EMAN-AS] are not EMAN =
working 
        group =
documents.  Hence, these references will be changed in =
the 
        =
future. 
        =
 
     2. Requirements & Use Cases =
 

        =
Requirements for power and energy monitoring for =
networking 
        devices =
are specified in [EMAN-REQ].  The Energy Management =
use 
        cases =
covered by this framework are covered in the =
EMAN 
        =
applicability statement document in [EMAN-AS]. =
 Typically 
        =
requirements and use cases for communication networks cover =
the 
        devices =
that make up the communication network and endpoints. =
 
        =
 
        With Energy Management, =
there exists a wide variety of devices 
  =
      that may be contained in the same deployments as a =
communication 
        network =
but comprise a separate facility, home, or =
power 
        =
distribution network.  
  =
       
  =
      For example, target devices for this specification =
can include 
        (but are =
not limited to): 

I am not sure =
it makes sure having this list. 
It is always incomplete. =
I would rather state that
"Target devices for the energy =
management framework are all devices that can directly or indirectly be =
monitored or controlled by an energy management system using the =
Internet protocol."

 
          =
  - Simple electrical appliances / fixtures =
 
            - Hosts, =
such as a PC or a datacenter =
server 

"a PC or a =
datacenter server"
--> a PC, a datacenter server, or a =
printer"

  =
          - Routers =
 
            - =
Switches 
          =
  - Switches with line card components =
 
            - Power over =
Ethernet (PoE) endpoints, 
  =
          - Power Distribution Units (PDU) =
 
            - Protocol =
gateways devices for Building Management =
Systems 
        =
(BMS) 
          =
  - Electrical Meters 
        =
    - Sensor controllers with subtended =
sensors 
    =
  
        There may =
also exist varying protocols deployed among =
these 
        parallel =
networks.  

To what does =
"these parallel networks" refer?

  =
      For an Energy Management framework to be useful, it =
should also 
        apply to =
these types of separate networks as they connect =
and 
        interact =
with a communications network.  
  =
       
  =
    
        =
 
     3. =
Terminology 

There is a =
section 4 titled "Energy Management Reference Model". But actually, most =
of the model's fundamentals are only explained in this terminology =
section. I don't think this is a good structure and I don't think this =
is sufficient. Basic concepts, such as the Energy Managed Object, the =
EMO relationships should be elaborated in section =
4.


        The key =
words "MUST", "MUST NOT", "REQUIRED", "SHALL", =
"SHALL 
        NOT", =
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", =
and 
        =
"OPTIONAL" in this document are to be interpreted as =
described 
        in RFC =
2119 [RFC2119]. 
        =
 
        This section contains =
definitions of terms used throughout this 
  =
      specification. Defined terms have their first =
letter 
        =
capitalized.  Entities, relationships and or capabilities =
are 

I am not in favor of =
the capitalization of terms.
Particularly for terms such as =
"energy", "power", "demand" which we are using fully in line with their =
common meaning it appears to be very confusing for a reader when (s)he =
needs to think: "Is capitalized "Energy" anyhow different from lower =
case "energy"?

  =
      defined with respect to well known software =
patterns as 
        described =
in [GAMMA] and =
[EIPATT] 

Why this? IMHO =
definitions for entities and relationships are better taken from =
standards (for example UML) than from books written by individual =
authors. The books referred to above may be useful when design patterns =
are used. But I do not see any of their design patterns being relevant =
for a standards on energy management, at least not more that for =
standards for IP traffic management and control where these books hardly =
appear as references in standards documents.
  =
    
  =
      Energy Management System =
(EnMS) 
        =
 
        An EnMS is a set of =
systems or procedures upon which 
  =
      organizations can develop and implement an energy =
policy, set 
        targets, =
action plans and take into account legal =
requirements 
        related =
to energy use.  An EnMS allows organizations to =
improve 
        energy =
performance and demonstrate conformity to =
requirements, 
        standards =
and/or legal requirements.  This definition is in =
line 
        with the =
definition of "Energy management systems - =
Requirements 
        with =
guidance for use" =
[ISO50001]. 

Wouldn't it be =
better to explicitly mention monitoring and control of energy =
consumption?
        =
 
  =
      With respect to communication networks these same =
goals will 
        apply to =
the communications networks and attached devices =
within 
        an =
organization. 

I would =
remove this paragraph. Either the first paragraph obviously applies =
already to communications networks or we need to change =
it.
        =
 
        Energy =
Management 
        =
 
        Energy Management is a set =
of functions for measuring, modeling, 
  =
      planning, and optimizing networks to ensure that =
the network 
        elements =
and attached devices use energy efficiently and =
is 

I disagree. Even if I =
don't like it, I would not limit energy management systems to the ones =
that ensure energy efficiency. Energy management deals with =
assessing and influencing the consumption of energy. This is =
independent from an objective of ensuring energy =
efficiency.
 
  =
      appropriate for the nature of the application and =
the cost 
  =
      Management is a system congruent to any of FCAPS =
area of 
        =
management in the ISO/OSI Network Management Model [TMN] =
Energy 
        =
Management for communication networks and attached devices is =
a 

"is a" --> "may =
be"

  =
      subset or part of an organization's greater =
EnMS. 

This is confusing, =
because it is completely different from the definition of =
EnMS
Why is energy management not
    "developing =
and implementing an energy policy, 
  =
   setting targets, action plans and taking =
into account 
     legal =
requirements related to energy use."
  =
      Energy Management Systems =
 

This is confusing. The =
same term with different acronym was already defined =
above. 
        =
 
  =
      An Energy Management System (EMS) is congruent to a =
Network 

EMS --> =
EnMS

  =
      Management System (NMS) and is a combination of =
hardware and 
        software =
used to administer a network with the primarily =
purpose 
        being =
Energy Management. 

This =
paragraph needs to be merged with the previous definition of the =
term. 

  =
       
  =
      Energy Monitoring 
  =
       
  =
      Energy Monitoring is a part of Energy Management =
that deals with 
        =
collecting or reading measurements from devices to aid in =
Energy 
        =
Management.  This could include Energy, Power, Demand, =
Quality, 
        Context =
and/or Battery information. 
  =
      Energy 
line to be =
deleted

  =
      Energy  
  =
       
  =
      Energy is the capacity of a system to produce =
external activity 
        or =
perform work and can be electricity, fuels, steam, =
heat, 
        =
compressed air, and other like media. Energy is =
typically 

This is =
certainly not taken from an IEEE or IEC =
dictionary: 
Energy is not steam, it is not fuel, it is =
not compressed air.
Let's take text from a =
dictionary.

  =
      expressed in watt hours or joules. =
 

can we restrict EMAN to =
electrical energy and power?
        =
 
  =
      Power 
  =
       
  =
      Power is a rate of energy conversion.  As the =
unit of time 
        =
approaches zero a power measurement is called an =
instantaneous 
        power =
reading.  Typically when implementing Power monitoring =
in 
        hardware, =
a measuring device may have to compute an =
average 
        value per =
some unit of time to express a reading to =
approximate 
        an =
instantaneous power =
measurement. 

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

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

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

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

  =
      of time and typically expressed in kilowatt hours. =
 This 
        =
measurement is significant because some utilities or =
energy 

remove "This =
measurement is significant because"

        providers bill by Demand =
measurements as well as for =
maximum 
  =
      Demand per billing periods.  Power values may =
spike during 
  =
      short-terms by devices, but Demand measurements =
recognize that 
        maximum =
Demand does not equal maximum Power during an =
interval. 
        =
 
        Power =
Quality 
        =
 
        EDITOR'S NOTE: This may be =
rephrased as Electrical 
  =
      =
Characteristics. 

Electrical =
characteristics seems to better match what the term has been used for in =
some drafts.
But the term power quality should still be here =
to refer to properties that are usually called =
so.

  =
      Power Quality is defined as a set of values to =
describe the 
        =
electrical characteristics of Power as provided by an =
electrical 
        source as =
seen by the Energy Managed Object.  For example: =
AC 
        phase, =
apparent and reactive power, =
etc. 

Yes. Phase, apparent =
and reactive power are not typical power quality issues. Power quality =
issues include the deviation of actual voltage from nominal/design =
voltage, the deviation of AC frequency from the nominal frequency, =
harmonic distortions, etc.
  =
       
  =
      Energy Control 
  =
       
  =
      Energy Control is a part of Energy Management that =
deals with 
        modifying =
or setting the state of an Energy Managed Object =
in 
        order to =
optimize or ensure its =
efficiency. 

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

What woud be the difference between =
modifying and setting a state? I don't make a suggestion for an =
alternative here. We should put ALL terms on the mailing list and =
discuss them until we reach something that comes closer to a reasonable =
definition.

        =
Energy Managed Object  
  =
       
  =
      An Energy Managed Object (EMO) is a device that is =
part of or 
        attached =
to a communications network that is =
monitored, 
        =
controlled, or aids in the management of another device =
for 
        Energy =
Management.  

Two =
issues: 
1. the term "managed object" is already in =
common use for the objects defined in a MIB module. Since we are also =
defining MIB modules, we will run into ambiguities and risk confusion of =
readers if we re-use the term here.
2. The attribute "managed" =
is confusing, because the term refers also to "unmanaged" objects that =
are neither monitored or controlled, but just "aid" in the management of =
other devices. These seem to be rather "managing" objects than "managed" =
objects.

  =
      Energy Aware Object  
  =
       
  =
      An Energy Managed Object may not have the =
capability to provide 
  =
      information necessary for Energy Management itself. =
If an Energy 
        Managed =
Object can provide Energy Management Context, =
Energy 
        Monitor =
and optionally Energy Control values for itself then =
the 

Monitor --> =
Monitoring

  =
      Energy Managed Object is said to be an Energy Aware =
Object 

I don't see good =
reasons for using the term energy awareness. IPFIX did all its =
specifications well without ever needing the term flow-awareness and the =
SNMP Interface MIB module never needed the term packet-awareness for =
interfaces that meter bytes and packets.

BTW, I =
wonder why a device that only reports its energy consumption is not =
called energy-aware.
It is only called energy-aware if it can =
also report its energy context. Why is this =
so?

My strongest concern is the following. What =
I would call energy aware would be a device that not just reports on its =
energy consumption, but rather tries to optimize its energy consumption =
by its own control logic, for example a TV sets that switches of the =
screen when its sensors indicates that the last watchers has left the =
room. If this TV should be called energy-aware even if it does not =
report anything to any management system.

I =
strongly suggest either to replace the term "energy aware" by "energy =
reporting" or something similar, or better, not to use the term at all. =
We don't need it.

        For =
example: as the most simplistic example, a set of =
light 
        bulbs =
where all values are provided by an EMS through =
estimation 
        and or =
catalogue information are not Energy Aware. In contrast =
a 
        set of =
network switches that can report the same =
information 
        based =
upon hardware sensing is said to be Energy =
Aware. 

Would you also call =
it energy aware if the device can report its energy information only =
using a non-IP protocol?
        =
 
  =
      Energy Managed Object =
Identification 
        =
 
        Energy Managed Object =
Identification is a set of attributes =
that 
        enable an =
Energy Managed Object to be: uniquely identified =
among 
        all =
Energy Management Domains; linked to other =
systems; 

Among all =
domains? 
This means globally unique. 
Do =
you really mean this? 
Do we need =
this?

What means "linked to other =
systems"? 

        classified as to type model =
and or =
manufacturer. 

I do =
think it is impossible to invent a type of identifier that enables all =
kinds of energy managed objects to derive their type model and =
manufacturer from it. This is particularly difficult for devices that do =
not have a particular or model type model or manufacturer that =
is registered somewhere.

  =
      RFC EDITOR'S: the uniqueness must be clarified in =
[EMAN-REQ] 
        =
  
        Energy =
Managed Object Context 
  =
       
  =
      Energy Managed Object Context is a set of =
attributes that allow 
  =
      an Energy Management system to classify the use of =
the Energy 
        Managed =
Object within an organization.  The =
classification 
        contains =
use and/or ranking of the Energy Managed Object =
as 
        compared =
to other Energy Managed Objects in the =
Energy 
        =
Management Domain. 

Just =
questions: 
Are there already standards defining contexts =
of devices?
Or is this something new? 
Is IANA =
maintaining a list of standardized contexts?
Are we planning =
to establish one? 
Or is a context just a string with =
arbitrary content?
        =
  
  =
      Energy Management =
Domain 
        =
 
        An Energy Management =
Domain is a name or name space =
that 

If a domain were a =
name, we could call it name.
A domain is not a name. It may =
have one.

  =
      logically groups Energy Managed Objects into a zone =
of Energy 
        =
Management.  Typically, this zone will have as members =
all 

What is a zone of =
energy management? 
Is it different in any way from a =
domain?

  =
      Energy Managed Objects that are powered from the =
same electrical 
        panel(s) =
for which there is a meter or sub meter. =


What is a sub =
meter? 
What would be the difference between having a =
meter or a sub meter at a panel?
  =
      For example: All Energy Managed Objects drawing =
power from the 
        same =
distribution panel with the same AC voltage within =
a 
        building, =
or all Energy Managed Objects in a building for =
which 
        there is =
one main meter, would comprise an Energy =
Management 
        Domain. =
 

I would not use this =
example over five lines of text in the definition. It should be rather =
mentioned when the trem is explained in the description of the reference =
model.
 
  =
      =46rom the standpoint of Energy Management, it is =
useful to report 
        Energy as =
the sum of the Energy of all the Energy =
Managed 
        Objects =
within an Energy Management Domain and then =
correlate 
        that =
value with metered values. =
 

The same for this use =
case: It belongs to the description of the reference =
model.
         
        Energy Managed Object =
Relationships 
        =
 
        Energy Managed Objects may =
have functional relationships to each 
  =
      other within an Energy Management Domain.  The =
functional 

Can't this be =
cross domain?
In our company, we have fuse cabinets equipped =
with power meters that have up to eight current claps and measure power =
for up to eight power distribution trees. Is the meter than member of =
all eight domains
at the same time because it measures in =
them. Note that the meter is powered by just one of the distribution =
trees or be neither of them.
Another case would be an energy =
management system that uses different domains for servers, PCs, phones, =
and switches. Still, a switch should be able to power a phone cross =
domain using PoE.

  =
      relationships include Aggregation, Metering, Power =
Source(s), 
        Proxy, =
and Dependency.  One device will provide a capability =
or 
        =
functional value in the relationship and another will be =
the 
        receiver =
of the capability.  These capabilities =
include

I do not understand why =
a PDU metering its output provides a capability?
Even less do =
I understand why a device (host, switch, light bulb) for which power is =
measured would receive any capability when this is =
done.

  =
      Aggregation, Metering, Power Source, Proxy and =
Dependency.  

Which =
capability is provided in the dependency =
relationship?

        =
Aggregation Relationship 
  =
    
        An Energy =
Managed Object may aggregate the Energy =
Management 
        =
information of one or more Energy Managed Objects and =
is 
        referred =
to as an Aggregation Relationship.  An Energy =
Managed 

The previous =
paragraph stated that objects may HAVE relations ships. This paragraph =
states that an object IS REFERRED TO  as relationship. This is not =
consistent.
 
  =
      Object may be aggregated by another Energy Managed =
Object(s).  
        Aggregate =
values are obtained by reading values from =
multiple 
        Energy =
Managed Objects and producing a single value of =
more 

I think it does not =
need to be just a single value. It can be multiple.
The =
definition should not focus on the number of values. A good indicator =
for an aggregation action is the presence of operations on multiple =
given values. Whether the operation(s) produce one or more values is not =
highly relevant for the definition.

        significant meaning such as =
average, count, maximum, =
median, 

I would not limit =
aggregation to operations generating values with more significant =
meanings. Even if the meaning is less significant, it still should be =
called aggregation.

  =
      minimum, mode and most commonly sum. =
 
        =
 
        Metering =
Relationship 
        =
 
        An Energy Managed Object =
may measure the Energy of another 
  =
      Energy Managed Object(s) and is referred to as a =
Metering 

I think it is =
important for the EnMS to distinguish two cases: A meter measures the =
energy of individual EMOs separately, or it measures just the =
accumulated energy and power for these devices, for example in the fuse =
cabinet.In the latter case, information on individual EMOs would not be =
available. This is a significant qualitative difference and should be =
modeled.

  =
      Relationship.  An Energy Managed Object may be =
metered by 

Again, "the EMO =
is referred to as metering relationship" does not seem to be what is =
intended to b said.

  =
      another Energy Managed Object(s).  Example: a =
PoE port on a 

Remove =
second sentence. It is redundant. Or use the following =
replacement:
"another Energy Managed Object(s)" --> =
"multiple Energy Management Objects and a single EMO may meter multiple =
other EMOs."

        switch measure the Power it =
provides to the connected Energy 
  =
      Managed =
Object. 

Why is this =
"providing a service to the powered EMO"?
It is providing a =
service to the EnMS and obviously not to the EMO that may not even have =
an information on whether or not the measurement is performed. The =
powered EMO does not ask for such a service. The EnMS does. In my view. =
The PoE switch measures at its output and provides this information to =
the EnMS. The EMS is the free to use this information also as power =
information for the powered EMO.

        Power Source =
Relationship 
        =
 
        An Energy Managed Object =
may be the source of or distributor of 
  =
      power to another Energy Managed Object(s) and is =
referred to as 
        a Power =
Source Relationship.  An Energy Managed Object may =
be 
        powered =
by another Energy Managed Object(s).  Example: a =
PDU 

"another Energy =
Managed Object(s)" --> "multiple Energy Management Objects and a =
single EMO may power multiple other EMOs."

        provides power for a =
connected host. 
        =
 
        Proxy =
Relationship 
        =
 
        An Energy Managed Object =
that provides Energy Management 
  =
      capabilities on behalf of another Energy Managed =
Object so that 
        is =
appears to be Energy Aware is referred to a =
Proxy 

What sense would it =
make to have another object appear to be energy aware? Fooling the =
EnMS?
Whether or not an EMO is energy aware should be =
completely independent from whether or not there is a proxy for it. And =
it should be possible to have a proxy relationship without pretending an =
unaware device to be aware.

        Relationship.  An =
Energy Managed Object may be proxied by 
  =
      another Energy Managed Object(s).  Example: a =
protocol =
gateways 

"another =
Energy Managed Object(s)" --> "multiple Energy Management Objects and =
a single EMO may proxy multiple other =
EMOs."

  =
      device for Building Management Systems (BMS) with =
subtended 
        devices. =
 
           =
        
  =
      Dependency =
Relationship 
        =
 
        An Energy Managed Object =
may be a component of or rely 
  =
      completely upon another Energy Managed Object to =
operate and is 
        referred =
to as a Dependency Relationship.  An Energy =
Managed 
        Object =
may be dependent on another Energy Managed Object(s). =
 
        Example: A Switch chassis =
with multiple line =
cards 

This is very =
foggy. 
What is the meaning of "rely completely upon =
another EMO to operate"?
Is a server in a datacenter =
completely dependent on the firewall(s) that connect the datacenter with =
the Internet? With a switched off firewall, the server cannot provide =
any service thus not operate.
How shall we detect all those =
dependencies. Wouldn't they be subject to dynamic =
changes?

  =
       
  =
      Energy Managed Object =
Parent 
   =
   
        An Energy =
Managed Object Parent is an Energy Managed Object =
that 
        provides =
one or more of the Energy Managed Object =
Relationships 
        =
capabilities. 

I don't =
think that in the case of dependency, a capability is provided to a =
EMO. 
Neither in the case of metering.
        =
 
        Energy Managed Object =
Child 
        =
 
        An Energy Managed Object =
Child is an Energy Managed Object that 
  =
      has at least one Energy Managed Object Relationship =
capability 
        provided =
by another Energy Managed Object. =
  

see previous =
comment.
  =
       
  =
      Power State 
  =
       
  =
      A Power State is a way to classify a Power setting =
on an Energy 

A power state =
is not a way.

  =
      Managed Object (e.g., on, off, or sleep).  A =
Power State can be 
        viewed =
as a method for Energy =
Control 

A power state =
should not be viewed as a method for power control. It is a state, not a =
method.
        =
 
  =
      Manufacturer Power =
State 
        =
 
        A Manufacturer Power State =
is a device-specific way to classify 
  =
      a Power setting implemented on an Energy Managed =
Object.

See power =
state.
   
  =
      Power State Set 
  =
       
  =
      A collection of Power States that comprise one =
named or logical 
        grouping =
of control is a Power State Set.  For example, =
the 
        states =
{on, off, and sleep} as defined in [IEEE1621], or the =
16 
        power =
states as defined by the [DMTF] can be considered =
two 
        different =
Power State Sets. 

We =
should add that a power state set implemented on a device MUST at all =
times have exactly one 
state that the device is =
in.

        =
Nameplate Power 
  =
       
  =
      The Nameplate Power is the maximal (nominal) Power =
that a device 
        can =
support.  This is typically determined via load testing =
and 

remove "specified via =
load testing and is"

  =
      is specified by the manufacturer as the maximum =
value required 
        to =
operate the device.  This is sometimes referred to as =
the 
        =
worst-case Power.  The actual or average Power may be lower. =
 
        The Nameplate Power is =
typically used for provisioning and 
  =
      capacity =
planning. 

Thanks,
=

    =
Juergen


=

--Apple-Mail-2-399922643--

From ietf@quittek.at  Sun Jul 24 21:26:28 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0F021F859E for ; Sun, 24 Jul 2011 21:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.748
X-Spam-Level: 
X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[AWL=1.500,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 mmgCO-LUTuGE for ; Sun, 24 Jul 2011 21:26:27 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD4C21F8450 for ; Sun, 24 Jul 2011 21:26:27 -0700 (PDT)
Received: from [172.16.53.213] ([207.96.251.20]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MLkF5-1Qm25r34bL-000vGG; Mon, 25 Jul 2011 06:26:25 +0200
References: <0131AC21C657A3418A5B6CA168C4C57E0A813EA6@USA7061MS04.na.xerox.net> <23E19EBD-1A1E-47AB-BA8F-47B8E919A2DE@quittek.at> <4E2C7E87.6060505@cisco.com>
In-Reply-To: <4E2C7E87.6060505@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-3-400818184
Message-Id: 
From: Juergen Quittek 
Date: Mon, 25 Jul 2011 00:26:23 -0400
To: Benoit Claise 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:liBE+4HZq1AwWCXl+Da/CET55gjEWbO+sdLVQNWDqD5 rg7PFM3SpL3/oBvrhH0PE2NKYA3K08cOTD8brJ0OLz9yjAJrCv EDJe2jXK4x0G8lXTpqGffHrP0V4L7RArzp2z60MbIKdKBqXrvF G9pa53g+V11x+3DnfnLlWrUOWt96Oc5q2HNJYlLJ8ZyZTbAZFY S5j/5QdR/G5TikB/OnPz/ostWYGu0dldNFFC4uFWDA=
Cc: eman@ietf.org, "Ebner, Fritz" 
Subject: Re: [eman] IETF EMAN request to address printers... -> draft-ietf-eman-requirements-04
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2011 04:26:28 -0000

--Apple-Mail-3-400818184
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Benoit,

Currently, there is the following paragraph in section 1 of =
draft-ietf-eman-requirements-04:

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

You see that we already address all kinds of IP devices: hosts, routers, =
and middleboxes.
There is no list of special hosts, such as servers, PCs, smart phones, =
printers, webcams, etc.=20
I do not see a need to introduce it. Since a printer is a device that =
can either be directly addressed with IP or that can be addressed via a =
host connected to it, I see no need to add a special comment on it, =
particularly not since I do not see any special requirements for a =
printer compared to other hosts.

Rather I see a need in the framework draft to discuss if and how =
alignment with the IEEE ISTO-PWG is realized.

Thanks,

    Juergen


Am 24.07.2011 um 16:20 schrieb Benoit Claise:

> Juergen,
>=20
> Reading this old email, I believe that we should mention "printer" =
somewhere in the requirements draft, as a device type addressed by the =
EMAN WG, and not only in the appendix.
>=20
> Regards, Benoit.
>> Hi Fritz,
>>=20
>> Thank you for your input.
>>=20
>> We will consider printers and the document your referred to in the =
next revision of the requirements.
>> I don't think many changes will need to be made here.
>>=20
>> But for the MIB documents, we now have another set of PWG =
power/functional states next to DMTF and ACPI states.
>>=20
>> Thanks,
>>=20
>>     Juergen
>>=20
>>=20
>> Am 18.03.2011 um 19:11 schrieb Ebner, Fritz:
>>=20
>>> Hello,
>>> Please make sure that any power control or monitoring MIBs or drafts =
that the EMAN WG produces can cover the use cases, power controls, and =
power monitoring features provided in the printer working group.  =
Details are below:
>>> =20
>>> The IEEE/ISTO Printer Working Group has published their Candidate =
Standard for Power Management and the associate protocol binding for =
SNMP.  Below are the links to the abstract model and MIB.
>>> =20
>>> PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0:
>>> =20
>>> The PWG Power Management Model for Imaging Systems 1.0 specification =
was=20
>>> recently approved as a PWG Candidate Standard and is now available =
at:
>>>=20
>>>  http://www.pwg.org/standards.html
>>>=20
>>> and
>>>=20
>>>  =
ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf =
/ doc
>>> =20
>>> PWG 5106-5 - PWG Imaging System Power MIB v1.0
>>> =20
>>> The PWG Imaging System Power MIB v1.0 specification was recently =
approved
>>> as a PWG Candidate Standard and is now available at:
>>>=20
>>>  http://www.pwg.org/standards.html
>>>=20
>>> and
>>>=20
>>>  =
ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf=
 / doc / mib
>>>  - PDF, MS Word, and ASN.1 source in plaintext
>>>=20
>>>  =
ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib=
.pdf
>>>  - ASN.1 source in color highlighted PDF
>>> =20
>>> Thanks,
>>> Fritz Ebner
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>>=20
>>=20
>>=20
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>=20


--Apple-Mail-3-400818184
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



 =20
    
 =20
  

    Juergen,

    

    Reading this old email, I believe that we should mention "printer"
    somewhere in the requirements draft, as a device type addressed by
    the EMAN WG, and not only in the appendix.

    

    Regards, Benoit.

    
Hi Fritz,
      


      

      
Thank you for your input.

      


      

      
We will consider printers and the document your referred to
        in the next revision of the requirements.

      
I don't think many changes will need to be made here.

      


      

      
But for the MIB documents, we now have another set of PWG
        power/functional states next to DMTF and ACPI states.

      


      

      
Thanks,

      


      

      
    Juergen

      


      

      


        

          
Am 18.03.2011 um 19:11 schrieb Ebner, Fritz:

          

          

              

    

  




=

--Apple-Mail-3-400818184--

From bill.mielke@alcatel-lucent.com  Sun Jul 24 21:32:05 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EC65E8003 for ; Sun, 24 Jul 2011 21:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf9kxvaGUvPr for ; Sun, 24 Jul 2011 21:32:04 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9711F21F86AA for ; Sun, 24 Jul 2011 21:32:04 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p6P4VxB5020446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 24 Jul 2011 23:31:59 -0500 (CDT)
Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6P4VxIN001960 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 24 Jul 2011 23:31:59 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Sun, 24 Jul 2011 23:31:59 -0500
From: "Mielke, William F (Bill)" 
To: Juergen Schoenwaelder , Benoit Claise 
Date: Sun, 24 Jul 2011 23:30:31 -0500
Thread-Topic: [eman] Two NMS configuring the Power Monitor with two different Power State Series
Thread-Index: AcwJdJC+LP19I28dS9yh0O0afBTXtxBDIssg
Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D5C0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: <4DBFC56E.2020908@cisco.com> <20110503092855.GA3772@elstar.local>
In-Reply-To: <20110503092855.GA3772@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Cc: eman mailing list 
Subject: Re: [eman] Two NMS configuring the Power Monitor with two different Power State Series
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, 25 Jul 2011 04:32:05 -0000

I apologize for having gone silent for so long but I am here in Quebec and =
am working through old emails to come back up to speed.  I also apologize f=
or perhaps covering old ground in some cases.  I plan to comment as I go ch=
ronologically through the list archive.  If I comment on something which wa=
s later resolved please bear with me as I will eventually find the resoluti=
on along the way.  Either way it is probably better that I record my commen=
ts in the event that I identify something that has not been considered full=
y.

Regarding the issue of 2 NMS's interacting with a single Managed Object usi=
ng different power state series, my thinking all along was that the managed=
 object would choose (align with) the power series that made sense for it a=
nd that the NMS's would have to adapt to talking to the managed object in i=
ts preferred  (supported) series.  So in this case there is no confusion, t=
he series selected by the managed object is always the one that will be use=
d by any NMS.  This approach is consistent with Juergen S. point that tradi=
tionally the NMS was assumed to be better able to deal with these types of =
variations rather then the managed object implementation.

How was this point ultimately resolved, assuming it was?

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

=20

> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, May 03, 2011 5:29 AM
> To: Benoit Claise
> Cc: eman mailing list
> Subject: Re: [eman] Two NMS configuring the Power Monitor=20
> with two different Power State Series
>=20
> On Tue, May 03, 2011 at 11:05:50AM +0200, Benoit Claise wrote:
> =20
> > Let's discuss the following situation: what if we have 2 NMS', and
> > they speak different Power State Series for a specific Power
> > Monitor? Should this be allowed by the [EMAN-REQ]?
>=20
> Traditionally, it was always assumed that an SNMP management system
> can more easily adapt to devices than the other way round.
>=20
> > Actually this requirement has got some implications in terms of the
> > MIB design (taking
> > http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07
> > into account)
> >=20
> > - If the answer is yes, then we need to have an extra index in the
> > power pmPowerTable. This index must abe a new TC, which is only for
> > the Power State Series.  Note: the table needs to redesigned because
> > the common variable (caliber, nameplate, etc...) are common per
> > Power State Series. Then we can have a new table, for discovery,
> > that will only contain  two indices: pmPowerMonitorIndex and the new
> > TC-defined pmPowerStateSeries.
> > - If the answer is no, then there is the risk that NMS1 will set the
> > DMTF:1 for example, and then NMS2 set it EMAN:3 (assuming that the
> > Power Monitor supports both the DMTF and the EMAN Power State
> > Series), and there is a ping-pong game between two NMS's that don't
> > synchronize between the two.
>=20
> If two management systems make changes without coordination, you
> always have a chance for ping-pong effects, even within a Power State
> Series. That said, it might be possible to provide guidelines such as
> if a device is reporting a value of a given Power State Series
> (e.g. DMTF:3), a management application should adapt and use DMTF
> power states.
>=20
> > The alternative is that the first NMS would say: I will speak to the
> > Power Monitor with the DMTF Power State Series, and then all the
> > other NMS's will have to speak the same language (i.e. DMTF).
>=20
> I think that is a reasonably assumption to make if the number of
> different Power State Series is kept limited (that is we prevent that
> every vendor/organization comes up with its own creative series of
> power states). A large number of different Power State Series will be
> hindering interoperability, with or without ping-pong effects.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
> =

From bclaise@cisco.com  Sun Jul 24 21:55:43 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C67321F86C0 for ; Sun, 24 Jul 2011 21:55:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.516
X-Spam-Level: 
X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.082,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9I9bh2WPPkQ for ; Sun, 24 Jul 2011 21:55:42 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1A00E21F85FE for ; Sun, 24 Jul 2011 21:55:41 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6P4teYI008770; Mon, 25 Jul 2011 06:55:40 +0200 (CEST)
Received: from [10.82.235.109] (rtp-vpn5-874.cisco.com [10.82.235.109]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6P4taxF018176; Mon, 25 Jul 2011 06:55:36 +0200 (CEST)
Message-ID: <4E2CF747.6000800@cisco.com>
Date: Mon, 25 Jul 2011 00:55:35 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Juergen Quittek 
References: <0131AC21C657A3418A5B6CA168C4C57E0A813EA6@USA7061MS04.na.xerox.net> <23E19EBD-1A1E-47AB-BA8F-47B8E919A2DE@quittek.at> <4E2C7E87.6060505@cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080305060500030605080604"
Cc: eman@ietf.org, "Ebner, Fritz" 
Subject: Re: [eman] IETF EMAN request to address printers... -> draft-ietf-eman-requirements-04
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2011 04:55:43 -0000

This is a multi-part message in MIME format.
--------------080305060500030605080604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Juergen,

So why is there an "IEEE-ISTO Printer WG" appendix if printers are not 
mentioned a single time in the document?

Regards, Benoit.
> Hi Benoit,
>
> Currently, there is the following paragraph in section 1 of 
> draft-ietf-eman-requirements-04:
>
> >   The main subject of energy management are powered entities that
> >   consume electric energy.  Powered entities include devices that have
> >   an IP address and can be addressed directly, such as hosts, routers,
> >   and middleboxes, as well as devices indirectly connected to an IP
> >   network, for which a proxy with an IP address provides a management
> >   interface, for example, devices in a building management
> >   infrastructure using BACNET or MODBUS protocols.
>
> You see that we already address all kinds of IP devices: hosts, 
> routers, and middleboxes.
> There is no list of special hosts, such as servers, PCs, smart phones, 
> printers, webcams, etc.
> I do not see a need to introduce it. Since a printer is a device that 
> can either be directly addressed with IP or that can be addressed via 
> a host connected to it, I see no need to add a special comment on it, 
> particularly not since I do not see any special requirements for a 
> printer compared to other hosts.
>
> Rather I see a need in the framework draft to discuss if and how 
> alignment with the IEEE ISTO-PWG is realized.
>
> Thanks,
>
>     Juergen
>
>
> Am 24.07.2011 um 16:20 schrieb Benoit Claise:
>
>> Juergen,
>>
>> Reading this old email, I believe that we should mention "printer" 
>> somewhere in the requirements draft, as a device type addressed by 
>> the EMAN WG, and not only in the appendix.
>>
>> Regards, Benoit.
>>> Hi Fritz,
>>>
>>> Thank you for your input.
>>>
>>> We will consider printers and the document your referred to in the 
>>> next revision of the requirements.
>>> I don't think many changes will need to be made here.
>>>
>>> But for the MIB documents, we now have another set of PWG 
>>> power/functional states next to DMTF and ACPI states.
>>>
>>> Thanks,
>>>
>>>     Juergen
>>>
>>>
>>> Am 18.03.2011 um 19:11 schrieb Ebner, Fritz:
>>>
>>>> Hello,
>>>> Please make sure that any power control or monitoring MIBs or 
>>>> drafts that the EMAN WG produces can cover the use cases, power 
>>>> controls, and power monitoring features provided in the printer 
>>>> working group.  Details are below:
>>>> The IEEE/ISTO Printer Working Group has published their Candidate 
>>>> Standard for Power Management and the associate protocol binding 
>>>> for SNMP.  Below are the links to the abstract model and MIB.
>>>> PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0:
>>>> The PWG Power Management Model for Imaging Systems 1.0 
>>>> specification was
>>>> recently approved as a PWGCandidateStandardand is now available at:
>>>>
>>>> http://www.pwg.org/standards.html
>>>>
>>>> and
>>>>
>>>> ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf/ 
>>>> doc
>>>> PWG 5106-5 - PWG Imaging System Power MIB v1.0
>>>> The PWG Imaging System Power MIB v1.0 specification was recently 
>>>> approved
>>>> as a PWGCandidateStandardand is now available at:
>>>>
>>>> http://www.pwg.org/standards.html
>>>>
>>>> and
>>>>
>>>> ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf/ 
>>>> doc / mib
>>>>  - PDF, MS Word, and ASN.1 source in plaintext
>>>>
>>>> ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.pdf
>>>>  - ASN.1 source in color highlighted PDF
>>>> Thanks,
>>>> Fritz Ebner
>>>> _______________________________________________
>>>> 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
>>
>


--------------080305060500030605080604
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Juergen,

    

    So why is there an "IEEE-ISTO Printer WG" appendix if printers are
    not mentioned a single time in the document?

    

    Regards, Benoit.
    

      
Hi Benoit,

      


      

      
Currently, there is the following paragraph in section 1 of
        draft-ietf-eman-requirements-04:

      


      

      

        
>   The main subject of energy management are powered
          entities that

        
>   consume electric energy.  Powered entities include
          devices that have

        
>   an IP address and can be addressed directly, such as
          hosts, routers,

        
>   and middleboxes, as well as devices indirectly
          connected to an IP

        
>   network, for which a proxy with an IP address
          provides a management

        
>   interface, for example, devices in a building
          management

        
>   infrastructure using BACNET or MODBUS protocols.

      

      


      

      
You see that we already address all kinds of IP
        devices: hosts, routers, and middleboxes.

      
There is no list of special hosts, such as servers, PCs,
        smart phones, printers, webcams, etc. 

      
I do not see a need to introduce it. Since a printer is a
        device that can either be directly addressed with IP or that can
        be addressed via a host connected to it, I see no need to add a
        special comment on it, particularly not since I do not see any
        special requirements for a printer compared to other hosts.

      


      

      
Rather I see a need in the framework draft to discuss if and
        how alignment with the IEEE ISTO-PWG is realized.

      


      

      
Thanks,

      


      

      
    Juergen

      


      

      


      

      

        
Am 24.07.2011 um 16:20 schrieb Benoit Claise:

        

        

          
          
 Juergen,

            

            Reading this old email, I believe that we should mention
            "printer" somewhere in the requirements draft, as a device
            type addressed by the EMAN WG, and not only in the appendix.

            

            Regards, Benoit.

            
Hi Fritz,
              


              

              
Thank you for your input.

              


              

              
We will consider printers and the document your
                referred to in the next revision of the requirements.

              
I don't think many changes will need to be made here.

              


              

              
But for the MIB documents, we now have another set of
                PWG power/functional states next to DMTF and ACPI
                states.

              


              

              
Thanks,

              


              

              
    Juergen

              


              

              


                

                  
Am 18.03.2011 um 19:11 schrieb Ebner, Fritz:

                  

                  

                    

                      

                        
Hello,

                        
Please make sure that any power
                          control or monitoring MIBs or drafts that the
                          EMAN WG produces can cover the use cases,
                          power controls, and power monitoring features
                          provided in the printer working group. 
                          Details are below:

                        
 

                        
The IEEE/ISTO Printer Working
                          Group has published their Candidate Standard
                          for Power Management and the associate
                          protocol binding for SNMP.  Below are the
                          links to the abstract model and MIB.

                        

                          
 

                        

                        
PWG 5106.4 - PWG Power Management
                            Model for Imaging Systems 1.0:

                        
 

                        

                          
The PWG Power
                            Management Model for Imaging Systems 1.0
                            specification was 

                            recently approved as a PWG Candidate Standard and
                            is now available at:

                            

                             http://www.pwg.org/standards.html

                            

                            and

                            

                             ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf /
                            doc

                          
 

                        

                        
PWG 5106-5 - PWG Imaging System
                            Power MIB v1.0

                        
 

                        

                          
The PWG Imaging
                            System Power MIB v1.0 specification was
                            recently approved

                            as a PWG Candidate Standard and
                            is now available at:

                            

                             http://www.pwg.org/standards.html

                            

                            and

                            

                             ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf /
                            doc / mib

                             - PDF, MS Word, and ASN.1 source in
                            plaintext

                            

                             ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.pdf

                             - ASN.1 source in color highlighted PDF

                        

                        
 

                        
Thanks,

                        
Fritz Ebner

                      

                      _______________________________________________

                      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


            

            

          

        

      

      

    

    

  


--------------080305060500030605080604--

From bclaise@cisco.com  Sun Jul 24 22:12:03 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1216311E808E for ; Sun, 24 Jul 2011 22:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level: 
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+Okh31fM44l for ; Sun, 24 Jul 2011 22:12:02 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D4ECC11E807E for ; Sun, 24 Jul 2011 22:12:01 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6P5BvUW010784; Mon, 25 Jul 2011 07:11:57 +0200 (CEST)
Received: from [10.82.235.109] (rtp-vpn5-874.cisco.com [10.82.235.109]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6P5Bts1026221; Mon, 25 Jul 2011 07:11:56 +0200 (CEST)
Message-ID: <4E2CFB1B.3030403@cisco.com>
Date: Mon, 25 Jul 2011 01:11:55 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "Mielke, William F (Bill)" 
References: <4DBFC56E.2020908@cisco.com> <20110503092855.GA3772@elstar.local> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D5C0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D5C0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: eman mailing list 
Subject: Re: [eman] Two NMS configuring the Power Monitor with two different Power State Series
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, 25 Jul 2011 05:12:03 -0000

Hi Bill,
> I apologize for having gone silent for so long but I am here in Quebec and am working through old emails to come back up to speed.  I also apologize for perhaps covering old ground in some cases.  I plan to comment as I go chronologically through the list archive.  If I comment on something which was later resolved please bear with me as I will eventually find the resolution along the way.  Either way it is probably better that I record my comments in the event that I identify something that has not been considered fully.
>
> Regarding the issue of 2 NMS's interacting with a single Managed Object using different power state series, my thinking all along was that the managed object would choose (align with) the power series that made sense for it and that the NMS's would have to adapt to talking to the managed object in its preferred  (supported) series.  So in this case there is no confusion, the series selected by the managed object is always the one that will be used by any NMS.  This approach is consistent with Juergen S. point that traditionally the NMS was assumed to be better able to deal with these types of variations rather then the managed object implementation.
>
> How was this point ultimately resolved, assuming it was?
By having an extra index in the tables. First the power state series, 
then the power state.
>From http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09:

        pmPowerTable OBJECT-TYPE
             SYNTAX          SEQUENCE OF PmPowerEntry
             MAX-ACCESS      not-accessible
             STATUS          current
             DESCRIPTION
                "This table lists Power Monitors."
             ::= { powerMonitorMIBObjects 1 }

         pmPowerEntry OBJECT-TYPE
             SYNTAX          PmPowerEntry
             MAX-ACCESS      not-accessible
             STATUS          current
             DESCRIPTION
                "An entry describes the power usage of a Power Monitor."
             INDEX           { pmPowerIndex, pmPowerStateSetIndex}



>
> William F. Mielke
> Alcatel-Lucent
> Distinguished Member of Technical Staff
> 6200 East Broad Street
> Room: 4B01-1V
> Columbus, OH  43213-1530
> Email: Bill.Mielke@alcatel-lucent.com
> Phone: 614 367 5628
> Fax: 614 367 5965
>
> "Live like you're going to die tomorrow.
>   Learn like you're going to live forever."
>
>      - Albert Einstein
>
>
>
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On
>> Behalf Of Juergen Schoenwaelder
>> Sent: Tuesday, May 03, 2011 5:29 AM
>> To: Benoit Claise
>> Cc: eman mailing list
>> Subject: Re: [eman] Two NMS configuring the Power Monitor
>> with two different Power State Series
>>
>> On Tue, May 03, 2011 at 11:05:50AM +0200, Benoit Claise wrote:
>>
>>> Let's discuss the following situation: what if we have 2 NMS', and
>>> they speak different Power State Series for a specific Power
>>> Monitor? Should this be allowed by the [EMAN-REQ]?
>> Traditionally, it was always assumed that an SNMP management system
>> can more easily adapt to devices than the other way round.
>>
>>> Actually this requirement has got some implications in terms of the
>>> MIB design (taking
>>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07
>>> into account)
>>>
>>> - If the answer is yes, then we need to have an extra index in the
>>> power pmPowerTable. This index must abe a new TC, which is only for
>>> the Power State Series.  Note: the table needs to redesigned because
>>> the common variable (caliber, nameplate, etc...) are common per
>>> Power State Series. Then we can have a new table, for discovery,
>>> that will only contain  two indices: pmPowerMonitorIndex and the new
>>> TC-defined pmPowerStateSeries.
>>> - If the answer is no, then there is the risk that NMS1 will set the
>>> DMTF:1 for example, and then NMS2 set it EMAN:3 (assuming that the
>>> Power Monitor supports both the DMTF and the EMAN Power State
>>> Series), and there is a ping-pong game between two NMS's that don't
>>> synchronize between the two.
>> If two management systems make changes without coordination, you
>> always have a chance for ping-pong effects, even within a Power State
>> Series. That said, it might be possible to provide guidelines such as
>> if a device is reporting a value of a given Power State Series
>> (e.g. DMTF:3), a management application should adapt and use DMTF
>> power states.
>>
>>> The alternative is that the first NMS would say: I will speak to the
>>> Power Monitor with the DMTF Power State Series, and then all the
>>> other NMS's will have to speak the same language (i.e. DMTF).
>> I think that is a reasonably assumption to make if the number of
>> different Power State Series is kept limited (that is we prevent that
>> every vendor/organization comes up with its own creative series of
>> power states). A large number of different Power State Series will be
>> hindering interoperability, with or without ping-pong effects.
>>
>> /js
>>
>> -- 
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>> Fax:   +49 421 200 3103
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>>


From ietf@quittek.at  Sun Jul 24 22:31:33 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E83321F85B8 for ; Sun, 24 Jul 2011 22:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.772
X-Spam-Level: 
X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=0.476,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 0QXM+s+IFKdh for ; Sun, 24 Jul 2011 22:31:32 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1189921F8591 for ; Sun, 24 Jul 2011 22:31:32 -0700 (PDT)
Received: from [10.7.0.92] (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0M4B8t-1RcdIG2lbX-00r8pT; Mon, 25 Jul 2011 07:31:28 +0200
References: <0131AC21C657A3418A5B6CA168C4C57E0A813EA6@USA7061MS04.na.xerox.net> <23E19EBD-1A1E-47AB-BA8F-47B8E919A2DE@quittek.at> <4E2C7E87.6060505@cisco.com>  <4E2CF747.6000800@cisco.com>
In-Reply-To: <4E2CF747.6000800@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-5-404713661
Message-Id: <0ECE79A2-F1F9-41B1-92B6-804AD65E823F@quittek.at>
From: Juergen Quittek 
Date: Mon, 25 Jul 2011 01:31:18 -0400
To: Benoit Claise 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:RbQmaDEQeJ7bmkaJ3/b4PcgcYRdnFDEDHNDPLBguz5A lxeBDf7dQjSWAmEAbDMctkBjQ7pHQHs9+3982m2GEyLY2aY6wS SW0vFx2yZBuRlCrDarTHFiqIQqtx3ATcCh/SSGOJRmg5N1O8gd 7SztH00uDqmuCABXsQsED87Udce0H1UzBkakehUA8i8i0A7DRz BlxRndw1FBRnWFJpn6qjvK5ay5rxLO5naN3YvHxKGM=
Cc: eman@ietf.org, "Ebner, Fritz" 
Subject: Re: [eman] IETF EMAN request to address printers... -> draft-ietf-eman-requirements-04
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2011 05:31:33 -0000

--Apple-Mail-5-404713661
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Benoit,

I think the entire Appendix can go away.=20
It does not contribute at all to the requirements. At least not so far.

Analyzing what standard is available to meet a requirement=20
is rather the task of a solution draft, such as the framework=20
or the MIB modules, but not of a requirement draft.

My proposal would be moving the standards analysis to the framework
and discuss there also=20
  - which of these standards are used for covering requirements, for =
example,=20
    Entity MIB for identification (if we do so)
  - which parts of these standards are supported, such as, for example,
    ACPI and DMTF power sets
  - to which standards our work is aligned, for example=20
    ODVA, IEEE-ISTO PWD, SBS, etc. and how we do so.
  - from which standards we deviate

Thanks,

    Juergen

Am 25.07.2011 um 00:55 schrieb Benoit Claise:

> Hi Juergen,
>=20
> So why is there an "IEEE-ISTO Printer WG" appendix if printers are not =
mentioned a single time in the document?
>=20
> Regards, Benoit.
>>=20
>> Hi Benoit,
>>=20
>> Currently, there is the following paragraph in section 1 of =
draft-ietf-eman-requirements-04:
>>=20
>> >   The main subject of energy management are powered entities that
>> >   consume electric energy.  Powered entities include devices that =
have
>> >   an IP address and can be addressed directly, such as hosts, =
routers,
>> >   and middleboxes, as well as devices indirectly connected to an IP
>> >   network, for which a proxy with an IP address provides a =
management
>> >   interface, for example, devices in a building management
>> >   infrastructure using BACNET or MODBUS protocols.
>>=20
>> You see that we already address all kinds of IP devices: hosts, =
routers, and middleboxes.
>> There is no list of special hosts, such as servers, PCs, smart =
phones, printers, webcams, etc.=20
>> I do not see a need to introduce it. Since a printer is a device that =
can either be directly addressed with IP or that can be addressed via a =
host connected to it, I see no need to add a special comment on it, =
particularly not since I do not see any special requirements for a =
printer compared to other hosts.
>>=20
>> Rather I see a need in the framework draft to discuss if and how =
alignment with the IEEE ISTO-PWG is realized.
>>=20
>> Thanks,
>>=20
>>     Juergen
>>=20
>>=20
>> Am 24.07.2011 um 16:20 schrieb Benoit Claise:
>>=20
>>> Juergen,
>>>=20
>>> Reading this old email, I believe that we should mention "printer" =
somewhere in the requirements draft, as a device type addressed by the =
EMAN WG, and not only in the appendix.
>>>=20
>>> Regards, Benoit.
>>>> Hi Fritz,
>>>>=20
>>>> Thank you for your input.
>>>>=20
>>>> We will consider printers and the document your referred to in the =
next revision of the requirements.
>>>> I don't think many changes will need to be made here.
>>>>=20
>>>> But for the MIB documents, we now have another set of PWG =
power/functional states next to DMTF and ACPI states.
>>>>=20
>>>> Thanks,
>>>>=20
>>>>     Juergen
>>>>=20
>>>>=20
>>>> Am 18.03.2011 um 19:11 schrieb Ebner, Fritz:
>>>>=20
>>>>> Hello,
>>>>> Please make sure that any power control or monitoring MIBs or =
drafts that the EMAN WG produces can cover the use cases, power =
controls, and power monitoring features provided in the printer working =
group.  Details are below:
>>>>> =20
>>>>> The IEEE/ISTO Printer Working Group has published their Candidate =
Standard for Power Management and the associate protocol binding for =
SNMP.  Below are the links to the abstract model and MIB.
>>>>> =20
>>>>> PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0:
>>>>> =20
>>>>> The PWG Power Management Model for Imaging Systems 1.0 =
specification was=20
>>>>> recently approved as a PWG Candidate Standard and is now available =
at:
>>>>>=20
>>>>>  http://www.pwg.org/standards.html
>>>>>=20
>>>>> and
>>>>>=20
>>>>>  =
ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf =
/ doc
>>>>> =20
>>>>> PWG 5106-5 - PWG Imaging System Power MIB v1.0
>>>>> =20
>>>>> The PWG Imaging System Power MIB v1.0 specification was recently =
approved
>>>>> as a PWG Candidate Standard and is now available at:
>>>>>=20
>>>>>  http://www.pwg.org/standards.html
>>>>>=20
>>>>> and
>>>>>=20
>>>>>  =
ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf=
 / doc / mib
>>>>>  - PDF, MS Word, and ASN.1 source in plaintext
>>>>>=20
>>>>>  =
ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib=
.pdf
>>>>>  - ASN.1 source in color highlighted PDF
>>>>> =20
>>>>> Thanks,
>>>>> Fritz Ebner
>>>>> _______________________________________________
>>>>> eman mailing list
>>>>> eman@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> eman mailing list
>>>> eman@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/eman
>>>=20
>>=20
>=20


--Apple-Mail-5-404713661
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
Benoit,

I think the entire Appendix can go =
away. 
It does not contribute at all to the requirements. =
At least not so far.

Analyzing what standard is =
available to meet a requirement 
is rather the task of a =
solution draft, such as the framework 
or the MIB =
modules, but not of a requirement draft.

My =
proposal would be moving the standards analysis to the =
framework
and discuss there also 
  - =
which of these standards are used for covering requirements, for =
example, 
    Entity MIB for identification (if =
we do so)
  - which parts of these standards are =
supported, such as, for example,
    ACPI and DMTF =
power sets
  - to which standards our work is aligned, =
for example 
    ODVA, IEEE-ISTO PWD, SBS, =
etc. and how we do so.
  - from which standards =
we =
deviate

Thanks,

  =
  Juergen

Am =
25.07.2011 um 00:55 schrieb Benoit Claise:


 =20
    
 =20
  

    Hi Juergen,

    

    So why is there an "IEEE-ISTO Printer WG" appendix if printers are
    not mentioned a single time in the document?

    

    Regards, Benoit.
    

      
Hi Benoit,

      


      

      
Currently, there is the following paragraph in section 1 of
        draft-ietf-eman-requirements-04:

      


      

      

        
>   The main subject of energy management are =
powered
          entities that

        
>   consume electric energy.  Powered entities =
include
          devices that have

        
>   an IP address and can be addressed directly, =
such as
          hosts, routers,

        
>   and middleboxes, as well as devices indirectly
          connected to an IP

        
>   network, for which a proxy with an IP address
          provides a management

        
>   interface, for example, devices in a building
          management

        
>   infrastructure using BACNET or MODBUS =
protocols.

      

      


      

      
You see that we already address all kinds of IP
        devices: hosts, routers, and middleboxes.

      
There is no list of special hosts, such as servers, PCs,
        smart phones, printers, webcams, etc. 

      
I do not see a need to introduce it. Since a printer is a
        device that can either be directly addressed with IP or that can
        be addressed via a host connected to it, I see no need to add a
        special comment on it, particularly not since I do not see any
        special requirements for a printer compared to other =
hosts.

      


      

      
Rather I see a need in the framework draft to discuss if and
        how alignment with the IEEE ISTO-PWG is realized.

      


      

      
Thanks,

      


      

      
    Juergen

      


      

      


      

      

        
Am 24.07.2011 um 16:20 schrieb Benoit Claise:

        

        

          
          
 Juergen,

            

            Reading this old email, I believe that we should mention
            "printer" somewhere in the requirements draft, as a device
            type addressed by the EMAN WG, and not only in the =
appendix.

            

            Regards, Benoit.

            
Hi Fritz,
              


              

              
Thank you for your input.

              


              

              
We will consider printers and the document your
                referred to in the next revision of the =
requirements.

              
I don't think many changes will need to be made =
here.

              


              

              
But for the MIB documents, we now have another set of
                PWG power/functional states next to DMTF and ACPI
                states.

              


              

              
Thanks,

              


              

              
    Juergen

              


              

              


                

                  
Am 18.03.2011 um 19:11 schrieb Ebner, =
Fritz:

                  

                  

                    

                      

                        
Hello,

                        
Please make sure that any power
                          control or monitoring MIBs or drafts that the
                          EMAN WG produces can cover the use cases,
                          power controls, and power monitoring features
                          provided in the printer working group. 
                          Details are below:

                        
 

                        
The IEEE/ISTO Printer Working
                          Group has published their Candidate Standard
                          for Power Management and the associate
                          protocol binding for SNMP.  Below are the
                          links to the abstract model and =
MIB.

                        

                          
 

                        

                        
PWG 5106.4 - PWG Power Management
                            Model for Imaging Systems =
1.0:

                        
 

                        

            

          

        

      

      

    

    

  




=

--Apple-Mail-5-404713661--

From bclaise@cisco.com  Sun Jul 24 23:00:16 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D212121F8AEE for ; Sun, 24 Jul 2011 23:00:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.52
X-Spam-Level: 
X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-SAHUWveeSx for ; Sun, 24 Jul 2011 23:00:14 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 101E321F85DA for ; Sun, 24 Jul 2011 23:00:12 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6P5uQXK016313; Mon, 25 Jul 2011 07:56:26 +0200 (CEST)
Received: from [10.82.235.109] (rtp-vpn5-874.cisco.com [10.82.235.109]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6P5uPul021356; Mon, 25 Jul 2011 07:56:25 +0200 (CEST)
Message-ID: <4E2D0588.5040602@cisco.com>
Date: Mon, 25 Jul 2011 01:56:24 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Bruce Nordman 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030708060606040209040206"
Cc: eman mailing list 
Subject: Re: [eman] Applicability comments
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2011 06:00:16 -0000

This is a multi-part message in MIME format.
--------------030708060606040209040206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Bruce,

I believe that there is a difference between the applicability statement 
as defined in the charter, and education to the people "who have little 
or no knowledge of network technology". For example, I would see your 
point about "The management system begins with a discovery process, to 
understand what devices are in the building, and which implement EMAN.  
This needs to be redone periodically." as part of the education, and not 
necessarily the applicability statement.

Also, I don't think that an applicability statement should assume 
statement about the future WG developments (referring to your comment "A 
later version of EMAN should consider extension to forms of energy  
other than electricity")., but should concentrate on how the technology 
could be used today.

Wrt "IANA may need to establish an enumeration of device types. ", if 
IANA is involved it should be in the framework or in one of the MIB 
documents.

Regards, Benoit
>
> In March I drafted content that I felt was useful and/or necessary for an
>
> applicability statement.This was done from the perspective of what is
>
> needed for understanding and improving energy use in IT networks and
>
> buildings.That content can be seen at
>
> draft-nordman-eman-energy-perspective-01
>
> It did not attempt to cover content already in the current version of 
> the other
>
> draft.
>
> The current other draft is: draft-tychon-eman-applicability-statement-02.
>
> There has been some convergence in content since the previous draft.
>
> It seems possible and desirable to merge the two drafts.
>
> A few of these points are covered in the current other draft, though with
>
> different language and emphasis, such as the importance of reporting
>
> "identity" and classification, and the relevance and status of the Ecma
>
> Smart Data Centre project.
>
> Many other points from energy-perspective are not covered in the other 
> draft:
>
> -At least one document published by EMAN should be readily accessible to a
>
> wide range of audiences, particularly those focused on energy use, 
> most of who
>
> have little or no knowledge of network technology.The Applicability 
> Statement
>
> seems to be the only suitable one in our charter.
>
> -At the core of EMAN is simple reporting of power/energy about a 
> simple device.
>
> -The EMAN protocol can be used in "series" relaying up information through
>
> any number of intermediate devices to an EMS, collecting and/or 
> aggregating.
>
> -The NMS is out of scope.
>
> -Any energy-using device is in scope (traditional IT, other IP 
> devices, non-IP
>
> devices).
>
> -The management system begins with a discovery process, to understand
>
> what devices are in the building, and which implement EMAN.This needs
>
> to be redone periodically.
>
> -Further details on how discovery may be implemented.
>
> -Devices may report intermittently due to being in a low-power state,
>
> being portable, or leaving the building permanently.
>
> -Ultimately, one key outlet for EMAN information is presentation (via an
>
> application) to people.
>
> -A later version of EMAN should consider extension to forms of energy
>
> other than electricity.
>
> -The Use Cases for EMAN can be viewed along three primary axes:
>
> -Management context: loosely, highly, or hybrid.
>
> -Building type: residential, commercial, data center, vehicle, other.
>
> -Device type: IT, other electronic, non-electronic.
>
> -Power distribution domains are becoming more varied and complex.
>
> -For measurement standards, IEC 62301 is widely used and relevant.
>
> -IANA may need to establish an enumeration of device types.
>
> -There are security issues related to control functions in changing
>
> what services a device provides, and potentially perturbing the
>
> power system with widely coordinated changes in energy demand.
>
> All of these points seem suitable and appropriate to be in a working
>
> group draft for Applicability.
>
> A few detailed comments on draft-tychon-eman-applicability-statement-02
>
> follow.
>
> 1.1
>
> --it seems unnecessary to define energy here -- other drafts will do that.
>
> -proxying and aggregation are mixed. They are distinct functions and
>
> one device can implement one, the other, or both.
>
> 2.
>
> -the "Scenarios and Target Devices" section mixes specific device types,
>
> with methods of powering devices.It would be helpful to separate
>
> these as well as to include the "use contexts" from the energy draft.
>
> There is also some redundancy in this section.
>
> 4.
>
> -other standards should be divided into measurement standards,
>
> reporting standards, and other standards.
>
> It may be that it would be helpful to create another document
>
> as output from the working group that is the primary document
>
> intended to be accessible to many readers, and to include detailed
>
> discussions of implementation scenarios.This would pull out some
>
> of the content described above and add to it.
>
> --Bruce (as contributor; I am off email Monday->Saturday)
>
>
>
> -- 
> *Bruce Nordman*
> Lawrence Berkeley National Laboratory
> eetd.lbl.gov/ea/nordman 
> BNordman@LBL.gov
> 510-486-7089
> m: 510-501-7943
>
>
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


--------------030708060606040209040206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Bruce,

    

    I believe that there is a difference between the applicability
    statement as defined in the charter, and education to the people
    "who have little or no knowledge of network
    technology". For example, I would see your point about "The
    management system begins with a discovery process, to
    understand what devices are in the building, and
    which implement EMAN.  This needs to be redone periodically." as
    part of the education, and not necessarily the applicability
    statement.

    

    Also, I don't think that an applicability statement should assume
    statement about the future WG developments (referring to your
    comment "A later version of EMAN should consider extension to forms
    of energy  other than electricity")., but should concentrate on how
    the technology could be used today.

    

    Wrt "IANA may need to establish an enumeration of device types.
    ", if IANA is involved it should be in the framework or in one of
    the MIB documents.

    

    Regards, Benoit

    

        
      
      
In March I drafted content that
          I felt was useful and/or necessary
          for an 

      
        
      
applicability statement. 
          This was done from the perspective of what is 

      
        
      
needed for understanding and
          improving energy use in IT
          networks and 

      
        
      
buildings.  That
          content can be seen at

      
        
      
draft-nordman-eman-energy-perspective-01

      
        
      
It did not attempt to cover
          content already in the current
          version of the other

      
        
      
draft.

      
        
      
 

      
        
      
The current other draft is:
          draft-tychon-eman-applicability-statement-02.

      
        
      
There has been some convergence
          in content since the
          previous draft.

      
        
      
It seems possible and desirable
          to merge the two drafts.

      
        
      
 

      
        
      
A few of these points are
          covered in the current other
          draft, though with

      
        
      
different language and
          emphasis, such as the importance of
          reporting 

      
        
      
“identity” and classification,
          and the relevance and status
          of the Ecma 

      
        
      
Smart Data Centre project.

      
        
      
 

      
        
      
Many other points from
          energy-perspective are not covered in
          the other draft:

      
        
      
 

      
        
      
-At least one document
          published by EMAN should be readily
          accessible to a

      
        
      
   wide
          range of audiences, particularly
          those focused on energy use, most of who

      
        
      
   have
          little or no knowledge of network
          technology.  The Applicability
          Statement

      
        
      
   seems
          to be the only suitable one in
          our charter.

    

    

        
      
-At the core of EMAN is simple
          reporting of power/energy
          about a simple device.

      
        
      
-The EMAN protocol can be used
          in “series” relaying up
          information through

      
        
      
   any
          number of intermediate devices to
          an EMS, collecting and/or aggregating.

      
        
      
-The NMS is out of scope.

      
        
      
-Any energy-using device is in
          scope (traditional IT, other
          IP devices, non-IP

      
        
      
   devices).

      
        
      
-The management system begins
          with a discovery process, to
          understand

      
        
      
   what
          devices are in the building, and
          which implement EMAN.  This needs

      
        
      
   to
          be redone periodically.

      
        
      
  -Further
          details on how discovery may be implemented.

      
        
      
-Devices may report
          intermittently due to being in a
          low-power state,

      
        
      
   being
          portable, or leaving the building
          permanently.

      
        
      
-Ultimately, one key outlet for
          EMAN information is
          presentation (via an

      
        
      
   application)
          to people.

      
        
      
-A later version of EMAN should
          consider extension to forms
          of energy

      
        
      
  other
          than electricity. 

      
        
      
-The Use Cases for EMAN can be
          viewed along three primary
          axes:

      
        
      
  -Management
          context: loosely, highly, or hybrid.

      
        
      
  -Building
          type: residential, commercial, data center, vehicle, other.

      
        
      
  -Device type:
          IT, other electronic, non-electronic.

      
        
      
-Power distribution domains are
          becoming more varied and
          complex.

      
        
      
-For measurement standards, IEC
          62301 is widely used and
          relevant.

      
        
      
-IANA may need to establish an
          enumeration of device types.

      
        
      
-There are security issues
          related to control functions in
          changing

      
        
      
  what services
          a device provides, and potentially perturbing the

      
        
      
  power system
          with widely coordinated changes in energy demand.

      
        
      
 

      
        
      
All of these points seem
          suitable and appropriate to be in a
          working

      
        
      
group draft for Applicability.

      
        
      
 

      
        
      
A few detailed comments on
          draft-tychon-eman-applicability-statement-02

      
        
      
follow.  

      
        
      
1.1

      
        
      
–it seems unnecessary to define
          energy here – other drafts
          will do that.

      
        
      
-proxying and aggregation are
          mixed. They are distinct
          functions and

      
        
      
  one device can
          implement one, the other, or both.

      
        
      
2.

      
        
      
-the “Scenarios and Target
          Devices” section mixes specific
          device types,

      
        
      
  with methods
          of powering devices.  It would be
          helpful to separate

      
        
      
  these as well
          as to include the “use contexts” from the energy draft.

      
        
      
  There is also
          some redundancy in this section.

      
        
      
4.

      
        
      
-other standards should be
          divided into measurement
          standards,

      
        
      
  
          reporting standards, and other standards.

      
        
      
 

      
        
      
It may be that it would be
          helpful to create another
          document

      
        
      
as output from the working
          group that is the primary
          document

      
        
      
intended to be accessible to
          many readers, and to include
          detailed

      
        
      
discussions of implementation
          scenarios.  This would pull out some

      
        
      
of the content described above
          and add to it.

      
        
      
 

      
        
      
--Bruce (as contributor; I am
          off email Monday->Saturday)

      
        

        

        -- 

      Bruce Nordman

        Lawrence Berkeley National
          Laboratory

        eetd.lbl.gov/ea/nordman

        BNordman@LBL.gov

        510-486-7089

        m:
          510-501-7943

        

      
      

      

      

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


    

    

  


--------------030708060606040209040206--

From Thomas.Dietz@neclab.eu  Mon Jul 25 01:26:23 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DD221F85FF for ; Mon, 25 Jul 2011 01:26:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 JME95eCWGekn for ; Mon, 25 Jul 2011 01:26:21 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA5321F8512 for ; Mon, 25 Jul 2011 01:26:20 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5D0C7280002FE; Mon, 25 Jul 2011 10:26:19 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIEJLhHwv1Gl; Mon, 25 Jul 2011 10:26:19 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 36D52280001AA; Mon, 25 Jul 2011 10:26:04 +0200 (CEST)
Received: from Polydeuces.office.hd ([169.254.3.125]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 25 Jul 2011 10:26:04 +0200
From: Thomas Dietz 
To: Benoit Claise , Juergen Quittek 
Thread-Topic: [eman] Do we need power state transition count and time in state?
Thread-Index: AQHL9fQ/R21OJYT8WUKnIsjtdvbL65RT4uGAgAAAvICAAAIlgIAADHcAgAAJMoCAB9InAIAAAMsAgAAAlACAAAkzAIChEPoAgABy12A=
Date: Mon, 25 Jul 2011 08:26:03 +0000
Message-ID: <75581E268A48F849916117B977D76D372CCD500E@Polydeuces.office.hd>
References: <4D9DE17D.5090606@cisco.com> <4D9F12FE.3080409@cisco.com> <20110408142048.GA81222@elstar.local> <4D9F1A5F.1030107@cisco.com> <20110408143107.GA81369@elstar.local> <4D9F26A0.20407@cisco.com> <20110408154839.GA81729@elstar.local> <4DA5BDDE.9060607@cisco.com> <20110413151728.GA32536@elstar.local> <4DA5BF04.8030204@cisco.com>  <4E2CE376.8050504@cisco.com>
In-Reply-To: <4E2CE376.8050504@cisco.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.1.137]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01CC4AB5.40F29F00"
MIME-Version: 1.0
Cc: "eman@ietf.org" 
Subject: Re: [eman] Do we need power state transition count and time in	state?
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2011 08:26:23 -0000

------=_NextPart_000_0008_01CC4AB5.40F29F00
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0009_01CC4AB5.40F29F00"


------=_NextPart_001_0009_01CC4AB5.40F29F00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Benoit, all,

 

I support having those objects in the MIB. The only point where those values
can be measured accurate is the device itself, and the values can be useful
for a number of use cases. We still can make those objects optional as
Juergen already suggested so that they don't need to be implemented if the
device does not or cannot support them.

 

Best Regards,

 

Thomas

 

-- 

Thomas Dietz

NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115
Heidelberg, Germany

 

NEC Europe Limited, Registered in England 2832014

Registered Office: NEC House, 1 Victoria Road, London W3 6BL

 

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Benoit Claise
Sent: Montag, 25. Juli 2011 05:31
To: Juergen Quittek
Cc: eman@ietf.org
Subject: Re: [eman] Do we need power state transition count and time in
state?

 

Dear all,

I'm not sure what is the conclusion regarding this old email about "Do we
need power state transition count and time in state?"
Currently, the EMAN requirements draft contains:


5.2.7.  Power state statistics


 


   The energy management standard must provide means for monitoring


   statistics per power state including at least the total time spent in


   a power state, the number of times a state was entered and the last


   time a state was entered.  More power state statistics are addressed


   by requirement 5.5.3.


Is this the consensus on the mailing list?

Regards, Benoit.



Am 13.04.2011 um 17:19 schrieb Russ White:

 

I assume people find it important to know the percentage of time a
device spends in a certain power state. Approximating this by active
polling of the current state is pretty inefficient and inaccurate
since you can miss state changes. If the device records the time spent
in each state, you get a precise breakdown of the time spend in each
power state between each poll, which means you can safely poll at a
much lower frequency.

 
It seems like this should be put into an extension, rather than in the
base spec... Or as a device specific option (given we build the branches
of information we had discussed on list before).

 
And the reason is?

 
Because this doesn't seem to be useful for all devices... And because we
should try and keep the MIB size down, with extensions, rather than
trying to bundle everything possible into the base MIB.

 
What about having it in the same MIB, but making it optional to implement?
 
    Juergen
 
 

:-)
 
Russ
 
 
 
-- 
riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone
 
Belief is a wise wager. Granted that faith cannot be proved, what harm
will come to you if you gamble on its truth and it proves false? If you
gain, you gain all; if you lose, you lose nothing. Wager, then, without
hesitation, that He exists. Blaise Pascal
 
 
_______________________________________________
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

 


------=_NextPart_001_0009_01CC4AB5.40F29F00
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Benoit, all,
 
I support having those objects in the MIB. The only point where those =
values can be measured accurate is the device itself, and the values can =
be useful for a number of use cases. We still can make those objects =
optional as Juergen already suggested so that they don’t need to =
be implemented if the device does not or cannot support =
them.
 
Best Regards,
 
Thomas
 
-- 
Thomas Dietz
NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 =
Heidelberg, Germany
 
NEC Europe Limited, Registered in England =
2832014
Registered Office: NEC House, 1 Victoria Road, London W3 =
6BL
 
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of Benoit Claise
Sent: Montag, 25. Juli 2011 =
05:31
To: Juergen Quittek
Cc: =
eman@ietf.org
Subject: Re: [eman] Do we need power state =
transition count and time in state?
 
Dear all,

I'm not sure what is the =
conclusion regarding this old email about "Do we need power state =
transition count and time in state?"
Currently, the EMAN =
requirements draft contains:
5.2.7.  =
Power state statistics
 
   The energy management =
standard must provide means for =
monitoring
   statistics per power state including at least the =
total time spent in
   a power state, the =
number of times a state was entered and the =
last
   time a state was entered.  More power state =
statistics are addressed
   by requirement =
5.5.3.
Is this the consensus =
on the mailing list?

Regards, =
Benoit.

Am 13.04.2011 um 17:19 schrieb Russ =
White:
 
I assume people find =
it important to know the percentage of time =
a
device spends in a certain power state. =
Approximating this by active
polling of the current =
state is pretty inefficient and inaccurate
since =
you can miss state changes. If the device records the time =
spent
in each state, you get a precise breakdown of =
the time spend in each
power state between each =
poll, which means you can safely poll at a
much =
lower =
frequency.
 
=
It seems like this should be put into an extension, rather than in =
the
base spec... Or as a device specific option =
(given we build the branches
of information we had =
discussed on list =
before).
 
An=
d the reason =
is?
 
Because=
 this doesn't seem to be useful for all devices... And because =
we
should try and keep the MIB size down, with =
extensions, rather than
trying to bundle everything =
possible into the base =
MIB.
 
What =
about having it in the same MIB, but making it optional to =
implement?
 
  &=
nbsp; =
Juergen
 
 
:-)
<=
pre> 
Russ
 
 
 
-- =

riw@cisco.com =
:: CCIE :: CCDE :: <>< Grace =
Alone
 
Belief is a wise =
wager. Granted that faith cannot be proved, what =
harm
will come to you if you gamble on its truth =
and it proves false? If you
gain, you gain all; if =
you lose, you lose nothing. Wager, then, =
without
hesitation, that He exists. Blaise =
Pascal
 
 =

_______________________________________________
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
 

------=_NextPart_001_0009_01CC4AB5.40F29F00--

------=_NextPart_000_0008_01CC4AB5.40F29F00
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNDCCA58w
ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz
Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT
GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw
MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT
FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD
QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu
3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp
I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB
PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP
GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq
B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw
BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL
E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH
YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ
5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f
uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj
KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG
EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy
dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5
MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp
bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA
W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b
AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj
pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9
ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7
wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j
Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1
ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW
gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB
AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd
GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/
M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4
XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z
a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX
oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W
ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt
IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG
A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES
MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA
bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf
ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r
Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B
PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf
tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+
/7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E
BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/
6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu
ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290
LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh
bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw
AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy
dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev
cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/
eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr
SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp
sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T
HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj
cEUYyiOSE+SFUTEdMIIFNTCCBB2gAwIBAgIED+0gWzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE
BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll
cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1
bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQ5MTVaFw0xMzA0MTkxMjQ5MTVaMGAx
CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv
cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQD2mMcvPbgraEaWMV6uNCs6t88lhBczgfxybD46mwr8D3VaQLEnqTsBOAf/
Y8ARtq+P6Dkm2MBMXQG+Ebo2qhif6O4dH7whcG9E88F9247R2EJjcXmxMYZWYGQTI2vGw/joerRB
waiwfxCXWBTLutbdWEEKL/DG9A1yQRPGJc+jJYfgm0ekYn+WESOLYaBH7G9aIIZQ7en3afhPpbQA
Ajh92K240TG+VgBpe1vnDdth28Ps5XeN+otookDZHwwGQYwYrPZJtnhGIyjKMm7OkXL62Rf3aSoI
doVUwYYS67RYYNOY0C7qOVyCUF+z4Bkn758sZhZzotiLQVT3AZ625PrvAgMBAAGjggHEMIIBwDAJ
BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG
AQQBgjcUAgIwHQYDVR0OBBYEFH9fxgi2EshupgLF49SzaAX0QFoMMB8GA1UdIwQYMBaAFE8ch3od
4C+Z9r4VqtE1nQ5K5ro2MCEGA1UdEQQaMBiBFlRob21hcy5EaWV0ekBuZWNsYWIuZXUwfQYDVR0f
BHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNy
bC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2Fj
cmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRm
bi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8v
Y2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN
AQEFBQADggEBACnPHI1mIY1TVY9Aj8zsHHxiwMRx02Hp6DLZGYXHGG9IkflrRKNiDIV2LbBDpXVH
vojMxTtCt10iwbyVMGaevet/VHYCJSHzrCLkw+GkvuhDU70lNsWw9P+mai7OHa+NQ6im8+4RnY1B
yhqidcCt3hIV9B69ax0/KIhIFpiWz/lKZVIghki07I4m8mf1sbvCORKxudH0TVLlRJlX1r8S+8ea
9e+Q8pgXfrsCeyxBV3KAjszRQkqDZsbD7jQHQWokkMPIjbaTjw6V/5SRzmcAy0XlKNOCbldlzmCB
jDZTQWdSH/AFDy5L2l4j0Ck0vVlQv+r1F4omsb4BelRq+vHd+lExggQsMIIEKAIBATCBmTCBkDEL
MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y
YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm
aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzAJBgUrDgMCGgUAoIICZzAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA3MjUwODI2MDJaMCMGCSqGSIb3
DQEJBDEWBBQ1nnPEcMxrMRtZw3NIcJhLf35r4zCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQswCQYD
VQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9y
aWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemll
cnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQP7SBbMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC
AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCG
SAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB
kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh
Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy
dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzANBgkqhkiG9w0BAQEFAASCAQA+
NYKmD3shLBvzH2ZoRNg3hArqr9e8ZlNZ4uOWv9kdncRdaIltoQWTZ3Ll7z6SsObEcXOuPut9x1BT
ien8vALIn4pLP2YhE6qvGNdkoMUw0NLXHa6U1K3GBjrBVQqkl9dAlEZvk7ViYeqZB+eiz6+tvX5v
rwOeAHjDfKjf+jcKlOqVAngoKIau+UH81joIQnO3NW3CIb0SAGH7HY32MUOxThf4IaFeUpMTzJvh
ggSqnNuPhiMUztPOeBDTyUJM4pCJ5c9+54ETc+2DpfOaw6vC5ocaxOO00Ae0MMchBlLRZSXf5xHD
6XQZVuXJX5ePpY/et8VBDQPa+tO9WwP+CNtYAAAAAAAA

------=_NextPart_000_0008_01CC4AB5.40F29F00--

From Thomas.Dietz@neclab.eu  Mon Jul 25 01:39:06 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6334521F8B26 for ; Mon, 25 Jul 2011 01:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jb81Ov0W0kmh for ; Mon, 25 Jul 2011 01:39:05 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3E02021F8B16 for ; Mon, 25 Jul 2011 01:39:05 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6D058280002FE; Mon, 25 Jul 2011 10:39:04 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFVFHSjoKFUm; Mon, 25 Jul 2011 10:39:04 +0200 (CEST)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 46DCD280001AA; Mon, 25 Jul 2011 10:38:49 +0200 (CEST)
Received: from Polydeuces.office.hd ([169.254.3.125]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Mon, 25 Jul 2011 10:38:48 +0200
From: Thomas Dietz 
To: Benoit Claise , "Mielke, William F (Bill)" 
Thread-Topic: [eman] Two NMS configuring the Power Monitor with two different Power State Series
Thread-Index: AQHMCXFiSCfqP4ogWEKUmuBzMsYh5ZR6tKGAgIIeIYCAAAuRgIAAWfxQ
Date: Mon, 25 Jul 2011 08:38:48 +0000
Message-ID: <75581E268A48F849916117B977D76D372CCD502D@Polydeuces.office.hd>
References: <4DBFC56E.2020908@cisco.com> <20110503092855.GA3772@elstar.local> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D5C0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4E2CFB1B.3030403@cisco.com>
In-Reply-To: <4E2CFB1B.3030403@cisco.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.1.137]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0010_01CC4AB7.0954BA40"
MIME-Version: 1.0
Cc: eman mailing list 
Subject: Re: [eman] Two NMS configuring the Power Monitor with two different Power State Series
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, 25 Jul 2011 08:39:06 -0000

------=_NextPart_000_0010_01CC4AB7.0954BA40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Bill,

The way set forward in the recent draft that was pointed out by Benoit gives
the different NMS the freedom to choose which power series to take if the
managed object supports more than one. And I don't think it is much of an
overhead for the managed object to match one power series to another.

Best Regards,

Thomas

-- 
Thomas Dietz
NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115
Heidelberg, Germany

NEC Europe Limited, Registered in England 2832014
Registered Office: NEC House, 1 Victoria Road, London W3 6BL


> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> Benoit Claise
> Sent: Montag, 25. Juli 2011 07:12
> To: Mielke, William F (Bill)
> Cc: eman mailing list
> Subject: Re: [eman] Two NMS configuring the Power Monitor with two
> different Power State Series
> 
> Hi Bill,
> > I apologize for having gone silent for so long but I am here in Quebec
> and am working through old emails to come back up to speed.  I also
> apologize for perhaps covering old ground in some cases.  I plan to
> comment as I go chronologically through the list archive.  If I comment on
> something which was later resolved please bear with me as I will
> eventually find the resolution along the way.  Either way it is probably
> better that I record my comments in the event that I identify something
> that has not been considered fully.
> >
> > Regarding the issue of 2 NMS's interacting with a single Managed Object
> using different power state series, my thinking all along was that the
> managed object would choose (align with) the power series that made sense
> for it and that the NMS's would have to adapt to talking to the managed
> object in its preferred  (supported) series.  So in this case there is no
> confusion, the series selected by the managed object is always the one
> that will be used by any NMS.  This approach is consistent with Juergen S.
> point that traditionally the NMS was assumed to be better able to deal
> with these types of variations rather then the managed object
> implementation.
> >
> > How was this point ultimately resolved, assuming it was?
> By having an extra index in the tables. First the power state series,
> then the power state.
> From http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09:
> 
>         pmPowerTable OBJECT-TYPE
>              SYNTAX          SEQUENCE OF PmPowerEntry
>              MAX-ACCESS      not-accessible
>              STATUS          current
>              DESCRIPTION
>                 "This table lists Power Monitors."
>              ::= { powerMonitorMIBObjects 1 }
> 
>          pmPowerEntry OBJECT-TYPE
>              SYNTAX          PmPowerEntry
>              MAX-ACCESS      not-accessible
>              STATUS          current
>              DESCRIPTION
>                 "An entry describes the power usage of a Power Monitor."
>              INDEX           { pmPowerIndex, pmPowerStateSetIndex}
> 
> 
> 
> >
> > William F. Mielke
> > Alcatel-Lucent
> > Distinguished Member of Technical Staff
> > 6200 East Broad Street
> > Room: 4B01-1V
> > Columbus, OH  43213-1530
> > Email: Bill.Mielke@alcatel-lucent.com
> > Phone: 614 367 5628
> > Fax: 614 367 5965
> >
> > "Live like you're going to die tomorrow.
> >   Learn like you're going to live forever."
> >
> >      - Albert Einstein
> >
> >
> >
> >> -----Original Message-----
> >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On
> >> Behalf Of Juergen Schoenwaelder
> >> Sent: Tuesday, May 03, 2011 5:29 AM
> >> To: Benoit Claise
> >> Cc: eman mailing list
> >> Subject: Re: [eman] Two NMS configuring the Power Monitor
> >> with two different Power State Series
> >>
> >> On Tue, May 03, 2011 at 11:05:50AM +0200, Benoit Claise wrote:
> >>
> >>> Let's discuss the following situation: what if we have 2 NMS', and
> >>> they speak different Power State Series for a specific Power
> >>> Monitor? Should this be allowed by the [EMAN-REQ]?
> >> Traditionally, it was always assumed that an SNMP management system
> >> can more easily adapt to devices than the other way round.
> >>
> >>> Actually this requirement has got some implications in terms of the
> >>> MIB design (taking
> >>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07
> >>> into account)
> >>>
> >>> - If the answer is yes, then we need to have an extra index in the
> >>> power pmPowerTable. This index must abe a new TC, which is only for
> >>> the Power State Series.  Note: the table needs to redesigned because
> >>> the common variable (caliber, nameplate, etc...) are common per
> >>> Power State Series. Then we can have a new table, for discovery,
> >>> that will only contain  two indices: pmPowerMonitorIndex and the new
> >>> TC-defined pmPowerStateSeries.
> >>> - If the answer is no, then there is the risk that NMS1 will set the
> >>> DMTF:1 for example, and then NMS2 set it EMAN:3 (assuming that the
> >>> Power Monitor supports both the DMTF and the EMAN Power State
> >>> Series), and there is a ping-pong game between two NMS's that don't
> >>> synchronize between the two.
> >> If two management systems make changes without coordination, you
> >> always have a chance for ping-pong effects, even within a Power State
> >> Series. That said, it might be possible to provide guidelines such as
> >> if a device is reporting a value of a given Power State Series
> >> (e.g. DMTF:3), a management application should adapt and use DMTF
> >> power states.
> >>
> >>> The alternative is that the first NMS would say: I will speak to the
> >>> Power Monitor with the DMTF Power State Series, and then all the
> >>> other NMS's will have to speak the same language (i.e. DMTF).
> >> I think that is a reasonably assumption to make if the number of
> >> different Power State Series is kept limited (that is we prevent that
> >> every vendor/organization comes up with its own creative series of
> >> power states). A large number of different Power State Series will be
> >> hindering interoperability, with or without ping-pong effects.
> >>
> >> /js
> >>
> >> --
> >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> >> Fax:   +49 421 200 3103
> >> _______________________________________________
> >> eman mailing list
> >> eman@ietf.org
> >> https://www.ietf.org/mailman/listinfo/eman
> >>
> 
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman

------=_NextPart_000_0010_01CC4AB7.0954BA40
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNDCCA58w
ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz
Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT
GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw
MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT
FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD
QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu
3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp
I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB
PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP
GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq
B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw
BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL
E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH
YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ
5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f
uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj
KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG
EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy
dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5
MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp
bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA
W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b
AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj
pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9
ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7
wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j
Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1
ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW
gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB
AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd
GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/
M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4
XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z
a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX
oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W
ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt
IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG
A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES
MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA
bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf
ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r
Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B
PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf
tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+
/7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E
BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/
6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu
ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290
LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh
bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw
AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy
dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev
cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/
eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr
SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp
sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T
HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj
cEUYyiOSE+SFUTEdMIIFNTCCBB2gAwIBAgIED+0gWzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE
BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll
cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1
bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQ5MTVaFw0xMzA0MTkxMjQ5MTVaMGAx
CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv
cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQD2mMcvPbgraEaWMV6uNCs6t88lhBczgfxybD46mwr8D3VaQLEnqTsBOAf/
Y8ARtq+P6Dkm2MBMXQG+Ebo2qhif6O4dH7whcG9E88F9247R2EJjcXmxMYZWYGQTI2vGw/joerRB
waiwfxCXWBTLutbdWEEKL/DG9A1yQRPGJc+jJYfgm0ekYn+WESOLYaBH7G9aIIZQ7en3afhPpbQA
Ajh92K240TG+VgBpe1vnDdth28Ps5XeN+otookDZHwwGQYwYrPZJtnhGIyjKMm7OkXL62Rf3aSoI
doVUwYYS67RYYNOY0C7qOVyCUF+z4Bkn758sZhZzotiLQVT3AZ625PrvAgMBAAGjggHEMIIBwDAJ
BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG
AQQBgjcUAgIwHQYDVR0OBBYEFH9fxgi2EshupgLF49SzaAX0QFoMMB8GA1UdIwQYMBaAFE8ch3od
4C+Z9r4VqtE1nQ5K5ro2MCEGA1UdEQQaMBiBFlRob21hcy5EaWV0ekBuZWNsYWIuZXUwfQYDVR0f
BHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNy
bC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2Fj
cmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRm
bi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8v
Y2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN
AQEFBQADggEBACnPHI1mIY1TVY9Aj8zsHHxiwMRx02Hp6DLZGYXHGG9IkflrRKNiDIV2LbBDpXVH
vojMxTtCt10iwbyVMGaevet/VHYCJSHzrCLkw+GkvuhDU70lNsWw9P+mai7OHa+NQ6im8+4RnY1B
yhqidcCt3hIV9B69ax0/KIhIFpiWz/lKZVIghki07I4m8mf1sbvCORKxudH0TVLlRJlX1r8S+8ea
9e+Q8pgXfrsCeyxBV3KAjszRQkqDZsbD7jQHQWokkMPIjbaTjw6V/5SRzmcAy0XlKNOCbldlzmCB
jDZTQWdSH/AFDy5L2l4j0Ck0vVlQv+r1F4omsb4BelRq+vHd+lExggQsMIIEKAIBATCBmTCBkDEL
MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y
YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm
aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzAJBgUrDgMCGgUAoIICZzAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA3MjUwODM4NDhaMCMGCSqGSIb3
DQEJBDEWBBSVN9sYMcP5AXe6uesJd2ojImfrAjCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQswCQYD
VQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9y
aWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemll
cnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQP7SBbMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC
AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCG
SAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB
kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh
Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy
dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzANBgkqhkiG9w0BAQEFAASCAQDo
cSUyesptaGQM5LoRN1mt8OkM21NT2ZADtYVQQdJHhbM+6jivapwrzsmfcf1EhNRZ9cvKKSkBGEQi
1BOFeUDZdktDpf5kI0ddJErXn9xjaBiMvwQ69OuT+n+ACQEp85lJc1yyUh+a6T5BZteJxLpyjguH
e3RKrWKEjhrpin3Trqyc/1XOhCrZLqnFDh+Ux1E1B/uSCiYC+WoSnkoSA4EGmL5ieA4/ywYfCFFB
eGEMaSyM8lyZcpfLvWfKRw2mHcpLuzYcPLV3kuWpQOXrzd37bl721ktmijWl/Il2FUkLV4kVkDKl
ZQF6tHTR+kTJGWOja/h+X5dzwcgLJhCt3O1wAAAAAAAA

------=_NextPart_000_0010_01CC4AB7.0954BA40--

From bclaise@cisco.com  Mon Jul 25 06:36:24 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DDD21F86B3 for ; Mon, 25 Jul 2011 06:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level: 
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA7o5Dth6FWK for ; Mon, 25 Jul 2011 06:36:24 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEBA21F854C for ; Mon, 25 Jul 2011 06:36:23 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6PDaLTc022352; Mon, 25 Jul 2011 15:36:21 +0200 (CEST)
Received: from [10.82.232.206] (rtp-vpn5-206.cisco.com [10.82.232.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6PDa8HK002553; Mon, 25 Jul 2011 15:36:09 +0200 (CEST)
Message-ID: <4E2D7148.4030207@cisco.com>
Date: Mon, 25 Jul 2011 09:36:08 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "Mouli Chandramouli (moulchan)" 
References: <4E2C76A3.90203@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: eman mailing list 
Subject: Re: [eman] Meeting + Agenda + presentation
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, 25 Jul 2011 13:36:24 -0000

Hi Mouli,
> Hi Bruce and Benoit,
>
> Thanks for allocating 15 minutes of the Agenda for the Monitoring MIB.
>
> There are 3 or 4 open issues and we would like to get feedback from the
> WG so that we can make progress.
Great. This is exactly what the presentation time should be focusing on.

Regards, Benoit.
> Expecting a lot of questions ...
>
> My request is that the timeslot is not reduced.
>
> Thanks for your consideration.
> Mouli
>
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> Benoit Claise (bclaise)
> Sent: Monday, July 25, 2011 1:17 AM
> To: eman mailing list
> Subject: [eman] Meeting + Agenda + presentation
>
> Dear all,
>
> The meeting is Thursday at 17h40, in the ROOM 204B.
> The agenda is posted at
> http://www.ietf.org/proceedings/81/agenda/eman.txt
> Presenters, please send your ppt by Wednesday.
>
> Regards, Benoit.
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From wamwagner@comcast.net  Mon Jul 25 09:24:05 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E1622800F for ; Mon, 25 Jul 2011 09:24:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HeYiSCCQi3EY for ; Mon, 25 Jul 2011 09:24:01 -0700 (PDT)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6B522800D for ; Mon, 25 Jul 2011 09:23:56 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by QMTA11.westchester.pa.mail.comcast.net with comcast id CG631h0021vXlb85BGPwNE; Mon, 25 Jul 2011 16:23:56 +0000
Received: from VistaBusiness ([24.61.240.234]) by omta17.westchester.pa.mail.comcast.net with comcast id CGPn1h01D548CT43dGPrzu; Mon, 25 Jul 2011 16:23:53 +0000
From: "William Wagner" 
To: "'Juergen Quittek'" , "'Benoit Claise'" 
References: <0131AC21C657A3418A5B6CA168C4C57E0A813EA6@USA7061MS04.na.xerox.net>	<23E19EBD-1A1E-47AB-BA8F-47B8E919A2DE@quittek.at>	<4E2C7E87.6060505@cisco.com>		<4E2CF747.6000800@cisco.com> <0ECE79A2-F1F9-41B1-92B6-804AD65E823F@quittek.at>
In-Reply-To: <0ECE79A2-F1F9-41B1-92B6-804AD65E823F@quittek.at>
Date: Mon, 25 Jul 2011 12:23:41 -0400
Message-ID: <006e01cc4ae7$3a71f770$af55e650$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01CC4AC5.B3605770"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcxKjB9sLbcqdwmmQkKVKKqHbD7FRAAU9s2g
Content-Language: en-us
Cc: eman@ietf.org, "'Ebner, Fritz'" 
Subject: Re: [eman] IETF EMAN request to address printers... ->	draft-ietf-eman-requirements-04
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2011 16:24:05 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_006F_01CC4AC5.B3605770
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Gentlemen,

 

As chairman of the IEEE-ISTO PWG workgroup that produced the  PWG Power
Management Model for Imaging Systems and the associated MIB
(ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.mib)
, I must say that the "printer" industry has been following the  'eman'
activites with interest and perhaps some apprehension. Although we  intend
to be compliant with industry standards, and anticipate our customers to
require that, we believe that the PWG Power Management Model best addresses
the unique power characteristics of hardcopy imaging equipment.  We realize
that all suppliers tend to regard their products as unique; but it must be
recognized that "printers" , particularly in the enterprise, have long
ceased to be little peripheral devices. They are now reasonably called
Multifunction Devices; perform copy, scan and facsimile functions as well as
printing; and have significant computing, storage and communication
components as well as electromechanical and often thermal processing
components. The power characteristics of these components and the somewhat
different duty cycle requirements compared with other networked devices
predicate the need for some special management elements, and we have spent
significant time and effort agreeing on these. 

 

The emergence of a separate IETF energy standard (or set of standards) that
does not recognize the existence of a power standard developed by and custom
to a particular industry would create confusion and act contrary to ensuring
interoperability. We would hope that in the 'eman' documentation, the PWG
Imaging Systems Power Management MIB is referenced and considered with
respect to applicability, coverage, and compatibility with 'eman'
objectives, so that users see that the eman and PWG products can complement
rather than substitute for each other. 

 

Thank you,

 

Bill Wagner, Chair WIMS/PWG

 

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Juergen Quittek
Sent: Monday, July 25, 2011 1:31 AM
To: Benoit Claise
Cc: eman@ietf.org; Ebner, Fritz
Subject: Re: [eman] IETF EMAN request to address printers... ->
draft-ietf-eman-requirements-04

 

Hi Benoit,

 

I think the entire Appendix can go away. 

It does not contribute at all to the requirements. At least not so far.

 

Analyzing what standard is available to meet a requirement 

is rather the task of a solution draft, such as the framework 

or the MIB modules, but not of a requirement draft.

 

My proposal would be moving the standards analysis to the framework

and discuss there also 

  - which of these standards are used for covering requirements, for
example, 

    Entity MIB for identification (if we do so)

  - which parts of these standards are supported, such as, for example,

    ACPI and DMTF power sets

  - to which standards our work is aligned, for example 

    ODVA, IEEE-ISTO PWD, SBS, etc. and how we do so.

  - from which standards we deviate

 

Thanks,

 

    Juergen

 

Am 25.07.2011 um 00:55 schrieb Benoit Claise:





Hi Juergen,

So why is there an "IEEE-ISTO Printer WG" appendix if printers are not
mentioned a single time in the document?

Regards, Benoit. 

Hi Benoit,

 

Currently, there is the following paragraph in section 1 of
draft-ietf-eman-requirements-04:

 

>   The main subject of energy management are powered entities that

>   consume electric energy.  Powered entities include devices that have

>   an IP address and can be addressed directly, such as hosts, routers,

>   and middleboxes, as well as devices indirectly connected to an IP

>   network, for which a proxy with an IP address provides a management

>   interface, for example, devices in a building management

>   infrastructure using BACNET or MODBUS protocols.

 

You see that we already address all kinds of IP devices: hosts, routers, and
middleboxes.

There is no list of special hosts, such as servers, PCs, smart phones,
printers, webcams, etc. 

I do not see a need to introduce it. Since a printer is a device that can
either be directly addressed with IP or that can be addressed via a host
connected to it, I see no need to add a special comment on it, particularly
not since I do not see any special requirements for a printer compared to
other hosts.

 

Rather I see a need in the framework draft to discuss if and how alignment
with the IEEE ISTO-PWG is realized.

 

Thanks,

 

    Juergen

 

 

Am 24.07.2011 um 16:20 schrieb Benoit Claise:





Juergen,

Reading this old email, I believe that we should mention "printer" somewhere
in the requirements draft, as a device type addressed by the EMAN WG, and
not only in the appendix.

Regards, Benoit.



Hi Fritz, 

 

Thank you for your input.

 

We will consider printers and the document your referred to in the next
revision of the requirements.

I don't think many changes will need to be made here.

 

But for the MIB documents, we now have another set of PWG power/functional
states next to DMTF and ACPI states.

 

Thanks,

 

    Juergen

 

 

Am 18.03.2011 um 19:11 schrieb Ebner, Fritz:





Hello,

Please make sure that any power control or monitoring MIBs or drafts that
the EMAN WG produces can cover the use cases, power controls, and power
monitoring features provided in the printer working group.  Details are
below:

 

The IEEE/ISTO Printer Working Group has published their Candidate Standard
for Power Management and the associate protocol binding for SNMP.  Below are
the links to the abstract model and MIB.

 

PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0:

 

The PWG Power Management Model for Imaging Systems 1.0 specification was 
recently approved as a PWG Candidate Standard and is now available at:

 http://www.pwg.org/standards.html

and

 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf /
doc

 

PWG 5106-5 - PWG Imaging System Power MIB v1.0

 

The PWG Imaging System Power MIB v1.0 specification was recently approved
as a PWG Candidate Standard and is now available at:

 http://www.pwg.org/standards.html

and

 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf
/ doc / mib
 - PDF, MS Word, and ASN.1 source in plaintext

 
ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.p
df
 - ASN.1 source in color highlighted PDF

 

Thanks,

Fritz Ebner

_______________________________________________
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

 

 

 

 


------=_NextPart_000_006F_01CC4AC5.B3605770
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


Gentlemen,
 
As chairman of the IEEE-ISTO =
PWG workgroup that produced the  PWG Power Management Model for =
Imaging Systems and the associated MIB (ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-2011021=
4-5106.5.mib), I must say that the “printer” industry =
has been following the  ‘eman’ activites with interest =
and perhaps some apprehension. Although we  intend to be compliant =
with industry standards, and anticipate our customers to require that, =
we believe that the PWG Power Management Model best addresses the unique =
power characteristics of hardcopy imaging equipment.  We realize =
that all suppliers tend to regard their products as unique; but it must =
be recognized that “printers” , particularly in the =
enterprise, have long ceased to be little peripheral devices. They are =
now reasonably called Multifunction Devices; perform copy, scan and =
facsimile functions as well as printing; and have significant computing, =
storage and communication components as well as electromechanical and =
often thermal processing components. The power characteristics of these =
components and the somewhat different duty cycle requirements compared =
with other networked devices predicate the need for some special =
management elements, and we have spent significant time and effort =
agreeing on these. 
 =

The =
emergence of a separate IETF energy standard (or set of standards) that =
does not recognize the existence of a power standard developed by and =
custom to a particular industry would create confusion and act contrary =
to ensuring interoperability. We would hope that in the =
‘eman’ documentation, the PWG Imaging Systems Power =
Management MIB is referenced and considered with respect to =
applicability, coverage, and compatibility with ‘eman’ =
objectives, so that users see that the eman and PWG products can =
complement rather than substitute for each other. =

 =

Thank =
you,
 =

Bill =
Wagner, Chair WIMS/PWG
 
From:=
 =
eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of =
Juergen Quittek
Sent: Monday, July 25, 2011 1:31 =
AM
To: Benoit Claise
Cc: eman@ietf.org; Ebner, =
Fritz
Subject: Re: [eman] IETF EMAN request to address =
printers... -> =
draft-ietf-eman-requirements-04
 
Hi =
Benoit,
 
I =
think the entire Appendix can go away. 
It does not contribute at all to the requirements. At =
least not so far.
 
Analyzing what standard is available to meet a =
requirement 
is =
rather the task of a solution draft, such as the =
framework 
or the MIB =
modules, but not of a requirement draft.
 
My proposal would be moving the standards analysis to =
the framework
and discuss =
there also 
  - =
which of these standards are used for covering requirements, for =
example, 
  =
  Entity MIB for identification (if we do =
so)
  - which parts =
of these standards are supported, such as, for =
example,
    =
ACPI and DMTF power sets
  - to which standards our work is aligned, for =
example 
  =
  ODVA, IEEE-ISTO PWD, SBS, etc. and how we do =
so.
  - =
from which standards we deviate
 
Thanks,
 
    Juergen
 
Am 25.07.2011 um 00:55 schrieb Benoit =
Claise:


Hi =
Juergen,

So why is there an "IEEE-ISTO Printer WG" =
appendix if printers are not mentioned a single time in the =
document?

Regards, Benoit. 
Hi Benoit,
 
Currently, there is the following paragraph in section =
1 of draft-ietf-eman-requirements-04:
 
>   The main subject of energy management are =
powered entities that
> =
  consume electric energy.  Powered entities include devices =
that have
>   an =
IP address and can be addressed directly, such as hosts, =
routers,
>   and =
middleboxes, as well as devices indirectly connected to an =
IP
>   network, =
for which a proxy with an IP address provides a =
management
>   =
interface, for example, devices in a building =
management
>   =
infrastructure using BACNET or MODBUS =
protocols.
 
You see that we already address all kinds of IP =
devices: hosts, routers, and =
middleboxes.
There is no =
list of special hosts, such as servers, PCs, smart phones, printers, =
webcams, etc. 
I do =
not see a need to introduce it. Since a printer is a device that can =
either be directly addressed with IP or that can be addressed via a host =
connected to it, I see no need to add a special comment on it, =
particularly not since I do not see any special requirements for a =
printer compared to other hosts.
 
Rather I see a need in the framework draft to discuss =
if and how alignment with the IEEE ISTO-PWG is =
realized.
 
Thanks,
 
    Juergen
 
 
Am 24.07.2011 um 16:20 schrieb Benoit =
Claise:


Juergen,

Reading this old email, I believe that =
we should mention "printer" somewhere in the requirements =
draft, as a device type addressed by the EMAN WG, and not only in the =
appendix.

Regards, Benoit.

Hi Fritz, 
 
Thank you for your input.
 
We will consider printers and the document your =
referred to in the next revision of the =
requirements.
I don't =
think many changes will need to be made =
here.
 
But for the MIB documents, we now have another set of =
PWG power/functional states next to DMTF and ACPI =
states.
 
Thanks,
 
    Juergen
 
 
Am =
18.03.2011 um 19:11 schrieb Ebner, Fritz:


Hello,=

Please =
make sure that any power control or monitoring MIBs or drafts that the =
EMAN WG produces can cover the use cases, power controls, and power =
monitoring features provided in the printer working group.  Details =
are below:
 =

The =
IEEE/ISTO Printer Working Group has published their Candidate Standard =
for Power Management and the associate protocol binding for SNMP.  =
Below are the links to the abstract model and =
MIB.
 =

PWG 5106.4 =
- PWG Power Management Model for Imaging Systems =
1.0:
 =

The PWG =
Power Management Model for Imaging Systems 1.0 specification was 
recently approved as a =
PWG Candidate Standard and is now available =
at:

 http://www.pwg.org/standards.html

and
 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-201=
10214-5106.4.pdf / =
doc
 =

PWG 5106-5 =
- PWG Imaging System Power MIB v1.0
 =

The PWG =
Imaging System Power MIB v1.0 specification was recently approved
as =
a PWG Candidate Standard and is now available =
at:

 http://www.pwg.org/standards.html

and
 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-=
20110214-5106.5.pdf / doc / mib
 - PDF, =
MS Word, and ASN.1 source in plaintext

 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-=
20110214-5106.5-mib.pdf
 - ASN.1 source in color highlighted =
PDF
 =

Thanks,
Fritz =
Ebner
_______________________________________________
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
 
 
 
 

------=_NextPart_000_006F_01CC4AC5.B3605770--


From bclaise@cisco.com  Mon Jul 25 11:04:53 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B031221F8A80 for ; Mon, 25 Jul 2011 11:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.074,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGD0GADWtIrA for ; Mon, 25 Jul 2011 11:04:51 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 620FF21F85B8 for ; Mon, 25 Jul 2011 11:04:51 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6PI4nko028605; Mon, 25 Jul 2011 20:04:50 +0200 (CEST)
Received: from [10.82.243.104] (rtp-vpn2-872.cisco.com [10.82.243.104]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6PI4mIC007953; Mon, 25 Jul 2011 20:04:48 +0200 (CEST)
Message-ID: <4E2DB03F.7070209@cisco.com>
Date: Mon, 25 Jul 2011 14:04:47 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Thomas Dietz 
References: <4D9DE17D.5090606@cisco.com> <4D9F12FE.3080409@cisco.com> <20110408142048.GA81222@elstar.local> <4D9F1A5F.1030107@cisco.com> <20110408143107.GA81369@elstar.local> <4D9F26A0.20407@cisco.com> <20110408154839.GA81729@elstar.local> <4DA5BDDE.9060607@cisco.com> <20110413151728.GA32536@elstar.local> <4DA5BF04.8030204@cisco.com>  <4E2CE376.8050504@cisco.com> <75581E268A48F849916117B977D76D372CCD500E@Polydeuces.office.hd>
In-Reply-To: <75581E268A48F849916117B977D76D372CCD500E@Polydeuces.office.hd>
Content-Type: multipart/alternative; boundary="------------040108040409060105030208"
Cc: "eman@ietf.org" 
Subject: Re: [eman] Do we need power state transition count and time in state?
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2011 18:04:53 -0000

This is a multi-part message in MIME format.
--------------040108040409060105030208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Thomas,
>
> Hi Benoit, all,
>
> I support having those objects in the MIB. The only point where those 
> values can be measured accurate is the device itself, and the values 
> can be useful for a number of use cases. We still can make those 
> objects optional as Juergen already suggested so that they don't need 
> to be implemented if the device does not or cannot support them.
>
Optional is fine with me.

Regards, Benoit (as a contributor)
>
> Best Regards,
>
> Thomas
>
> -- 
>
> Thomas Dietz
>
> NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 
> Heidelberg, Germany
>
> NEC Europe Limited, Registered in England 2832014
>
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>
> *From:*eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] *On Behalf 
> Of *Benoit Claise
> *Sent:* Montag, 25. Juli 2011 05:31
> *To:* Juergen Quittek
> *Cc:* eman@ietf.org
> *Subject:* Re: [eman] Do we need power state transition count and time 
> in state?
>
> Dear all,
>
> I'm not sure what is the conclusion regarding this old email about "Do 
> we need power state transition count and time in state?"
> Currently, the EMAN requirements draft contains:
>
>
>         5.2.7.  Power state statistics
>
>
>            The energy management standard must provide means for
>         monitoring
>
>
>            statistics per power state including at least the total
>         time spent in
>
>
>            a power state, the number of times a state was entered and
>         the last
>
>
>            time a state was entered.  More power state statistics are
>         addressed
>
>
>            by requirement 5.5.3.
>
> Is this the consensus on the mailing list?
>
> Regards, Benoit.
>
> Am 13.04.2011 um 17:19 schrieb Russ White:
>
>       
>
>                 I assume people find it important to know the percentage of time a
>
>                 device spends in a certain power state. Approximating this by active
>
>                 polling of the current state is pretty inefficient and inaccurate
>
>                 since you can miss state changes. If the device records the time spent
>
>                 in each state, you get a precise breakdown of the time spend in each
>
>                 power state between each poll, which means you can safely poll at a
>
>                 much lower frequency.
>
>               
>
>             It seems like this should be put into an extension, rather than in the
>
>             base spec... Or as a device specific option (given we build the branches
>
>             of information we had discussed on list before).
>
>           
>
>         And the reason is?
>
>       
>
>     Because this doesn't seem to be useful for all devices... And because we
>
>     should try and keep the MIB size down, with extensions, rather than
>
>     trying to bundle everything possible into the base MIB.
>
>   
> What about having it in the same MIB, but making it optional to implement?
>   
>      Juergen
>   
>   
>
>     :-)
>
>       
>
>     Russ
>
>       
>
>       
>
>       
>
>     -- 
>
>     riw@cisco.com    :: CCIE :: CCDE ::<><  Grace Alone
>
>       
>
>     Belief is a wise wager. Granted that faith cannot be proved, what harm
>
>     will come to you if you gamble on its truth and it proves false? If you
>
>     gain, you gain all; if you lose, you lose nothing. Wager, then, without
>
>     hesitation, that He exists. Blaise Pascal
>
>       
>
>       
>
>     _______________________________________________
>
>     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
>


--------------040108040409060105030208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Thomas,

    

      
      
      
      

        
Hi
            Benoit, all,

        
 

        
I support having those objects in the MIB. The
            only point where those values can be measured accurate is
            the device itself, and the values can be useful for a number
            of use cases. We still can make those objects optional as
            Juergen already suggested so that they don’t need to be
            implemented if the device does not or cannot support them.

      

    

    Optional is fine with me.

    

    Regards, Benoit (as a contributor)

    

      

        

        
 

        
Best
            Regards,

        
 

        
Thomas

        
 

        

          
--
              

          
Thomas
              Dietz

          
NEC
              Europe Ltd., NEC Laboratories, Network Research Division,
              69115 Heidelberg, Germany

          
 

          
NEC
              Europe Limited, Registered in England 2832014

          
Registered
              Office: NEC House, 1 Victoria Road, London W3 6BL

        

        
 

        

          

            

              
From:
                  eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On
                    Behalf Of Benoit Claise

                  Sent: Montag, 25. Juli 2011 05:31

                  To: Juergen Quittek

                  Cc: eman@ietf.org

                  Subject: Re: [eman] Do we need power state
                  transition count and time in state?

            

          

          
 

          
Dear all,

            

            I'm not sure what is the conclusion regarding this old email
            about "Do we need power state transition count and time in
            state?"

            Currently, the EMAN requirements draft contains:

          
5.2.7.  Power state
              statistics

          
 

          
   The
              energy management standard must provide means for
              monitoring

          
  
              statistics per power state including at least the total
              time spent in

          
   a
              power state, the number of times a state was entered and
              the last

          
   time
              a state was entered.  More power state statistics are
              addressed

          
   by
              requirement 5.5.3.

          
Is this the consensus on the mailing
            list?

            

            Regards, Benoit.

            

            

          
Am 13.04.2011 um 17:19 schrieb Russ White:

          

            
 

            

              

                

                  
I assume people find it important to know the percentage of time a

                  
device spends in a certain power state. Approximating this by active

                  
polling of the current state is pretty inefficient and inaccurate

                  
since you can miss state changes. If the device records the time spent

                  
in each state, you get a precise breakdown of the time spend in each

                  
power state between each poll, which means you can safely poll at a

                  
much lower frequency.

                

                
 

                
It seems like this should be put into an extension, rather than in the

                
base spec... Or as a device specific option (given we build the branches

                
of information we had discussed on list before).

              

              
 

              
And the reason is?

            

            
 

            
Because this doesn't seem to be useful for all devices... And because we

            
should try and keep the MIB size down, with extensions, rather than

            
trying to bundle everything possible into the base MIB.

          

          
 

          
What about having it in the same MIB, but making it optional to implement?

          
 

          
    Juergen

          
 

          
 

          

            
:-)

            
 

            
Russ

            
 

            
 

            
 

            
-- 

            
riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone

            
 

            
Belief is a wise wager. Granted that faith cannot be proved, what harm

            
will come to you if you gamble on its truth and it proves false? If you

            
gain, you gain all; if you lose, you lose nothing. Wager, then, without

            
hesitation, that He exists. Blaise Pascal

            
 

            
 

            
_______________________________________________

            
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

          
 

        

      

    

    

  


--------------040108040409060105030208--

From jparello@cisco.com  Mon Jul 25 11:06:40 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D540D21F8B78 for ; Mon, 25 Jul 2011 11:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.974
X-Spam-Level: 
X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6eB6-Mjt20x for ; Mon, 25 Jul 2011 11:06:39 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 161C621F8B6F for ; Mon, 25 Jul 2011 11:06:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=7772; q=dns/txt; s=iport; t=1311617199; x=1312826799; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=kbo91kRt/3JZPqkqSaYVZoKA/nc+e3dRV7jpoQNyeKo=; b=CjLxmGshP1me44enPZCQQfbjcVDzQeQMLDK3NdwQ1R9JhbL4FKBFj13P ED2KVczFfdeHHB7UcU5Fxe5UW+PKu/zdoB1tfSEXAR9xteL2UqB0rcEVY ghKpZ7XWvIqeQp6DfaFqEpHNPXKEU70ZqGp/zUnz6Gnl3wzWfD3vm7PBi g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Au0AAJKvLU6rRDoI/2dsb2JhbAA0AQEBAQIBAQEBEQEhCjoLBQcDAgIBCRABBAEBAQoGBggBFAEGARMMDCMOCAIFARYMG5dbj1d3iHwEoXieHAKDIRMHgiNfBIdVkCuLcA
X-IronPort-AV: E=Sophos;i="4.67,263,1309737600";  d="scan'208";a="6210858"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jul 2011 18:06:38 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6PI6cRJ001050; Mon, 25 Jul 2011 18:06:38 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 25 Jul 2011 11:06:36 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 25 Jul 2011 11:06:06 -0700
Message-ID: 
In-Reply-To: <75581E268A48F849916117B977D76D372CCD502D@Polydeuces.office.hd>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] Two NMS configuring the Power Monitor with two different Power State Series
Thread-Index: AQHMCXFiSCfqP4ogWEKUmuBzMsYh5ZR6tKGAgIIeIYCAAAuRgIAAWfxQgACfKjA=
References: <4DBFC56E.2020908@cisco.com> <20110503092855.GA3772@elstar.local><0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D5C0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com><4E2CFB1B.3030403@cisco.com> <75581E268A48F849916117B977D76D372CCD502D@Polydeuces.office.hd>
From: "John Parello (jparello)" 
To: "Thomas Dietz" , "Benoit Claise (bclaise)" , "Mielke, William F (Bill)" 
X-OriginalArrivalTime: 25 Jul 2011 18:06:36.0836 (UTC) FILETIME=[983B2E40:01CC4AF5]
Cc: eman mailing list 
Subject: Re: [eman] Two NMS configuring the Power Monitor with two different Power State Series
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, 25 Jul 2011 18:06:40 -0000

Hi Thomas,

I agree with you. Having multiple series supported at the same time is
not an overhead. If a device cannot then it should advertise only the
one.

I don't see why a device would advertise more than one series then
restrict to one.

if a devices can do multiple series then advertise as such if not
advertise only one.

I have implementations that multiple series right now so it's not
difficult and makes the NMS discovery much more straight forward and
more importantly universal.

+1


Jp


-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Thomas Dietz
Sent: Monday, July 25, 2011 1:39 AM
To: Benoit Claise (bclaise); Mielke, William F (Bill)
Cc: eman mailing list
Subject: Re: [eman] Two NMS configuring the Power Monitor with two
different Power State Series

Dear Bill,

The way set forward in the recent draft that was pointed out by Benoit
gives the different NMS the freedom to choose which power series to take
if the managed object supports more than one. And I don't think it is
much of an overhead for the managed object to match one power series to
another.

Best Regards,

Thomas

--
Thomas Dietz
NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115
Heidelberg, Germany

NEC Europe Limited, Registered in England 2832014 Registered Office: NEC
House, 1 Victoria Road, London W3 6BL


> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf=20
> Of Benoit Claise
> Sent: Montag, 25. Juli 2011 07:12
> To: Mielke, William F (Bill)
> Cc: eman mailing list
> Subject: Re: [eman] Two NMS configuring the Power Monitor with two=20
> different Power State Series
>=20
> Hi Bill,
> > I apologize for having gone silent for so long but I am here in=20
> > Quebec
> and am working through old emails to come back up to speed.  I also=20
> apologize for perhaps covering old ground in some cases.  I plan to=20
> comment as I go chronologically through the list archive.  If I=20
> comment on something which was later resolved please bear with me as I

> will eventually find the resolution along the way.  Either way it is=20
> probably better that I record my comments in the event that I identify

> something that has not been considered fully.
> >
> > Regarding the issue of 2 NMS's interacting with a single Managed=20
> > Object
> using different power state series, my thinking all along was that the

> managed object would choose (align with) the power series that made=20
> sense for it and that the NMS's would have to adapt to talking to the=20
> managed object in its preferred  (supported) series.  So in this case=20
> there is no confusion, the series selected by the managed object is=20
> always the one that will be used by any NMS.  This approach is
consistent with Juergen S.
> point that traditionally the NMS was assumed to be better able to deal

> with these types of variations rather then the managed object=20
> implementation.
> >
> > How was this point ultimately resolved, assuming it was?
> By having an extra index in the tables. First the power state series,=20
> then the power state.
> From http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09:
>=20
>         pmPowerTable OBJECT-TYPE
>              SYNTAX          SEQUENCE OF PmPowerEntry
>              MAX-ACCESS      not-accessible
>              STATUS          current
>              DESCRIPTION
>                 "This table lists Power Monitors."
>              ::=3D { powerMonitorMIBObjects 1 }
>=20
>          pmPowerEntry OBJECT-TYPE
>              SYNTAX          PmPowerEntry
>              MAX-ACCESS      not-accessible
>              STATUS          current
>              DESCRIPTION
>                 "An entry describes the power usage of a Power
Monitor."
>              INDEX           { pmPowerIndex, pmPowerStateSetIndex}
>=20
>=20
>=20
> >
> > William F. Mielke
> > Alcatel-Lucent
> > Distinguished Member of Technical Staff 6200 East Broad Street
> > Room: 4B01-1V
> > Columbus, OH  43213-1530
> > Email: Bill.Mielke@alcatel-lucent.com
> > Phone: 614 367 5628
> > Fax: 614 367 5965
> >
> > "Live like you're going to die tomorrow.
> >   Learn like you're going to live forever."
> >
> >      - Albert Einstein
> >
> >
> >
> >> -----Original Message-----
> >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20
> >> Behalf Of Juergen Schoenwaelder
> >> Sent: Tuesday, May 03, 2011 5:29 AM
> >> To: Benoit Claise
> >> Cc: eman mailing list
> >> Subject: Re: [eman] Two NMS configuring the Power Monitor with two=20
> >> different Power State Series
> >>
> >> On Tue, May 03, 2011 at 11:05:50AM +0200, Benoit Claise wrote:
> >>
> >>> Let's discuss the following situation: what if we have 2 NMS', and

> >>> they speak different Power State Series for a specific Power=20
> >>> Monitor? Should this be allowed by the [EMAN-REQ]?
> >> Traditionally, it was always assumed that an SNMP management system

> >> can more easily adapt to devices than the other way round.
> >>
> >>> Actually this requirement has got some implications in terms of=20
> >>> the MIB design (taking
> >>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07
> >>> into account)
> >>>
> >>> - If the answer is yes, then we need to have an extra index in the

> >>> power pmPowerTable. This index must abe a new TC, which is only=20
> >>> for the Power State Series.  Note: the table needs to redesigned=20
> >>> because the common variable (caliber, nameplate, etc...) are=20
> >>> common per Power State Series. Then we can have a new table, for=20
> >>> discovery, that will only contain  two indices:=20
> >>> pmPowerMonitorIndex and the new TC-defined pmPowerStateSeries.
> >>> - If the answer is no, then there is the risk that NMS1 will set=20
> >>> the
> >>> DMTF:1 for example, and then NMS2 set it EMAN:3 (assuming that the

> >>> Power Monitor supports both the DMTF and the EMAN Power State=20
> >>> Series), and there is a ping-pong game between two NMS's that=20
> >>> don't synchronize between the two.
> >> If two management systems make changes without coordination, you=20
> >> always have a chance for ping-pong effects, even within a Power=20
> >> State Series. That said, it might be possible to provide guidelines

> >> such as if a device is reporting a value of a given Power State=20
> >> Series (e.g. DMTF:3), a management application should adapt and use

> >> DMTF power states.
> >>
> >>> The alternative is that the first NMS would say: I will speak to=20
> >>> the Power Monitor with the DMTF Power State Series, and then all=20
> >>> the other NMS's will have to speak the same language (i.e. DMTF).
> >> I think that is a reasonably assumption to make if the number of=20
> >> different Power State Series is kept limited (that is we prevent=20
> >> that every vendor/organization comes up with its own creative=20
> >> series of power states). A large number of different Power State=20
> >> Series will be hindering interoperability, with or without
ping-pong effects.
> >>
> >> /js
> >>
> >> --
> >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen,
Germany
> >> Fax:   +49 421 200 3103
> >> _______________________________________________
> >> eman mailing list
> >> eman@ietf.org
> >> https://www.ietf.org/mailman/listinfo/eman
> >>
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman

From bill.mielke@alcatel-lucent.com  Mon Jul 25 11:07:38 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2459B21F8BCD for ; Mon, 25 Jul 2011 11:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmF9hLzpM5zP for ; Mon, 25 Jul 2011 11:07:37 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4F421F8B2D for ; Mon, 25 Jul 2011 11:07:34 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p6PI7XbQ007799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 25 Jul 2011 13:07:33 -0500 (CDT)
Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6PI7X0h029625 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 25 Jul 2011 13:07:33 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 25 Jul 2011 13:07:33 -0500
From: "Mielke, William F (Bill)" 
To: eman mailing list 
Date: Mon, 25 Jul 2011 13:07:30 -0500
Thread-Topic: [eman] Comments on eman requirements
Thread-Index: Acw7juOte3bolUrmQ/69wGh2K3qKdAPYVQIg
Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D817@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: Re: [eman] Comments on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2011 18:07:38 -0000

A few thoughts provided inline.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20
> Behalf Of JinHyeock Choi
> Sent: Tuesday, July 05, 2011 11:44 PM
> To: Juergen Quittek
> Cc: eman mailing list
> Subject: [eman] Comments on eman requirements
>=20

> > 5.2.6. Maximum and average power per power state
> >
> > The energy management standard must provide means for retrieving the
> > maximum power and the average power as a typically static property
> > for each supported power state.
>=20
> Maximum power at maximum capacity?
>=20
> Average power in which sense?
> Just a arithmetic mean value between maximum and minimum power?

I agree that "average power" needs some clarification as the arithmetic mea=
n of the minimum and maximum values does not seem to be the correct value h=
ere.  I believe that the intent is

Average Power for an Interval =3D Total Energy Consumed in that Interval / =
Length of the Interval

Example:

Average Power =3D 10 Watt-Hour / 1 Hour =3D 10 Watts

Whereas the observed Max Power during that hour may have been 15 Watts and =
the observed Min Power may have been 9 Watts which would yield an arithmeti=
c mean of (15 + 9) / 2 =3D 12 Watts which is not what I think most people e=
xpect or want.

This begs the question of what interval the object should be reporting.

Do others agree?

> > 5.5. Energy
> >
> > In order to monitor energy consumption in different power states, it
> > is useful if entities record their energy consumption per=20
> power state
> > and report these quantities.
>=20
> Energy consumption varies according to power state and traffic load.
> How do you take 'traffic load' into consideration?

This raises a very important point and one that I am not certain is within =
scope of EMAN but which is certainly an important point for Energy Manageme=
nt in general.  I would generalize this point from the networking example a=
 bit as the fundamental point is about efficiency.

Let us define efficiency in this context as follows:

Energy Efficiency =3D Total Energy Consumed per Unit of Useful Work

In the example discussed above the "Unit of Useful Work" is the transmissio=
n of a bit (i.e. a unit of traffic).  But in other domains the units will b=
e different.  For example, in the case of light bulbs the interesting unit =
would be the number of Lumens emitted.  So as you can see "Unit of Useful W=
ork" is application domain dependent.

Given that EMAN wishes to be application domain agnostic this presents a pr=
oblem for us to provide a meaningful definition of Energy Efficiency becaus=
e we would need to provide definitions for an endless number of domains.  I=
 do not believe that the concept of "Unit of Useful Work" can be reasonably=
 abstracted to the point of having a consistent set of units across dispara=
te application domains.

This is a thorny issue IMHO, and I am not sure how best to address it.

>=20
> > 5.5.4. Time series of energy values
> >
> > The energy management standard must provide means for=20
> collecting time
> > series of energy values for each power inlet and for each power
> > outlet of an entity
>=20
> Energy would be measured over time interval.
>=20
> Would time series of energy values be measured
> over the sequence of time intervals in 5.5.2?

I am assuming that we would be reporting the relevant values for each of a =
sequence of contiguous and non-overlapping intervals where each interval is=
 identified with a timestamp that corresponds to either the start or the en=
d of that interval.

Is this the correct understanding?


From bill.mielke@alcatel-lucent.com  Mon Jul 25 12:18:14 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA9121F8748 for ; Mon, 25 Jul 2011 12:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfz9xRJ20urW for ; Mon, 25 Jul 2011 12:18:13 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 50F0921F8726 for ; Mon, 25 Jul 2011 12:18:13 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p6PJICk7013966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 25 Jul 2011 14:18:12 -0500 (CDT)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6PJICMW007167 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 25 Jul 2011 14:18:12 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 25 Jul 2011 14:18:12 -0500
From: "Mielke, William F (Bill)" 
To: eman mailing list 
Date: Mon, 25 Jul 2011 14:18:08 -0500
Thread-Topic: [eman] New draft on eman requirements - issue 1 - Device type
Thread-Index: Acw9P31+zxauYAdDQHCQA9ZAWZ0oLQNvpy8g
Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D86D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References:    <1127B34B-6899-4F1D-966E-ED841E25E554@quittek.at> <4E142A61.3010103@cisco.com> <20248561-E87E-4CD0-9E57-E031B00E479A@quittek.at> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type
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, 25 Jul 2011 19:18:14 -0000

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

Grouping for what purpose?

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

I agree with Bruce that we should be supporting some sort of device type id=
entification information.  This would be useful for identifying, for exampl=
e, which "Unit of Useful Work" would be applicable to a given device to der=
ive a meaningful efficiency metric for it.=20

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com =20
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein=20

=20


________________________________

	From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Br=
uce Nordman
	Sent: Friday, July 08, 2011 3:17 AM
	To: eman mailing list
	Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type
=09
=09


	On Wed, Jul 6, 2011 at 4:59 AM, Juergen Quittek  wrote:
=09

		On 06.07.2011  11:26, Benoit Claise wrote:
		....


			Coming back to this requirement
		=09
		=09

				5.1.1. Type of powered entity
			=09
				The energy management standard must provide means to retrieve and
				report the type of powered entities.

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

				5.1.2.  Grouping of powered entities
			=09
				   The energy management standard must provide means for grouping
				   powered entities, for example, into energy monitoring domains, energ=
y
				   control domains, power supply domains, groups of entities of the sam=
e
				   type, etc.

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


	I have to disagree completely on this point.
	A major barrier to understanding energy use in
	buildings and in doing things to reduce it is
	lack of information about what devices are=20
	present in a building and how much each
	one is using.  We are going into great detail
	about the quantities of energy, but seem to
	want to avoid saying anything about what
	the device actually is.
=09
	Accomplishing this and meeting the needs of
	energy efficiency need not be burdensome.
	Just a few variables can point to a standard
	index of device types (or "product types" in
	my line of work) and short brand/model
	information.
=09
	Thanks,
=09
	--Bruce
	=20
=09





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


From bill.mielke@alcatel-lucent.com  Mon Jul 25 13:01:38 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BBD21F8B9F for ; Mon, 25 Jul 2011 13:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZFYuPqwwFXA for ; Mon, 25 Jul 2011 13:01:37 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id DE72F21F8B9B for ; Mon, 25 Jul 2011 13:01:36 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p6PK1ZOH020771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 25 Jul 2011 15:01:36 -0500 (CDT)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6PK1ZCa019972 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 25 Jul 2011 15:01:35 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Mon, 25 Jul 2011 15:01:35 -0500
From: "Mielke, William F (Bill)" 
To: eman mailing list 
Date: Mon, 25 Jul 2011 15:01:31 -0500
Thread-Topic: [eman] new revision of eman requirements - open issue 12.3: time series of energy/power values
Thread-Index: AcxBW8xadqm3PibEROGblU7yKwdZJAJpnMqw
Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D8A1@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References:   <54ECD73F-B9A8-440F-970B-B9DD538CA186@quittek.at>
In-Reply-To: <54ECD73F-B9A8-440F-970B-B9DD538CA186@quittek.at>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:	time series of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2011 20:01:38 -0000

I believe that it is very important for devices to maintain and report a (l=
imited amount of) time series data for the energy and power related values.=
  This is needed to reasonably support a pull model for such information.  =
An NMS cannot poll individual devices with sufficiently accurate timing to =
collect and maintain this information on its own.  This is especially true =
as the NMS tries to scale up to a large number of devices and when the comm=
unications between the NMS and the device is subject to congestion and outa=
ges.

I think that the primary issue at play here is that the desired measurement=
 interval (1 sec up to 1 min?) is likely shorter than the typical NMS polli=
ng interval (1 min up to 1 day?).  So the collection of the time series dat=
a must be delegated to the device and it must be retained there for a suffi=
ciently long time that the NMS can be reasonably expected to be able to col=
lect it on its next polling interval.

I believe that existing devices such as Smart PDUs already collect and main=
tain time series measurements and retain them in just this manner and for j=
ust this purpose.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

=20

> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20
> Behalf Of Juergen Quittek
> Sent: Wednesday, July 13, 2011 8:53 AM
> To: Mouli Chandramouli (moulchan)
> Cc: eman mailing list
> Subject: Re: [eman] new revision of eman requirements - open=20
> issue 12.3: time series of energy/power values
>=20
> Dear Mouli,
>=20
> Thank you for commenting on this issue. I would like to have=20
> a look at the following point of view:
>=20
> So far, storing time series of measurements on managed nodes=20
> is rarely standardized and rarely available as implementation.
>=20
> Typically, it is the job of a network management system to=20
> collect time series and store them.
>=20
> Take for example byte and packet counters at line cards. You=20
> see many curves showing time series of traffic rate/volume in=20
> the Internet, but almost all of them were collected at=20
> management stations or data collector modules, but not within=20
> MIB modules. (Please correct me if I'm wrong.)=20
>=20
> Now the question is: Is energy management so much different=20
> from other network management tasks, that we need the rarely=20
> used mechanism of storing time series in MIB modules?
>=20
> If not, it would be sufficient to just report the number of=20
> total energy consumed since the last re-start as you do it=20
> with packet and byte counters.
> This would be just a single managed object to be specified=20
> and implemented.
>=20
> Thanks,
>=20
>     Juergen
>=20
> Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):
>=20
> > Regarding the Time Series debate - the crucial question -=20
> where is the
> > data / measurements stored.=20
> > It would not be possible for small devices to store such data for a
> > sufficiently long time period.=20
> >=20
> > The NMS can store the values for a sufficiently long period=20
> of time, for
> > trending analysis.=20
> >=20
> > In the case of demand measurement, since the maximum over a=20
> window is
> > computed, it is important for the device store atleast a=20
> window length
> > of measurements.=20
> >=20
> > I am not sure about that Requirement 5.4.10 - Time Series of Power
> > Values - to be stored in the device
> >=20
> > Thanks
> > Mouli
> >=20
> >=20
> > -----Original Message-----
> > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org]=20
> On Behalf Of
> > Juergen Quittek
> > Sent: Tuesday, July 12, 2011 2:31 PM
> > To: eman mailing list
> > Subject: [eman] new revision of eman requirements
> >=20
> > Dear all,
> >=20
> > I posted a new version of the eman requirements yesterday.
> > Please find it at=20
> > http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/
> >=20
> >=20
> > Of course, feel free to also comment on the other open issues or to
> > raise
> > new ones. All such contributions are highly appreciated.
> >=20
> > Thanks,
> >=20
> >    Juergen
> >=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
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
> =

From bill.mielke@alcatel-lucent.com  Mon Jul 25 15:32:51 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909D111E80D7 for ; Mon, 25 Jul 2011 15:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgqCm4LWSzJT for ; Mon, 25 Jul 2011 15:32:50 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CDFB811E80B1 for ; Mon, 25 Jul 2011 15:32:44 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p6PMWh8S016024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 25 Jul 2011 17:32:44 -0500 (CDT)
Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6PMWhpm005930 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 25 Jul 2011 17:32:43 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 25 Jul 2011 17:32:44 -0500
From: "Mielke, William F (Bill)" 
To: eman mailing list 
Date: Mon, 25 Jul 2011 17:31:59 -0500
Thread-Topic: [eman] Two NMS configuring the Power Monitor with two different Power State Series
Thread-Index: AQHMCXFiSCfqP4ogWEKUmuBzMsYh5ZR6tKGAgIIeIYCAAAuRgIAAWfxQgACfKjCAAEh4gA==
Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D925@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: <4DBFC56E.2020908@cisco.com> <20110503092855.GA3772@elstar.local><0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D5C0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com><4E2CFB1B.3030403@cisco.com> <75581E268A48F849916117B977D76D372CCD502D@Polydeuces.office.hd> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
Subject: Re: [eman] Two NMS configuring the Power Monitor with two different Power State Series
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, 25 Jul 2011 22:32:51 -0000

OK, I think I understand now.  I have no problem with a given device being =
able to support multiple power series simultaneously if it chooses to do so=
.

So let me articulate the operational scenario and you tell me if I have the=
 proper understanding.

1. Assume some device X supports multiple power series.

2. NMS 1 queries to determine which power series device X supports.

3. NMS 1 selects one power series from the available set and uses that to i=
nteract with X.

4. NMS 2 queries to determine which power series device X supports.

5. NMS 2 selects a potentially different power series from the available se=
t and uses that to interact with X.

6. NMS 1 and 2 both continue to interact with X using their respective choi=
ces and these interactions can be interleaved without difficulty.

If a device decides to only support one power series then when queried it o=
nly reports that one.

Is this generally the correct idea?

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

=20

> -----Original Message-----
> From: John Parello (jparello) [mailto:jparello@cisco.com]=20
> Sent: Monday, July 25, 2011 2:06 PM
> To: Thomas Dietz; Benoit Claise (bclaise); Mielke, William F (Bill)
> Cc: eman mailing list
> Subject: RE: [eman] Two NMS configuring the Power Monitor=20
> with two different Power State Series
>=20
> Hi Thomas,
>=20
> I agree with you. Having multiple series supported at the same time is
> not an overhead. If a device cannot then it should advertise only the
> one.
>=20
> I don't see why a device would advertise more than one series then
> restrict to one.
>=20
> if a devices can do multiple series then advertise as such if not
> advertise only one.
>=20
> I have implementations that multiple series right now so it's not
> difficult and makes the NMS discovery much more straight forward and
> more importantly universal.
>=20
> +1
>=20
>=20
> Jp
>=20
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20
> Behalf Of
> Thomas Dietz
> Sent: Monday, July 25, 2011 1:39 AM
> To: Benoit Claise (bclaise); Mielke, William F (Bill)
> Cc: eman mailing list
> Subject: Re: [eman] Two NMS configuring the Power Monitor with two
> different Power State Series
>=20
> Dear Bill,
>=20
> The way set forward in the recent draft that was pointed out by Benoit
> gives the different NMS the freedom to choose which power=20
> series to take
> if the managed object supports more than one. And I don't think it is
> much of an overhead for the managed object to match one power=20
> series to
> another.
>=20
> Best Regards,
>=20
> Thomas
>=20
> --
> Thomas Dietz
> NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115
> Heidelberg, Germany
>=20
> NEC Europe Limited, Registered in England 2832014 Registered=20
> Office: NEC
> House, 1 Victoria Road, London W3 6BL
>=20
>=20
> > -----Original Message-----
> > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org]=20
> On Behalf=20
> > Of Benoit Claise
> > Sent: Montag, 25. Juli 2011 07:12
> > To: Mielke, William F (Bill)
> > Cc: eman mailing list
> > Subject: Re: [eman] Two NMS configuring the Power Monitor with two=20
> > different Power State Series
> >=20
> > Hi Bill,
> > > I apologize for having gone silent for so long but I am here in=20
> > > Quebec
> > and am working through old emails to come back up to speed.  I also=20
> > apologize for perhaps covering old ground in some cases.  I plan to=20
> > comment as I go chronologically through the list archive.  If I=20
> > comment on something which was later resolved please bear=20
> with me as I
>=20
> > will eventually find the resolution along the way.  Either=20
> way it is=20
> > probably better that I record my comments in the event that=20
> I identify
>=20
> > something that has not been considered fully.
> > >
> > > Regarding the issue of 2 NMS's interacting with a single Managed=20
> > > Object
> > using different power state series, my thinking all along=20
> was that the
>=20
> > managed object would choose (align with) the power series that made=20
> > sense for it and that the NMS's would have to adapt to=20
> talking to the=20
> > managed object in its preferred  (supported) series.  So in=20
> this case=20
> > there is no confusion, the series selected by the managed object is=20
> > always the one that will be used by any NMS.  This approach is
> consistent with Juergen S.
> > point that traditionally the NMS was assumed to be better=20
> able to deal
>=20
> > with these types of variations rather then the managed object=20
> > implementation.
> > >
> > > How was this point ultimately resolved, assuming it was?
> > By having an extra index in the tables. First the power=20
> state series,=20
> > then the power state.
> > From=20
> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09:
> >=20
> >         pmPowerTable OBJECT-TYPE
> >              SYNTAX          SEQUENCE OF PmPowerEntry
> >              MAX-ACCESS      not-accessible
> >              STATUS          current
> >              DESCRIPTION
> >                 "This table lists Power Monitors."
> >              ::=3D { powerMonitorMIBObjects 1 }
> >=20
> >          pmPowerEntry OBJECT-TYPE
> >              SYNTAX          PmPowerEntry
> >              MAX-ACCESS      not-accessible
> >              STATUS          current
> >              DESCRIPTION
> >                 "An entry describes the power usage of a Power
> Monitor."
> >              INDEX           { pmPowerIndex, pmPowerStateSetIndex}
> >=20
> >=20
> >=20
> > >
> > > William F. Mielke
> > > Alcatel-Lucent
> > > Distinguished Member of Technical Staff 6200 East Broad Street
> > > Room: 4B01-1V
> > > Columbus, OH  43213-1530
> > > Email: Bill.Mielke@alcatel-lucent.com
> > > Phone: 614 367 5628
> > > Fax: 614 367 5965
> > >
> > > "Live like you're going to die tomorrow.
> > >   Learn like you're going to live forever."
> > >
> > >      - Albert Einstein
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20
> > >> Behalf Of Juergen Schoenwaelder
> > >> Sent: Tuesday, May 03, 2011 5:29 AM
> > >> To: Benoit Claise
> > >> Cc: eman mailing list
> > >> Subject: Re: [eman] Two NMS configuring the Power=20
> Monitor with two=20
> > >> different Power State Series
> > >>
> > >> On Tue, May 03, 2011 at 11:05:50AM +0200, Benoit Claise wrote:
> > >>
> > >>> Let's discuss the following situation: what if we have=20
> 2 NMS', and
>=20
> > >>> they speak different Power State Series for a specific Power=20
> > >>> Monitor? Should this be allowed by the [EMAN-REQ]?
> > >> Traditionally, it was always assumed that an SNMP=20
> management system
>=20
> > >> can more easily adapt to devices than the other way round.
> > >>
> > >>> Actually this requirement has got some implications in terms of=20
> > >>> the MIB design (taking
> > >>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07
> > >>> into account)
> > >>>
> > >>> - If the answer is yes, then we need to have an extra=20
> index in the
>=20
> > >>> power pmPowerTable. This index must abe a new TC, which is only=20
> > >>> for the Power State Series.  Note: the table needs to=20
> redesigned=20
> > >>> because the common variable (caliber, nameplate, etc...) are=20
> > >>> common per Power State Series. Then we can have a new=20
> table, for=20
> > >>> discovery, that will only contain  two indices:=20
> > >>> pmPowerMonitorIndex and the new TC-defined pmPowerStateSeries.
> > >>> - If the answer is no, then there is the risk that NMS1=20
> will set=20
> > >>> the
> > >>> DMTF:1 for example, and then NMS2 set it EMAN:3=20
> (assuming that the
>=20
> > >>> Power Monitor supports both the DMTF and the EMAN Power State=20
> > >>> Series), and there is a ping-pong game between two NMS's that=20
> > >>> don't synchronize between the two.
> > >> If two management systems make changes without coordination, you=20
> > >> always have a chance for ping-pong effects, even within a Power=20
> > >> State Series. That said, it might be possible to provide=20
> guidelines
>=20
> > >> such as if a device is reporting a value of a given Power State=20
> > >> Series (e.g. DMTF:3), a management application should=20
> adapt and use
>=20
> > >> DMTF power states.
> > >>
> > >>> The alternative is that the first NMS would say: I will=20
> speak to=20
> > >>> the Power Monitor with the DMTF Power State Series, and=20
> then all=20
> > >>> the other NMS's will have to speak the same language=20
> (i.e. DMTF).
> > >> I think that is a reasonably assumption to make if the number of=20
> > >> different Power State Series is kept limited (that is we prevent=20
> > >> that every vendor/organization comes up with its own creative=20
> > >> series of power states). A large number of different Power State=20
> > >> Series will be hindering interoperability, with or without
> ping-pong effects.
> > >>
> > >> /js
> > >>
> > >> --
> > >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > >> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen,
> Germany
> > >> Fax:   +49 421 200 3103
> > >> _______________________________________________
> > >> eman mailing list
> > >> eman@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/eman
> > >>
> >=20
> > _______________________________________________
> > eman mailing list
> > eman@ietf.org
> > https://www.ietf.org/mailman/listinfo/eman
> =

From ietf@quittek.at  Mon Jul 25 15:48:04 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96DB11E80E0 for ; Mon, 25 Jul 2011 15:48:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.794
X-Spam-Level: 
X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=0.455,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLmexLjEhyqb for ; Mon, 25 Jul 2011 15:48:03 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 847F511E80CF for ; Mon, 25 Jul 2011 15:48:03 -0700 (PDT)
Received: from [10.7.0.92] (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LwSnT-1RUbkM0Oq7-018NN8; Tue, 26 Jul 2011 00:47:47 +0200
References: <4DBFC56E.2020908@cisco.com> <20110503092855.GA3772@elstar.local><0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D5C0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com><4E2CFB1B.3030403@cisco.com> <75581E268A48F849916117B977D76D372CCD502D@Polydeuces.office.hd>  <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D925@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D925@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <958F3EC5-6B40-498E-9EFC-811A7DC4AB74@quittek.at>
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Mon, 25 Jul 2011 18:47:42 -0400
To: "Mielke, William F (Bill)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:Iwc+wy+V9AqeqRRtjLbxgOJZre3sj8jCs3BtCZXpx9d IJWaoDKSt9f9ALxyo92NxZdTlbKj+uZ658Zdy96irjXLvhJPKN jkgCzWtYK9mpl1ogdHDhYgSxQh3OLSCiaZBOnHJUJmSoafPJTC jTClkaVWvWUIgUU5caX/JPNWaAWJKODHhdMQuVsW8uevlU/nA5 lYHcxVpcHynQesEacStQLySn4e+GuNxsOBabmQzt2A=
Cc: eman mailing list 
Subject: Re: [eman] Two NMS configuring the Power Monitor with two different Power State Series
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, 25 Jul 2011 22:48:05 -0000

Hi Bill,

Yes, that's exactly the idea.

    Juergen

Am 25.07.2011 um 18:31 schrieb Mielke, William F (Bill):

> OK, I think I understand now.  I have no problem with a given device =
being able to support multiple power series simultaneously if it chooses =
to do so.
>=20
> So let me articulate the operational scenario and you tell me if I =
have the proper understanding.
>=20
> 1. Assume some device X supports multiple power series.
>=20
> 2. NMS 1 queries to determine which power series device X supports.
>=20
> 3. NMS 1 selects one power series from the available set and uses that =
to interact with X.
>=20
> 4. NMS 2 queries to determine which power series device X supports.
>=20
> 5. NMS 2 selects a potentially different power series from the =
available set and uses that to interact with X.
>=20
> 6. NMS 1 and 2 both continue to interact with X using their respective =
choices and these interactions can be interleaved without difficulty.
>=20
> If a device decides to only support one power series then when queried =
it only reports that one.
>=20
> Is this generally the correct idea?
>=20
> William F. Mielke
> Alcatel-Lucent
> Distinguished Member of Technical Staff
> 6200 East Broad Street
> Room: 4B01-1V
> Columbus, OH  43213-1530
> Email: Bill.Mielke@alcatel-lucent.com
> Phone: 614 367 5628
> Fax: 614 367 5965
>=20
> "Live like you're going to die tomorrow.
> Learn like you're going to live forever."
>=20
>    - Albert Einstein
>=20
>=20
>=20
>> -----Original Message-----
>> From: John Parello (jparello) [mailto:jparello@cisco.com]=20
>> Sent: Monday, July 25, 2011 2:06 PM
>> To: Thomas Dietz; Benoit Claise (bclaise); Mielke, William F (Bill)
>> Cc: eman mailing list
>> Subject: RE: [eman] Two NMS configuring the Power Monitor=20
>> with two different Power State Series
>>=20
>> Hi Thomas,
>>=20
>> I agree with you. Having multiple series supported at the same time =
is
>> not an overhead. If a device cannot then it should advertise only the
>> one.
>>=20
>> I don't see why a device would advertise more than one series then
>> restrict to one.
>>=20
>> if a devices can do multiple series then advertise as such if not
>> advertise only one.
>>=20
>> I have implementations that multiple series right now so it's not
>> difficult and makes the NMS discovery much more straight forward and
>> more importantly universal.
>>=20
>> +1
>>=20
>>=20
>> Jp
>>=20
>>=20
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20
>> Behalf Of
>> Thomas Dietz
>> Sent: Monday, July 25, 2011 1:39 AM
>> To: Benoit Claise (bclaise); Mielke, William F (Bill)
>> Cc: eman mailing list
>> Subject: Re: [eman] Two NMS configuring the Power Monitor with two
>> different Power State Series
>>=20
>> Dear Bill,
>>=20
>> The way set forward in the recent draft that was pointed out by =
Benoit
>> gives the different NMS the freedom to choose which power=20
>> series to take
>> if the managed object supports more than one. And I don't think it is
>> much of an overhead for the managed object to match one power=20
>> series to
>> another.
>>=20
>> Best Regards,
>>=20
>> Thomas
>>=20
>> --
>> Thomas Dietz
>> NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115
>> Heidelberg, Germany
>>=20
>> NEC Europe Limited, Registered in England 2832014 Registered=20
>> Office: NEC
>> House, 1 Victoria Road, London W3 6BL
>>=20
>>=20
>>> -----Original Message-----
>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org]=20
>> On Behalf=20
>>> Of Benoit Claise
>>> Sent: Montag, 25. Juli 2011 07:12
>>> To: Mielke, William F (Bill)
>>> Cc: eman mailing list
>>> Subject: Re: [eman] Two NMS configuring the Power Monitor with two=20=

>>> different Power State Series
>>>=20
>>> Hi Bill,
>>>> I apologize for having gone silent for so long but I am here in=20
>>>> Quebec
>>> and am working through old emails to come back up to speed.  I also=20=

>>> apologize for perhaps covering old ground in some cases.  I plan to=20=

>>> comment as I go chronologically through the list archive.  If I=20
>>> comment on something which was later resolved please bear=20
>> with me as I
>>=20
>>> will eventually find the resolution along the way.  Either=20
>> way it is=20
>>> probably better that I record my comments in the event that=20
>> I identify
>>=20
>>> something that has not been considered fully.
>>>>=20
>>>> Regarding the issue of 2 NMS's interacting with a single Managed=20
>>>> Object
>>> using different power state series, my thinking all along=20
>> was that the
>>=20
>>> managed object would choose (align with) the power series that made=20=

>>> sense for it and that the NMS's would have to adapt to=20
>> talking to the=20
>>> managed object in its preferred  (supported) series.  So in=20
>> this case=20
>>> there is no confusion, the series selected by the managed object is=20=

>>> always the one that will be used by any NMS.  This approach is
>> consistent with Juergen S.
>>> point that traditionally the NMS was assumed to be better=20
>> able to deal
>>=20
>>> with these types of variations rather then the managed object=20
>>> implementation.
>>>>=20
>>>> How was this point ultimately resolved, assuming it was?
>>> By having an extra index in the tables. First the power=20
>> state series,=20
>>> then the power state.
>>> =46rom=20
>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09:
>>>=20
>>>        pmPowerTable OBJECT-TYPE
>>>             SYNTAX          SEQUENCE OF PmPowerEntry
>>>             MAX-ACCESS      not-accessible
>>>             STATUS          current
>>>             DESCRIPTION
>>>                "This table lists Power Monitors."
>>>             ::=3D { powerMonitorMIBObjects 1 }
>>>=20
>>>         pmPowerEntry OBJECT-TYPE
>>>             SYNTAX          PmPowerEntry
>>>             MAX-ACCESS      not-accessible
>>>             STATUS          current
>>>             DESCRIPTION
>>>                "An entry describes the power usage of a Power
>> Monitor."
>>>             INDEX           { pmPowerIndex, pmPowerStateSetIndex}
>>>=20
>>>=20
>>>=20
>>>>=20
>>>> William F. Mielke
>>>> Alcatel-Lucent
>>>> Distinguished Member of Technical Staff 6200 East Broad Street
>>>> Room: 4B01-1V
>>>> Columbus, OH  43213-1530
>>>> Email: Bill.Mielke@alcatel-lucent.com
>>>> Phone: 614 367 5628
>>>> Fax: 614 367 5965
>>>>=20
>>>> "Live like you're going to die tomorrow.
>>>>  Learn like you're going to live forever."
>>>>=20
>>>>     - Albert Einstein
>>>>=20
>>>>=20
>>>>=20
>>>>> -----Original Message-----
>>>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20
>>>>> Behalf Of Juergen Schoenwaelder
>>>>> Sent: Tuesday, May 03, 2011 5:29 AM
>>>>> To: Benoit Claise
>>>>> Cc: eman mailing list
>>>>> Subject: Re: [eman] Two NMS configuring the Power=20
>> Monitor with two=20
>>>>> different Power State Series
>>>>>=20
>>>>> On Tue, May 03, 2011 at 11:05:50AM +0200, Benoit Claise wrote:
>>>>>=20
>>>>>> Let's discuss the following situation: what if we have=20
>> 2 NMS', and
>>=20
>>>>>> they speak different Power State Series for a specific Power=20
>>>>>> Monitor? Should this be allowed by the [EMAN-REQ]?
>>>>> Traditionally, it was always assumed that an SNMP=20
>> management system
>>=20
>>>>> can more easily adapt to devices than the other way round.
>>>>>=20
>>>>>> Actually this requirement has got some implications in terms of=20=

>>>>>> the MIB design (taking
>>>>>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07
>>>>>> into account)
>>>>>>=20
>>>>>> - If the answer is yes, then we need to have an extra=20
>> index in the
>>=20
>>>>>> power pmPowerTable. This index must abe a new TC, which is only=20=

>>>>>> for the Power State Series.  Note: the table needs to=20
>> redesigned=20
>>>>>> because the common variable (caliber, nameplate, etc...) are=20
>>>>>> common per Power State Series. Then we can have a new=20
>> table, for=20
>>>>>> discovery, that will only contain  two indices:=20
>>>>>> pmPowerMonitorIndex and the new TC-defined pmPowerStateSeries.
>>>>>> - If the answer is no, then there is the risk that NMS1=20
>> will set=20
>>>>>> the
>>>>>> DMTF:1 for example, and then NMS2 set it EMAN:3=20
>> (assuming that the
>>=20
>>>>>> Power Monitor supports both the DMTF and the EMAN Power State=20
>>>>>> Series), and there is a ping-pong game between two NMS's that=20
>>>>>> don't synchronize between the two.
>>>>> If two management systems make changes without coordination, you=20=

>>>>> always have a chance for ping-pong effects, even within a Power=20
>>>>> State Series. That said, it might be possible to provide=20
>> guidelines
>>=20
>>>>> such as if a device is reporting a value of a given Power State=20
>>>>> Series (e.g. DMTF:3), a management application should=20
>> adapt and use
>>=20
>>>>> DMTF power states.
>>>>>=20
>>>>>> The alternative is that the first NMS would say: I will=20
>> speak to=20
>>>>>> the Power Monitor with the DMTF Power State Series, and=20
>> then all=20
>>>>>> the other NMS's will have to speak the same language=20
>> (i.e. DMTF).
>>>>> I think that is a reasonably assumption to make if the number of=20=

>>>>> different Power State Series is kept limited (that is we prevent=20=

>>>>> that every vendor/organization comes up with its own creative=20
>>>>> series of power states). A large number of different Power State=20=

>>>>> Series will be hindering interoperability, with or without
>> ping-pong effects.
>>>>>=20
>>>>> /js
>>>>>=20
>>>>> --
>>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>>> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen,
>> Germany
>>>>> Fax:   +49 421 200 3103
>>>>> _______________________________________________
>>>>> eman mailing list
>>>>> eman@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>>>=20
>>>=20
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From bclaise@cisco.com  Mon Jul 25 18:37:22 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6EA11E8098 for ; Mon, 25 Jul 2011 18:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.03
X-Spam-Level: 
X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=-2.432,  BAYES_00=-2.599, GB_SUMOF=5, 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 EVbN0tGF-aFY for ; Mon, 25 Jul 2011 18:37:22 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id DA20511E8071 for ; Mon, 25 Jul 2011 18:37:21 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q1bK7R025724; Tue, 26 Jul 2011 03:37:20 +0200 (CEST)
Received: from [10.82.224.242] (rtp-vpn1-242.cisco.com [10.82.224.242]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q1bDYl009300; Tue, 26 Jul 2011 03:37:14 +0200 (CEST)
Message-ID: <4E2E1A49.2050503@cisco.com>
Date: Mon, 25 Jul 2011 21:37:13 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Rich A Morgan 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080500020501070203000903"
Cc: John P Caspers , eman@ietf.org
Subject: Re: [eman] ODVA <-> IETF EMAN
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, 26 Jul 2011 01:37:22 -0000

This is a multi-part message in MIME format.
--------------080500020501070203000903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Rich,

Thanks for your review.
See inside.
>
> Hello, Benoit,
>
> Thank you for the opportunity to review the draft IETF EMAN 
> requirements 03 document.
>
> The EMAN effort and the ODVA Energy Initiative clearly have many 
> similar goals. 
Fully agree.
> ODVA is an association of vendors that operates at the device level in 
> the industrial manuafacturing ecosystem within the overall framework 
> of the Common Industrial Protocol, or CIP.. The Energy Initiative is 
> in its first phase: developing standardized communication methods for 
> energy-aware industrial devices to report power, energy and other 
> associated data. The ODVA Energy special interest group (SIG) is 
> completing work on phase 1 and moving into the next phase: developing 
> standardized methods for commanding industrial devices to thates that 
> use energy more efficiently.
>
> The CIP Energy phase 1 effort includes a number of concepts that may 
> be useful within EMAN.
>
>   * Support of all types of energy with normalized reporting in
>     kilo-Watthours
>
Yes.
>
>  *
>
>
>   * Support of energy-aware devices with varying capabilities
>
Did you actually define the term "energy-aware devices"?
>
>  *
>       o Those that measure energy
>       o Those that derive power and energy from measurement and/or
>         other data such as device states
>       o Those that act as proxy for an external device or load
>       o Those that aggregate energy use of child devices
>       o Those that simply report a fixed power value or zero depending
>         on the device state
>       o Standardized reporting of energy data using "odometer"
>         structures (consumed energy, generated energy and net energy).
>
This is a very good concept for our EMAN framework.
I believe it should be mentioned in our EMAN requirements.
>
>  *
>       o Each odometer is an array of 5 INTs scaled by powers of 10
>       o Definition of the operation of an aggregation device. The
>         aggregator periodically polls data from its children, assesses
>         the incremental energy consumption (generation) of each child
>         and presents the sum of the child devices' incremental usage
>         in the aggregator's own set of odometers.
>
>     A reason for the use of an odometer as a 5-INT array is that many
>     CIP enabled devices are simple devices that do not support data
>     types such as INT64 or F64. An energy counter needs to be precise
>     but with a large enough maximum value that a value rollover is a
>     rare event.
>
>     The EMAN draft appears to create a valuable standardized framework
>     for not only energy management but also asset management of the
>     network infrastructure.
>
>     Thank you again for sharing this work with ODVA.
>
You're very welcome.
Your feedback is much appreciated.

Regards, Benoit.
>
>  *
>
>
>     Regards,
>
>     Rich Morgan
>     Rockwell Automation
>     Power and Energy Products
>     Office:  (+1) 414 382 0329
>     Mobile: (+1) 414 517 9071
>
>     ##
>


--------------080500020501070203000903
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Rich,

    

    Thanks for your review.

    See inside.

    

      

      Hello, Benoit,
      

      

      Thank you for the opportunity to
        review
        the draft IETF EMAN requirements 03 document.
      

      

      The EMAN effort and the ODVA
        Energy
        Initiative clearly have many similar goals. 

    Fully agree.

    
ODVA is an
        association of vendors
        that operates at the device level in the industrial
        manuafacturing ecosystem
        within the overall framework of the Common Industrial Protocol,
        or CIP..
        The Energy Initiative is in its first phase: developing
        standardized communication
        methods for energy-aware industrial devices to report power,
        energy and
        other associated data. The ODVA Energy special interest group
        (SIG) is
        completing work on phase 1 and moving into the next phase:
        developing standardized
        methods for commanding industrial devices to thates that use
        energy more
        efficiently.
      

      

      The CIP Energy phase 1 effort
        includes
        a number of concepts that may be useful within EMAN. 
      
    
        
  • Support of all types of
            energy with
            normalized reporting in kilo-Watthours
    • 
      

    

    Yes. 

    

      
    
        
  • 
          
    
        
    • 
        
  • Support of energy-aware
            devices with
            varying capabilities
    • 
      

    

    Did you actually define the term "energy-aware
      devices"?
    

      
    
        
  • 
          
      
            
    • Those that measure
                energy
            
      • 
            
    • Those that derive power
                and energy from
                measurement and/or other data such as device states
            
      • 
            
    • Those that act as proxy
                for an external
                device or load
            
      • 
            
    • Those that aggregate
                energy use of child
                devices
            
      • 
            
    • Those that simply
                report a fixed power
                value or zero depending on the device state
      • 
          
    
          
      
            
    • Standardized reporting
                of energy data
                using "odometer" structures (consumed energy, generated
                energy
                and net energy). 
      • 
          
    
        
    • 
      

    

    This is a very good concept for our EMAN framework.

    I believe it should be mentioned in our EMAN requirements.

    

      
    
        
  • 
          
      
            
    • Each odometer is an
                array of 5 INTs scaled by powers of
                10
            
      • 
            
    • Definition of the
                operation of an aggregation
                device. The aggregator periodically polls data from its
                children, assesses
                the incremental energy consumption (generation) of each
                child and presents
                the sum of the child devices' incremental usage in the
                aggregator's own
                set of odometers.
      • 
          
    
          
    
          A reason for the use of an
            odometer
            as a 5-INT array is that many CIP enabled devices are simple
            devices that
            do not support data types such as INT64 or F64. An energy
            counter needs
            to be precise but with a large enough maximum value that a
            value rollover
            is a rare event.
          
    
          
    
          The EMAN draft appears to
            create a valuable
            standardized framework for not only energy management but
            also asset management
            of the network infrastructure. 
          
    
          
    
          Thank you again for sharing
            this work
            with ODVA. 
          
    
        
    • 
      

    

    You're very welcome.

    Your feedback is much appreciated.

    

    Regards, Benoit.

    

      
    
        

  • 
            Regards,
    
            
    
            Rich Morgan
    
            Rockwell Automation
    
            Power and Energy Products
    
            Office:  (+1) 414 382 0329
    
            Mobile: (+1) 414 517 9071
    
            
    
            ##
    • 
      

    

    

  


--------------080500020501070203000903--

From bclaise@cisco.com  Mon Jul 25 18:43:25 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7901B11E8098 for ; Mon, 25 Jul 2011 18:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.33
X-Spam-Level: 
X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=-1.031,  BAYES_00=-2.599, MANGLED_SEX=2.3]
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 t4DLxgre9SHc for ; Mon, 25 Jul 2011 18:43:24 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 467CD11E8071 for ; Mon, 25 Jul 2011 18:43:24 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q1dTS0026008; Tue, 26 Jul 2011 03:39:29 +0200 (CEST)
Received: from [10.82.224.242] (rtp-vpn1-242.cisco.com [10.82.224.242]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q1dO4f010752; Tue, 26 Jul 2011 03:39:25 +0200 (CEST)
Message-ID: <4E2E1ACC.5030408@cisco.com>
Date: Mon, 25 Jul 2011 21:39:24 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Georgios Karagiannis 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: eman mailing list 
Subject: Re: [eman] New draft on eman requirements
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 01:43:25 -0000

Georgios,

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

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

Regards, Benoit (as a contributor)
> Hi Mouli
>
> Examples are given in Sectin 12.3 of the requirements draft:
>
> An example is a battery that
>     receives power at a socket at one time.  Then the socket is an inlet.
>     At another time the battery provides power at the same socket.  Then
>     it's an outlet.  The same holds for entities with integrated power
>     generators.
>
> Best regards,
> Georgios
>
> On 7/6/2011, "Mouli Chandramouli (moulchan)"  wrote:
>
>> Hi Georgios,
>>
>>
>> It would help if you can provide some more of the context of what is a
>> hybrid inlet/outlet. Where are these used ?
>>
>> Thanks
>> Mouli
>>
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
>> Georgios Karagiannis
>> Sent: Wednesday, July 06, 2011 12:04 PM
>> To: Juergen Quittek; eman mailing list
>> Subject: Re: [eman] New draft on eman requirements
>>
>> Hi Juergen,
>>
>> I think that the draft looks good!
>>
>> I have some comments on the open issues sections 12.3 and 12.4. In this
>> email I will only
>> address 12.3. In another email I will address 12.4.
>>
>> Regarding Section 12.3 Inlet/outlet combinations:
>> --------------------------------
>>
>> I am in favour of introducing a new kind of hybrid in/outlets. This is
>> because such sockets are different than the typical inlet and outlet
>> sockets.
>>
>> If these hybrid sockets are used then the requirements associated with
>> inlet/outlet socket have to somehow be modified, see below:
>>
>>
>>
>> Change_1 related to Inlet/outlet combinations:
>>
>>
>> 5.3.  Power inlet and power outlet
>>
>>    Powered entities have power inlets at which they are supplied with
>>    electric power.  Many entities just have a single power inlet, while
>>    others have multiple ones.  Often different power inlets are
>>    connected to separate power distribution trees.  For energy
>>    monitoring, it is important information which power inlets an entity
>>    has, if power is available at an inlet and which of them are actually
>>    in use.
>>
>>    Some entities have power outlets for supplying other entities with
>>    electric power.  An entity may have multiple power outlets.  Examples
>>    are a Power Distribution Units (PDU) and a Power over Ethernet (PoE)
>>    Power Sourcing Equipment (PSE).
>>
>>    For identifying and potentially controlling the source of power
>>    received at an inlet, it is useful to identify the power outlet of
>>    another entity at which the received power is provided.  Analogously,
>>    for each outlet it is of interest to identify the power inlets that
>>    receive the power provided at a certain outlet.
>>
>>    Static properties of each power inlet and each power outlet are
>>    useful information for energy management.  Static properties include
>>    the kind of electric current (Alternating Current (AC) or Direct
>>    Current (DC)), the nominal voltage, the nominal AC frequency, and the
>>    number of AC phases.
>>
>> INTO something like:
>>
>> 5.3.  Power inlet, power outlet and hybrid power inlet/outlet
>>
>>    Powered entities have power inlets at which they are supplied with
>>    electric power.  Many entities just have a single power inlet, while
>>    others have multiple ones.  Often different power inlets are
>>    connected to separate power distribution trees.  For energy
>>    monitoring, it is important information which power inlets an entity
>>    has, if power is available at an inlet and which of them are actually
>>    in use.
>>
>>    Some entities have power outlets for supplying other entities with
>>    electric power.  An entity may have multiple power outlets.  Examples
>>    are a Power Distribution Units (PDU) and a Power over Ethernet (PoE)
>>    Power Sourcing Equipment (PSE).
>>
>>
>>    There are entities where the inlet or outlet changes during
>>    operation from one kind to the other.  An example is a battery that
>>    receives power at a socket at one time.  Then the socket is an inlet.
>>    At another time the battery provides power at the same socket.  Then
>>    it's an outlet.  The same holds for entities with integrated power
>>    generators. This type of socket is denoted as a hybrid power
>> inlet/outlet.
>>
>>    For identifying and potentially controlling the source of power
>>    received at an inlet, it is useful to identify the power outlet of
>>    another entity at which the received power is provided.  Analogously,
>>    for each outlet it is of interest to identify the power inlets that
>>    receive the power provided at a certain outlet. For hybrid power
>> inlet/outlet
>>    it is for interest to identify and control when and for how long a
>>    hybrid socket operates as a power inlet and for how long it operates
>>    as a power outlet.
>>
>>    Static properties of each power inlet and each power outlet are
>>    useful information for energy management.  Static properties include
>>    the kind of electric current (Alternating Current (AC) or Direct
>>    Current (DC)), the nominal voltage, the nominal AC frequency, and the
>>    number of AC phases.
>>
>>
>>
>> Change_2: related to Inlet/outlet combinations:
>>
>> Please change from:
>>
>> 5.3.2.  Corresponding power outlet
>>
>>    The energy management standard must provide means for identifying the
>>    power outlet that provides the power received at a power inlet.
>>
>>
>> INto something like:
>>
>> 5.3.2.  Corresponding power outlet
>>
>>    The energy management standard must provide means for identifying the
>>    power outlet that provides the power received at a power inlet or at
>> a
>> hybrid power
>>    inlet/outlet.
>>
>> -----------------------
>>
>> Change_3: related to Inlet/outlet combinations:
>>
>> Please change from:
>>
>>
>>
>> 5.3.3.  Corresponding power inlets
>>
>>    The energy management standard must provide means for identifying the
>>    list of power inlets that receive the power provided at a power
>>    outlet.
>>
>> INto something like:
>>
>> 5.3.3.  Corresponding power inlets
>>
>>    The energy management standard must provide means for identifying the
>>    list of power inlets that receive the power provided at a power
>>    outlet or a hybrid power inlet/outlet.
>>
>> ---------------
>>
>>
>>
>> Change_4 related to Inlet/outlet combinations:
>>
>> Include a new section in 5.3, after section 5.3.3, something like:
>>
>> 5.3.x Corresponding hybrid power inlets/outlets
>>
>>    The energy management standard must provide means for identifying the
>>    hybrid power inlet/outlet that provides the power received at a power
>> inlet or
>>    another hybrid power inlet/outlet.
>>
>> ------------------
>>
>> Change_5 related to Inlet/outlet combinations:
>>
>> Please change from:
>>
>> 5.3.4.  Availability of power
>>
>>    The energy management standard must provide means for monitoring the
>>    availability of power at each power inlet and each power outlet.
>>    This information indicates whether at a power providing outlet power
>>    supply is switched on or off.
>>
>> INto something like:
>>
>> 5.3.4.  Availability of power
>>
>>    The energy management standard must provide means for monitoring the
>>    availability of power at each power inlet, at each power outlet and
>> at
>> each
>>    hybrid power inlet/outlet.
>>    This information indicates whether at a power providing outlet
>>    the power supply is switched on or off. For a hybrid power
>> inlet/outlet this indicates whether
>>    the hybrid inlet/outlet operates as an inlet or as an outlet.
>>
>>
>> --------------
>>
>> Change 6 related to Inlet/outlet combinations:
>>
>> Please change from:
>>
>> 5.3.5.  Use of power
>>
>>    The energy management standard must provide means for monitoring for
>>    each power inlet and each power outlet if it is in actual use.  For
>>    the inlet this means that the entity actually receives power at the
>>    inlet.  For the outlet this means that actually power is provided to
>>    one or more entities at the outlet.
>>
>> INTO something like:
>>
>> 5.3.5.  Use of power
>>
>>    The energy management standard must provide means for monitoring for
>>    each power inlet, for each power outlet and for each hybrid power
>> inlet/outlet
>>    if it is in actual use.  For
>>    the inlet this means that the entity actually receives power at the
>>    inlet.  For the outlet this means that actually power is provided to
>>    one or more entities at the outlet. For the hybrid inlet/outlet this
>> means
>>    that the energy management standard must be able to distinguish
>> whether
>>    power is received to the hybrid inlet/outlet or power is provided by
>> the
>>    hybrid inlet/outlet to one or more entities.
>>
>> ------------------
>>
>> Change 7 related to Inlet/outlet combinations:
>>
>> Please a new subsection after subsection 6.2
>>
>> 6.2.x Controlling power supply and consumption
>>    The energy management standard must provide means for switching power
>>    supply off or turning power supply on at power outlets providing
>>    power to one or more powered entity.
>>
>> INTO something like:
>>
>> 6.2.x Controlling power supply and consumption
>>
>>    The energy management standard must provide means for switching power
>>    supply off or turning power supply on at hybrid power inlet/outlets.
>>    Furthermore, the energy management standard must provide means for
>> switching
>>    the power consumption off or turning power consumption on at hybrid
>> power inlet/outlets.
>>
>> ---------------
>>
>> Best regards,
>> Georgios
>> PS: I will provide some comments on the aggregation related issue in
>> another email
>>
>>
>>
>>
>>
>>
>> On 6/30/2011, "Juergen Quittek"  wrote:
>>
>>> Dear all,
>>>
>>> I am sorry for posting another version just one day after the previous
>> one.
>>> Now out is version -03 to be found at
>>>
>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>> The reason was that a change in terminology ("powered device" ->
>> "powered
>>> entity") was not done consistently in all sections, particularly not in
>> the
>>> battery section.
>>>
>>> There are no further changes, particularly no technical changes
>> compared to
>>> the previous version.
>>>
>>> Thanks,
>>>
>>>     Juergen
>>>
>>> Am 29.06.11 16:53 schrieb "Juergen Quittek" unter:
>>>
>>>> Dear all,
>>>>
>>>> I just posted a new version on the requirements draft.
>>>> Please find it at
>>>>
>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-02.txt
>>>> We had intensive discussions among the authors and received a lot of
>> useful
>>>> comments from John Parello. This resulted in many changes and a
>> modified
>>>> structure. We consider the version posted today as an intermediate
>> one and
>>>> intend to post another update before the cut-off date.
>>>>
>>>> Please have a look at the new structure and give us your feedback.
>>>>
>>>> Issues that we definitely want to solve for the next version are
>> described
>>>> in section 12. Among them are
>>>>    - High/Low power notifications
>>>>    - Power and energy time series?
>>>>    - Inlet/outlet combinations
>>>>    - Aggregation functions
>>>> Your advice on these issues is highly appreciated.
>>>>
>>>> Thanks,
>>>>
>>>>      Juergen
>>>>
>>>> _______________________________________________
>>>> eman mailing list
>>>> eman@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/eman
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From bclaise@cisco.com  Mon Jul 25 18:56:59 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8091E21F874E for ; Mon, 25 Jul 2011 18:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.458
X-Spam-Level: 
X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.140,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9s0M1bF9NkC for ; Mon, 25 Jul 2011 18:56:56 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8494721F8749 for ; Mon, 25 Jul 2011 18:56:55 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q1r50W027684; Tue, 26 Jul 2011 03:53:05 +0200 (CEST)
Received: from [10.82.224.242] (rtp-vpn1-242.cisco.com [10.82.224.242]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q1r0hU017500; Tue, 26 Jul 2011 03:53:02 +0200 (CEST)
Message-ID: <4E2E1DFC.6050706@cisco.com>
Date: Mon, 25 Jul 2011 21:53:00 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: William Wagner 
References: <0131AC21C657A3418A5B6CA168C4C57E0A813EA6@USA7061MS04.na.xerox.net> <23E19EBD-1A1E-47AB-BA8F-47B8E919A2DE@quittek.at>	<4E2C7E87.6060505@cisco.com> 	<4E2CF747.6000800@cisco.com> <0ECE79A2-F1F9-41B1-92B6-804AD65E823F@quittek.at> <006e01cc4ae7$3a71f770$af55e650$@net>
In-Reply-To: <006e01cc4ae7$3a71f770$af55e650$@net>
Content-Type: multipart/alternative; boundary="------------070309020600020708060805"
Cc: eman@ietf.org, "'Ebner, Fritz'" 
Subject: Re: [eman] IETF EMAN request to address printers... -> draft-ietf-eman-requirements-04
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 01:56:59 -0000

This is a multi-part message in MIME format.
--------------070309020600020708060805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Bill,

Thanks for your feedback.
See inline.
>
> Gentlemen,
>
> As chairman of the IEEE-ISTO PWG workgroup that produced the  PWG 
> Power Management Model for Imaging Systems and the associated MIB 
> (ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.mib), 
> I must say that the "printer" industry has been following the  'eman' 
> activites with interest and perhaps some apprehension. Although we 
>  intend to be compliant with industry standards, and anticipate our 
> customers to require that, we believe that the PWG Power Management 
> Model best addresses the unique power characteristics of hardcopy 
> imaging equipment.  We realize that all suppliers tend to regard their 
> products as unique; but it must be recognized that "printers" , 
> particularly in the enterprise, have long ceased to be little 
> peripheral devices. They are now reasonably called Multifunction 
> Devices; perform copy, scan and facsimile functions as well as 
> printing; and have significant computing, storage and communication 
> components as well as electromechanical and often thermal processing 
> components. The power characteristics of these components and the 
> somewhat different duty cycle requirements compared with other 
> networked devices predicate the need for some special management 
> elements, and we have spent significant time and effort agreeing on 
> these.
>
> The emergence of a separate IETF energy standard (or set of standards) 
> that does not recognize the existence of a power standard developed by 
> and custom to a particular industry would create confusion and act 
> contrary to ensuring interoperability.
>
The consensus so far is that multiple power state sets would be 
supported by the EMAN framework. Obviously a device doesn't have to 
support all them.
Note that, to be compliant with the IETF, an IANA registration of the 
power state series will be required... but we're not at that stage yet.

Regards, Benoit, EMAN co-chair.

> We would hope that in the 'eman' documentation, the PWG Imaging 
> Systems Power Management MIB is referenced and considered with respect 
> to applicability, coverage, and compatibility with 'eman' objectives, 
> so that users see that the eman and PWG products can complement rather 
> than substitute for each other.
>
> Thank you,
>
> Bill Wagner, Chair WIMS/PWG
>
> *From:*eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] *On Behalf 
> Of *Juergen Quittek
> *Sent:* Monday, July 25, 2011 1:31 AM
> *To:* Benoit Claise
> *Cc:* eman@ietf.org; Ebner, Fritz
> *Subject:* Re: [eman] IETF EMAN request to address printers... -> 
> draft-ietf-eman-requirements-04
>
> Hi Benoit,
>
> I think the entire Appendix can go away.
>
> It does not contribute at all to the requirements. At least not so far.
>
> Analyzing what standard is available to meet a requirement
>
> is rather the task of a solution draft, such as the framework
>
> or the MIB modules, but not of a requirement draft.
>
> My proposal would be moving the standards analysis to the framework
>
> and discuss there also
>
>   - which of these standards are used for covering requirements, for 
> example,
>
>     Entity MIB for identification (if we do so)
>
>   - which parts of these standards are supported, such as, for example,
>
>     ACPI and DMTF power sets
>
>   - to which standards our work is aligned, for example
>
>     ODVA, IEEE-ISTO PWD, SBS, etc. and how we do so.
>
>   - from which standards we deviate
>
> Thanks,
>
>     Juergen
>
> Am 25.07.2011 um 00:55 schrieb Benoit Claise:
>
>
>
> Hi Juergen,
>
> So why is there an "IEEE-ISTO Printer WG" appendix if printers are not 
> mentioned a single time in the document?
>
> Regards, Benoit.
>
> Hi Benoit,
>
> Currently, there is the following paragraph in section 1 of 
> draft-ietf-eman-requirements-04:
>
> >   The main subject of energy management are powered entities that
>
> >   consume electric energy.  Powered entities include devices that have
>
> >   an IP address and can be addressed directly, such as hosts, routers,
>
> >   and middleboxes, as well as devices indirectly connected to an IP
>
> >   network, for which a proxy with an IP address provides a management
>
> >   interface, for example, devices in a building management
>
> >   infrastructure using BACNET or MODBUS protocols.
>
> You see that we already address all kinds of IP devices: hosts, 
> routers, and middleboxes.
>
> There is no list of special hosts, such as servers, PCs, smart phones, 
> printers, webcams, etc.
>
> I do not see a need to introduce it. Since a printer is a device that 
> can either be directly addressed with IP or that can be addressed via 
> a host connected to it, I see no need to add a special comment on it, 
> particularly not since I do not see any special requirements for a 
> printer compared to other hosts.
>
> Rather I see a need in the framework draft to discuss if and how 
> alignment with the IEEE ISTO-PWG is realized.
>
> Thanks,
>
>     Juergen
>
> Am 24.07.2011 um 16:20 schrieb Benoit Claise:
>
>
>
> Juergen,
>
> Reading this old email, I believe that we should mention "printer" 
> somewhere in the requirements draft, as a device type addressed by the 
> EMAN WG, and not only in the appendix.
>
> Regards, Benoit.
>
> Hi Fritz,
>
> Thank you for your input.
>
> We will consider printers and the document your referred to in the 
> next revision of the requirements.
>
> I don't think many changes will need to be made here.
>
> But for the MIB documents, we now have another set of PWG 
> power/functional states next to DMTF and ACPI states.
>
> Thanks,
>
>     Juergen
>
> Am 18.03.2011 um 19:11 schrieb Ebner, Fritz:
>
>
>
> Hello,
>
> Please make sure that any power control or monitoring MIBs or drafts 
> that the EMAN WG produces can cover the use cases, power controls, and 
> power monitoring features provided in the printer working group.  
> Details are below:
>
> The IEEE/ISTO Printer Working Group has published their Candidate 
> Standard for Power Management and the associate protocol binding for 
> SNMP.  Below are the links to the abstract model and MIB.
>
> PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0:
>
> The PWG Power Management Model for Imaging Systems 1.0 specification was
> recently approved as a PWGCandidateStandardand is now available at:
>
> http://www.pwg.org/standards.html
>
> and
>
> ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf/ 
> doc
>
> PWG 5106-5 - PWG Imaging System Power MIB v1.0
>
> The PWG Imaging System Power MIB v1.0 specification was recently approved
> as a PWGCandidateStandardand is now available at:
>
> http://www.pwg.org/standards.html
>
> and
>
> ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf/ 
> doc / mib
>  - PDF, MS Word, and ASN.1 source in plaintext
>
> ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.pdf
>  - ASN.1 source in color highlighted PDF
>
> Thanks,
>
> Fritz Ebner
>
> _______________________________________________
> 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
>


--------------070309020600020708060805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Bill,

    

    Thanks for your feedback.

    See inline.

    

      
      
      
      
      

        
Gentlemen,

        
 

        
As
            chairman of the IEEE-ISTO
            PWG workgroup that produced the  PWG Power Management Model
            for Imaging Systems and the associated MIB (ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.mib),
            I must say that the “printer” industry has been following
            the  ‘eman’ activites with interest and perhaps some
            apprehension. Although we  intend to be compliant with
            industry standards, and anticipate our customers to require
            that, we believe that the PWG Power Management Model best
            addresses the unique power characteristics of hardcopy
            imaging equipment.  We realize that all suppliers tend to
            regard their products as unique; but it must be recognized
            that “printers” , particularly in the enterprise, have long
            ceased to be little peripheral devices. They are now
            reasonably called Multifunction Devices; perform copy, scan
            and facsimile functions as well as printing; and have
            significant computing, storage and communication components
            as well as electromechanical and often thermal processing
            components. The power characteristics of these components
            and the somewhat different duty cycle requirements compared
            with other networked devices predicate the need for some
            special management elements, and we have spent significant
            time and effort agreeing on these. 

        
 

        
The emergence
            of a separate IETF energy standard (or set of standards)
            that does not recognize the existence of a power standard
            developed by and custom to a particular industry would
            create confusion and act contrary to ensuring
            interoperability. 

      

    

    The consensus so far is that multiple power state sets would be
    supported by the EMAN framework. Obviously a device doesn't have to
    support all them.

    Note that, to be compliant with the IETF, an IANA registration of
    the power state series will be required... but we're not at that
    stage yet.

    

    Regards, Benoit, EMAN co-chair.

    

    

      

        
We
            would hope that in the ‘eman’ documentation, the PWG Imaging
            Systems Power Management MIB is referenced and considered
            with respect to applicability, coverage, and compatibility
            with ‘eman’ objectives, so that users see that the eman and
            PWG products can complement rather than substitute for each
            other. 

        
 

        
Thank
            you,

        
 

        
Bill
            Wagner, Chair WIMS/PWG

        
 

        

          

            
From:
                eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On
                  Behalf Of Juergen Quittek

                Sent: Monday, July 25, 2011 1:31 AM

                To: Benoit Claise

                Cc: eman@ietf.org; Ebner, Fritz

                Subject: Re: [eman] IETF EMAN request to address
                printers... -> draft-ietf-eman-requirements-04

          

        

        
 

        
Hi Benoit,

        

          
 

        

        

          
I think the entire Appendix can go away. 

        

        

          
It does not contribute at all to the
            requirements. At least not so far.

        

        

          
 

        

        

          
Analyzing what standard is available to
            meet a requirement 

        

        

          
is rather the task of a solution draft,
            such as the framework 

        

        

          
or the MIB modules, but not of a
            requirement draft.

        

        

          
 

        

        

          
My proposal would be moving the standards
            analysis to the framework

        

        

          
and discuss there also 

        

        

          
  - which of these standards are used for
            covering requirements, for example, 

        

        

          
    Entity MIB for identification (if we
            do so)

        

        

          
  - which parts of these standards are
            supported, such as, for example,

        

        

          
    ACPI and DMTF power sets

        

        

          
  - to which standards our work is
            aligned, for example 

        

        

          
    ODVA, IEEE-ISTO PWD, SBS, etc. and
            how we do so.

        

        

          

            

              
  - from which standards we deviate

            

            

              
 

            

            

              
Thanks,

            

            

              
 

            

            

              
    Juergen

            

            

              
 

            

            

              
Am 25.07.2011 um 00:55 schrieb Benoit
                Claise:

            

            


              

              

            

              
Hi Juergen,

                

                So why is there an "IEEE-ISTO Printer WG" appendix if
                printers are not mentioned a single time in the
                document?

                

                Regards, Benoit. 

              

                
Hi Benoit,

              

              

                
 

              

              

                
Currently, there is the following
                  paragraph in section 1 of
                  draft-ietf-eman-requirements-04:

              

              

                
 

              

              

                

                  
>   The main subject of energy
                    management are powered entities that

                

                

                  
>   consume electric energy.
                     Powered entities include devices that have

                

                

                  
>   an IP address and can be
                    addressed directly, such as hosts, routers,

                

                

                  
>   and middleboxes, as well
                    as devices indirectly connected to an IP

                

                

                  
>   network, for which a proxy
                    with an IP address provides a management

                

                

                  
>   interface, for example,
                    devices in a building management

                

                

                  
>   infrastructure using
                    BACNET or MODBUS protocols.

                

              

              

                
 

              

              

                
You see that we already address all
                  kinds of IP devices: hosts, routers, and middleboxes.

              

              

                
There is no list of special hosts,
                  such as servers, PCs, smart phones, printers, webcams,
                  etc. 

              

              

                
I do not see a need to introduce
                  it. Since a printer is a device that can either be
                  directly addressed with IP or that can be addressed
                  via a host connected to it, I see no need to add a
                  special comment on it, particularly not since I do not
                  see any special requirements for a printer compared to
                  other hosts.

              

              

                
 

              

              

                
Rather I see a need in the
                  framework draft to discuss if and how alignment with
                  the IEEE ISTO-PWG is realized.

              

              

                
 

              

              

                
Thanks,

              

              

                
 

              

              

                
    Juergen

              

              

                
 

              

              

                
 

              

              

                

                  
Am 24.07.2011 um 16:20 schrieb
                    Benoit Claise:

                

                


                  

                  

                

                  
Juergen,

                    

                    Reading this old email, I believe that we should
                    mention "printer" somewhere in the requirements
                    draft, as a device type addressed by the EMAN WG,
                    and not only in the appendix.

                    

                    Regards, Benoit.

                    

                    

                  
Hi Fritz, 

                  

                    
 

                  

                  

                    
Thank you for your input.

                  

                  

                    
 

                  

                  

                    
We will consider printers and
                      the document your referred to in the next revision
                      of the requirements.

                  

                  

                    
I don't think many changes will
                      need to be made here.

                  

                  

                    
 

                  

                  

                    
But for the MIB documents, we
                      now have another set of PWG power/functional
                      states next to DMTF and ACPI states.

                  

                  

                    
 

                  

                  

                    
Thanks,

                  

                  

                    
 

                  

                  

                    
    Juergen

                  

                  

                    
 

                  

                  

                    
 

                    

                      

                        
Am 18.03.2011 um 19:11
                          schrieb Ebner, Fritz:

                      

                      


                        

                        

                      

                        

                          
Hello,

                        

                        

                          
Please
                              make sure that any power control or
                              monitoring MIBs or drafts that the EMAN WG
                              produces can cover the use cases, power
                              controls, and power monitoring features
                              provided in the printer working group. 
                              Details are below:

                        

                        

                          
 

                        

                        

                          
The
                              IEEE/ISTO Printer Working Group has
                              published their Candidate Standard for
                              Power Management and the associate
                              protocol binding for SNMP.  Below are the
                              links to the abstract model and MIB.

                        

                        

                          

                            
 

                          

                        

                        

                          
PWG
                              5106.4 - PWG Power Management Model for
                              Imaging Systems 1.0:

                        

                        

                          
 

                        

                        

                          

                            
The
                                PWG Power Management Model for Imaging
                                Systems 1.0 specification was 

                                recently approved as a PWG Candidate Standard and
                                is now available at:

                                

                                 http://www.pwg.org/standards.html

                                

                                and

                                

                                 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf /
                                doc

                          

                          

                            
 

                          

                        

                        

                          
PWG
                              5106-5 - PWG Imaging System Power MIB v1.0

                        

                        

                          
 

                        

                        

                          

                            
The
                                PWG Imaging System Power MIB v1.0
                                specification was recently approved

                                as a PWG Candidate Standard and
                                is now available at:

                                

                                 http://www.pwg.org/standards.html

                                

                                and

                                

                                 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf /
                                doc / mib

                                 - PDF, MS Word, and ASN.1 source in
                                plaintext

                                

                                 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.pdf

                                 - ASN.1 source in color highlighted PDF

                          

                        

                        

                          
 

                        

                        

                          
Thanks,

                        

                        

                          
Fritz
                              Ebner

                        

                        
_______________________________________________

                          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

                  
 

                

              

              
 

              
 

            

          

          
 

        

      

    

    

  


--------------070309020600020708060805--

From bclaise@cisco.com  Mon Jul 25 19:03:11 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8AD21F87AF for ; Mon, 25 Jul 2011 19:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.461
X-Spam-Level: 
X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.137,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3mEgnVgSB1V for ; Mon, 25 Jul 2011 19:03:10 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 61F2E21F8797 for ; Mon, 25 Jul 2011 19:03:09 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q1nGDs027197; Tue, 26 Jul 2011 03:49:16 +0200 (CEST)
Received: from [10.82.224.242] (rtp-vpn1-242.cisco.com [10.82.224.242]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q1n9RS015846; Tue, 26 Jul 2011 03:49:10 +0200 (CEST)
Message-ID: <4E2E1D14.5040109@cisco.com>
Date: Mon, 25 Jul 2011 21:49:08 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Juergen Quittek 
References: <0131AC21C657A3418A5B6CA168C4C57E0A813EA6@USA7061MS04.na.xerox.net> <23E19EBD-1A1E-47AB-BA8F-47B8E919A2DE@quittek.at> <4E2C7E87.6060505@cisco.com>  <4E2CF747.6000800@cisco.com> <0ECE79A2-F1F9-41B1-92B6-804AD65E823F@quittek.at>
In-Reply-To: <0ECE79A2-F1F9-41B1-92B6-804AD65E823F@quittek.at>
Content-Type: multipart/alternative; boundary="------------070807050808080700020700"
Cc: eman@ietf.org, "Ebner, Fritz" 
Subject: Re: [eman] IETF EMAN request to address printers... -> draft-ietf-eman-requirements-04
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 02:03:11 -0000

This is a multi-part message in MIME format.
--------------070807050808080700020700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Juergen,

Keep in mind that we need a place to describe why what exists today is 
not good enough for our requirements
For example, the ENTITY-SENSOR MIB.
I believe the right place is the requirement draft.

Regards, Benoit.
> Hi Benoit,
>
> I think the entire Appendix can go away.
> It does not contribute at all to the requirements. At least not so far.
>
> Analyzing what standard is available to meet a requirement
> is rather the task of a solution draft, such as the framework
> or the MIB modules, but not of a requirement draft.
>
> My proposal would be moving the standards analysis to the framework
> and discuss there also
>   - which of these standards are used for covering requirements, for 
> example,
>     Entity MIB for identification (if we do so)
>   - which parts of these standards are supported, such as, for example,
>     ACPI and DMTF power sets
>   - to which standards our work is aligned, for example
>     ODVA, IEEE-ISTO PWD, SBS, etc. and how we do so.
>   - from which standards we deviate
>
> Thanks,
>
>     Juergen
>
> Am 25.07.2011 um 00:55 schrieb Benoit Claise:
>
>> Hi Juergen,
>>
>> So why is there an "IEEE-ISTO Printer WG" appendix if printers are 
>> not mentioned a single time in the document?
>>
>> Regards, Benoit.
>>> Hi Benoit,
>>>
>>> Currently, there is the following paragraph in section 1 of 
>>> draft-ietf-eman-requirements-04:
>>>
>>> >   The main subject of energy management are powered entities that
>>> >   consume electric energy.  Powered entities include devices that have
>>> >   an IP address and can be addressed directly, such as hosts, routers,
>>> >   and middleboxes, as well as devices indirectly connected to an IP
>>> >   network, for which a proxy with an IP address provides a management
>>> >   interface, for example, devices in a building management
>>> >   infrastructure using BACNET or MODBUS protocols.
>>>
>>> You see that we already address all kinds of IP devices: hosts, 
>>> routers, and middleboxes.
>>> There is no list of special hosts, such as servers, PCs, smart 
>>> phones, printers, webcams, etc.
>>> I do not see a need to introduce it. Since a printer is a device 
>>> that can either be directly addressed with IP or that can be 
>>> addressed via a host connected to it, I see no need to add a special 
>>> comment on it, particularly not since I do not see any special 
>>> requirements for a printer compared to other hosts.
>>>
>>> Rather I see a need in the framework draft to discuss if and how 
>>> alignment with the IEEE ISTO-PWG is realized.
>>>
>>> Thanks,
>>>
>>>     Juergen
>>>
>>>
>>> Am 24.07.2011 um 16:20 schrieb Benoit Claise:
>>>
>>>> Juergen,
>>>>
>>>> Reading this old email, I believe that we should mention "printer" 
>>>> somewhere in the requirements draft, as a device type addressed by 
>>>> the EMAN WG, and not only in the appendix.
>>>>
>>>> Regards, Benoit.
>>>>> Hi Fritz,
>>>>>
>>>>> Thank you for your input.
>>>>>
>>>>> We will consider printers and the document your referred to in the 
>>>>> next revision of the requirements.
>>>>> I don't think many changes will need to be made here.
>>>>>
>>>>> But for the MIB documents, we now have another set of PWG 
>>>>> power/functional states next to DMTF and ACPI states.
>>>>>
>>>>> Thanks,
>>>>>
>>>>>     Juergen
>>>>>
>>>>>
>>>>> Am 18.03.2011 um 19:11 schrieb Ebner, Fritz:
>>>>>
>>>>>> Hello,
>>>>>> Please make sure that any power control or monitoring MIBs or 
>>>>>> drafts that the EMAN WG produces can cover the use cases, power 
>>>>>> controls, and power monitoring features provided in the printer 
>>>>>> working group.  Details are below:
>>>>>> The IEEE/ISTO Printer Working Group has published their Candidate 
>>>>>> Standard for Power Management and the associate protocol binding 
>>>>>> for SNMP.  Below are the links to the abstract model and MIB.
>>>>>> PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0:
>>>>>> The PWG Power Management Model for Imaging Systems 1.0 
>>>>>> specification was
>>>>>> recently approved as a PWGCandidateStandardand is now available at:
>>>>>>
>>>>>> http://www.pwg.org/standards.html
>>>>>>
>>>>>> and
>>>>>>
>>>>>> ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf/ 
>>>>>> doc
>>>>>> PWG 5106-5 - PWG Imaging System Power MIB v1.0
>>>>>> The PWG Imaging System Power MIB v1.0 specification was recently 
>>>>>> approved
>>>>>> as a PWGCandidateStandardand is now available at:
>>>>>>
>>>>>> http://www.pwg.org/standards.html
>>>>>>
>>>>>> and
>>>>>>
>>>>>> ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf/ 
>>>>>> doc / mib
>>>>>>  - PDF, MS Word, and ASN.1 source in plaintext
>>>>>>
>>>>>> ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.pdf
>>>>>>  - ASN.1 source in color highlighted PDF
>>>>>> Thanks,
>>>>>> Fritz Ebner
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>
>>
>


--------------070807050808080700020700
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Juergen,

    

    Keep in mind that we need a place to describe why what exists today
    is not good enough for our requirements

    For example, the ENTITY-SENSOR MIB.

    I believe the right place is the requirement draft.

    

    Regards, Benoit.

    
Hi Benoit,
      


      

      
I think the entire Appendix can go away. 

      
It does not contribute at all to the requirements. At least
        not so far.

      


      

      
Analyzing what standard is available to meet a requirement 

      
is rather the task of a solution draft, such as the
        framework 

      
or the MIB modules, but not of a requirement draft.

      


      

      
My proposal would be moving the standards analysis to the
        framework

      
and discuss there also 

      
  - which of these standards are used for covering
        requirements, for example, 

      
    Entity MIB for identification (if we do so)

      
  - which parts of these standards are supported, such as,
        for example,

      
    ACPI and DMTF power sets

      
  - to which standards our work is aligned, for example 

      
    ODVA, IEEE-ISTO PWD, SBS, etc. and how we do so.

      

        

          
  - from which standards we deviate

          


          

          
Thanks,

          


          

          
    Juergen

          


          

          
Am 25.07.2011 um 00:55 schrieb Benoit Claise:

          

          

            
            
 Hi Juergen,

              

              So why is there an "IEEE-ISTO Printer WG" appendix if
              printers are not mentioned a single time in the document?

              

              Regards, Benoit.
              

                
Hi Benoit,

                


                

                
Currently, there is the following paragraph in
                  section 1 of draft-ietf-eman-requirements-04:

                


                

                

                  
>   The main subject of energy management are
                    powered entities that

                  
>   consume electric energy.  Powered entities
                    include devices that have

                  
>   an IP address and can be addressed
                    directly, such as hosts, routers,

                  
>   and middleboxes, as well as devices
                    indirectly connected to an IP

                  
>   network, for which a proxy with an IP
                    address provides a management

                  
>   interface, for example, devices in a
                    building management

                  
>   infrastructure using BACNET or MODBUS
                    protocols.

                

                


                

                
You see that we already address all kinds of IP
                  devices: hosts, routers, and middleboxes.

                
There is no list of special hosts, such as servers,
                  PCs, smart phones, printers, webcams, etc. 

                
I do not see a need to introduce it. Since a
                  printer is a device that can either be directly
                  addressed with IP or that can be addressed via a host
                  connected to it, I see no need to add a special
                  comment on it, particularly not since I do not see any
                  special requirements for a printer compared to other
                  hosts.

                


                

                
Rather I see a need in the framework draft to
                  discuss if and how alignment with the IEEE ISTO-PWG is
                  realized.

                


                

                
Thanks,

                


                

                
    Juergen

                


                

                


                

                

                  
Am 24.07.2011 um 16:20 schrieb Benoit Claise:

                  

                  

                    
                    
 Juergen,

                      

                      Reading this old email, I believe that we should
                      mention "printer" somewhere in the requirements
                      draft, as a device type addressed by the EMAN WG,
                      and not only in the appendix.

                      

                      Regards, Benoit.

                      
Hi Fritz,
                        


                        

                        
Thank you for your input.

                        


                        

                        
We will consider printers and the document
                          your referred to in the next revision of the
                          requirements.

                        
I don't think many changes will need to be
                          made here.

                        


                        

                        
But for the MIB documents, we now have
                          another set of PWG power/functional states
                          next to DMTF and ACPI states.

                        


                        

                        
Thanks,

                        


                        

                        
    Juergen

                        


                        

                        


                          

                            
Am 18.03.2011 um 19:11 schrieb Ebner,
                              Fritz:

                            

                            

                              

                                

                                  
Hello,

                                  
Please make
                                    sure that any power control or
                                    monitoring MIBs or drafts that the
                                    EMAN WG produces can cover the use
                                    cases, power controls, and power
                                    monitoring features provided in the
                                    printer working group.  Details are
                                    below:

                                  
 

                                  
The IEEE/ISTO
                                    Printer Working Group has published
                                    their Candidate Standard for Power
                                    Management and the associate
                                    protocol binding for SNMP.  Below
                                    are the links to the abstract model
                                    and MIB.

                                  

                                    
 

                                  

                                  
PWG
                                      5106.4 - PWG Power Management
                                      Model for Imaging Systems 1.0:

                                  
 

                                  

                                    
The PWG Power
                                      Management Model for Imaging
                                      Systems 1.0 specification was 

                                      recently approved as a PWG Candidate Standard and

                                      is now available at:

                                      

                                       http://www.pwg.org/standards.html

                                      

                                      and

                                      

                                       ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf /
                                      doc

                                    
 

                                  

                                  
PWG
                                      5106-5 - PWG Imaging System Power
                                      MIB v1.0

                                  
 

                                  

                                    
The PWG
                                      Imaging System Power MIB v1.0
                                      specification was recently
                                      approved

                                      as a PWG Candidate Standard and

                                      is now available at:

                                      

                                       http://www.pwg.org/standards.html

                                      

                                      and

                                      

                                       ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf /
                                      doc / mib

                                       - PDF, MS Word, and ASN.1 source
                                      in plaintext

                                      

                                       ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.pdf

                                       - ASN.1 source in color
                                      highlighted PDF

                                  

                                  
 

                                  
Thanks,

                                  
Fritz Ebner

                                

_______________________________________________

                                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


                      

                      

                    

                  

                

                

              

              

            

          

        

        

      

    

    

  


--------------070807050808080700020700--

From bclaise@cisco.com  Mon Jul 25 19:49:43 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C5011E8077 for ; Mon, 25 Jul 2011 19:49:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.464
X-Spam-Level: 
X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.134,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOGWV-TEe3tp for ; Mon, 25 Jul 2011 19:49:42 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 80B7B11E8071 for ; Mon, 25 Jul 2011 19:49:42 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q2jupo003938; Tue, 26 Jul 2011 04:45:56 +0200 (CEST)
Received: from [10.82.243.234] (rtp-vpn2-1002.cisco.com [10.82.243.234]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q2jslc011626; Tue, 26 Jul 2011 04:45:54 +0200 (CEST)
Message-ID: <4E2E2A61.6060503@cisco.com>
Date: Mon, 25 Jul 2011 22:45:53 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Michael Suchoff 
References:   <54ECD73F-B9A8-440F-970B-B9DD538CA186@quittek.at> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070704050302050207090108"
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - open issue 12.3: time series of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 02:49:43 -0000

This is a multi-part message in MIME format.
--------------070704050302050207090108
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Michael,

This is exactly what's available in the EMAN monitoring MIB for the energy
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09, 
section 5.5

Regards, Benoit
> Dear Juergen,
>
> The larger manufacturers of managed power distribution equipment (APC, 
> Eaton, Raritan...) all provide circular buffers of time stamped power 
> measurements.  Certification of our products for use with IBM System 
> Director required this as well.
>
> The better products allow the polling interval to be specified and 
> provide ability for events (under currents, circuit breaker trips, 
> etc.) to be reported as traps.
>
> Our larger data center customers wanted this feature too as they 
> realized polling thousands of devices minute by minute was inefficient 
> and can yield unacceptable timing uncertainty.
>
> Our products are able to report accurate measurements - accuracy being 
> defined as how close do two or more devices agree with a calibrated 
> reference meter when measuring the same quantity.  This cannot be 
> achieved without considering time.
>
> On Wed, Jul 13, 2011 at 8:52 AM, Juergen Quittek  > wrote:
>
>     Dear Mouli,
>
>     Thank you for commenting on this issue. I would like to have a
>     look at the following point of view:
>
>     So far, storing time series of measurements on managed nodes is
>     rarely standardized and rarely available as implementation.
>
>     Typically, it is the job of a network management system to collect
>     time series and store them.
>
>     Take for example byte and packet counters at line cards. You see
>     many curves showing time series of traffic rate/volume in the
>     Internet, but almost all of them were collected at management
>     stations or data collector modules, but not within MIB modules.
>     (Please correct me if I'm wrong.)
>
>     Now the question is: Is energy management so much different from
>     other network management tasks, that we need the rarely used
>     mechanism of storing time series in MIB modules?
>
>     If not, it would be sufficient to just report the number of total
>     energy consumed since the last re-start as you do it with packet
>     and byte counters.
>     This would be just a single managed object to be specified and
>     implemented.
>
>     Thanks,
>
>        Juergen
>
>     Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):
>
>     > Regarding the Time Series debate - the crucial question - where
>     is the
>     > data / measurements stored.
>     > It would not be possible for small devices to store such data for a
>     > sufficiently long time period.
>     >
>     > The NMS can store the values for a sufficiently long period of
>     time, for
>     > trending analysis.
>     >
>     > In the case of demand measurement, since the maximum over a
>     window is
>     > computed, it is important for the device store atleast a window
>     length
>     > of measurements.
>     >
>     > I am not sure about that Requirement 5.4.10 - Time Series of Power
>     > Values - to be stored in the device
>     >
>     > Thanks
>     > Mouli
>     >
>     >
>     > -----Original Message-----
>     > From: eman-bounces@ietf.org 
>     [mailto:eman-bounces@ietf.org ] On
>     Behalf Of
>     > Juergen Quittek
>     > Sent: Tuesday, July 12, 2011 2:31 PM
>     > To: eman mailing list
>     > Subject: [eman] new revision of eman requirements
>     >
>     > Dear all,
>     >
>     > I posted a new version of the eman requirements yesterday.
>     > Please find it at
>     > http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/
>     >
>     >
>     > Of course, feel free to also comment on the other open issues or to
>     > raise
>     > new ones. All such contributions are highly appreciated.
>     >
>     > Thanks,
>     >
>     >    Juergen
>     >
>     > _______________________________________________
>     > eman mailing list
>     > eman@ietf.org 
>     > https://www.ietf.org/mailman/listinfo/eman
>     > _______________________________________________
>     > eman mailing list
>     > eman@ietf.org 
>     > https://www.ietf.org/mailman/listinfo/eman
>
>     _______________________________________________
>     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


--------------070704050302050207090108
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Dear Michael,

    

    This is exactly what's available in the EMAN monitoring MIB for the
    energy

    http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09,
    section 5.5

    

    Regards, Benoit

    
Dear Juergen,

      

      The larger manufacturers of managed power distribution equipment
      (APC, Eaton, Raritan...) all provide circular buffers of time
      stamped power measurements.  Certification of our products for use
      with IBM System Director required this as well.

      

      The better products allow the polling interval to be specified and
      provide ability for events (under currents, circuit breaker trips,
      etc.) to be reported as traps.

      

      Our larger data center customers wanted this feature too as they
      realized polling thousands of devices minute by minute was
      inefficient and can yield unacceptable timing uncertainty.

      

      Our products are able to report accurate measurements - accuracy
      being defined as how close do two or more devices agree with a
      calibrated reference meter when measuring the same quantity.  This
      cannot be achieved without considering time.

      

      
On Wed, Jul 13, 2011 at 8:52 AM, Juergen
        Quittek <ietf@quittek.at>
        wrote:

        

          Dear Mouli,

          

          Thank you for commenting on this issue. I would like to have a
          look at the following point of view:

          

          So far, storing time series of measurements on managed nodes
          is rarely standardized and rarely available as implementation.

          

          Typically, it is the job of a network management system to
          collect time series and store them.

          

          Take for example byte and packet counters at line cards. You
          see many curves showing time series of traffic rate/volume in
          the Internet, but almost all of them were collected at
          management stations or data collector modules, but not within
          MIB modules. (Please correct me if I'm wrong.)

          

          Now the question is: Is energy management so much different
          from other network management tasks, that we need the rarely
          used mechanism of storing time series in MIB modules?

          

          If not, it would be sufficient to just report the number of
          total energy consumed since the last re-start as you do it
          with packet and byte counters.

          This would be just a single managed object to be specified and
          implemented.

          

          Thanks,

          

             Juergen

          

          Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):

          

          > Regarding the Time Series debate - the crucial question -
          where is the

          > data / measurements stored.

          > It would not be possible for small devices to store such
          data for a

          > sufficiently long time period.

          >

          > The NMS can store the values for a sufficiently long
          period of time, for

          > trending analysis.

          >

          > In the case of demand measurement, since the maximum over
          a window is

          > computed, it is important for the device store atleast a
          window length

          > of measurements.

          >

          > I am not sure about that Requirement 5.4.10 - Time Series
          of Power

          > Values - to be stored in the device

          >

          > Thanks

          > Mouli

          >

          >

          > -----Original Message-----

          > From: eman-bounces@ietf.org
          [mailto:eman-bounces@ietf.org]
          On Behalf Of

          > Juergen Quittek

          > Sent: Tuesday, July 12, 2011 2:31 PM

          > To: eman mailing list

          > Subject: [eman] new revision of eman requirements

          >

          > Dear all,

          >

          > I posted a new version of the eman requirements
          yesterday.

          > Please find it at

          > http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/

          >

          >

          > Of course, feel free to also comment on the other open
          issues or to

          > raise

          > new ones. All such contributions are highly appreciated.

          >

          > Thanks,

          >

          >    Juergen

          >

          > _______________________________________________

          > eman mailing list

          > eman@ietf.org

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

          > _______________________________________________

          > eman mailing list

          > eman@ietf.org

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

          

          _______________________________________________

          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


    

    

  


--------------070704050302050207090108--

From bclaise@cisco.com  Mon Jul 25 19:54:11 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C858211E8071 for ; Mon, 25 Jul 2011 19:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.466
X-Spam-Level: 
X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.132,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zY23FlU2ixTz for ; Mon, 25 Jul 2011 19:54:11 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id B336421F854F for ; Mon, 25 Jul 2011 19:54:10 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q2s9I4004921; Tue, 26 Jul 2011 04:54:09 +0200 (CEST)
Received: from [10.82.243.234] (rtp-vpn2-1002.cisco.com [10.82.243.234]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q2s4ZA015666; Tue, 26 Jul 2011 04:54:05 +0200 (CEST)
Message-ID: <4E2E2C4C.8070605@cisco.com>
Date: Mon, 25 Jul 2011 22:54:04 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Juergen Quittek 
References:    <1127B34B-6899-4F1D-966E-ED841E25E554@quittek.at> <4E142A61.3010103@cisco.com> <20248561-E87E-4CD0-9E57-E031B00E479A@quittek.at>
In-Reply-To: <20248561-E87E-4CD0-9E57-E031B00E479A@quittek.at>
Content-Type: multipart/alternative; boundary="------------070702000407050203000300"
Cc: eman mailing list 
Subject: Re: [eman] New draft on eman requirements  - issue 1 - Device type
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, 26 Jul 2011 02:54:11 -0000

This is a multi-part message in MIME format.
--------------070702000407050203000300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Juergen,
> On 06.07.2011  11:26, Benoit Claise wrote:
>
>> On 01/07/2011 14:10, Juergen Quittek wrote:
>>> Hi Mouli,
>>>
>>> I'm glad you comment on this. It was too vague so far.
>>> Please see plies inline.
>>>
>>> Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan):
>>>
>>>> Hello,
>>>>
>>>> As Juergen has mentioned, while the first version has been released to
>>>> solicit feedback, some of the concepts are still debated.
>>>> The perspectives from the email list would be useful to shape the draft.
>>>>
>>>> I shall post some of the discussion points.
>>>>
>>>> Thanks
>>>> Mouli
>>>>
>>>> ------------
>>>>
>>>> There is a requirement -
>>>> http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>>>
>>>>
>>>> 5.1.1.  Type of powered entity
>>>>
>>>>    The energy management standard must provide means to retrieve and
>>>>    report the type of powered entities.
>>>>
>>>> I think it would be useful to expand this requirement. Device Type could
>>>> be inferred as "IP Phone" or "Line Card 3", ...
>>> Yes. The question is what is needed?
>> We don't want we redo the ENTITY-MIB work, but  I believe that having 
>> a way to map to the ENTITY-MIB index is important.
>> The more generic requirements should be something such as:
>>
>>     The energy management standard must provide means to map the power entities
>>     to existing managed device inventory such as the ENTITY-MIB.
>>
>>     The energy management standard must provide means to map the power entities
>>     to existing energy related MIBs such as the POE and LLPD MIBs
>>
>>
>> Those two requirements should be in the section 4. Identification of 
>> Powered Entities
>
> I agree on moving it to section 4.  The discussion on the content is 
> going on in another email thread.
I would appreciate if you could either introduce this text in the draft, 
or list this as an open issue, instead of just ignoring it.

Regards, Benoit (as a contributor)


--------------070702000407050203000300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Juergen,
    

      

        
On 06.07.2011  11:26, Benoit Claise wrote:

        

        

          
 On 01/07/2011 14:10,
            Juergen Quittek wrote:
            

              
Hi Mouli,

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

Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan):



              

                
Hello,

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

I shall post some of the discussion points. 

Thanks
Mouli

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

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


5.1.1.  Type of powered entity

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

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


              

              
Yes. The question is what is needed?


            

            We don't want we redo the ENTITY-MIB work, but  I believe
            that having a way to map to the ENTITY-MIB index is
            important.

            The more generic requirements should be something such as:

            

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

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



            

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

          

        

        


        

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

      

    

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

    

    Regards, Benoit (as a contributor)

    

  


--------------070702000407050203000300--

From bclaise@cisco.com  Mon Jul 25 20:37:07 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9234D21F8788 for ; Mon, 25 Jul 2011 20:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.469
X-Spam-Level: 
X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kd22b4h+Pt6C for ; Mon, 25 Jul 2011 20:37:07 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D301D21F8772 for ; Mon, 25 Jul 2011 20:37:06 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q3b53e010415; Tue, 26 Jul 2011 05:37:05 +0200 (CEST)
Received: from [10.82.244.143] (rtp-vpn2-1167.cisco.com [10.82.244.143]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q3axDW004772; Tue, 26 Jul 2011 05:37:00 +0200 (CEST)
Message-ID: <4E2E365B.9090501@cisco.com>
Date: Mon, 25 Jul 2011 23:36:59 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Juergen Quittek 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: eman mailing list 
Subject: Re: [eman] Requirements comments, part II
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, 26 Jul 2011 03:37:07 -0000

Hi Juergen, Bruce,
> Hi Bruce,
>
> Am 08.07.11 09:25 schrieb "Bruce Nordman" unter:
>
>> Part II:
>>
>>
>> 5. Required Information on Powered Entities
>>    It would be helpful to identify variables that are static vs. those that are
>> dynamic.
>>    There are some that are absolutely static, and others that just rarely
>> change.
> Right. But I think this can be done in the framework or the MIB module.
> The Battery MIB clearly separates static from dynamic values.
Agreed.

Regards, Benoit (as a contributor)

From bclaise@cisco.com  Mon Jul 25 20:48:11 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AB211E8077 for ; Mon, 25 Jul 2011 20:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.471
X-Spam-Level: 
X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.127,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zMibV1TsY5F for ; Mon, 25 Jul 2011 20:48:10 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8C52A11E8076 for ; Mon, 25 Jul 2011 20:48:09 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q3Jcvj008341; Tue, 26 Jul 2011 05:19:38 +0200 (CEST)
Received: from [10.82.244.143] (rtp-vpn2-1167.cisco.com [10.82.244.143]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q3JWJl027213; Tue, 26 Jul 2011 05:19:33 +0200 (CEST)
Message-ID: <4E2E3244.8020605@cisco.com>
Date: Mon, 25 Jul 2011 23:19:32 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "Mielke, William F (Bill)" 
References:    <1127B34B-6899-4F1D-966E-ED841E25E554@quittek.at> <4E142A61.3010103@cisco.com> <20248561-E87E-4CD0-9E57-E031B00E479A@quittek.at>  <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D86D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D86D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="------------090107040807050408070506"
Cc: eman mailing list 
Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type
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, 26 Jul 2011 03:48:11 -0000

This is a multi-part message in MIME format.
--------------090107040807050408070506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

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

    5.1.1. Type of powered entity

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

>
> Grouping for what purpose?
For reporting.
>
> Bruce on the other hand appears to be using the term to mean literally what type of device it is, e.g. a light bulb, a network router, a refrigerator, etc.  This usage seems unrelated to grouping although it could be used as a means of identying all the light bulbs, or all the refrigerators.
>
> I agree with Bruce that we should be supporting some sort of device type identification information.  This would be useful for identifying, for example, which "Unit of Useful Work" would be applicable to a given device to derive a meaningful efficiency metric for it.
Hence my previous request to have a pointer to the ENTITY-MIB clearly 
mentioned in the requirements, just in case the MIB is present.

Regards, Benoit.
>
> William F. Mielke
> Alcatel-Lucent
> Distinguished Member of Technical Staff
> 6200 East Broad Street
> Room: 4B01-1V
> Columbus, OH  43213-1530
> Email: Bill.Mielke@alcatel-lucent.com
> Phone: 614 367 5628
> Fax: 614 367 5965
>
> "Live like you're going to die tomorrow.
>   Learn like you're going to live forever."
>
>      - Albert Einstein
>
>
>
>
> ________________________________
>
> 	From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Bruce Nordman
> 	Sent: Friday, July 08, 2011 3:17 AM
> 	To: eman mailing list
> 	Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type
> 	
> 	
>
>
> 	On Wed, Jul 6, 2011 at 4:59 AM, Juergen Quittek  wrote:
> 	
>
> 		On 06.07.2011  11:26, Benoit Claise wrote:
> 		....
>
>
> 			Coming back to this requirement
> 			
> 			
>
> 				5.1.1. Type of powered entity
> 				
> 				The energy management standard must provide means to retrieve and
> 				report the type of powered entities.
>
> 			I believe the "type" is misleading. The main requirement is that we want the ability to group powered entities based on something, which could be the type, what the type definition you want.
> 			Therefore, I would remove the requirement 5.1.1 and only keep the current 5.1.2
> 			
>
> 				5.1.2.  Grouping of powered entities
> 				
> 				   The energy management standard must provide means for grouping
> 				   powered entities, for example, into energy monitoring domains, energy
> 				   control domains, power supply domains, groups of entities of the same
> 				   type, etc.
>
> 		I agree. I do not know what an entity type is. So let's remove 5.1.1.
> 		However, 5.1.2 also talks about entities of the same type :-)
> 		Shall we remove "type" also here?
>
>
> 	I have to disagree completely on this point.
> 	A major barrier to understanding energy use in
> 	buildings and in doing things to reduce it is
> 	lack of information about what devices are
> 	present in a building and how much each
> 	one is using.  We are going into great detail
> 	about the quantities of energy, but seem to
> 	want to avoid saying anything about what
> 	the device actually is.
> 	
> 	Accomplishing this and meeting the needs of
> 	energy efficiency need not be burdensome.
> 	Just a few variables can point to a standard
> 	index of device types (or "product types" in
> 	my line of work) and short brand/model
> 	information.
> 	
> 	Thanks,
> 	
> 	--Bruce
> 	
> 	
>
>
>
>
>
> 	--
> 	Bruce Nordman
> 	Lawrence Berkeley National Laboratory
> 	eetd.lbl.gov/ea/nordman
> 	BNordman@LBL.gov
> 	510-486-7089
> 	m: 510-501-7943
> 	
> 	
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


--------------090107040807050408070506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Bill,

    

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

    

    Sorry for being really unclear. I should have written. The main
    requirement is that we want the ability to group powered entities
    based on something, whatever this criteria is .... Let me explain.
    If we do EMAN monitoring, it's to report on power/energy. Those
    reports can be based on the device type (PC, Phone, printer, router,
    switch, ..), based on the business context, based on the
    software/hardware version, based on your own criteria, ...

    

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

    

    
5.1.1. Type of powered entity

      

      The energy management standard must provide means to retrieve and

      report the type of powered entities.

    

    

      

Grouping for what purpose?

    

    For reporting.

    

      

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

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

    

    Hence my previous request to have a pointer to the ENTITY-MIB
    clearly mentioned in the requirements, just in case the MIB is
    present.

    

    Regards, Benoit.

    

      

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com <mailto:mielke@alcatel-lucent.com> 
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein 

 


________________________________

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


	On Wed, Jul 6, 2011 at 4:59 AM, Juergen Quittek <ietf@quittek.at> wrote:
	

		On 06.07.2011  11:26, Benoit Claise wrote:
		....


			Coming back to this requirement
			
			

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

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

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

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


	I have to disagree completely on this point.
	A major barrier to understanding energy use in
	buildings and in doing things to reduce it is
	lack of information about what devices are 
	present in a building and how much each
	one is using.  We are going into great detail
	about the quantities of energy, but seem to
	want to avoid saying anything about what
	the device actually is.
	
	Accomplishing this and meeting the needs of
	energy efficiency need not be burdensome.
	Just a few variables can point to a standard
	index of device types (or "product types" in
	my line of work) and short brand/model
	information.
	
	Thanks,
	
	--Bruce
	 
	





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

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


    

    

  


--------------090107040807050408070506--

From bclaise@cisco.com  Mon Jul 25 23:19:46 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8C111E8085 for ; Mon, 25 Jul 2011 23:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.473
X-Spam-Level: 
X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.125,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jN71HSNsb3av for ; Mon, 25 Jul 2011 23:19:37 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E545D11E807E for ; Mon, 25 Jul 2011 23:19:29 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q6JRO8000384 for ; Tue, 26 Jul 2011 08:19:27 +0200 (CEST)
Received: from [10.82.253.241] (rtp-vpn6-1516.cisco.com [10.82.253.241]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6Q6JOof027003 for ; Tue, 26 Jul 2011 08:19:25 +0200 (CEST)
Message-ID: <4E2E5C6C.6070502@cisco.com>
Date: Tue, 26 Jul 2011 02:19:24 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: eman mailing list 
References: <4E2E1729.3070600@cisco.com>
In-Reply-To: <4E2E1729.3070600@cisco.com>
Content-Type: multipart/alternative; boundary="------------080707000203080108030702"
Subject: [eman] feedback on the eman-ietf-eman-requirements-04
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 06:19:46 -0000

This is a multi-part message in MIME format.
--------------080707000203080108030702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

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

A couple of big points
- the outlet gang was mentioned by Chris Verges as a requirement. I 
don't think I've seen it mentioned.
     Note: this could be solved by a specificEnergy Managed Object 
Relationships  (Metering, Power Source, Proxy, Dependency)
- we would need some requirements about producer and/or consumer
- I've been thinking about the following requirement some more

    7.3.  Reporting quantities accumulated over multiple powered entities

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

And I wonder if we're not trying to make EMAN too complex by adding this 
aggregation function.
Note: I've been involved in aggregation scheme (See RFC 5982, RFC 6183, 
and http://tools.ietf.org/html/draft-trammell-ipfix-a9n-03) and this is 
not straight forward to list all powered entities for which there is an 
aggregation.
My point is that there is some debate whether or not a switch should 
aggregate all values for children, or if this is a NMS issue.
Feedback?

See inline
> Network Working Group                                    J. Quittek, Ed.
> Internet-Draft                                                 R. Winter
> Intended status: Informational                                  T. Dietz
> Expires: January 12, 2012                                NEC Europe Ltd.
>                                                                B. Claise
>                                                          M. Chandramouli
>                                                      Cisco Systems, Inc.
>                                                            July 11, 2011
>
>
>                    Requirements for Energy Management
>                     draft-ietf-eman-requirements-04
>
> Abstract
>
>    This document defines requirements for standards specifications for
>    energy management.  Defined requirements concern monitoring functions
>    as well as control functions.  Covered functions include
>    identification of powered entities, monitoring of their power state,
>    power inlets, power outlets, actual power, consumed energy, and
>    contained batteries.  Further included is control of powered
>    entities' power supply and power state.  This document does not
>    specify the features that must be implemented by compliant
>    implementations but rather features that must be supported by
>    standards for energy management.
This misses the power quality, or whatever name we want to call it.
For example "power characteristics)"
>
> Status of this Memo
>
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    This Internet-Draft will expire on January 12, 2012.
>
> Copyright Notice
>
>    Copyright (c) 2011 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>
>
>
> Quittek, et al.         Expires January 12, 2012                [Page 1]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
>
>
> Table of Contents
>
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
>      1.1.   Conventional requirements for energy management . . . . .  4
>      1.2.   Specific requirements for energy management . . . . . . .  5
>
>    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
>
>    3.  General Objectives of Energy Management  . . . . . . . . . . .  8
>      3.1.   Power states  . . . . . . . . . . . . . . . . . . . . . .  8
>      3.2.   Trade-offs  . . . . . . . . . . . . . . . . . . . . . . .  8
>      3.3.   Local and network-wide energy management  . . . . . . . .  8
>      3.4.   Energy monitoring . . . . . . . . . . . . . . . . . . . .  9
>      3.5.   Overview of energy management requirements  . . . . . . . 10
>
>    4.  Identification of Powered Entities . . . . . . . . . . . . . . 10
>
>    5.  Information on Powered Entities  . . . . . . . . . . . . . . . 11
>      5.1.   General information on powered entities . . . . . . . . . 11
>      5.2.   Power state . . . . . . . . . . . . . . . . . . . . . . . 12
>      5.3.   Power inlet and power outlet  . . . . . . . . . . . . . . 14
>      5.4.   Power . . . . . . . . . . . . . . . . . . . . . . . . . . 16
>      5.5.   Energy  . . . . . . . . . . . . . . . . . . . . . . . . . 18
>      5.6.   Battery State . . . . . . . . . . . . . . . . . . . . . . 19
>
>    6.  Control of Powered Entities  . . . . . . . . . . . . . . . . . 21
>
>    7.  Reporting on Other Powered Entities  . . . . . . . . . . . . . 22
>
>    8.  Controlling Other Powered Entities . . . . . . . . . . . . . . 23
>      8.1.   Controlling power states of other powered entities  . . . 23
>      8.2.   Controlling power supply of other powered entities  . . . 24
>
>    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
>
>    10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
>
>
>
>
> Quittek, et al.         Expires January 12, 2012                [Page 2]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
>
>    12. Open issues  . . . . . . . . . . . . . . . . . . . . . . . . . 26
>      12.1.  Revise security considerations  . . . . . . . . . . . . . 26
>      12.2.  High/Low power notifications  . . . . . . . . . . . . . . 26
>      12.3.  Power and energy time series? . . . . . . . . . . . . . . 26
>      12.4.  Inlet/outlet combinations . . . . . . . . . . . . . . . . 26
>      12.5.  Aggregation functions . . . . . . . . . . . . . . . . . . 27
>      12.6.  Add a definition of 'demand'  . . . . . . . . . . . . . . 27
>      12.7.  IEC references  . . . . . . . . . . . . . . . . . . . . . 27
>      12.8.  Standard references for BACNET or MODBUS  . . . . . . . . 27
>      12.9.  IEEE 1621 and 802.3az references  . . . . . . . . . . . . 27
>      12.10. DC power quality covered by IEC standard? . . . . . . . . 27
>      12.11. Introduce 'disconnected from power' as power state  . . . 27
>      12.12. Need for basic state 'reduced power'? . . . . . . . . . . 27
>      12.13. Local and network-wide energy management  . . . . . . . . 28
>      12.14. Do we need entity types?  . . . . . . . . . . . . . . . . 28
>      12.15. Power availability mode 'minimum' or 'ready'? . . . . . . 28
>      12.16. Is there a need for metering power supply inpedance?  . . 28
>      12.17. Confidence in power values  . . . . . . . . . . . . . . . 28
>      12.18. Terminology for reporting on other entitites  . . . . . . 28
>
>    13. Informative References . . . . . . . . . . . . . . . . . . . . 29
>
>    Appendix A.  Existing Standards  . . . . . . . . . . . . . . . . . 30
>      A.1.   Existing IETF Standards . . . . . . . . . . . . . . . . . 30
>        A.1.1.  ENTITY MIB . . . . . . . . . . . . . . . . . . . . . . 30
>        A.1.2.  ENTITY STATE MIB . . . . . . . . . . . . . . . . . . . 31
>        A.1.3.  ENTITY SENSOR MIB  . . . . . . . . . . . . . . . . . . 31
>        A.1.4.  UPS MIB  . . . . . . . . . . . . . . . . . . . . . . . 32
>        A.1.5.  POWER ETHERNET MIB . . . . . . . . . . . . . . . . . . 32
>        A.1.6.  LLDP MED MIB . . . . . . . . . . . . . . . . . . . . . 33
>      A.2.   Existing standards of other bodies  . . . . . . . . . . . 33
>        A.2.1.  DMTF . . . . . . . . . . . . . . . . . . . . . . . . . 33
>        A.2.2.  OVDA . . . . . . . . . . . . . . . . . . . . . . . . . 33
>        A.2.3.  IEEE-ISTO Printer WG . . . . . . . . . . . . . . . . . 33
>
>    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
>
>
>
>
>
>
>
>
>
>
>
>
>
> Quittek, et al.         Expires January 12, 2012                [Page 3]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
> 1.  Introduction
>
>    With rising energy cost and with an increasing awareness of the
>    ecological impact of running IT and networking equipment, energy
>    management is becoming an additional basic requirement for network
>    management systems and frameworks.
>
>    This document defines requirements for standards specifications for
>    energy management.  Defined requirements concern monitoring functions
>    as well as control functions.  Covered functions include
>    identification of powered entities, monitoring of their power state,
>    power inlets, power outlets, actual power, consumed energy, and
>    contained batteries.  Further included is control of powered
>    entities' power supply and power state.  Note that this document does
>    not specify the features that must be implemented by compliant
>    implementations but rather features that must be supported by
>    standards for energy management.
Same remark about power quality
>
>    The main subject of energy management are powered entities that
>    consume electric energy.  Powered entities include devices that have
>    an IP address and can be addressed directly, such as hosts, routers,
>    and middleboxes, as well as devices indirectly connected to an IP
>    network, for which a proxy with an IP address provides a management
>    interface, for example, devices in a building management
>    infrastructure using BACNET or MODBUS protocols.
>
>    The requirements specified in this document explicitly concern the
>    standards specification process and not the implementation of
>    specified standards.  All requirements in this document must be
>    reflected by standards specifications to be developed.  But which of
>    the features specified by these standards will be mandatory,
>    recommended, or optional for compliant implementations is to be
>    defined by the concrete standards track document(s) and not in this
>    document.
>
>    This document first discusses general objectives of energy management
>    in Section 3.  Requirements for an energy management standard are
>    specified in Sections 4 to 8.
>
> 1.1.  Conventional requirements for energy management
I don't know what "conventional" is supposed to mean.
>
>    The specification of requirements for an energy management standard
>    starts with Section 4 addressing the identification of powered
>    entities and the granularity of reporting of energy-related
>    information. 
I don't understand why we have that sentence here and not in the 
identifier in section 4.
> A standard must support unique identification of
>    powered entities.  Furthermore, it must support more than just
>    reporting per powered device.  Support is required for also reporting
>    energy-related information on individual components of a device or
>
>
>
> Quittek, et al.         Expires January 12, 2012                [Page 4]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    subtended devices.  This is why this draft uses the more general term
>    "powered entity" rather than "powered device".  A powered entity may
>    be a device or a component of a device.
>
>    Section 5 specifies requirements related to monitoring of powered
>    entities.  This includes general (type, context) information and
>    specific information on power states, power inlets, power outlets,
>    power, energy, and batteries.  Control power state and power supply
>    of powered entities is covered by requirements specified in
>    Section 6.
>
> 1.2.  Specific requirements for energy management
>
>    At first glance the rather conventional requirements summarized above
>    seem to be all that would be needed for energy management.  But it
>    turns out that there are some significant differences between energy
>    management and most of the well known conventional network management
>    functions.  The most significant difference from many other
>    management functions is the need for some devices to report on other
>    entities.  There are three major reasons for this.
>    o  For monitoring and controlling a particular powered entity in
>       general it is not sufficient to communicate with the powered
"sufficient" is not the right wording.
In some cases, this is just impossible to communicate with the powered 
entity.
Example: proxy.

>       entity only, but in many cases also communication with other
>       powered entities along the power distribution path may be
>       necessary, for example, with power switches and power meters.
>       Indeed, there are situations where a power or energy meter is not
>       located in the powered entity, but in a different physical
>       location.  For example, a Power Distribution Unit (PDU), which
>       supplies power for a server connected to a PDU socket, would meter
>       the power supplied, while the server may not have the capability
>       to measure its power consumption. 
new text: In specific cases, the monitoring and controlling of powered 
entities must be done by another entity along the power distribution 
domain. For example.
And you remove "a second example" below
> A second example is a Power
>       over Ethernet port, which provides power to the attached device,
>       and which can meter how much power/energy it delivers to the
>       attached device.
>    o  Energy management often extends its scope beyond powered entities
>       with IP network interfaces, for example toward non-IP building
>       networks, that are accessed via an IP gateway.  Requirements in
>       this document do not fully cover all these networks, but they
>       cover means for opening IP network management towards them.
>    o  For monitoring of particular powered entities, it is sometimes not
>       a scalable approach to communicate directly with all the powered
>       entities directly from a central energy management system as the
>       number of powered entities keeps increasing.
>
>    This specific issue of energy management and a set of further ones
>    are covered by requirements specified in Sections 7 and 8.
>
>
>
>
>
> Quittek, et al.         Expires January 12, 2012                [Page 5]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
> 2.  Terminology
>
> 2.1.  Energy
>
>    the definition of the term energy is to be agreed on in the EMAN WG.
>
>    The term 'energy consumption' is commonly used for both, for
>    referring to the amount of consumed energy and also for referring to
>    the rate of consuming energy.  In the first case it addresses
>    consumed energy measured by joule, watthour, or another energy unit,
>    in the second one it addresses power, typically an average power
>    measured by watt.
>
>    However, in this document the term "consumed energy" always refers to
>    an energy quantity (measured in joule, watthour, etc.) and not to a
>    power quantity (measured in watt, etc.).
>
> 2.2.  Power
>
>    the definition of the term power is to be agreed on in the EMAN WG.
>
> 2.3.  Powered entity
>
>    A powered entity is a consumer of energy that is subject to energy
>    management.  In general, all managed physical entities in a
>    communication network consume electric energy and thus are subject to
>    energy management including particularly energy monitoring and energy
>    control.
>
>    A powered entity can be a managed device or a component of a managed
>    device, which is monitored or controlled individually.
>
> 2.4.  Power state
>
>    Power state of a powered entitiy is defined as a specific settings of
>    a powered entitiy that influences its power.  Examples of power
>    states of a powered entitiy are on, off, and sleep.
>
> 2.5.  Power monitor
>
>    Energy management requires retrieving energy-related information on
>    powered entities.  In many cases this information is not available at
>    the powered entities themselves, but at other powered entities.  For
>    example measurement of power and energy consumption can be conducted
>    by power meters at other locations along the power distribution tree
>    for the powered entity.
>
>    A power monitor is a module that reports energy-related information
>
>
>
> Quittek, et al.         Expires January 12, 2012                [Page 6]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    on powered entities.  A power monitor may be integrated into a
>    powered entity or located remotely of the powered entity.  Instances
>    of power monitors may report information on, for example, power
>    supply, power, and power state of a powered entity.  There may be
>    multiple power monitors reporting information on the same powered
>    entity.
>
> 2.6.  Power inlet
>
>    Powered entities receive power at their power inlets.  Powered
>    entities may have multiple inlets, for example, servers with
>    redundant power supply.  Examples for power inlets are AC power cords
>    of a powered entity or an Ethernet port at which the powered entity
>    receives DC Power over Ethernet (PoE).
>
> 2.7.  Power outlet
>
>    Powered entities may have means to supply others with electrical
>    power.  Power is delivered to other powered entities through power
>    outlets.  Power sourcing entities often have more than one power
>    outlet.  Examples for power outlets are AC power sockets at a Power
>    Distribution Unit (PDU) and Ethernet ports at a Power over Ethernet
>    (PoE) Power Sourcing Equipment (PSE), that can supply powered
>    entities with DC power using the Ethernet cable.
>
> 2.8.  Energy management
>
>    the definition of the term power is to be agreed on in the EMAN WG.
>
> 2.9.  Energy management standard
This doesn't look like a definition. At least, the first paragraph 
should be removed.
>
>    This document specifies requirements for an energy management
>    standard.  This term refers to a collections of documents specifying
>    standards for energy-related monitoring and control.  The energy
>    management standard specifies means for building energy management
>    systems.
>
>    Requirements specified in this document concern the means that an
>    energy management standard must provide.  It does not imply that all
>    required means must be implemented in all energy standard scenarios.
>    Which means and features must be implemented by compliant
>    implementations is to be specified by the energy management standard
>    itself, not by this requirements document.
>
>    Note that for meeting individual requirements specified in this
>    document, new standards are not necessarily required.  It is
>    recommended to rather use existing standards than specify new ones.

>
>
>
>
> Quittek, et al.         Expires January 12, 2012                [Page 7]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
> 3.  General Objectives of Energy Management
Rename to "general considerations related to energy management"
>
>    The basic objective of energy management is operating communication
>    networks and other equipment with minimal amount of energy, while
>    maintaining a certain level of service.  A set of use cases for
>    energy management can be found in
>    [I-D.tychon-eman-applicability-statement].
It would read better if the content of section about trade-offs was next 
in this introduction (without having a specific section)
Then
     3.1. Power States
     3.2 Energy Monitoring versus Energy Savings
     3.3 Local versus network-wide energy management
     3.4. Overview of the energy management requirements

>
> 3.1.  Power states
>
>    One approach to achieve this goal is by setting all powered entities
>    to an operational state that results in lower energy consumption, but
>    still meets the service level performance objectives.  The sufficient
>    performance level may vary over time and can depend on several
>    factors.  In principle, there are four basic types of power states
>    for a powered entity or for a whole system:
>    o  full power state
>    o  reduced power states (lower clock rate for processor, lower data
>       rate on a link, etc.)
>    o  sleep state (not functional, but immediately available)
>    o  off state (may imply requiring significant time for becoming
>       operational)
>    In actual implementations the number of power states and their
>    properties vary a lot.  Very simple powered entities may just have
>    only the extreme states, full power and off state.  Some
>    implementations might use IEEE1621 model of three states on, off, and
>    sleep.  However, more granular power states can be implemented with
>    many levels of off, sleep, and reduced power states.
>
> 3.2.  Trade-offs
>
>    While the general objective of energy management is quite clear, the
>    way to attain that goal is often difficult.  In many cases there is
>    no way of reducing power consumption without the consequence of a
>    potential performance, service, or capacity degradation.  Then a
>    trade-off needs to be dealt with between service level objectives and
>    energy efficiency.  In other cases a reduction of energy consumption
>    can easily be achieved while still maintaining sufficient service
>    level performance, for example, by switching powered entities to
>    lower power states when higher performance is not needed.
>
> 3.3.  Local and network-wide energy management
>
>    Many energy saving functions can be executed locally by a powered
>    entitiy.  The basic principle is that a powered entitiy monitors its
>    usage and dynamically adapts its energy consumption according to the
>    required performance.  It may switch to a sleep state when it is not
>    in use at all. 
Well, not only when it's not in use.
It could be based on the time of day, or any other energy saving policies.
> Potential interactions with an energy management
>
>
>
> Quittek, et al.         Expires January 12, 2012                [Page 8]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    system for such an entity include the observation of the entity's
>    power state and the configuration of power saving policies, for
>    example, by setting thresholds for power state changes.
>
>    Energy savings can also be achieved with policies implemented by a
>    network management system that controls power states of managed
>    entities.  In order to make policy decisions properly, information
>    about the energy consumption of powered entities in different power
>    states is required.  Often this information is acquired best through
>    monitoring.
>
>    Both methods, network-wide and local energy management, have
>    advantages and disadvantages.  Most buildings use both of them.  In
>    some cases for example, significant energy savings can be achieved by
>    simply setting all powered entities in a network to sleep, when the
>    network is not needed.  However, in general it is dangerous to set
>    all powered entities of a group to the same state, because there is a
>    risk that such actions ignore specifics of individual powered
>    entities or violate local service level agreements.
Can you please expand the previous sentence.
I'm not sure that I agree.
>
> 3.4.  Energy monitoring
rename to "energy monitoring versus energy savings"
>
>    It should be noted that only monitoring energy consumption and power
>    states is obviously not a means to reduce the energy consumption of a
>    powered entitiy.  In fact, it is likely to increase the power
>    consumption of a powered entitiy slightly because monitoring energy
>    may require instrumentation that consumes energy when in use.  And
>    also reporting of measured quantities over the network consumes
>    energy.  However, the acquired energy consumption and power state
>    information is essential for defining energy saving policies and can
>    be used as input to power state control loops that in total can lead
>    to energy savings.
>
>    Monitoring operational power states and energy consumption can also
>    be required for other energy management purposes including but not
>    limited to:
>    o  investigating power saving potential
>    o  evaluating the effectiveness of energy saving policies and
>       measures
>    o  deriving, implementing, and testing power management strategies
>    o  accounting for the total power consumption of a powered entity, a
>       network, or a service
>    o  predicting a powered entitiy's reliability based on power usage
>    o  choosing time of next maintenance cycle for a powered entitiy
>
>
>
>
>
>
>
> Quittek, et al.         Expires January 12, 2012                [Page 9]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
> 3.5.  Overview of energy management requirements
>
>    From the considerations described above the following basic
>    management functions appear to be required for energy management:
>    o  monitoring power states
>    o  monitoring power (energy consumption rate)
>    o  monitoring (accumulated) energy consumption
>    o  setting power states
>    o  setting and enforcing power saving policies
And again the comment about the power quality
>
>    It should be noted that active power control is complementary (but
what does the "active" power control mean?
>    essential) to other energy savings measures such as low power
>    electronics, energy saving protocols (for example, IEEE 802.3az),
>    energy-efficient device design (for example, sleep and low-power
>    modes for individual components of a device), and energy-efficient
>    network architectures.  Measurement of energy consumption may also
>    provide useful input for developing these technologies.
>
>
> 4.  Identification of Powered Entities
>
>    As already stated Section 1.1, powered entities on which energy-
>    related information is provided
add a comma
> are identified in a sufficiently
>    unique way.  This holds in particular for powered entities that are
>    components of managed devices and in case that one powered entity
>    reports information on another one, see Section 7.  For powered
>    entities that control other powered entities it is important to
>    identify the powered entities they control, see Section 8.
>
>    Also stated already in Section 1.1 is the requirement of providing
>    means for reporting energy-related information on components of a
>    managed device.  An entity in this document may be an entire managed
>    device or just a component of it.  Examples of components of interest
>    are a hard drive, a battery, or a line card.  For controlling
>    entities it may be required to be able to address individual
>    components in order to save energy.  For example, server blades can
>    be switched off when the overall load is low or line cards at
>    switches may be powered down at night times.
>
>    Instrumentation for measuring energy consumption of a device is
>    typically more expensive than instrumentation for retrieving the
>    devices power state.  It may be a reasonable compromise in many cases
>    to provide power state information for all individually switchable
>    components of a device separately, while the energy consumption is
>    only measured for the entire device.
>
>    Detailed Requirements:
>
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 10]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
> 4.1.  Identifying powered entities
>
>    The energy management standard must provide means for uniquely and
>    persistently identifying powered entities that are monitored or
>    controlled by an energy management system.  Uniqueness must be given
>    in a domain that is large enough to avoid collisions of identities at
>    potential receivers of monitored information.
We want to remove "and persistently" from the sentence, as this is 
covered in 4.3

We should have a requirement about a UUID for powered entities.
Let's cover that during the WG.
>
> 4.2.  Identifying components of powered devices
>
>    The energy management standard must provide means for identifying not
>    just entire devices as powered entities, but also individual
>    components of powered devices.
>
> 4.3.  Persistency of Identifiers
>
>    The energy management standard must provide means for indicating
>    whether identifiers of powered entities are persistent across a re-
>    start of the powered entitiy that provides the identifiers.
>
>
> 5.  Information on Powered Entities
>
>    This section describes energy-related information on powered entities
>    for which an energy management standard must provide means for
>    retrieving and reporting.
>
>    Note that the fact that an energy management standard provides
>    required means does not imply that all of them must be implemented by
>    every compliant implementation.  The concrete specification of
>    standards based on these requirements may label individual features
>    as mandatory, recommended, or optional.
Remove this paragraph above, as this is already covered before, and this 
is not specific to this section 5.
>
>    Required information on powered entities can be structured into six
>    groups.  Section 5.1 specifies requirements for general information
>    on powered entities, such as type of powered entity or context
>    information.  Section 5.2 covers requirements related to entities'
>    power states.  Requirements for information on power inlets and power
>    outlets of powered entities are specified in Section 5.3.  Monitoring
>    of power and energy is covered by Sections 5.4 and 5.5, respectively.
>    Finally, Section 5.6 specified requirements for monitoring batteries.
>
> 5.1.  General information on powered entities
>
>    For energy management it may be required to understand the role and
>    context of a powered entitiy.  When monitoring, it may be helpful to
>    group energy consumption per kind of entity.  When controlling and
>    setting power states it may be helpful to understand the kind and
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 11]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    role of a powered entitiy in a network, for example, in order to
>    avoid switching off vital network components.
>
>    Detailed Requirements:
>
> 5.1.1.  Type of powered entity
>
>    The energy management standard must provide means to retrieve and
>    report the type of powered entities according to a standrdized
>    classification scheme.
see the email thread on the mailing list.
>
> 5.1.2.  Context information on powered entities
>
>    The energy management standard must provide means for retrieving and
>    reporting context information on powered entities, for example tags
>    associated with a powered entity that indicate the powered entitiy's
>    role, or importance.
>
> 5.1.3.  Grouping of powered entities
>
>    The energy management standard must provide means for grouping
>    powered entities, for example, into energy monitoring domains, energy
>    control domains, power supply domains, groups of powered entities of
>    the same type, etc.
>
> 5.2.  Power state
>
>    Many powered entities have a limited number of discrete power states,
>    such as, for example, full power, low power, sleep, and off.
>
>    Obviously, there is a need to report the actual power state of a
>    powered entitiy.  Beyond that, there is also a requirement for
>    standardizing means for retrieving the list of all supported power
>    states of a powered entitiy.
>
>    Different standards bodies have already defined their own sets of
>    power states for powered entities.  Further organizations are in the
>    process of adding more of these sets.  In order to support multiple
>    management systems possibly using different power state sets, while
>    simultaneously interfacing with a particular powered entity, the
>    energy management standard must provide means for supporting multiple
>    power state sets used simultaneously at a powered entity.
>
>    Power states have parameters that describe its properties It is
>    required to have standardized means for reporting some key
>    properties, such as mean power and maximum power of a powered entitiy
>    in a certain state.
>
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 12]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    There also is a need to report statistics on power states including
>    the time spent an the energy consumed in a power state.
>
>    For some network management tasks, it may be desirable to receive
>    notifications from powered entities, for example, when the components
>    or the entire entity change their power state.
>
>    Detailed Requirements:
>
> 5.2.1.  Actual power state
>
>    The energy management standard must provide means for reporting the
>    actual power state of a powered entitiy.
>
> 5.2.2.  List of supported power states
>
>    The energy management standard must provide means for retrieving the
>    list of all potential power states of a powered entitiy.
>
> 5.2.3.  Multiple power state sets
>
>    The energy management standard must provide means for supporting
>    multiple power state sets simultaneously at a powered entity.
>
> 5.2.4.  List of supported power state sets
>
>    The energy management standard must provide means for retrieving the
>    list of all power state sets supported by a powered entitiy.
>
> 5.2.5.  List of supported power states
5.2.2 has got the same title.
Proposal for 5.2.5 "List of supported power states within power state set"
>
>    Referring to the "list of supported power state sets" requirement,
>    the energy management standard must provide means for retrieving the
>    list of all potential power states of a powered entitiy that belong
>    to a given power state set.
new text.
     For the rest of the document, when the Power State term is used, it 
implicitly refers to a power state within a power state set.

Note that this comment might be part of the power State definition
>
> 5.2.6.  Maximum and average power per power state
>
>    The energy management standard must provide means for retrieving the
>    maximum power and the average power as a typically static property
>    for each supported power state.
>
> 5.2.7.  Power state statistics
>
>    The energy management standard must provide means for monitoring
>    statistics per power state including at least the total time spent in
>    a power state, the number of times a state was entered and the last
>    time a state was entered.  More power state statistics are addressed
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 13]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    by requirement 5.5.3.
>
> 5.2.8.  Power state changes
>
>    The energy management standard must provide means for generating a
>    notification when the actual power state of a powered entity changes.
>
> 5.3.  Power inlet and power outlet
>
>    Powered entities have power inlets at which they are supplied with
>    electric power.  Most powered entities just have a single power
>    inlet, while some have multiple ones.  Often different power inlets
>    are connected to separate power distribution trees.  For energy
>    monitoring, it is important information which power inlets a powered
>    entitiy has, 
what do you mean? the type, the number, or something else?
> if power is available at an inlet and which of them are
>    actually in use.
>
>    Some powered entities have power outlets for supplying other powered
>    entities with electric power.  A powered entitiy may have multiple
>    power outlets.  Examples are Power Distribution Units (PDUs) and
>    Power over Ethernet (PoE) Power Sourcing Equipment (PSE).
Remove the previous sentence, as this is already in the terminology section.
>
>    For identifying and potentially controlling the source of power
>    received at an inlet, it may be required to identify the power outlet
>    of another powered entity at which the received power is provided.
>    Analogously, for each outlet it is of interest to identify the power
>    inlets that receive the power provided at a certain outlet.
>
>    Static properties of each power inlet and each power outlet are
>    required information for energy management.  Static properties
>    include the kind of electric current (Alternating Current (AC) or
>    Direct Current (DC)), the nominal voltage, the nominal AC frequency,
>    and the number of AC phases.
So "static properties" is what we called "power quality"?
>
>    Detailed Requirements:
>
> 5.3.1.  List of power inlets and power outlets
>
>    The energy management standard must provide means for monitoring the
>    list of power inlets and power outlets at a powered entitiy.
>
> 5.3.2.  Corresponding power outlet
>
>    The energy management standard must provide means for identifying the
>    power outlet that provides the power received at a power inlet.
>
>
>
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 14]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
> 5.3.3.  Corresponding power inlets
>
>    The energy management standard must provide means for identifying the
>    list of power inlets that receive the power provided at a power
>    outlet.
>
> 5.3.4.  Availability of power
>
>    The energy management standard must provide means for monitoring the
>    availability of power at each power inlet and each power outlet.
>    This information indicates whether at a power providing outlet power
>    supply is switched on or off.
>
> 5.3.5.  Use of power
>
>    The energy management standard must provide means for monitoring for
>    each power inlet and each power outlet if it is in actual use.  For
>    the inlet this means that the powered entitiy actually receives power
>    at the inlet.  For the outlet this means that actually power is
>    provided to one or more powered entities at the outlet.
>
> 5.3.6.  Type of current
>
>    The energy management standard must provide means for reporting the
>    type of current (Alternating Current (AC) or Direct Current (DC)) for
>    each power inlet and each power outlet of a powered entity.
>
> 5.3.7.  Nominal voltage
>
>    The energy management standard must provide means for reporting the
>    nominal voltage for each power inlet and each power outlet of a
>    powered entity.
>
> 5.3.8.  Nominal AC frequency
>
>    The energy management standard must provide means for reporting the
>    nominal AC frequency for each power inlet and each power outlet of a
>    powered entity.
>
> 5.3.9.  number of AC phases
number -> Number
>
>    The energy management standard must provide means for reporting the
>    number of AC phases for each power inlet and each power outlet of a
>    powered entity.
>
>
>
>
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 15]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
> 5.4.  Power
>
>    Power is a quantity measured as instantaneous power or as average
>    power over a time interval.  In contrast to power state values, this
>    quantity may change continuously.
>
>    Obtaining highly accurate values for power and energy may be costly.
>    Often dedicated metering hardware is needed for this purpose.
>    Powered entities without the ability to measure their power and
>    energy consumption with high accuracy may just report estimated
>    values, for example based on load monitoring or even just the entity
>    type.
>
>    Depending on how power and energy consumption values are obtained the
>    confidence in the reported value and its accuracy may vary.  Powered
>    entities reporting such values should qualify the confidence in the
>    reported values and quantify the accuracy of measurements.  For
>    reporting accuracy, the accuracy classes specified in IEC 62053-21
>    [IEC.62053-21] and IEC 62053-22 [IEC.62053-22] should be considered.
>
>    In addition to the plain real power value, also further properties of
>    the supplied power are subject to monitoring.  In case of AC power
>    supply, there are more power values beyond the real power to be
>    reported including the apparent power, the reactive power, and the
>    phase angle of the current or the power factor.  For both AC and DC
>    power the power quality is also subject of monitoring.
So "power quality" is mentioned.
> Power quality
>    parameters include the actual voltage, the actual frequency, the
>    Total Harmonic Distortion (THD) of voltage and current, the impedance
>    of an AC phase or of the DC supply.  Power quality monitoring should
>    be in line with existing standards, such as [IEC.61850-7-4].
>
>    For some network management tasks, it is required to obtain time
>    series of power values (or energy consumption values).  In general
>    these could be obtained in many different ways.  It should be avoided
>    that such time series can only be obtained by regular polling by the
>    energy management system.  Means should be provided to either push
>    such values from the place they are available to the management
>    system or to have them stored at the powered entitiy for a
>    sufficiently long period of time such that a management system can
>    retrieve a stored time series of values.
>
>    Detailed Requirements:
>
> 5.4.1.  Real power
>
>    The energy management standard must provide means for reporting the
>    real power for each power inlet and each power outlet of a powered
>    entity.
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 16]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
> 5.4.2.  Power measurement interval
>
>    The energy management standard must provide means for reporting the
>    corresponding time or time interval for which a power value is
>    reported.  The power value can be measured at the corresponding time
>    or averaged over the corresponding time interval.
>
> 5.4.3.  Confidence in power values
>
>    The energy management standard must provide means for reporting the
>    confidence in reported power values by indicating the way these
>    values have been obtained. for example, by power measurement, by
>    estimation based on performance values, or hard coding average power
>    values for a powered entity.
>
> 5.4.4.  Accuracy of power and energy values
>
>    The energy management standard must provide means for reporting the
>    accuracy of reported power values.
>
> 5.4.5.  Complex power
>
>    The energy management standard must provide means for reporting the
>    complex power for each power inlet and each power outlet of a powered
>    entity.  Besides the real power, at least two out of the following
>    three quantities need to be reported: apparent power, reactive power,
>    phase angle.  The phase angle can be substituted by the power factor.
>    In case of AC power supply, means must be provided for reporting the
>    complex power per phase.
>
> 5.4.6.  Actual voltage and current
>
>    The energy management standard must provide means for reporting the
>    actual voltage and actual current for each power inlet and each power
>    outlet of a powered entity.  In case of AC power supply, means must
>    be provided for reporting the actual voltage and actual current per
>    phase.
>
> 5.4.7.  Actual AC frequency
>
>    The energy management standard must provide means for reporting the
>    actual AC frequency for each power inlet and each power outlet of a
>    powered entity.
>
> 5.4.8.  Total harmonic distortion
>
>    The energy management standard must provide means for reporting the
>    Total Harmonic Distortion (THD) of voltage and current for each power
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 17]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    inlet and each power outlet of a powered entity.  In case of AC power
>    supply, means must be provided for reporting the THD per phase.
>
> 5.4.9.  Power supply impedance
>
>    The energy management standard must provide means for reporting the
>    impedance of power supply for each power inlet and each power outlet
>    of a powered entity.  In case of AC power supply, means must be
>    provided for reporting the impedance per phase.
>
> 5.4.10.  Time series of power values
>
>    The energy management standard must provide means for collecting time
>    series of real power values for each power inlet and for each power
>    outlet of a powered entitiy without requiring to regularly poll the
>    powered entitiy from an energy management station.  A solution for
>    this is that the concerned powered entity or another powered entity
>    closely interacting with the concerned powered entity collect time
>    series of power values and make them available via push or pull
>    mechanisms to receivers of the information.
>
> 5.5.  Energy
>
>    Monitoring of electrical energy consumed (or converted) at a powered
>    entitiy can be done in various ways.  One is collecting time series
>    of power values for the powered entitiy and calculating the consumed
>    energy from these values.  An alternative is the powered entity
>    itself or another powered entity taking care of energy measurement
>    and reporting energy consumption values for certain time intervals.
>    Time intervals of interest are the time from the last restart of the
>    powered entitiy to the reporting time, the time from another past
>    event to the reporting time, or the last given amount of time before
>    the reporting time.
>
>    In order to monitor energy consumption in different power states, it
>    is useful if powered entities record their energy consumption per
>    power state and report these quantities.
>
>    For some network management tasks, it is required to obtain time
>    series of energy values.  In general these could be obtained in many
>    different ways.  It should be avoided that such time series can only
>    be obtained by regular polling by the energy management system.
>    Means should be provided to either push such values from the place
>    they are available to the management system or to have them stored at
>    the powered entitiy for a sufficiently long period of time such that
>    a management system can retrieve a stored time series of values.
>
>    Detailed Requirements:
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 18]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
> 5.5.1.  Energy
>
>    The energy management standard must provide means for reporting the
>    consumed energy received at a power input or provided at a power
>    outlet of a powered entitiy.  Reports must be made for a clearly
>    specified time interval.
>
> 5.5.2.  Time intervals
>
>    The energy management standard must provide means for reporting the
>    consumed energy of a powered entitiy for certain time intervals.
>    o  Reports must be supported for the time interval starting at the
>       last restart of the powered entitiy and ending at a certain point
>       in time, such as the time when a report was delivered.
>    o  Reports must be supported for a sequence of consecutive non-
>       overlapping time intervals of fixed size (periodic reports).
>    o  Reports must be supported for a sequence of consecutive
>       overlapping time intervals of fixed size (periodic reports).
>    o  Reports must be supported for an interval of given length ending
>       at a certain point in time, such as the time when a report was
>       delivered (sliding window)
>
> 5.5.3.  Energy per power state
>
>    The energy management standard must provide means for reporting the
>    consumed energy individually for each power state.  This extends the
>    requirement 5.2.7 on power state statistics.
>
> 5.5.4.  Time series of energy values
>
>    The energy management standard must provide means for collecting time
>    series of energy values for each power inlet and for each power
>    outlet of a powered entitiy without requiring to regularly poll the
>    powered entitiy from an energy management station.  A solution for
>    this is that the concerned powered entity or another powered entity
>    closely interacting with the concerned powered entity collect time
>    series of energy values and make them available via push or pull
>    mechanisms to receivers of the information.
>
> 5.6.  Battery State
>
>    Today more and more powered entities contain batteries that supply
>    them with power when disconnected from electrical power distribution
>    grids.  Common examples are nomadic and mobile devices, such as
>    notebook computers, netbooks, and smart phones.  The status of
>    batteries in such an powered entity, particularly the charging status
>    is typically controlled by automatic functions that act locally on
>    the powered entitiy and manually by users of the powered entity.  In
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 19]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    addition to this, there is a need to monitor the battery status of
>    these entities by network management systems.
>
>    The management requirements discussed above in Sections 5.1 to 5.5
>    concern energy-related information on powered entities.  Powered
>    entities may be powered devices or components of powered devices.
I  believe that we mentioned that sentence already.
>    Devices containing batteries can be modeled in two ways.  The entire
>    device can be modeled as a single powered entity on which energy-
>    related information is reported or the battery can be modeled as an
>    individual powered entity for which energy-related information is
>    monitored individually according to requirements in Sections 5.1 to
>    5.5.
>
>    In both cases further information on batteries is of interest for
>    energy management, such as the current charge of the battery, the
>    number of completed charging cycles, the charging state of the
>    battery, and further static and dynamic battery properties.  Also
>    desirable is to receive notifications if the charge of a battery
>    becomes very low or if a battery needs to be replaced.
>
>    Detailed Requirements:
>
> 5.6.1.  Battery charge
>
>    The energy management standard must provide means for reporting the
>    current charge of a battery.
>
> 5.6.2.  Battery charging state
>
>    The energy management standard must provide means for reporting the
>    charging state (charged, discharged, etc.) of a battery.
>
> 5.6.3.  Battery charging cycles
>
>    The energy management standard must provide means for reporting the
>    number of completed charging cycles of a battery.
>
> 5.6.4.  Actual battery capacity
>
>    The energy management standard must provide means for reporting the
>    actual capacity of a battery.
>
> 5.6.5.  Static battery properties
>
>    The energy management standard must provide means for reporting
>    static properties of a battery, including the nominal capacity, the
>    number of cells, the nominal voltage, and the battery technology.
>
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 20]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
> 5.6.6.  Low battery charge notification
>
>    The energy management standard must provide means for generating a
>    notification when a the charge of a battery decreases below a given
>    threshold.
remove "a"
>
> 5.6.7.  Battery replacement notification
>
>    The energy management standard must provide means for generating a
>    notification when the number of charging cycles of battery exceeds a
>    given threshold.
>
> 5.6.8.  Multiple batteries
>
>    The energy management standard must provide means for meeting
>    requirements 5.6.1 to 5.6.7 for each individual battery contained in
>    a single powered entity.
>
>
> 6.  Control of Powered Entities
>
>    Many powered entities control their power state locally by self-
>    managed dynamic adaptation to the environment.  But other powered
>    entities without that capability need interfaces for a energy
>    management system to control their power states in order to save
>    energy.  Even for self-managed powered entities such interface may be
>    required for overruling local policy decisions by global ones from an
>    energy management system.
>
>    Power supply is typically not self-managed by powered entities.  And
>    controlling power supply is typically not conducted as interaction
>    between energy management system and the powered entity itself.  It
>    is rather an interaction between the management system and an entity
>    providing power at its power outlets.  Still, requirements for power
>    state control apply accordingly to power supply control.
>
>    Note that shutting down the power supply abruptly may have severe
>    consequences for the powered entity.
>
>    Detailed Requirements:
>
> 6.1.  Controlling power states
>
>    The energy management standard must provide means for setting power
>    states of powered entities.
>
>
>
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 21]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
> 6.2.  Controlling power supply
>
>    The energy management standard must provide means for switching power
>    supply off or turning power supply on at power outlets providing
>    power to one or more powered entity.
>
>
> 7.  Reporting on Other Powered Entities
>
>    As already discussed in the introduction of Section 5, not all
>    energy-related information may be available at the concerned powered
>    entity.  Such information may be provided by other powered entities,
>    such as a Power Distribution Unit (PDU), external power meter, or a
>    Power over Ethernet (PoE) Power Sourcing Equipment (PSE).  Some of
>    these entities (PDU, PSE) can also control the power provided to the
>    other powered entities, while some can just report on the remote
>    powered entities (external power meter).  This section covers
>    reporting of information (monitoring) only.  See Section 8 for
>    requirements on controlling other powered entities.
>
>    There are cases where a power supply unit switches power for several
>    powered entities by turning power on or off at a single power outlet
>    or where a power meter measures the accumulated power of several
>    powered entities at a single power line.  Consequently, it should be
>    possible to report that a monitored value does not relate to just a
>    single powered entity, but is an accumulated value for a set of
>    powered entities.  All of these powered entities belonging to that
>    set need to be identified.
>
>    If a powered entity has information about where energy-related
>    information on itself can be retrieved, then it would be very useful
>    if it has a way to communicate this information to an energy
>    management system.  This applies even if the information only
>    provides accumulated quantities for several powered entities.
>
>    Detailed Requirements:
>
> 7.1.  Reports on other powered entities
>
>    The energy management standard must provide means for a powered
>    entitiy to report energy-related information on another powered
>    entity.
>
> 7.2.  Identity of other powered entities on which is reported
>
>    The energy management standard must provide means for reporting the
>    identity of another powered entity on which energy-related
>    information is reported.
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 22]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
> 7.3.  Reporting quantities accumulated over multiple powered entities
>
>    For powered entities reporting single values that are accumulated
>    over multiple powered entities, the energy management standard must
>    provide means for reporting the list of all powered entities from
>    which contributions are included in the accumulated value.
See my comments at the beginning of the email
>
> 7.4.  List of all powered entities on which is reported
>
>    The energy management standard must provide means for a powered
>    entitiy to report the list of all other powered entities on which it
>    can report energy-related information.
>
> 7.5.  Content of reports on other powered entities
>
>    The energy management standard must provide means for a powered
>    entitiy to indicate for each other powered entity on which it can
>    provide energy-related information which energy-related information
>    can be provided for this powered entity.
>
> 7.6.  Indicating source of remote information
>
>    The energy management standard must provide means for a powered
>    entity to indicate another powered entity at which energy-related
>    information on itself can be retrieved.
>
> 7.7.  Indicating source of remote information
>
>    For a powered entity that has another powered entity at which energy-
>    related information on itself can be retrieved, the energy management
>    standard must provide means for indicating the information that is
>    available at other powered entities per other powered entity.
>
>
> 8.  Controlling Other Powered Entities
>
>    This section specifies requirements for controlling power states and
>    power supply of powered entities by communicating not with these
>    powered entities themselves, but with other powered entities that
>    have means for controlling power state or power supply of others.
>
> 8.1.  Controlling power states of other powered entities
>
>    Some powered entities may have control of power states of other
>    powered entities.  For example a gateway to a building network may
>    have means to control the power state of powered entities in the
>    building that do not have an IP interface.  For this and similar
>    cases means are needed to make this control accessible to the energy
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 23]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    management system.
>
>    In addition to this, it is required that a powered entitiy that has
>    its state controlled by other powered entities has means to report
>    the list of these other powered entities.
>
>    Detailed Requirements:
>
> 8.1.1.  Control of power states of other powered entities
>
>    The energy management standard must provide means for an energy
>    management system to send power state control commands to a powered
>    entity that concern the power states of other powered entities than
>    the one the command was send to.
>
> 8.1.2.  Identity of other power state controlled entities
>
>    The energy management standard must provide means for reporting the
>    identity of another powered entity for which the reporting powered
>    entity has means to control the power state.
>
> 8.1.3.  List of all power state controlled entities
>
>    The energy management standard must provide means for a powered
>    entitiy to report the list of all powered entities for which it can
>    control the power state.
>
> 8.1.4.  List of all power state controllers
>
>    The energy management standard must provide means for a powered
>    entitiy that receives commands controlling its power state from other
>    powered entities to report the list of all those entities.
>
> 8.2.  Controlling power supply of other powered entities
>
>    Some powered entities may have control of the power supply of other
>    powered entities, for example, because the other powered entity is
>    supplied via a power outlet of the powered entitiy.  For this and
>    similar cases means are needed to make this control accessible to the
>    energy management system.
>
>    In addition to this, it is very required that a powered entitiy that
very required -> required
>    has its supply controlled by other powered entities has means to
>    report the list of these other powered entities.
>
>    Detailed Requirements:
>
>
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 24]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
> 8.2.1.  Control of power supply of other powered entities
>
>    The energy management standard must provide means for an energy
>    management system to send power supply control commands to a powered
>    entity that concern the power supply of other powered entities than
>    the one the command was send to.
>
> 8.2.2.  Identity of other power supply controlled powered entities
>
>    The energy management standard must provide means for reporting the
>    identity of another powered entity for which the reporting powered
>    entity has means to control the power supply.
>
> 8.2.3.  List of all power supply controlled powered entities
>
>    The energy management standard must provide means for a powered
>    entitiy to report the list of all other powered entities for which it
>    can control the power supply.
>
> 8.2.4.  List of all power supply controllers
>
>    The energy management standard must provide means for a powered
>    entitiy that has other powered entities controlling its power supply
>    to report the list of all those powered entities.
>
>
> 9.  Security Considerations
>
>    The typical security threats for the management protocol for energy
>    monitoring are similar to the ones specified in the SNMP security
>    framework.  In other words, from an energy monitoring point of view,
>    no additional security requirements have been imposed.
>
>    Link layer discovery mechanisms need to ensure that only the trusted
>    powered entities shall be discovered during discovery and detect/
>    discard powered entities without a trusted relationship to be
>    included among the powered entities for energy monitoring.
>
>    In terms of monitoring, considering that there can be some network
>    entities which shall be entitled to collect the measured data on
>    behalf of other powered entities, then it is important to
>    authenticate and/or authorize such powered entities.  In addition, in
>    the case of control of other powered entities, it would be highly
>    desirable to have some form of an authentication mechanism to ensure
>    that only the designated powered entities shall control the powered
>    entities within its control domain.  It should be possible to prevent
>    a powered entity which does not have the appropriate authorization
>    and authority to control or configure powered entities in its control
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 25]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    domain/purview.  Secondly, it should be possible to prevent malicious
>    powered entities from exercising control over entities.
>
>
> 10.  IANA Considerations
>
>    This document has no actions for IANA.
>
>
> 11.  Acknowledgements
>
>    The authors would like to thank Ralf Wolter for his first essay on
>    this draft.  Many thanks to William Mielke, John Parello, Bruce
>    Nordman, JinHyeock Choi, Georgios Karagiannis, and Michael Suchoff
>    for helpful comments on the draft.
>
I'll address the open issues in separate email threads.

Regards, Benoit.
>
> 12.  Open issues
>
> 12.1.  Revise security considerations
>
>    A discussion of the sensitivity of the content of the monitoring data
>    is missing.
>
> 12.2.  High/Low power notifications
>
>    For some network management tasks it may be desirable to receive
>    notifications from entities when the power of an powered entity
>    exceeds or falls below certain thresholds.  Do we want to make this a
>    requirement?
>
>    Proposal: added "for example" so that we don't restrict the framework
>    to only this notification
>
> 12.3.  Power and energy time series?
>
>    We have requirements for reporting of time series of power and energy
>    values.  Do we need both or just one of them?  If just one, then
>    which one?
>
> 12.4.  Inlet/outlet combinations
>
>    How to model the case that an inlet or outlet changes during
>    operation from one kind to the other.  An example is a battery that
>    receives power at a socket at one time.  Then the socket is an inlet.
>    At another time the battery provides power at the same socket.  Then
>    it's an outlet.  The same holds for entities with integrated power
>    generators.
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 26]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    One solution would be to introduce a new kind of hybrid in/outlets.
>    Another one would be to model the same socket as inlet as well as as
>    outlet.  It would appear twice in the list of all inlets and outlets.
>    Then received power/energy would be reported under the inlet entry
>    and provided power/energy would be reported under the outlet entry.
>
>    These would be two solutions.  What would be the concrete requirement
>    behind them?
>
> 12.5.  Aggregation functions
>
>    Aggregation functions are not covered (yet).  Are there requirements
>    on aggregation?  Which are they?
>
> 12.6.  Add a definition of 'demand'
>
> 12.7.  IEC references
>
>    References to mentioned IEC standards are missing.  Also these
>    references should be double checked.
>
> 12.8.  Standard references for BACNET or MODBUS
>
>    Section 1 mentions BACNET or MODBUS as examples for building network
>    protocols.  We need references to the standards specifications for
>    these protocols.
>
> 12.9.  IEEE 1621 and 802.3az references
>
>    A reference to the IEEE 1621 standard is missing in section 3.1 and a
>    reference to IEEE 802.3az is missing in section 3.4.  The references
>    should be double checked if they are well applicable in the
>    respective section.
>
> 12.10.  DC power quality covered by IEC standard?
>
>    Is there an IEC standard on DC power quality?
>
> 12.11.  Introduce 'disconnected from power' as power state
>
>    We need to introduce the concept of a device being "disconnected"
>    from power.  This is a subset of the Off state.  Shall we do it here
>    or rather in the framework draft?
>
> 12.12.  Need for basic state 'reduced power'?
>
>    Are "full power" and "reduced power" really different basic types of
>    power states?  Both may be forms of the on state.  Identifying "full"
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 27]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    separately is arbitrary.  (For something like a computer, "idle" is
>    the most common state so would be the one to call out separately
>    rather than "full".)
>
> 12.13.  Local and network-wide energy management
>
>    All but first sentence of the third paragraph in section 3.3 seem to
>    be true not needed here.  Proposal: remove them.
>
> 12.14.  Do we need entity types?
>
>    Or shall we remove Section 5.1.1?
>
> 12.15.  Power availability mode 'minimum' or 'ready'?
>
>    Do we need an additional mode for power availability called "minimum"
>    or "ready" for power availability in xref target="availability"/>?
>    This would reflect a PoE state at which the PSE is ready to serve the
>    PD.
>
> 12.16.  Is there a need for metering power supply inpedance?
>
>
>
> 12.17.  Confidence in power values
>
>    Shall we rename "confidence in power values" to "method for
>    determining power values"?
>
> 12.18.  Terminology for reporting on other entitites
>
>    In Section 7 we need some additional terms here to streamline the
>    text (and ultimately our thinking).  Nominations include:
>    o  "powered entity" (which may be "self-reporting")
>    o  "reporting entity" (can be "self" or "other")
>    o  "other entity" (a reporting entity reporting not on itself; likely
>       a different term would be better for this)
>    o  "controlled entity", "controlling entity" (section 8.1)
>    o  "switched entity", "switching entity" (section 8.2)
>
>    Also, there are two cases for an "other entity".  One is where the
>    powered entity cannot report the value in question itself (either
>    because it can't report anything, or doesn't know the value in
>    question, e.g. when metering is external).
>
>    The second is where the powered entity can report, but the other
>    entity is doing the reporting for some convenience.  We need to be
>    aware of both even if the framework does not need to make the
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 28]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    distinction.
>
>    There may be multiple other reporting entities, not just a single
>    one.
>
>    Do components of devices ever report, or do only devices do the
>    reporting?  This seems like an important point.
>
>
> 13.  Informative References
>
>    [RFC1628]  Case, J., "UPS Management Information Base", RFC 1628,
>               May 1994.
>
>    [RFC3433]  Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor
>               Management Information Base", RFC 3433, December 2002.
>
>    [RFC3621]  Berger, A. and D. Romascanu, "Power Ethernet MIB",
>               RFC 3621, December 2003.
>
>    [RFC3805]  Bergman, R., Lewis, H., and I. McDonald, "Printer MIB v2",
>               RFC 3805, June 2004.
>
>    [RFC4133]  Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)",
>               RFC 4133, August 2005.
>
>    [RFC4268]  Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268,
>               November 2005.
>
>    [I-D.tychon-eman-applicability-statement]
>               Tychon, E., Silver, L., and M. Chandramouli, "Energy
>               Management (EMAN) Applicability Statement",
>               draft-tychon-eman-applicability-statement-02 (work in
>               progress), June 2011.
>
>    [ACPI.R30b]
>               Hewlett-Packard Corporation, Intel Corporation, Microsoft
>               Corporation, Phoenix Corporation, and Toshiba Corporation,
>               "Advanced Configuration and Power Interface Specification,
>               Revision 3.0b", October 2006.
>
>    [DMTF.DSP1027]
>               Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.),
>               "Power State Management Profile", September 2008.
>
>    [IEEE-ISTO]
>               Printer Working Group, "PWG 5106.4 - PWG Power Management
>               Model for Imaging Systems 1.0:", February 2011.
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 29]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    [IEC.62053-21]
>               International Electrotechnical Commission, "Electricity
>               metering equipment (a.c.) - Particular requirements - Part
>               22: Static meters for active energy  (classes 1 and 2)",
>               2003.
>
>    [IEC.62053-22]
>               International Electrotechnical Commission, "Electricity
>               metering equipment (a.c.) - Particular requirements - Part
>               22: Static meters for active energy  (classes 0,2 S and
>               0,5 S)", 2003.
>
>    [IEC.61850-7-4]
>               International Electrotechnical Commission, "Communication
>               networks and systems for power utility automation - Part
>               7-4: Basic communication structure - Compatible logical
>               node classes and data object classes", 2010.
>
>
> Appendix A.  Existing Standards
>
>    This section analyzes existing standards for energy consumption and
>    power state monitoring.  It shows that there are already several
>    standards that cover only some part of the requirements listed above,
>    but even all together they do not cover all of the requirements for
>    energy management.
>
> A.1.  Existing IETF Standards
>
>    There are already RFCs available that address a subset of the
>    requirements.
>
> A.1.1.  ENTITY MIB
>
>    The ENTITY-MIB module defined in [RFC4133] was designed to model
>    physical and logical entities of a managed system.  A physical entity
>    is an identifiable physical component.  A logical entity can use one
>    or more physical entities.  From an energy monitoring perspective of
>    a managed system, the ENTITY-MIB modeling framework can be reused and
>    whenever RFC 4133 [RFC4133] has been implemented.  The
>    entPhysicalIndex from entPhysicalTable can be used to identify an
>    entity/component.  However, there are use cases of energy monitoring,
>    where the application of the ENTITY-MIB does not seem readily
>    apparent and some of those entities could be beyond the original
>    scope and intent of the ENTITY-MIB.
>
>    Consider the case of remote devices attached to the network, and the
>    network device could collect the energy measurement and report on
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 30]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    behalf of such attached devices.  Some of the remote devices such as
>    PoE phones attached to a switch port have been considered in the
>    Power-over-Ethernet MIB module [RFC3621].  However, there are many
>    other devices such as a computer, which draw power from a wall outlet
>    or building HVAC devices which seem to be beyond the original scope
>    of the ENTITY-MIB.
>
>    Yet another example, is smart-PDUs, which can report the energy
>    consumption of the device attached to the power outlet of the PDU.
>    In some cases, the device can be attached to multiple to power
>    outlets.  Thus, the energy measured at multiple outlets need to be
>    aggregated to determine the consumption of a single device.  From
>    mapping perspective, between the PDU outlets and the device this is a
>    many-to-one mapping.  It is not clear if such a many-to-one mapping
>    is feasible within the ENTITY-MIB framework.
>
> A.1.2.  ENTITY STATE MIB
>
>    RFC 4268 [RFC4268] defines the ENTITY STATE MIB module.
>    Implementations of this module provide information on entities
>    including the standby status (hotStandby, coldStandby,
>    providingService), the operational status (disabled, enabled,
>    testing), the alarm status (underRepair, critical, major, minor,
>    warning), and the usage status (idle, active, busy).  This
>    information is already useful as input for policy decisions and for
>    other network management tasks.  However, the number of states would
>    cover only a small subset of the requirements for power state
>    monitoring and it does not provide means for energy consumption
>    monitoring.  For associating the information conveyed by the ENTITY
>    STATE MIB to specific components of a device, the ENTITY STATE MIB
>    module makes use of the means provided by the ENTITY MIB module
>    [RFC4133].  Particularly, it uses the entPhysicalIndex for
>    identifying entities.
>
>    The standby status provided by the ENTITY STATE MIB module is related
>    to power states required for energy management, but the number of
>    states is too restricted for meeting all energy management
>    requirements.  For energy management several more power states are
>    required, such as different sleep and operational states as defined
>    by the Advanced Configuration and Power Interface (ACPI) [ACPI.R30b]
>    or the DMTF Power State Management Profile [DMTF.DSP1027].
>
> A.1.3.  ENTITY SENSOR MIB
>
>    RFC 3433 [RFC3433] defines the ENTITY SENSOR MIB module.
>    Implementations of this module offer a generic way to provide data
>    collected by a sensor.  A sensor could be an energy consumption meter
>    delivering measured values in Watt.  This could be used for reporting
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 31]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    current power of an entity and its components.  Furthermore, the
>    ENTITY SENSOR MIB can be used to retrieve the accuracy of the used
>    power meter.
>
>    Similar to the ENTITY STATE MIB module, the ENTITY SENSOR MIB module
>    makes use of the means provided by the ENTITY MIB module [RFC4133]
>    for relating provided information to components of a device.
>
>    However, there is no unit available for reporting energy quantities,
>    such as, for example, watt seconds or kilowatt hours, and the ENTITY
>    SENSOR MIB module does not support reporting accuracy of measurements
>    according to the IEC / ANSI accuracy classes, which are commonly in
>    use for electric power and energy measurements.  The ENTITY SENSOR
>    MIB modules only provides a coarse-grained method for indicating
>    accuracy by stating the number of correct digits of fixed point
>    values.
>
> A.1.4.  UPS MIB
>
>    RFC 1628 [RFC1628] defines the UPS MIB module.  Implementations of
>    this module provide information on the current real power of entities
>    attached to an uninterruptible power supply (UPS) device.  This
>    application would require identifying which entity is attached to
>    which port of the UPS device.
>
>    UPS MIB provides information on the state of the UPS network.  The
>    MIB module contains several variables that are used to identify the
>    UPS entity (name, model,..), the battery state, to characterize the
>    input load to the UPS, to characterize the output from the UPS, to
>    indicate the various alarm events.  The measurements of power in UPS
>    MIB are in Volts, Amperes and Watts.  The units of power measurement
>    are RMS volts, RMS Amperes and are not based on Entity-Sensor MIB
>    [RFC3433].
>
> A.1.5.  POWER ETHERNET MIB
>
>    Similar to the UPS MIB, implementations of the POWER ETHERNET MIB
>    module defined in RFC3621 [RFC3621] provide information on the
>    current energy consumption of the entities that receive Power over
>    Ethernet (PoE).  This information can be retrieved at the power
>    sourcing equipment.  Analogous to the UPS MIB, it is required to
>    identify which entities are attached to which port of the power
>    sourcing equipment.
>
>    The POWER ETHERNET MIB does not report power and energy consumption
>    on a per port basis, but can report aggregated values for groups of
>    ports.  It does not use objects of the ENTITY MIB module for
>    identifying entities, although this module existed already when the
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 32]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    POWER ETHERNET MIB modules was standardized.
>
> A.1.6.  LLDP MED MIB
>
>    The Link Layer Discovery Protocol (LLDP) defined in IEEE 802.1ab is a
>    data link layer protocol used by network devices for advertising of
>    their identities, capabilities, and interconnections on a LAN
>    network.  The Media Endpoint Discovery (MED) (ANSI/TIA-1057) is an
>    enhancement of LLDP known as LLDP-MED.  The LLDP-MED enhancements
>    specifically address voice applications.  LLDP-MED covers 6 basic
>    areas: capabilities discovery, LAN speed and duplex discovery,
>    network policy discovery, location identification discovery,
>    inventory discovery, and power discovery.
>
> A.2.  Existing standards of other bodies
>
> A.2.1.  DMTF
>
>    The DMTF has defined a power state management profile [DMTF.DSP1027]
>    that is targeted at computer systems.  It is based on the DMTF's
>    Common Information Model (CIM) and rather an entity profile than an
>    actual energy consumption monitoring standard.
>
>    The power state management profile is used to describe and to manage
>    the power state of computer systems.  This includes e.g. means to
>    change the power state of an entity (e.g. to shutdown the entity)
>    which is an aspect of but not sufficient for active energy
>    management.
>
> A.2.2.  OVDA
>
>    ODVA is an association consisting of members from industrial
>    automation companies.  ODVA supports standardization of network
>    technologies based on the Common Industrial Protocol (CIP).  Within
>    ODVA, there is a special interest group focused on energy and
>    standardization and inter-operability of energy aware entities.
>
> A.2.3.  IEEE-ISTO Printer WG
>
>    The charter of the IEEE-ISTO Printer Working Group is for open
>    standards that define printer related protocols, that printer
>    manufacturers and related software vendors shall benefit from the
>    interoperability provided by conformance to these standards.  One
>    particular aspect the Printer WG is focused on is power monitoring
>    and management of network printers and imaging systems PWG Power
>    Management Model for Imaging Systems [IEEE-ISTO].  Clearly, these
>    devices are within the scope of energy management since these devices
>    consume power and are attached to the network.  In addition, there is
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 33]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    ample scope of power management since printers and imaging systems
>    are not used that often.  IEEE-ISTO Printer working group has defined
>    MIB modules for monitoring the power consumption and power state
>    series that can be useful for power management of printers.  The
>    energy management framework should also take into account the
>    standards defined in the Printer working group.  In terms of other
>    standards, IETF Printer MIB RFC3805 [RFC3805] has been standardized,
>    however, this MIB module does not address power management of
>    printers.
>
>
> Authors' Addresses
>
>    Juergen Quittek (editor)
>    NEC Europe Ltd.
>    NEC Laboratories Europe
>    Network Research Division
>    Kurfuersten-Anlage 36
>    Heidelberg  69115
>    DE
>
>    Phone: +49 6221 4342-115
>    Email: quittek@neclab.eu
>
>
>    Rolf Winter
>    NEC Europe Ltd.
>    NEC Laboratories Europe
>    Network Research Division
>    Kurfuersten-Anlage 36
>    Heidelberg  69115
>    DE
>
>    Phone: +49 6221 4342-121
>    Email: Rolf.Winter@neclab.eu
>
>
>    Thomas Dietz
>    NEC Europe Ltd.
>    NEC Laboratories Europe
>    Network Research Division
>    Kurfuersten-Anlage 36
>    Heidelberg  69115
>    DE
>
>    Phone: +49 6221 4342-128
>    Email: Thomas.Dietz@neclab.eu
>
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 34]
> 
> Internet-Draft     Requirements for Energy Management          July 2011
>
>
>    Benoit Claise
>    Cisco Systems, Inc.
>    De Kleetlaan 6a b1
>    Degem  1831
>    BE
>
>    Phone: +32 2 704 5622
>    Email: bclaise@cisco.com
>
>
>    Mouli Chandramouli
>    Cisco Systems, Inc.
>    Sarjapur Outer Ring Road
>    Bangalore,
>    IN
>
>    Phone: +91 80 4426 3947
>    Email: moulchan@cisco.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Quittek, et al.         Expires January 12, 2012               [Page 35]
> 


--------------080707000203080108030702
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Dear all,

    

    Here is my feedback regarding the EMAN requirement, as a
    contributor.

    Note that some points might have been made on the mailing list
    already.

    

    A couple of big points

    - the outlet gang was mentioned by Chris Verges as a requirement. I
    don't think I've seen it mentioned.

        Note: this could be solved by a specificEnergy Managed Object
    Relationships  (Metering, Power Source, Proxy, Dependency)

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

    - I've been thinking about the following requirement some more

    
7.3.  Reporting quantities accumulated over multiple
      powered entities
      

      

         For powered entities reporting single values that are
      accumulated
      

         over multiple powered entities, the energy management standard
      must
      

         provide means for reporting the list of all powered entities
      from
      

         which contributions are included in the accumulated value.
      

    

    And I wonder if we're not trying to make EMAN too complex by adding
    this aggregation function.

    Note: I've been involved in aggregation scheme (See RFC 5982, RFC
    6183, and http://tools.ietf.org/html/draft-trammell-ipfix-a9n-03)
    and this is not straight forward to list all powered entities for
    which there is an aggregation.

    My point is that there is some debate whether or not a switch should
    aggregate all values for children, or if this is a NMS issue.

    Feedback?

    

    See inline

    
Network
      Working Group                                    J. Quittek, Ed.
      

      Internet-Draft                                                 R.
      Winter
      

      Intended status: Informational                                  T.
      Dietz
      

      Expires: January 12, 2012                                NEC
      Europe Ltd.
      

                                                                     B.
      Claise
      

                                                               M.
      Chandramouli
      

                                                           Cisco
      Systems, Inc.
      

                                                                 July
      11, 2011
      

      

      

                         Requirements for Energy Management
      

                          draft-ietf-eman-requirements-04
      

      

      Abstract
      

      

         This document defines requirements for standards specifications
      for
      

         energy management.  Defined requirements concern monitoring
      functions
      

         as well as control functions.  Covered functions include
      

         identification of powered entities, monitoring of their power
      state,
      

         power inlets, power outlets, actual power, consumed energy, and
      

         contained batteries.  Further included is control of powered
      

         entities' power supply and power state.  This document does not
      

         specify the features that must be implemented by compliant
      

         implementations but rather features that must be supported by
      

         standards for energy management.
      

    

    This misses the power quality, or whatever name we want to call it.

    For example "power characteristics)"

    

      

      Status of this Memo
      

      

         This Internet-Draft is submitted in full conformance with the
      

         provisions of BCP 78 and BCP 79.
      

      

         Internet-Drafts are working documents of the Internet
      Engineering
      

         Task Force (IETF).  Note that other groups may also distribute
      

         working documents as Internet-Drafts.  The list of current
      Internet-
      

         Drafts is at http://datatracker.ietf.org/drafts/current/.
      

      

         Internet-Drafts are draft documents valid for a maximum of six
      months
      

         and may be updated, replaced, or obsoleted by other documents
      at any
      

         time.  It is inappropriate to use Internet-Drafts as reference
      

         material or to cite them other than as "work in progress."
      

      

         This Internet-Draft will expire on January 12, 2012.
      

      

      Copyright Notice
      

      

         Copyright (c) 2011 IETF Trust and the persons identified as the
      

         document authors.  All rights reserved.
      

      

      

      

      

      Quittek, et al.         Expires January 12, 2012               
      [Page 1]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         This document is subject to BCP 78 and the IETF Trust's Legal
      

         Provisions Relating to IETF Documents
      

         (http://trustee.ietf.org/license-info) in effect on the date of
      

         publication of this document.  Please review these documents
      

         carefully, as they describe your rights and restrictions with
      respect
      

         to this document.  Code Components extracted from this document
      must
      

         include Simplified BSD License text as described in Section 4.e
      of
      

         the Trust Legal Provisions and are provided without warranty as
      

         described in the Simplified BSD License.
      

      

      

      Table of Contents
      

      

         1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .
      . .  4
      

           1.1.   Conventional requirements for energy management . . .
      . .  4
      

           1.2.   Specific requirements for energy management . . . . .
      . .  5
      

      

         2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .
      . .  6
      

      

         3.  General Objectives of Energy Management  . . . . . . . . .
      . .  8
      

           3.1.   Power states  . . . . . . . . . . . . . . . . . . . .
      . .  8
      

           3.2.   Trade-offs  . . . . . . . . . . . . . . . . . . . . .
      . .  8
      

           3.3.   Local and network-wide energy management  . . . . . .
      . .  8
      

           3.4.   Energy monitoring . . . . . . . . . . . . . . . . . .
      . .  9
      

           3.5.   Overview of energy management requirements  . . . . .
      . . 10
      

      

         4.  Identification of Powered Entities . . . . . . . . . . . .
      . . 10
      

      

         5.  Information on Powered Entities  . . . . . . . . . . . . .
      . . 11
      

           5.1.   General information on powered entities . . . . . . .
      . . 11
      

           5.2.   Power state . . . . . . . . . . . . . . . . . . . . .
      . . 12
      

           5.3.   Power inlet and power outlet  . . . . . . . . . . . .
      . . 14
      

           5.4.   Power . . . . . . . . . . . . . . . . . . . . . . . .
      . . 16
      

           5.5.   Energy  . . . . . . . . . . . . . . . . . . . . . . .
      . . 18
      

           5.6.   Battery State . . . . . . . . . . . . . . . . . . . .
      . . 19
      

      

         6.  Control of Powered Entities  . . . . . . . . . . . . . . .
      . . 21
      

      

         7.  Reporting on Other Powered Entities  . . . . . . . . . . .
      . . 22
      

      

         8.  Controlling Other Powered Entities . . . . . . . . . . . .
      . . 23
      

           8.1.   Controlling power states of other powered entities  .
      . . 23
      

           8.2.   Controlling power supply of other powered entities  .
      . . 24
      

      

         9.  Security Considerations  . . . . . . . . . . . . . . . . .
      . . 25
      

      

         10. IANA Considerations  . . . . . . . . . . . . . . . . . . .
      . . 26
      

      

      

      

      

      Quittek, et al.         Expires January 12, 2012               
      [Page 2]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         11. Acknowledgements . . . . . . . . . . . . . . . . . . . . .
      . . 26
      

      

         12. Open issues  . . . . . . . . . . . . . . . . . . . . . . .
      . . 26
      

           12.1.  Revise security considerations  . . . . . . . . . . .
      . . 26
      

           12.2.  High/Low power notifications  . . . . . . . . . . . .
      . . 26
      

           12.3.  Power and energy time series? . . . . . . . . . . . .
      . . 26
      

           12.4.  Inlet/outlet combinations . . . . . . . . . . . . . .
      . . 26
      

           12.5.  Aggregation functions . . . . . . . . . . . . . . . .
      . . 27
      

           12.6.  Add a definition of 'demand'  . . . . . . . . . . . .
      . . 27
      

           12.7.  IEC references  . . . . . . . . . . . . . . . . . . .
      . . 27
      

           12.8.  Standard references for BACNET or MODBUS  . . . . . .
      . . 27
      

           12.9.  IEEE 1621 and 802.3az references  . . . . . . . . . .
      . . 27
      

           12.10. DC power quality covered by IEC standard? . . . . . .
      . . 27
      

           12.11. Introduce 'disconnected from power' as power state  .
      . . 27
      

           12.12. Need for basic state 'reduced power'? . . . . . . . .
      . . 27
      

           12.13. Local and network-wide energy management  . . . . . .
      . . 28
      

           12.14. Do we need entity types?  . . . . . . . . . . . . . .
      . . 28
      

           12.15. Power availability mode 'minimum' or 'ready'? . . . .
      . . 28
      

           12.16. Is there a need for metering power supply inpedance? 
      . . 28
      

           12.17. Confidence in power values  . . . . . . . . . . . . .
      . . 28
      

           12.18. Terminology for reporting on other entitites  . . . .
      . . 28
      

      

         13. Informative References . . . . . . . . . . . . . . . . . .
      . . 29
      

      

         Appendix A.  Existing Standards  . . . . . . . . . . . . . . .
      . . 30
      

           A.1.   Existing IETF Standards . . . . . . . . . . . . . . .
      . . 30
      

             A.1.1.  ENTITY MIB . . . . . . . . . . . . . . . . . . . .
      . . 30
      

             A.1.2.  ENTITY STATE MIB . . . . . . . . . . . . . . . . .
      . . 31
      

             A.1.3.  ENTITY SENSOR MIB  . . . . . . . . . . . . . . . .
      . . 31
      

             A.1.4.  UPS MIB  . . . . . . . . . . . . . . . . . . . . .
      . . 32
      

             A.1.5.  POWER ETHERNET MIB . . . . . . . . . . . . . . . .
      . . 32
      

             A.1.6.  LLDP MED MIB . . . . . . . . . . . . . . . . . . .
      . . 33
      

           A.2.   Existing standards of other bodies  . . . . . . . . .
      . . 33
      

             A.2.1.  DMTF . . . . . . . . . . . . . . . . . . . . . . .
      . . 33
      

             A.2.2.  OVDA . . . . . . . . . . . . . . . . . . . . . . .
      . . 33
      

             A.2.3.  IEEE-ISTO Printer WG . . . . . . . . . . . . . . .
      . . 33
      

      

         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .
      . . 34
      

      

      

      

      

      

      

      

      

      

      

      

      

      

      Quittek, et al.         Expires January 12, 2012               
      [Page 3]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

      1.  Introduction
      

      

         With rising energy cost and with an increasing awareness of the
      

         ecological impact of running IT and networking equipment,
      energy
      

         management is becoming an additional basic requirement for
      network
      

         management systems and frameworks.
      

      

         This document defines requirements for standards specifications
      for
      

         energy management.  Defined requirements concern monitoring
      functions
      

         as well as control functions.  Covered functions include
      

         identification of powered entities, monitoring of their power
      state,
      

         power inlets, power outlets, actual power, consumed energy, and
      

         contained batteries.  Further included is control of powered
      

         entities' power supply and power state.  Note that this
      document does
      

         not specify the features that must be implemented by compliant
      

         implementations but rather features that must be supported by
      

         standards for energy management.
      

    

    Same remark about power quality

    

      

         The main subject of energy management are powered entities that
      

         consume electric energy.  Powered entities include devices that
      have
      

         an IP address and can be addressed directly, such as hosts,
      routers,
      

         and middleboxes, as well as devices indirectly connected to an
      IP
      

         network, for which a proxy with an IP address provides a
      management
      

         interface, for example, devices in a building management
      

         infrastructure using BACNET or MODBUS protocols.
      

      

         The requirements specified in this document explicitly concern
      the
      

         standards specification process and not the implementation of
      

         specified standards.  All requirements in this document must be
      

         reflected by standards specifications to be developed.  But
      which of
      

         the features specified by these standards will be mandatory,
      

         recommended, or optional for compliant implementations is to be
      

         defined by the concrete standards track document(s) and not in
      this
      

         document.
      

      

         This document first discusses general objectives of energy
      management
      

         in Section 3.  Requirements for an energy management standard
      are
      

         specified in Sections 4 to 8.
      

      

      1.1.  Conventional requirements for energy management
      

    

    I don't know what "conventional" is supposed to mean.

    

      

         The specification of requirements for an energy management
      standard
      

         starts with Section 4 addressing the identification of powered
      

         entities and the granularity of reporting of energy-related
      

         information.  

    I don't understand why we have that sentence here and not in the
    identifier in section 4.

    
A
      standard must support unique identification of
      

         powered entities.  Furthermore, it must support more than just
      

         reporting per powered device.  Support is required for also
      reporting
      

         energy-related information on individual components of a device
      or
      

      

      

      

      Quittek, et al.         Expires January 12, 2012               
      [Page 4]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         subtended devices.  This is why this draft uses the more
      general term
      

         "powered entity" rather than "powered device".  A powered
      entity may
      

         be a device or a component of a device.
      

      

         Section 5 specifies requirements related to monitoring of
      powered
      

         entities.  This includes general (type, context) information
      and
      

         specific information on power states, power inlets, power
      outlets,
      

         power, energy, and batteries.  Control power state and power
      supply
      

         of powered entities is covered by requirements specified in
      

         Section 6.
      

      

      1.2.  Specific requirements for energy management
      

      

         At first glance the rather conventional requirements summarized
      above
      

         seem to be all that would be needed for energy management.  But
      it
      

         turns out that there are some significant differences between
      energy
      

         management and most of the well known conventional network
      management
      

         functions.  The most significant difference from many other
      

         management functions is the need for some devices to report on
      other
      

         entities.  There are three major reasons for this.
      

         o  For monitoring and controlling a particular powered entity
      in
      

            general it is not sufficient to communicate with the powered
      

    

    "sufficient" is not the right wording.

    In some cases, this is just impossible to communicate with the
    powered entity.

    Example: proxy.

    

    
     
      entity only, but in many cases also communication with other
      

            powered entities along the power distribution path may be
      

            necessary, for example, with power switches and power
      meters.
      

            Indeed, there are situations where a power or energy meter
      is not
      

            located in the powered entity, but in a different physical
      

            location.  For example, a Power Distribution Unit (PDU),
      which
      

            supplies power for a server connected to a PDU socket, would
      meter
      

            the power supplied, while the server may not have the
      capability
      

            to measure its power consumption.  

    new text: In specific cases, the monitoring and controlling of
    powered entities must be done by another entity along the power
    distribution domain. For example. 

    And you remove "a second example" below

    
A
      second example is a Power
      

            over Ethernet port, which provides power to the attached
      device,
      

            and which can meter how much power/energy it delivers to the
      

            attached device.
      

         o  Energy management often extends its scope beyond powered
      entities
      

            with IP network interfaces, for example toward non-IP
      building
      

            networks, that are accessed via an IP gateway.  Requirements
      in
      

            this document do not fully cover all these networks, but
      they
      

            cover means for opening IP network management towards them.
      

         o  For monitoring of particular powered entities, it is
      sometimes not
      

            a scalable approach to communicate directly with all the
      powered
      

            entities directly from a central energy management system as
      the
      

            number of powered entities keeps increasing.
      

      

         This specific issue of energy management and a set of further
      ones
      

         are covered by requirements specified in Sections 7 and 8.
      

      

      

      

      

      

      Quittek, et al.         Expires January 12, 2012               
      [Page 5]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

      2.  Terminology
      

      

      2.1.  Energy
      

      

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

      

         The term 'energy consumption' is commonly used for both, for
      

         referring to the amount of consumed energy and also for
      referring to
      

         the rate of consuming energy.  In the first case it addresses
      

         consumed energy measured by joule, watthour, or another energy
      unit,
      

         in the second one it addresses power, typically an average
      power
      

         measured by watt.
      

      

         However, in this document the term "consumed energy" always
      refers to
      

         an energy quantity (measured in joule, watthour, etc.) and not
      to a
      

         power quantity (measured in watt, etc.).
      

      

      2.2.  Power
      

      

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

      

      2.3.  Powered entity
      

      

         A powered entity is a consumer of energy that is subject to
      energy
      

         management.  In general, all managed physical entities in a
      

         communication network consume electric energy and thus are
      subject to
      

         energy management including particularly energy monitoring and
      energy
      

         control.
      

      

         A powered entity can be a managed device or a component of a
      managed
      

         device, which is monitored or controlled individually.
      

      

      2.4.  Power state
      

      

         Power state of a powered entitiy is defined as a specific
      settings of
      

         a powered entitiy that influences its power.  Examples of power
      

         states of a powered entitiy are on, off, and sleep.
      

      

      2.5.  Power monitor
      

      

         Energy management requires retrieving energy-related
      information on
      

         powered entities.  In many cases this information is not
      available at
      

         the powered entities themselves, but at other powered
      entities.  For
      

         example measurement of power and energy consumption can be
      conducted
      

         by power meters at other locations along the power distribution
      tree
      

         for the powered entity.
      

      

         A power monitor is a module that reports energy-related
      information
      

      

      

      

      Quittek, et al.         Expires January 12, 2012               
      [Page 6]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         on powered entities.  A power monitor may be integrated into a
      

         powered entity or located remotely of the powered entity. 
      Instances
      

         of power monitors may report information on, for example, power
      

         supply, power, and power state of a powered entity.  There may
      be
      

         multiple power monitors reporting information on the same
      powered
      

         entity.
      

      

      2.6.  Power inlet
      

      

         Powered entities receive power at their power inlets.  Powered
      

         entities may have multiple inlets, for example, servers with
      

         redundant power supply.  Examples for power inlets are AC power
      cords
      

         of a powered entity or an Ethernet port at which the powered
      entity
      

         receives DC Power over Ethernet (PoE).
      

      

      2.7.  Power outlet
      

      

         Powered entities may have means to supply others with
      electrical
      

         power.  Power is delivered to other powered entities through
      power
      

         outlets.  Power sourcing entities often have more than one
      power
      

         outlet.  Examples for power outlets are AC power sockets at a
      Power
      

         Distribution Unit (PDU) and Ethernet ports at a Power over
      Ethernet
      

         (PoE) Power Sourcing Equipment (PSE), that can supply powered
      

         entities with DC power using the Ethernet cable.
      

      

      2.8.  Energy management
      

      

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

      

      2.9.  Energy management standard
      

    

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

    

      

         This document specifies requirements for an energy management
      

         standard.  This term refers to a collections of documents
      specifying
      

         standards for energy-related monitoring and control.  The
      energy
      

         management standard specifies means for building energy
      management
      

         systems.
      

      

         Requirements specified in this document concern the means that
      an
      

         energy management standard must provide.  It does not imply
      that all
      

         required means must be implemented in all energy standard
      scenarios.
      

         Which means and features must be implemented by compliant
      

         implementations is to be specified by the energy management
      standard
      

         itself, not by this requirements document.
      

      

         Note that for meeting individual requirements specified in this
      

         document, new standards are not necessarily required.  It is
      

         recommended to rather use existing standards than specify new
      ones.
      

    

    

    

      

      

      

      

      Quittek, et al.         Expires January 12, 2012               
      [Page 7]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

      3.  General Objectives of Energy Management
      

    

    Rename to "general considerations related to energy management"

    

      

         The basic objective of energy management is operating
      communication
      

         networks and other equipment with minimal amount of energy,
      while
      

         maintaining a certain level of service.  A set of use cases for
      

         energy management can be found in
      

         [I-D.tychon-eman-applicability-statement].
      

    

    It would read better if the content of section about trade-offs was
    next in this introduction (without having a specific section)

    Then 

        3.1. Power States

        3.2 Energy Monitoring versus Energy Savings

        3.3 Local versus network-wide energy management

        3.4. Overview of the energy management requirements

    

    

      

      3.1.  Power states
      

      

         One approach to achieve this goal is by setting all powered
      entities
      

         to an operational state that results in lower energy
      consumption, but
      

         still meets the service level performance objectives.  The
      sufficient
      

         performance level may vary over time and can depend on several
      

         factors.  In principle, there are four basic types of power
      states
      

         for a powered entity or for a whole system:
      

         o  full power state
      

         o  reduced power states (lower clock rate for processor, lower
      data
      

            rate on a link, etc.)
      

         o  sleep state (not functional, but immediately available)
      

         o  off state (may imply requiring significant time for becoming
      

            operational)
      

         In actual implementations the number of power states and their
      

         properties vary a lot.  Very simple powered entities may just
      have
      

         only the extreme states, full power and off state.  Some
      

         implementations might use IEEE1621 model of three states on,
      off, and
      

         sleep.  However, more granular power states can be implemented
      with
      

         many levels of off, sleep, and reduced power states.
      

      

      3.2.  Trade-offs
      

      

         While the general objective of energy management is quite
      clear, the
      

         way to attain that goal is often difficult.  In many cases
      there is
      

         no way of reducing power consumption without the consequence of
      a
      

         potential performance, service, or capacity degradation.  Then
      a
      

         trade-off needs to be dealt with between service level
      objectives and
      

         energy efficiency.  In other cases a reduction of energy
      consumption
      

         can easily be achieved while still maintaining sufficient
      service
      

         level performance, for example, by switching powered entities
      to
      

         lower power states when higher performance is not needed.
      

      

      3.3.  Local and network-wide energy management
      

      

         Many energy saving functions can be executed locally by a
      powered
      

         entitiy.  The basic principle is that a powered entitiy
      monitors its
      

         usage and dynamically adapts its energy consumption according
      to the
      

         required performance.  It may switch to a sleep state when it
      is not
      

         in use at all.  

    Well, not only when it's not in use.

    It could be based on the time of day, or any other energy saving
    policies.

    
Potential
      interactions with an energy management
      

      

      

      

      Quittek, et al.         Expires January 12, 2012               
      [Page 8]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         system for such an entity include the observation of the
      entity's
      

         power state and the configuration of power saving policies, for
      

         example, by setting thresholds for power state changes.
      

      

         Energy savings can also be achieved with policies implemented
      by a
      

         network management system that controls power states of managed
      

         entities.  In order to make policy decisions properly,
      information
      

         about the energy consumption of powered entities in different
      power
      

         states is required.  Often this information is acquired best
      through
      

         monitoring.
      

      

         Both methods, network-wide and local energy management, have
      

         advantages and disadvantages.  Most buildings use both of
      them.  In
      

         some cases for example, significant energy savings can be
      achieved by
      

         simply setting all powered entities in a network to sleep, when
      the
      

         network is not needed.  However, in general it is dangerous to
      set
      

         all powered entities of a group to the same state, because
      there is a
      

         risk that such actions ignore specifics of individual powered
      

         entities or violate local service level agreements.
      

    

    Can you please expand the previous sentence.

    I'm not sure that I agree.

    

      

      3.4.  Energy monitoring
      

    

    rename to "energy monitoring versus energy savings"

    

      

         It should be noted that only monitoring energy consumption and
      power
      

         states is obviously not a means to reduce the energy
      consumption of a
      

         powered entitiy.  In fact, it is likely to increase the power
      

         consumption of a powered entitiy slightly because monitoring
      energy
      

         may require instrumentation that consumes energy when in use. 
      And
      

         also reporting of measured quantities over the network consumes
      

         energy.  However, the acquired energy consumption and power
      state
      

         information is essential for defining energy saving policies
      and can
      

         be used as input to power state control loops that in total can
      lead
      

         to energy savings.
      

      

         Monitoring operational power states and energy consumption can
      also
      

         be required for other energy management purposes including but
      not
      

         limited to:
      

         o  investigating power saving potential
      

         o  evaluating the effectiveness of energy saving policies and
      

            measures
      

         o  deriving, implementing, and testing power management
      strategies
      

         o  accounting for the total power consumption of a powered
      entity, a
      

            network, or a service
      

         o  predicting a powered entitiy's reliability based on power
      usage
      

         o  choosing time of next maintenance cycle for a powered
      entitiy
      

      

      

      

      

      

      

      

      Quittek, et al.         Expires January 12, 2012               
      [Page 9]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

      3.5.  Overview of energy management requirements
      

      

         From the considerations described above the following basic
      

         management functions appear to be required for energy
      management:
      

         o  monitoring power states
      

         o  monitoring power (energy consumption rate)
      

         o  monitoring (accumulated) energy consumption
      

         o  setting power states
      

         o  setting and enforcing power saving policies
      

    

    And again the comment about the power quality

    

      

         It should be noted that active power control is complementary
      (but
      

    

    what does the "active" power control mean?

    
  
      essential) to other energy savings measures such as low power
      

         electronics, energy saving protocols (for example, IEEE
      802.3az),
      

         energy-efficient device design (for example, sleep and
      low-power
      

         modes for individual components of a device), and
      energy-efficient
      

         network architectures.  Measurement of energy consumption may
      also
      

         provide useful input for developing these technologies.
      

      

      

      4.  Identification of Powered Entities
      

      

         As already stated Section 1.1, powered entities on which
      energy-
      

         related information is provided

    add a comma

    
 are
      identified in a sufficiently
      

         unique way.  This holds in particular for powered entities that
      are
      

         components of managed devices and in case that one powered
      entity
      

         reports information on another one, see Section 7.  For powered
      

         entities that control other powered entities it is important to
      

         identify the powered entities they control, see Section 8.
      

      

         Also stated already in Section 1.1 is the requirement of
      providing
      

         means for reporting energy-related information on components of
      a
      

         managed device.  An entity in this document may be an entire
      managed
      

         device or just a component of it.  Examples of components of
      interest
      

         are a hard drive, a battery, or a line card.  For controlling
      

         entities it may be required to be able to address individual
      

         components in order to save energy.  For example, server blades
      can
      

         be switched off when the overall load is low or line cards at
      

         switches may be powered down at night times.
      

      

         Instrumentation for measuring energy consumption of a device is
      

         typically more expensive than instrumentation for retrieving
      the
      

         devices power state.  It may be a reasonable compromise in many
      cases
      

         to provide power state information for all individually
      switchable
      

         components of a device separately, while the energy consumption
      is
      

         only measured for the entire device.
      

      

         Detailed Requirements:
      

      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 10]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

      4.1.  Identifying powered entities
      

      

         The energy management standard must provide means for uniquely
      and
      

         persistently identifying powered entities that are monitored or
      

         controlled by an energy management system.  Uniqueness must be
      given
      

         in a domain that is large enough to avoid collisions of
      identities at
      

         potential receivers of monitored information.
      

    

    We want to remove "and persistently" from the sentence, as this is
    covered in 4.3

    

    We should have a requirement about a UUID for powered entities.

    Let's cover that during the WG.

    

      

      4.2.  Identifying components of powered devices
      

      

         The energy management standard must provide means for
      identifying not
      

         just entire devices as powered entities, but also individual
      

         components of powered devices.
      

      

      4.3.  Persistency of Identifiers
      

      

         The energy management standard must provide means for
      indicating
      

         whether identifiers of powered entities are persistent across a
      re-
      

         start of the powered entitiy that provides the identifiers.
      

      

      

      5.  Information on Powered Entities
      

      

         This section describes energy-related information on powered
      entities
      

         for which an energy management standard must provide means for
      

         retrieving and reporting.
      

      

         Note that the fact that an energy management standard provides
      

         required means does not imply that all of them must be
      implemented by
      

         every compliant implementation.  The concrete specification of
      

         standards based on these requirements may label individual
      features
      

         as mandatory, recommended, or optional.
      

    

    Remove this paragraph above, as this is already covered before, and
    this is not specific to this section 5.

    

      

         Required information on powered entities can be structured into
      six
      

         groups.  Section 5.1 specifies requirements for general
      information
      

         on powered entities, such as type of powered entity or context
      

         information.  Section 5.2 covers requirements related to
      entities'
      

         power states.  Requirements for information on power inlets and
      power
      

         outlets of powered entities are specified in Section 5.3. 
      Monitoring
      

         of power and energy is covered by Sections 5.4 and 5.5,
      respectively.
      

         Finally, Section 5.6 specified requirements for monitoring
      batteries.
      

      

      5.1.  General information on powered entities
      

      

         For energy management it may be required to understand the role
      and
      

         context of a powered entitiy.  When monitoring, it may be
      helpful to
      

         group energy consumption per kind of entity.  When controlling
      and
      

         setting power states it may be helpful to understand the kind
      and
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 11]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         role of a powered entitiy in a network, for example, in order
      to
      

         avoid switching off vital network components.
      

      

         Detailed Requirements:
      

      

      5.1.1.  Type of powered entity
      

      

         The energy management standard must provide means to retrieve
      and
      

         report the type of powered entities according to a standrdized
      

         classification scheme.
      

    

    see the email thread on the mailing list.

    

      

      5.1.2.  Context information on powered entities
      

      

         The energy management standard must provide means for
      retrieving and
      

         reporting context information on powered entities, for example
      tags
      

         associated with a powered entity that indicate the powered
      entitiy's
      

         role, or importance.
      

      

      5.1.3.  Grouping of powered entities
      

      

         The energy management standard must provide means for grouping
      

         powered entities, for example, into energy monitoring domains,
      energy
      

         control domains, power supply domains, groups of powered
      entities of
      

         the same type, etc.
      

      

      5.2.  Power state
      

      

         Many powered entities have a limited number of discrete power
      states,
      

         such as, for example, full power, low power, sleep, and off.
      

      

         Obviously, there is a need to report the actual power state of
      a
      

         powered entitiy.  Beyond that, there is also a requirement for
      

         standardizing means for retrieving the list of all supported
      power
      

         states of a powered entitiy.
      

      

         Different standards bodies have already defined their own sets
      of
      

         power states for powered entities.  Further organizations are
      in the
      

         process of adding more of these sets.  In order to support
      multiple
      

         management systems possibly using different power state sets,
      while
      

         simultaneously interfacing with a particular powered entity,
      the
      

         energy management standard must provide means for supporting
      multiple
      

         power state sets used simultaneously at a powered entity.
      

      

         Power states have parameters that describe its properties It is
      

         required to have standardized means for reporting some key
      

         properties, such as mean power and maximum power of a powered
      entitiy
      

         in a certain state.
      

      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 12]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         There also is a need to report statistics on power states
      including
      

         the time spent an the energy consumed in a power state.
      

      

         For some network management tasks, it may be desirable to
      receive
      

         notifications from powered entities, for example, when the
      components
      

         or the entire entity change their power state.
      

      

         Detailed Requirements:
      

      

      5.2.1.  Actual power state
      

      

         The energy management standard must provide means for reporting
      the
      

         actual power state of a powered entitiy.
      

      

      5.2.2.  List of supported power states
      

    

    

      

         The energy management standard must provide means for
      retrieving the
      

         list of all potential power states of a powered entitiy.
      

      

      5.2.3.  Multiple power state sets
      

      

         The energy management standard must provide means for
      supporting
      

         multiple power state sets simultaneously at a powered entity.
      

      

      5.2.4.  List of supported power state sets
      

      

         The energy management standard must provide means for
      retrieving the
      

         list of all power state sets supported by a powered entitiy.
      

      

      5.2.5.  List of supported power states
      

    

    5.2.2 has got the same title.

    Proposal for 5.2.5 "List of supported power states within power
    state set"

    

      

         Referring to the "list of supported power state sets"
      requirement,
      

         the energy management standard must provide means for
      retrieving the
      

         list of all potential power states of a powered entitiy that
      belong
      

         to a given power state set.
      

    

    new text.

        For the rest of the document, when the Power State term is used,
    it implicitly refers to a power state within a power state set.

    

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

    

      

      5.2.6.  Maximum and average power per power state
      

      

         The energy management standard must provide means for
      retrieving the
      

         maximum power and the average power as a typically static
      property
      

         for each supported power state.
      

      

      5.2.7.  Power state statistics
      

      

         The energy management standard must provide means for
      monitoring
      

         statistics per power state including at least the total time
      spent in
      

         a power state, the number of times a state was entered and the
      last
      

         time a state was entered.  More power state statistics are
      addressed
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 13]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         by requirement 5.5.3.
      

      

      5.2.8.  Power state changes
      

      

         The energy management standard must provide means for
      generating a
      

         notification when the actual power state of a powered entity
      changes.
      

      

      5.3.  Power inlet and power outlet
      

      

         Powered entities have power inlets at which they are supplied
      with
      

         electric power.  Most powered entities just have a single power
      

         inlet, while some have multiple ones.  Often different power
      inlets
      

         are connected to separate power distribution trees.  For energy
      

         monitoring, it is important information which power inlets a
      powered
      

         entitiy has, 

    what do you mean? the type, the number, or something else?

    
if
      power is available at an inlet and which of them are
      

         actually in use.
      

      

         Some powered entities have power outlets for supplying other
      powered
      

         entities with electric power.  A powered entitiy may have
      multiple
      

         power outlets.  Examples are Power Distribution Units (PDUs)
      and
      

         Power over Ethernet (PoE) Power Sourcing Equipment (PSE).
      

    

    Remove the previous sentence, as this is already in the terminology
    section.

    

      

         For identifying and potentially controlling the source of power
      

         received at an inlet, it may be required to identify the power
      outlet
      

         of another powered entity at which the received power is
      provided.
      

         Analogously, for each outlet it is of interest to identify the
      power
      

         inlets that receive the power provided at a certain outlet.
      

      

         Static properties of each power inlet and each power outlet are
      

         required information for energy management.  Static properties
      

         include the kind of electric current (Alternating Current (AC)
      or
      

         Direct Current (DC)), the nominal voltage, the nominal AC
      frequency,
      

         and the number of AC phases.
      

    

    So "static properties" is what we called "power quality"?

    

      

         Detailed Requirements:
      

      

      5.3.1.  List of power inlets and power outlets
      

      

         The energy management standard must provide means for
      monitoring the
      

         list of power inlets and power outlets at a powered entitiy.
      

      

      5.3.2.  Corresponding power outlet
      

      

         The energy management standard must provide means for
      identifying the
      

         power outlet that provides the power received at a power inlet.
      

      

      

      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 14]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

      5.3.3.  Corresponding power inlets
      

      

         The energy management standard must provide means for
      identifying the
      

         list of power inlets that receive the power provided at a power
      

         outlet.
      

      

      5.3.4.  Availability of power
      

      

         The energy management standard must provide means for
      monitoring the
      

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

         This information indicates whether at a power providing outlet
      power
      

         supply is switched on or off.
      

      

      5.3.5.  Use of power
      

      

         The energy management standard must provide means for
      monitoring for
      

         each power inlet and each power outlet if it is in actual use. 
      For
      

         the inlet this means that the powered entitiy actually receives
      power
      

         at the inlet.  For the outlet this means that actually power is
      

         provided to one or more powered entities at the outlet.
      

      

      5.3.6.  Type of current
      

      

         The energy management standard must provide means for reporting
      the
      

         type of current (Alternating Current (AC) or Direct Current
      (DC)) for
      

         each power inlet and each power outlet of a powered entity.
      

      

      5.3.7.  Nominal voltage
      

      

         The energy management standard must provide means for reporting
      the
      

         nominal voltage for each power inlet and each power outlet of a
      

         powered entity.
      

      

      5.3.8.  Nominal AC frequency
      

      

         The energy management standard must provide means for reporting
      the
      

         nominal AC frequency for each power inlet and each power outlet
      of a
      

         powered entity.
      

      

      5.3.9.  number of AC phases
      

    

    number -> Number

    

      

         The energy management standard must provide means for reporting
      the
      

         number of AC phases for each power inlet and each power outlet
      of a
      

         powered entity.
      

      

      

      

      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 15]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

      5.4.  Power
      

      

         Power is a quantity measured as instantaneous power or as
      average
      

         power over a time interval.  In contrast to power state values,
      this
      

         quantity may change continuously.
      

      

         Obtaining highly accurate values for power and energy may be
      costly.
      

         Often dedicated metering hardware is needed for this purpose.
      

         Powered entities without the ability to measure their power and
      

         energy consumption with high accuracy may just report estimated
      

         values, for example based on load monitoring or even just the
      entity
      

         type.
      

      

         Depending on how power and energy consumption values are
      obtained the
      

         confidence in the reported value and its accuracy may vary. 
      Powered
      

         entities reporting such values should qualify the confidence in
      the
      

         reported values and quantify the accuracy of measurements.  For
      

         reporting accuracy, the accuracy classes specified in IEC
      62053-21
      

         [IEC.62053-21] and IEC 62053-22 [IEC.62053-22] should be
      considered.
      

      

         In addition to the plain real power value, also further
      properties of
      

         the supplied power are subject to monitoring.  In case of AC
      power
      

         supply, there are more power values beyond the real power to be
      

         reported including the apparent power, the reactive power, and
      the
      

         phase angle of the current or the power factor.  For both AC
      and DC
      

         power the power quality is also subject of monitoring. 

    

    So "power quality" is mentioned.

    
 Power
      quality
      

         parameters include the actual voltage, the actual frequency,
      the
      

         Total Harmonic Distortion (THD) of voltage and current, the
      impedance
      

         of an AC phase or of the DC supply.  Power quality monitoring
      should
      

         be in line with existing standards, such as [IEC.61850-7-4].
      

      

         For some network management tasks, it is required to obtain
      time
      

         series of power values (or energy consumption values).  In
      general
      

         these could be obtained in many different ways.  It should be
      avoided
      

         that such time series can only be obtained by regular polling
      by the
      

         energy management system.  Means should be provided to either
      push
      

         such values from the place they are available to the management
      

         system or to have them stored at the powered entitiy for a
      

         sufficiently long period of time such that a management system
      can
      

         retrieve a stored time series of values.
      

      

         Detailed Requirements:
      

      

      5.4.1.  Real power
      

      

         The energy management standard must provide means for reporting
      the
      

         real power for each power inlet and each power outlet of a
      powered
      

         entity.
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 16]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

      5.4.2.  Power measurement interval
      

      

         The energy management standard must provide means for reporting
      the
      

         corresponding time or time interval for which a power value is
      

         reported.  The power value can be measured at the corresponding
      time
      

         or averaged over the corresponding time interval.
      

      

      5.4.3.  Confidence in power values
      

      

         The energy management standard must provide means for reporting
      the
      

         confidence in reported power values by indicating the way these
      

         values have been obtained. for example, by power measurement,
      by
      

         estimation based on performance values, or hard coding average
      power
      

         values for a powered entity.
      

      

      5.4.4.  Accuracy of power and energy values
      

      

         The energy management standard must provide means for reporting
      the
      

         accuracy of reported power values.
      

      

      5.4.5.  Complex power
      

      

         The energy management standard must provide means for reporting
      the
      

         complex power for each power inlet and each power outlet of a
      powered
      

         entity.  Besides the real power, at least two out of the
      following
      

         three quantities need to be reported: apparent power, reactive
      power,
      

         phase angle.  The phase angle can be substituted by the power
      factor.
      

         In case of AC power supply, means must be provided for
      reporting the
      

         complex power per phase.
      

      

      5.4.6.  Actual voltage and current
      

      

         The energy management standard must provide means for reporting
      the
      

         actual voltage and actual current for each power inlet and each
      power
      

         outlet of a powered entity.  In case of AC power supply, means
      must
      

         be provided for reporting the actual voltage and actual current
      per
      

         phase.
      

      

      5.4.7.  Actual AC frequency
      

      

         The energy management standard must provide means for reporting
      the
      

         actual AC frequency for each power inlet and each power outlet
      of a
      

         powered entity.
      

      

      5.4.8.  Total harmonic distortion
      

      

         The energy management standard must provide means for reporting
      the
      

         Total Harmonic Distortion (THD) of voltage and current for each
      power
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 17]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         inlet and each power outlet of a powered entity.  In case of AC
      power
      

         supply, means must be provided for reporting the THD per phase.
      

      

      5.4.9.  Power supply impedance
      

      

         The energy management standard must provide means for reporting
      the
      

         impedance of power supply for each power inlet and each power
      outlet
      

         of a powered entity.  In case of AC power supply, means must be
      

         provided for reporting the impedance per phase.
      

      

      5.4.10.  Time series of power values
      

      

         The energy management standard must provide means for
      collecting time
      

         series of real power values for each power inlet and for each
      power
      

         outlet of a powered entitiy without requiring to regularly poll
      the
      

         powered entitiy from an energy management station.  A solution
      for
      

         this is that the concerned powered entity or another powered
      entity
      

         closely interacting with the concerned powered entity collect
      time
      

         series of power values and make them available via push or pull
      

         mechanisms to receivers of the information.
      

      

      5.5.  Energy
      

      

         Monitoring of electrical energy consumed (or converted) at a
      powered
      

         entitiy can be done in various ways.  One is collecting time
      series
      

         of power values for the powered entitiy and calculating the
      consumed
      

         energy from these values.  An alternative is the powered entity
      

         itself or another powered entity taking care of energy
      measurement
      

         and reporting energy consumption values for certain time
      intervals.
      

         Time intervals of interest are the time from the last restart
      of the
      

         powered entitiy to the reporting time, the time from another
      past
      

         event to the reporting time, or the last given amount of time
      before
      

         the reporting time.
      

      

         In order to monitor energy consumption in different power
      states, it
      

         is useful if powered entities record their energy consumption
      per
      

         power state and report these quantities.
      

      

         For some network management tasks, it is required to obtain
      time
      

         series of energy values.  In general these could be obtained in
      many
      

         different ways.  It should be avoided that such time series can
      only
      

         be obtained by regular polling by the energy management system.
      

         Means should be provided to either push such values from the
      place
      

         they are available to the management system or to have them
      stored at
      

         the powered entitiy for a sufficiently long period of time such
      that
      

         a management system can retrieve a stored time series of
      values.
      

      

         Detailed Requirements:
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 18]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

      5.5.1.  Energy
      

      

         The energy management standard must provide means for reporting
      the
      

         consumed energy received at a power input or provided at a
      power
      

         outlet of a powered entitiy.  Reports must be made for a
      clearly
      

         specified time interval.
      

      

      5.5.2.  Time intervals
      

      

         The energy management standard must provide means for reporting
      the
      

         consumed energy of a powered entitiy for certain time
      intervals.
      

         o  Reports must be supported for the time interval starting at
      the
      

            last restart of the powered entitiy and ending at a certain
      point
      

            in time, such as the time when a report was delivered.
      

         o  Reports must be supported for a sequence of consecutive non-
      

            overlapping time intervals of fixed size (periodic reports).
      

         o  Reports must be supported for a sequence of consecutive
      

            overlapping time intervals of fixed size (periodic reports).
      

         o  Reports must be supported for an interval of given length
      ending
      

            at a certain point in time, such as the time when a report
      was
      

            delivered (sliding window)
      

      

      5.5.3.  Energy per power state
      

      

         The energy management standard must provide means for reporting
      the
      

         consumed energy individually for each power state.  This
      extends the
      

         requirement 5.2.7 on power state statistics.
      

      

      5.5.4.  Time series of energy values
      

      

         The energy management standard must provide means for
      collecting time
      

         series of energy values for each power inlet and for each power
      

         outlet of a powered entitiy without requiring to regularly poll
      the
      

         powered entitiy from an energy management station.  A solution
      for
      

         this is that the concerned powered entity or another powered
      entity
      

         closely interacting with the concerned powered entity collect
      time
      

         series of energy values and make them available via push or
      pull
      

         mechanisms to receivers of the information.
      

      

      5.6.  Battery State
      

      

         Today more and more powered entities contain batteries that
      supply
      

         them with power when disconnected from electrical power
      distribution
      

         grids.  Common examples are nomadic and mobile devices, such as
      

         notebook computers, netbooks, and smart phones.  The status of
      

         batteries in such an powered entity, particularly the charging
      status
      

         is typically controlled by automatic functions that act locally
      on
      

         the powered entitiy and manually by users of the powered
      entity.  In
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 19]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         addition to this, there is a need to monitor the battery status
      of
      

         these entities by network management systems.
      

      

         The management requirements discussed above in Sections 5.1 to
      5.5
      

         concern energy-related information on powered entities. 
      Powered
      

         entities may be powered devices or components of powered
      devices.
      

    

    I  believe that we mentioned that sentence already.

    
  
      Devices containing batteries can be modeled in two ways.  The
      entire
      

         device can be modeled as a single powered entity on which
      energy-
      

         related information is reported or the battery can be modeled
      as an
      

         individual powered entity for which energy-related information
      is
      

         monitored individually according to requirements in Sections
      5.1 to
      

         5.5.
      

      

         In both cases further information on batteries is of interest
      for
      

         energy management, such as the current charge of the battery,
      the
      

         number of completed charging cycles, the charging state of the
      

         battery, and further static and dynamic battery properties. 
      Also
      

         desirable is to receive notifications if the charge of a
      battery
      

         becomes very low or if a battery needs to be replaced.
      

      

         Detailed Requirements:
      

      

      5.6.1.  Battery charge
      

      

         The energy management standard must provide means for reporting
      the
      

         current charge of a battery.
      

      

      5.6.2.  Battery charging state
      

      

         The energy management standard must provide means for reporting
      the
      

         charging state (charged, discharged, etc.) of a battery.
      

      

      5.6.3.  Battery charging cycles
      

      

         The energy management standard must provide means for reporting
      the
      

         number of completed charging cycles of a battery.
      

      

      5.6.4.  Actual battery capacity
      

      

         The energy management standard must provide means for reporting
      the
      

         actual capacity of a battery.
      

      

      5.6.5.  Static battery properties
      

      

         The energy management standard must provide means for reporting
      

         static properties of a battery, including the nominal capacity,
      the
      

         number of cells, the nominal voltage, and the battery
      technology.
      

      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 20]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

      5.6.6.  Low battery charge notification
      

      

         The energy management standard must provide means for
      generating a
      

         notification when a the charge of a battery decreases below a
      given
      

         threshold.
      

    

    remove "a"

    

      

      5.6.7.  Battery replacement notification
      

      

         The energy management standard must provide means for
      generating a
      

         notification when the number of charging cycles of battery
      exceeds a
      

         given threshold.
      

      

      5.6.8.  Multiple batteries
      

      

         The energy management standard must provide means for meeting
      

         requirements 5.6.1 to 5.6.7 for each individual battery
      contained in
      

         a single powered entity.
      

      

      

      6.  Control of Powered Entities
      

      

         Many powered entities control their power state locally by
      self-
      

         managed dynamic adaptation to the environment.  But other
      powered
      

         entities without that capability need interfaces for a energy
      

         management system to control their power states in order to
      save
      

         energy.  Even for self-managed powered entities such interface
      may be
      

         required for overruling local policy decisions by global ones
      from an
      

         energy management system.
      

      

         Power supply is typically not self-managed by powered
      entities.  And
      

         controlling power supply is typically not conducted as
      interaction
      

         between energy management system and the powered entity
      itself.  It
      

         is rather an interaction between the management system and an
      entity
      

         providing power at its power outlets.  Still, requirements for
      power
      

         state control apply accordingly to power supply control.
      

      

         Note that shutting down the power supply abruptly may have
      severe
      

         consequences for the powered entity.
      

      

         Detailed Requirements:
      

      

      6.1.  Controlling power states
      

      

         The energy management standard must provide means for setting
      power
      

         states of powered entities.
      

      

      

      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 21]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

      6.2.  Controlling power supply
      

      

         The energy management standard must provide means for switching
      power
      

         supply off or turning power supply on at power outlets
      providing
      

         power to one or more powered entity.
      

      

      

      7.  Reporting on Other Powered Entities
      

      

         As already discussed in the introduction of Section 5, not all
      

         energy-related information may be available at the concerned
      powered
      

         entity.  Such information may be provided by other powered
      entities,
      

         such as a Power Distribution Unit (PDU), external power meter,
      or a
      

         Power over Ethernet (PoE) Power Sourcing Equipment (PSE).  Some
      of
      

         these entities (PDU, PSE) can also control the power provided
      to the
      

         other powered entities, while some can just report on the
      remote
      

         powered entities (external power meter).  This section covers
      

         reporting of information (monitoring) only.  See Section 8 for
      

         requirements on controlling other powered entities.
      

      

         There are cases where a power supply unit switches power for
      several
      

         powered entities by turning power on or off at a single power
      outlet
      

         or where a power meter measures the accumulated power of
      several
      

         powered entities at a single power line.  Consequently, it
      should be
      

         possible to report that a monitored value does not relate to
      just a
      

         single powered entity, but is an accumulated value for a set of
      

         powered entities.  All of these powered entities belonging to
      that
      

         set need to be identified.
      

      

         If a powered entity has information about where energy-related
      

         information on itself can be retrieved, then it would be very
      useful
      

         if it has a way to communicate this information to an energy
      

         management system.  This applies even if the information only
      

         provides accumulated quantities for several powered entities.
      

      

         Detailed Requirements:
      

      

      7.1.  Reports on other powered entities
      

      

         The energy management standard must provide means for a powered
      

         entitiy to report energy-related information on another powered
      

         entity.
      

      

      7.2.  Identity of other powered entities on which is reported
      

      

         The energy management standard must provide means for reporting
      the
      

         identity of another powered entity on which energy-related
      

         information is reported.
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 22]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

      7.3.  Reporting quantities accumulated over multiple powered
      entities
      

      

         For powered entities reporting single values that are
      accumulated
      

         over multiple powered entities, the energy management standard
      must
      

         provide means for reporting the list of all powered entities
      from
      

         which contributions are included in the accumulated value.
      

    

    See my comments at the beginning of the email

    

      

      7.4.  List of all powered entities on which is reported
      

      

         The energy management standard must provide means for a powered
      

         entitiy to report the list of all other powered entities on
      which it
      

         can report energy-related information.
      

      

      7.5.  Content of reports on other powered entities
      

      

         The energy management standard must provide means for a powered
      

         entitiy to indicate for each other powered entity on which it
      can
      

         provide energy-related information which energy-related
      information
      

         can be provided for this powered entity.
      

      

      7.6.  Indicating source of remote information
      

      

         The energy management standard must provide means for a powered
      

         entity to indicate another powered entity at which
      energy-related
      

         information on itself can be retrieved.
      

      

      7.7.  Indicating source of remote information
      

      

         For a powered entity that has another powered entity at which
      energy-
      

         related information on itself can be retrieved, the energy
      management
      

         standard must provide means for indicating the information that
      is
      

         available at other powered entities per other powered entity.
      

      

      

      8.  Controlling Other Powered Entities
      

      

         This section specifies requirements for controlling power
      states and
      

         power supply of powered entities by communicating not with
      these
      

         powered entities themselves, but with other powered entities
      that
      

         have means for controlling power state or power supply of
      others.
      

      

      8.1.  Controlling power states of other powered entities
      

      

         Some powered entities may have control of power states of other
      

         powered entities.  For example a gateway to a building network
      may
      

         have means to control the power state of powered entities in
      the
      

         building that do not have an IP interface.  For this and
      similar
      

         cases means are needed to make this control accessible to the
      energy
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 23]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         management system.
      

      

         In addition to this, it is required that a powered entitiy that
      has
      

         its state controlled by other powered entities has means to
      report
      

         the list of these other powered entities.
      

      

         Detailed Requirements:
      

      

      8.1.1.  Control of power states of other powered entities
      

      

         The energy management standard must provide means for an energy
      

         management system to send power state control commands to a
      powered
      

         entity that concern the power states of other powered entities
      than
      

         the one the command was send to.
      

      

      8.1.2.  Identity of other power state controlled entities
      

      

         The energy management standard must provide means for reporting
      the
      

         identity of another powered entity for which the reporting
      powered
      

         entity has means to control the power state.
      

      

      8.1.3.  List of all power state controlled entities
      

      

         The energy management standard must provide means for a powered
      

         entitiy to report the list of all powered entities for which it
      can
      

         control the power state.
      

      

      8.1.4.  List of all power state controllers
      

      

         The energy management standard must provide means for a powered
      

         entitiy that receives commands controlling its power state from
      other
      

         powered entities to report the list of all those entities.
      

      

      8.2.  Controlling power supply of other powered entities
      

      

         Some powered entities may have control of the power supply of
      other
      

         powered entities, for example, because the other powered entity
      is
      

         supplied via a power outlet of the powered entitiy.  For this
      and
      

         similar cases means are needed to make this control accessible
      to the
      

         energy management system.
      

      

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

    

    very required -> required

    
   has
      its supply controlled by other powered entities has means to
      

         report the list of these other powered entities.
      

      

         Detailed Requirements:
      

      

      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 24]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

      8.2.1.  Control of power supply of other powered entities
      

      

         The energy management standard must provide means for an energy
      

         management system to send power supply control commands to a
      powered
      

         entity that concern the power supply of other powered entities
      than
      

         the one the command was send to.
      

      

      8.2.2.  Identity of other power supply controlled powered entities
      

      

         The energy management standard must provide means for reporting
      the
      

         identity of another powered entity for which the reporting
      powered
      

         entity has means to control the power supply.
      

      

      8.2.3.  List of all power supply controlled powered entities
      

      

         The energy management standard must provide means for a powered
      

         entitiy to report the list of all other powered entities for
      which it
      

         can control the power supply.
      

      

      8.2.4.  List of all power supply controllers
      

      

         The energy management standard must provide means for a powered
      

         entitiy that has other powered entities controlling its power
      supply
      

         to report the list of all those powered entities.
      

      

      

      9.  Security Considerations
      

      

         The typical security threats for the management protocol for
      energy
      

         monitoring are similar to the ones specified in the SNMP
      security
      

         framework.  In other words, from an energy monitoring point of
      view,
      

         no additional security requirements have been imposed.
      

      

         Link layer discovery mechanisms need to ensure that only the
      trusted
      

         powered entities shall be discovered during discovery and
      detect/
      

         discard powered entities without a trusted relationship to be
      

         included among the powered entities for energy monitoring.
      

      

         In terms of monitoring, considering that there can be some
      network
      

         entities which shall be entitled to collect the measured data
      on
      

         behalf of other powered entities, then it is important to
      

         authenticate and/or authorize such powered entities.  In
      addition, in
      

         the case of control of other powered entities, it would be
      highly
      

         desirable to have some form of an authentication mechanism to
      ensure
      

         that only the designated powered entities shall control the
      powered
      

         entities within its control domain.  It should be possible to
      prevent
      

         a powered entity which does not have the appropriate
      authorization
      

         and authority to control or configure powered entities in its
      control
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 25]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         domain/purview.  Secondly, it should be possible to prevent
      malicious
      

         powered entities from exercising control over entities.
      

      

      

      10.  IANA Considerations
      

      

         This document has no actions for IANA.
      

      

      

      11.  Acknowledgements
      

      

         The authors would like to thank Ralf Wolter for his first essay
      on
      

         this draft.  Many thanks to William Mielke, John Parello, Bruce
      

         Nordman, JinHyeock Choi, Georgios Karagiannis, and Michael
      Suchoff
      

         for helpful comments on the draft.
      

      

    

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

    

    Regards, Benoit.

    

      

      12.  Open issues
      

      

      12.1.  Revise security considerations
      

      

         A discussion of the sensitivity of the content of the
      monitoring data
      

         is missing.
      

      

      12.2.  High/Low power notifications
      

      

         For some network management tasks it may be desirable to
      receive
      

         notifications from entities when the power of an powered entity
      

         exceeds or falls below certain thresholds.  Do we want to make
      this a
      

         requirement?
      

      

         Proposal: added "for example" so that we don't restrict the
      framework
      

         to only this notification
      

      

      12.3.  Power and energy time series?
      

      

         We have requirements for reporting of time series of power and
      energy
      

         values.  Do we need both or just one of them?  If just one,
      then
      

         which one?
      

      

      12.4.  Inlet/outlet combinations
      

      

         How to model the case that an inlet or outlet changes during
      

         operation from one kind to the other.  An example is a battery
      that
      

         receives power at a socket at one time.  Then the socket is an
      inlet.
      

         At another time the battery provides power at the same socket. 
      Then
      

         it's an outlet.  The same holds for entities with integrated
      power
      

         generators.
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 26]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         One solution would be to introduce a new kind of hybrid
      in/outlets.
      

         Another one would be to model the same socket as inlet as well
      as as
      

         outlet.  It would appear twice in the list of all inlets and
      outlets.
      

         Then received power/energy would be reported under the inlet
      entry
      

         and provided power/energy would be reported under the outlet
      entry.
      

      

         These would be two solutions.  What would be the concrete
      requirement
      

         behind them?
      

      

      12.5.  Aggregation functions
      

      

         Aggregation functions are not covered (yet).  Are there
      requirements
      

         on aggregation?  Which are they?
      

      

      12.6.  Add a definition of 'demand'
      

      

      12.7.  IEC references
      

      

         References to mentioned IEC standards are missing.  Also these
      

         references should be double checked.
      

      

      12.8.  Standard references for BACNET or MODBUS
      

      

         Section 1 mentions BACNET or MODBUS as examples for building
      network
      

         protocols.  We need references to the standards specifications
      for
      

         these protocols.
      

      

      12.9.  IEEE 1621 and 802.3az references
      

      

         A reference to the IEEE 1621 standard is missing in section 3.1
      and a
      

         reference to IEEE 802.3az is missing in section 3.4.  The
      references
      

         should be double checked if they are well applicable in the
      

         respective section.
      

      

      12.10.  DC power quality covered by IEC standard?
      

      

         Is there an IEC standard on DC power quality?
      

      

      12.11.  Introduce 'disconnected from power' as power state
      

      

         We need to introduce the concept of a device being
      "disconnected"
      

         from power.  This is a subset of the Off state.  Shall we do it
      here
      

         or rather in the framework draft?
      

      

      12.12.  Need for basic state 'reduced power'?
      

      

         Are "full power" and "reduced power" really different basic
      types of
      

         power states?  Both may be forms of the on state.  Identifying
      "full"
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 27]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         separately is arbitrary.  (For something like a computer,
      "idle" is
      

         the most common state so would be the one to call out
      separately
      

         rather than "full".)
      

      

      12.13.  Local and network-wide energy management
      

      

         All but first sentence of the third paragraph in section 3.3
      seem to
      

         be true not needed here.  Proposal: remove them.
      

      

      12.14.  Do we need entity types?
      

      

         Or shall we remove Section 5.1.1?
      

      

      12.15.  Power availability mode 'minimum' or 'ready'?
      

      

         Do we need an additional mode for power availability called
      "minimum"
      

         or "ready" for power availability in xref
      target="availability"/>?
      

         This would reflect a PoE state at which the PSE is ready to
      serve the
      

         PD.
      

      

      12.16.  Is there a need for metering power supply inpedance?
      

      

      

      

      12.17.  Confidence in power values
      

      

         Shall we rename "confidence in power values" to "method for
      

         determining power values"?
      

      

      12.18.  Terminology for reporting on other entitites
      

      

         In Section 7 we need some additional terms here to streamline
      the
      

         text (and ultimately our thinking).  Nominations include:
      

         o  "powered entity" (which may be "self-reporting")
      

         o  "reporting entity" (can be "self" or "other")
      

         o  "other entity" (a reporting entity reporting not on itself;
      likely
      

            a different term would be better for this)
      

         o  "controlled entity", "controlling entity" (section 8.1)
      

         o  "switched entity", "switching entity" (section 8.2)
      

      

         Also, there are two cases for an "other entity".  One is where
      the
      

         powered entity cannot report the value in question itself
      (either
      

         because it can't report anything, or doesn't know the value in
      

         question, e.g. when metering is external).
      

      

         The second is where the powered entity can report, but the
      other
      

         entity is doing the reporting for some convenience.  We need to
      be
      

         aware of both even if the framework does not need to make the
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 28]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         distinction.
      

      

         There may be multiple other reporting entities, not just a
      single
      

         one.
      

      

         Do components of devices ever report, or do only devices do the
      

         reporting?  This seems like an important point.
      

      

      

      13.  Informative References
      

      

         [RFC1628]  Case, J., "UPS Management Information Base", RFC
      1628,
      

                    May 1994.
      

      

         [RFC3433]  Bierman, A., Romascanu, D., and K. Norseth, "Entity
      Sensor
      

                    Management Information Base", RFC 3433, December
      2002.
      

      

         [RFC3621]  Berger, A. and D. Romascanu, "Power Ethernet MIB",
      

                    RFC 3621, December 2003.
      

      

         [RFC3805]  Bergman, R., Lewis, H., and I. McDonald, "Printer
      MIB v2",
      

                    RFC 3805, June 2004.
      

      

         [RFC4133]  Bierman, A. and K. McCloghrie, "Entity MIB (Version
      3)",
      

                    RFC 4133, August 2005.
      

      

         [RFC4268]  Chisholm, S. and D. Perkins, "Entity State MIB", RFC
      4268,
      

                    November 2005.
      

      

         [I-D.tychon-eman-applicability-statement]
      

                    Tychon, E., Silver, L., and M. Chandramouli, "Energy
      

                    Management (EMAN) Applicability Statement",
      

                    draft-tychon-eman-applicability-statement-02 (work
      in
      

                    progress), June 2011.
      

      

         [ACPI.R30b]
      

                    Hewlett-Packard Corporation, Intel Corporation,
      Microsoft
      

                    Corporation, Phoenix Corporation, and Toshiba
      Corporation,
      

                    "Advanced Configuration and Power Interface
      Specification,
      

                    Revision 3.0b", October 2006.
      

      

         [DMTF.DSP1027]
      

                    Dasari (ed.), R., Davis (ed.), J., and J. Hilland
      (ed.),
      

                    "Power State Management Profile", September 2008.
      

      

         [IEEE-ISTO]
      

                    Printer Working Group, "PWG 5106.4 - PWG Power
      Management
      

                    Model for Imaging Systems 1.0:", February 2011.
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 29]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         [IEC.62053-21]
      

                    International Electrotechnical Commission,
      "Electricity
      

                    metering equipment (a.c.) - Particular requirements
      - Part
      

                    22: Static meters for active energy  (classes 1 and
      2)",
      

                    2003.
      

      

         [IEC.62053-22]
      

                    International Electrotechnical Commission,
      "Electricity
      

                    metering equipment (a.c.) - Particular requirements
      - Part
      

                    22: Static meters for active energy  (classes 0,2 S
      and
      

                    0,5 S)", 2003.
      

      

         [IEC.61850-7-4]
      

                    International Electrotechnical Commission,
      "Communication
      

                    networks and systems for power utility automation -
      Part
      

                    7-4: Basic communication structure - Compatible
      logical
      

                    node classes and data object classes", 2010.
      

      

      

      Appendix A.  Existing Standards
      

      

         This section analyzes existing standards for energy consumption
      and
      

         power state monitoring.  It shows that there are already
      several
      

         standards that cover only some part of the requirements listed
      above,
      

         but even all together they do not cover all of the requirements
      for
      

         energy management.
      

      

      A.1.  Existing IETF Standards
      

      

         There are already RFCs available that address a subset of the
      

         requirements.
      

      

      A.1.1.  ENTITY MIB
      

      

         The ENTITY-MIB module defined in [RFC4133] was designed to
      model
      

         physical and logical entities of a managed system.  A physical
      entity
      

         is an identifiable physical component.  A logical entity can
      use one
      

         or more physical entities.  From an energy monitoring
      perspective of
      

         a managed system, the ENTITY-MIB modeling framework can be
      reused and
      

         whenever RFC 4133 [RFC4133] has been implemented.  The
      

         entPhysicalIndex from entPhysicalTable can be used to identify
      an
      

         entity/component.  However, there are use cases of energy
      monitoring,
      

         where the application of the ENTITY-MIB does not seem readily
      

         apparent and some of those entities could be beyond the
      original
      

         scope and intent of the ENTITY-MIB.
      

      

         Consider the case of remote devices attached to the network,
      and the
      

         network device could collect the energy measurement and report
      on
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 30]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         behalf of such attached devices.  Some of the remote devices
      such as
      

         PoE phones attached to a switch port have been considered in
      the
      

         Power-over-Ethernet MIB module [RFC3621].  However, there are
      many
      

         other devices such as a computer, which draw power from a wall
      outlet
      

         or building HVAC devices which seem to be beyond the original
      scope
      

         of the ENTITY-MIB.
      

      

         Yet another example, is smart-PDUs, which can report the energy
      

         consumption of the device attached to the power outlet of the
      PDU.
      

         In some cases, the device can be attached to multiple to power
      

         outlets.  Thus, the energy measured at multiple outlets need to
      be
      

         aggregated to determine the consumption of a single device. 
      From
      

         mapping perspective, between the PDU outlets and the device
      this is a
      

         many-to-one mapping.  It is not clear if such a many-to-one
      mapping
      

         is feasible within the ENTITY-MIB framework.
      

      

      A.1.2.  ENTITY STATE MIB
      

      

         RFC 4268 [RFC4268] defines the ENTITY STATE MIB module.
      

         Implementations of this module provide information on entities
      

         including the standby status (hotStandby, coldStandby,
      

         providingService), the operational status (disabled, enabled,
      

         testing), the alarm status (underRepair, critical, major,
      minor,
      

         warning), and the usage status (idle, active, busy).  This
      

         information is already useful as input for policy decisions and
      for
      

         other network management tasks.  However, the number of states
      would
      

         cover only a small subset of the requirements for power state
      

         monitoring and it does not provide means for energy consumption
      

         monitoring.  For associating the information conveyed by the
      ENTITY
      

         STATE MIB to specific components of a device, the ENTITY STATE
      MIB
      

         module makes use of the means provided by the ENTITY MIB module
      

         [RFC4133].  Particularly, it uses the entPhysicalIndex for
      

         identifying entities.
      

      

         The standby status provided by the ENTITY STATE MIB module is
      related
      

         to power states required for energy management, but the number
      of
      

         states is too restricted for meeting all energy management
      

         requirements.  For energy management several more power states
      are
      

         required, such as different sleep and operational states as
      defined
      

         by the Advanced Configuration and Power Interface (ACPI)
      [ACPI.R30b]
      

         or the DMTF Power State Management Profile [DMTF.DSP1027].
      

      

      A.1.3.  ENTITY SENSOR MIB
      

      

         RFC 3433 [RFC3433] defines the ENTITY SENSOR MIB module.
      

         Implementations of this module offer a generic way to provide
      data
      

         collected by a sensor.  A sensor could be an energy consumption
      meter
      

         delivering measured values in Watt.  This could be used for
      reporting
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 31]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         current power of an entity and its components.  Furthermore,
      the
      

         ENTITY SENSOR MIB can be used to retrieve the accuracy of the
      used
      

         power meter.
      

      

         Similar to the ENTITY STATE MIB module, the ENTITY SENSOR MIB
      module
      

         makes use of the means provided by the ENTITY MIB module
      [RFC4133]
      

         for relating provided information to components of a device.
      

      

         However, there is no unit available for reporting energy
      quantities,
      

         such as, for example, watt seconds or kilowatt hours, and the
      ENTITY
      

         SENSOR MIB module does not support reporting accuracy of
      measurements
      

         according to the IEC / ANSI accuracy classes, which are
      commonly in
      

         use for electric power and energy measurements.  The ENTITY
      SENSOR
      

         MIB modules only provides a coarse-grained method for
      indicating
      

         accuracy by stating the number of correct digits of fixed point
      

         values.
      

      

      A.1.4.  UPS MIB
      

      

         RFC 1628 [RFC1628] defines the UPS MIB module.  Implementations
      of
      

         this module provide information on the current real power of
      entities
      

         attached to an uninterruptible power supply (UPS) device.  This
      

         application would require identifying which entity is attached
      to
      

         which port of the UPS device.
      

      

         UPS MIB provides information on the state of the UPS network. 
      The
      

         MIB module contains several variables that are used to identify
      the
      

         UPS entity (name, model,..), the battery state, to characterize
      the
      

         input load to the UPS, to characterize the output from the UPS,
      to
      

         indicate the various alarm events.  The measurements of power
      in UPS
      

         MIB are in Volts, Amperes and Watts.  The units of power
      measurement
      

         are RMS volts, RMS Amperes and are not based on Entity-Sensor
      MIB
      

         [RFC3433].
      

      

      A.1.5.  POWER ETHERNET MIB
      

      

         Similar to the UPS MIB, implementations of the POWER ETHERNET
      MIB
      

         module defined in RFC3621 [RFC3621] provide information on the
      

         current energy consumption of the entities that receive Power
      over
      

         Ethernet (PoE).  This information can be retrieved at the power
      

         sourcing equipment.  Analogous to the UPS MIB, it is required
      to
      

         identify which entities are attached to which port of the power
      

         sourcing equipment.
      

      

         The POWER ETHERNET MIB does not report power and energy
      consumption
      

         on a per port basis, but can report aggregated values for
      groups of
      

         ports.  It does not use objects of the ENTITY MIB module for
      

         identifying entities, although this module existed already when
      the
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 32]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         POWER ETHERNET MIB modules was standardized.
      

      

      A.1.6.  LLDP MED MIB
      

      

         The Link Layer Discovery Protocol (LLDP) defined in IEEE
      802.1ab is a
      

         data link layer protocol used by network devices for
      advertising of
      

         their identities, capabilities, and interconnections on a LAN
      

         network.  The Media Endpoint Discovery (MED) (ANSI/TIA-1057) is
      an
      

         enhancement of LLDP known as LLDP-MED.  The LLDP-MED
      enhancements
      

         specifically address voice applications.  LLDP-MED covers 6
      basic
      

         areas: capabilities discovery, LAN speed and duplex discovery,
      

         network policy discovery, location identification discovery,
      

         inventory discovery, and power discovery.
      

      

      A.2.  Existing standards of other bodies
      

      

      A.2.1.  DMTF
      

      

         The DMTF has defined a power state management profile
      [DMTF.DSP1027]
      

         that is targeted at computer systems.  It is based on the
      DMTF's
      

         Common Information Model (CIM) and rather an entity profile
      than an
      

         actual energy consumption monitoring standard.
      

      

         The power state management profile is used to describe and to
      manage
      

         the power state of computer systems.  This includes e.g. means
      to
      

         change the power state of an entity (e.g. to shutdown the
      entity)
      

         which is an aspect of but not sufficient for active energy
      

         management.
      

      

      A.2.2.  OVDA
      

      

         ODVA is an association consisting of members from industrial
      

         automation companies.  ODVA supports standardization of network
      

         technologies based on the Common Industrial Protocol (CIP). 
      Within
      

         ODVA, there is a special interest group focused on energy and
      

         standardization and inter-operability of energy aware entities.
      

      

      A.2.3.  IEEE-ISTO Printer WG
      

      

         The charter of the IEEE-ISTO Printer Working Group is for open
      

         standards that define printer related protocols, that printer
      

         manufacturers and related software vendors shall benefit from
      the
      

         interoperability provided by conformance to these standards. 
      One
      

         particular aspect the Printer WG is focused on is power
      monitoring
      

         and management of network printers and imaging systems PWG
      Power
      

         Management Model for Imaging Systems [IEEE-ISTO].  Clearly,
      these
      

         devices are within the scope of energy management since these
      devices
      

         consume power and are attached to the network.  In addition,
      there is
      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 33]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         ample scope of power management since printers and imaging
      systems
      

         are not used that often.  IEEE-ISTO Printer working group has
      defined
      

         MIB modules for monitoring the power consumption and power
      state
      

         series that can be useful for power management of printers. 
      The
      

         energy management framework should also take into account the
      

         standards defined in the Printer working group.  In terms of
      other
      

         standards, IETF Printer MIB RFC3805 [RFC3805] has been
      standardized,
      

         however, this MIB module does not address power management of
      

         printers.
      

      

      

      Authors' Addresses
      

      

         Juergen Quittek (editor)
      

         NEC Europe Ltd.
      

         NEC Laboratories Europe
      

         Network Research Division
      

         Kurfuersten-Anlage 36
      

         Heidelberg  69115
      

         DE
      

      

         Phone: +49 6221 4342-115
      

         Email: quittek@neclab.eu
      

      

      

         Rolf Winter
      

         NEC Europe Ltd.
      

         NEC Laboratories Europe
      

         Network Research Division
      

         Kurfuersten-Anlage 36
      

         Heidelberg  69115
      

         DE
      

      

         Phone: +49 6221 4342-121
      

         Email: Rolf.Winter@neclab.eu
      

      

      

         Thomas Dietz
      

         NEC Europe Ltd.
      

         NEC Laboratories Europe
      

         Network Research Division
      

         Kurfuersten-Anlage 36
      

         Heidelberg  69115
      

         DE
      

      

         Phone: +49 6221 4342-128
      

         Email: Thomas.Dietz@neclab.eu
      

      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 34]
      

      
      

      Internet-Draft     Requirements for Energy Management         
      July 2011
      

      

      

         Benoit Claise
      

         Cisco Systems, Inc.
      

         De Kleetlaan 6a b1
      

         Degem  1831
      

         BE
      

      

         Phone: +32 2 704 5622
      

         Email: bclaise@cisco.com
      

      

      

         Mouli Chandramouli
      

         Cisco Systems, Inc.
      

         Sarjapur Outer Ring Road
      

         Bangalore,
      

         IN
      

      

         Phone: +91 80 4426 3947
      

         Email: moulchan@cisco.com
      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      

      Quittek, et al.         Expires January 12, 2012              
      [Page 35]
      

      
      

    

    

  


--------------080707000203080108030702--

From bclaise@cisco.com  Tue Jul 26 06:10:47 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAB221F8AF3 for ; Tue, 26 Jul 2011 06:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.476
X-Spam-Level: 
X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXOj7SdfYsRS for ; Tue, 26 Jul 2011 06:10:46 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1739721F889F for ; Tue, 26 Jul 2011 06:10:44 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6QD6aPR029295 for ; Tue, 26 Jul 2011 15:06:36 +0200 (CEST)
Received: from [10.82.236.31] (rtp-vpn5-1051.cisco.com [10.82.236.31]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6QD6VNk012490 for ; Tue, 26 Jul 2011 15:06:32 +0200 (CEST)
Message-ID: <4E2EBBD7.3020002@cisco.com>
Date: Tue, 26 Jul 2011 09:06:31 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: eman mailing list 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [eman] ISSUE #1 in EMAN: the terminology
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, 26 Jul 2011 13:10:47 -0000

Dear all,

Pretty happy that there are lively discussions on the list these days.
It seems that the number 1 issue in the group these days is the 
terminology, which is discussed in multiple email threads, based on the 
content of different drafts. So this is pretty difficult to comment on, 
and obviously to follow.

So I'm pretty happy that John Parello combined all the terminology in a 
single draft.
Can you please comment on this draft, trying to reach a consensus.

Regards, Benoit, co-chair hat on.



From bclaise@cisco.com  Tue Jul 26 06:17:39 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74B921F8AD6 for ; Tue, 26 Jul 2011 06:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.478
X-Spam-Level: 
X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUwQGn4nxfw3 for ; Tue, 26 Jul 2011 06:17:39 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 08B0321F8B26 for ; Tue, 26 Jul 2011 06:17:38 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6QDDoHC000407 for ; Tue, 26 Jul 2011 15:13:50 +0200 (CEST)
Received: from [10.82.236.31] (rtp-vpn5-1051.cisco.com [10.82.236.31]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6QDDnWu017491 for ; Tue, 26 Jul 2011 15:13:49 +0200 (CEST)
Message-ID: <4E2EBD8D.502@cisco.com>
Date: Tue, 26 Jul 2011 09:13:49 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: eman mailing list 
References: <4E2EBBD7.3020002@cisco.com>
In-Reply-To: <4E2EBBD7.3020002@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [eman] ISSUE #1 in EMAN: the terminology
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, 26 Jul 2011 13:17:39 -0000

And the draft is 
http://wwwin-eng.cisco.com/rfc/DRAFTS/draft-parello-eman-definitions-00.txt.

I should have some coffee before sending emails in the morning ;-)

Regards, Benoit.
> Dear all,
>
> Pretty happy that there are lively discussions on the list these days.
> It seems that the number 1 issue in the group these days is the 
> terminology, which is discussed in multiple email threads, based on 
> the content of different drafts. So this is pretty difficult to 
> comment on, and obviously to follow.
>
> So I'm pretty happy that John Parello combined all the terminology in 
> a single draft.
> Can you please comment on this draft, trying to reach a consensus.
>
> Regards, Benoit, co-chair hat on.
>
>


From Michael.Suchoff@raritan.com  Tue Jul 26 08:07:14 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE43D21F8BFE for ; Tue, 26 Jul 2011 08:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.724
X-Spam-Level: 
X-Spam-Status: No, score=-0.724 tagged_above=-999 required=5 tests=[AWL=1.874,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghuCNTjgYobk for ; Tue, 26 Jul 2011 08:07:11 -0700 (PDT)
Received: from fig.raritan.com (fig.raritan.com [12.144.63.197]) by ietfa.amsl.com (Postfix) with ESMTP id EACEC21F8BEB for ; Tue, 26 Jul 2011 08:07:10 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4BA5.ADA0934D"
Date: Tue, 26 Jul 2011 11:07:02 -0400
Message-ID: <9C329342B62B87498B92834DEC9FF51E0D5A0A7C@fig.raritan.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - open issue 12.3: time series of energy/power values
Thread-Index: AcxLQM7JM6tcIqDfRMKZ81T5ANSLYwAXeBUg
References:   <54ECD73F-B9A8-440F-970B-B9DD538CA186@quittek.at>  <4E2E2A61.6060503@cisco.com>
From: "Michael Suchoff" 
To: "Benoit Claise" 
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - open issue 12.3: time series of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 15:07:14 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4BA5.ADA0934D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Benoit,

=20

I've looked over section 5.5 of the EMAN MIB and it is not how existing
products I'm familiar with work.

=20

First, products that can accurately report energy (IEC 62053-21 energy
meters, smart PDUs that use special purpose energy measuring ICs, etc.)
do not derive energy by periodically polling a power measurement with a
pmEnergyParametersSampleRate.  In other words, energy in not derived
from the power measurement by multiplying by time (E =3D watts * time =
=3D
inaccurate energy measurement).  Rather, energy (E) is measured to the
product's certified IEC 62053-21 accuracy class and then the power
measurement is derived by dividing by time (power =3D dE/dt =3D energy /
time =3D accurate power measurement).

=20

Second, products that report time series report all measurements
(voltage, current, power, energy) and can report intermediate
measurements using traps when values exceeding thresholds or state
changes occur.

=20

Third, section 5.5 of MIB appears to be an attempt to have agent perform
programmable demand interval calculations.  This seems overly
complicated and places an unnecessary computational burden on the agent.
Existing products with time series simply report accurately time stamped
measurements.  The burden of computing demand interval (and other
analytics and what-ifs) is placed on the energy management program.

=20

=20

________________________________

From: Benoit Claise [mailto:bclaise@cisco.com]=20
Sent: Monday, July 25, 2011 10:46 PM
To: Michael Suchoff
Cc: Juergen Quittek; eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:
time series of energy/power values

=20

Dear Michael,

This is exactly what's available in the EMAN monitoring MIB for the
energy
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09,
section 5.5

Regards, Benoit



Dear Juergen,

The larger manufacturers of managed power distribution equipment (APC,
Eaton, Raritan...) all provide circular buffers of time stamped power
measurements.  Certification of our products for use with IBM System
Director required this as well.

The better products allow the polling interval to be specified and
provide ability for events (under currents, circuit breaker trips, etc.)
to be reported as traps.

Our larger data center customers wanted this feature too as they
realized polling thousands of devices minute by minute was inefficient
and can yield unacceptable timing uncertainty.

Our products are able to report accurate measurements - accuracy being
defined as how close do two or more devices agree with a calibrated
reference meter when measuring the same quantity.  This cannot be
achieved without considering time.

On Wed, Jul 13, 2011 at 8:52 AM, Juergen Quittek 
wrote:

Dear Mouli,

Thank you for commenting on this issue. I would like to have a look at
the following point of view:

So far, storing time series of measurements on managed nodes is rarely
standardized and rarely available as implementation.

Typically, it is the job of a network management system to collect time
series and store them.

Take for example byte and packet counters at line cards. You see many
curves showing time series of traffic rate/volume in the Internet, but
almost all of them were collected at management stations or data
collector modules, but not within MIB modules. (Please correct me if I'm
wrong.)

Now the question is: Is energy management so much different from other
network management tasks, that we need the rarely used mechanism of
storing time series in MIB modules?

If not, it would be sufficient to just report the number of total energy
consumed since the last re-start as you do it with packet and byte
counters.
This would be just a single managed object to be specified and
implemented.

Thanks,

   Juergen

Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):

> Regarding the Time Series debate - the crucial question - where is the
> data / measurements stored.
> It would not be possible for small devices to store such data for a
> sufficiently long time period.
>
> The NMS can store the values for a sufficiently long period of time,
for
> trending analysis.
>
> In the case of demand measurement, since the maximum over a window is
> computed, it is important for the device store atleast a window length
> of measurements.
>
> I am not sure about that Requirement 5.4.10 - Time Series of Power
> Values - to be stored in the device
>
> Thanks
> Mouli
>
>
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
Of
> Juergen Quittek
> Sent: Tuesday, July 12, 2011 2:31 PM
> To: eman mailing list
> Subject: [eman] new revision of eman requirements
>
> Dear all,
>
> I posted a new version of the eman requirements yesterday.
> Please find it at
> http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/
>
>
> Of course, feel free to also comment on the other open issues or to
> raise
> new ones. All such contributions are highly appreciated.
>
> Thanks,
>
>    Juergen
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman

_______________________________________________
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


------_=_NextPart_001_01CC4BA5.ADA0934D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















Benoit,
=



 



I’ve looked over section 5.5 =
of the
EMAN MIB and it is not how existing products I’m familiar with =
work.



 



First, products that can accurately =
report
energy (IEC 62053-21 energy meters, smart PDUs that use special purpose =
energy
measuring ICs, etc.) do not derive energy by periodically polling a =
power measurement
with a pmEnergyParametersSampleRate.  In other words, energy in not =
derived
from the power measurement by multiplying by time (E =3D watts * time =
=3D
inaccurate energy measurement).  Rather, energy (E) is measured to =
the
product’s certified IEC 62053-21 accuracy class and then the power
measurement is derived by dividing by time (power =3D dE/dt =3D energy / =
time =3D
accurate power measurement).



 



Second, products that report time =
series
report all measurements (voltage, current, power, energy) and can report =
intermediate
measurements using traps when values exceeding thresholds or state =
changes
occur.



 



Third, section 5.5 of MIB appears =
to be an
attempt to have agent perform programmable demand interval calculations. =
 This
seems overly complicated and places an unnecessary computational burden =
on the
agent.  Existing products with time series simply report accurately =
time stamped
measurements.  The burden of computing demand interval (and other
analytics and what-ifs) is placed on the energy management =
program.



 



 















From: Benoit Claise [mailto:bclaise@cisco.com] 

Sent: Monday, July 25, =
2011 10:46
PM

To: Michael Suchoff

Cc: Juergen Quittek; eman =
mailing
list

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






 



Dear Michael,



This is exactly what's available in the EMAN monitoring MIB for the =
energy

http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09,
section 5.5



Regards, Benoit







Dear =
Juergen,



The larger manufacturers of managed power distribution equipment (APC, =
Eaton,
Raritan...) all provide circular buffers of time stamped power
measurements.  Certification of our products for use with IBM =
System
Director required this as well.



The better products allow the polling interval to be specified and =
provide
ability for events (under currents, circuit breaker trips, etc.) to be =
reported
as traps.



Our larger data center customers wanted this feature too as they =
realized
polling thousands of devices minute by minute was inefficient and can =
yield
unacceptable timing uncertainty.



Our products are able to report accurate measurements - accuracy being =
defined
as how close do two or more devices agree with a calibrated reference =
meter
when measuring the same quantity.  This cannot be achieved without
considering time.






On Wed, Jul 13, 2011 at 8:52 AM, Juergen =
Quittek <ietf@quittek.at>
wrote:



Dear Mouli,



Thank you for commenting on this issue. I would like to have a look at =
the
following point of view:



So far, storing time series of measurements on managed nodes is rarely
standardized and rarely available as implementation.



Typically, it is the job of a network management system to collect time =
series
and store them.



Take for example byte and packet counters at line cards. You see many =
curves
showing time series of traffic rate/volume in the Internet, but almost =
all of
them were collected at management stations or data collector modules, =
but not
within MIB modules. (Please correct me if I'm wrong.)



Now the question is: Is energy management so much different from other =
network
management tasks, that we need the rarely used mechanism of storing time =
series
in MIB modules?



If not, it would be sufficient to just report the number of total energy
consumed since the last re-start as you do it with packet and byte =
counters.

This would be just a single managed object to be specified and =
implemented.



Thanks,



   Juergen



Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):



> Regarding the Time Series debate - the crucial question - where is =
the

> data / measurements stored.

> It would not be possible for small devices to store such data for =
a

> sufficiently long time period.

>

> The NMS can store the values for a sufficiently long period of =
time, for

> trending analysis.

>

> In the case of demand measurement, since the maximum over a window =
is

> computed, it is important for the device store atleast a window =
length

> of measurements.

>

> I am not sure about that Requirement 5.4.10 - Time Series of =
Power

> Values - to be stored in the device

>

> Thanks

> Mouli

>

>

> -----Original Message-----

> From: eman-bounces@ietf.org
[mailto:eman-bounces@ietf.org]
On Behalf Of

> Juergen Quittek

> Sent: Tuesday, July 12, 2011 2:31 PM

> To: eman mailing list

> Subject: [eman] new revision of eman requirements

>

> Dear all,

>

> I posted a new version of the eman requirements yesterday.

> Please find it at

> http://datatracker.ietf.org/doc/draft-ietf-eman-re=
quirements/

>

>

> Of course, feel free to also comment on the other open issues or =
to

> raise

> new ones. All such contributions are highly appreciated.

>

> Thanks,

>

>    Juergen

>

> _______________________________________________

> eman mailing list

> eman@ietf.org

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

> _______________________________________________

> eman mailing list

> eman@ietf.org

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



_______________________________________________

eman mailing list

eman@ietf.org

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


















______________________________________________=
_
eman mailing =
list
eman@ietf.org<=
/pre>
https://www.ietf.org/=
mailman/listinfo/eman



 









------_=_NextPart_001_01CC4BA5.ADA0934D--

From Michael.Suchoff@raritan.com  Tue Jul 26 08:53:17 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE1811E810E for ; Tue, 26 Jul 2011 08:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level: 
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=1.500,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxXXY5EVVfIG for ; Tue, 26 Jul 2011 08:53:17 -0700 (PDT)
Received: from fig.raritan.com (fig.raritan.com [12.144.63.197]) by ietfa.amsl.com (Postfix) with ESMTP id F161A11E80D8 for ; Tue, 26 Jul 2011 08:53:16 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Jul 2011 11:53:14 -0400
Message-ID: <9C329342B62B87498B92834DEC9FF51E0D5A0B5F@fig.raritan.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - open issue12.3:	time series of energy/power values
Thread-Index: AcxBW8xadqm3PibEROGblU7yKwdZJAJpnMqwACmki7A=
References: <54ECD73F-B9A8-440F-970B-B9DD538CA186@quittek.at> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D8A1@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
From: "Michael Suchoff" 
To: "Mielke, William F \(Bill\)" , "eman mailing list" 
Subject: Re: [eman] new revision of eman requirements - open issue12.3:	time series of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 15:53:18 -0000

Bill,

I agree with you.  Our Smart PDUs (as well as Eaton's and APC's) use
fixed size circular buffers to store measurements.  Circular buffers
work with the limited memory space of embedded devices as well as the
limitations of SNMP tables.  An SNMP variable is available which
indicates index of most recent write into buffer.  By keeping track of
this variable, a manager can determine how many new entries have been
written into the buffer since the last poll and the new entries can
efficiently be retrieved using get-bulk.

Our present buffer size is 120 and the typical measurement interval is 1
minute.  Values for each measurement include the min, max and average
value that occurred during the measurement interval.=20

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Mielke, William F (Bill)
Sent: Monday, July 25, 2011 4:02 PM
To: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue12.3:
time series of energy/power values

I believe that it is very important for devices to maintain and report a
(limited amount of) time series data for the energy and power related
values.  This is needed to reasonably support a pull model for such
information.  An NMS cannot poll individual devices with sufficiently
accurate timing to collect and maintain this information on its own.
This is especially true as the NMS tries to scale up to a large number
of devices and when the communications between the NMS and the device is
subject to congestion and outages.

I think that the primary issue at play here is that the desired
measurement interval (1 sec up to 1 min?) is likely shorter than the
typical NMS polling interval (1 min up to 1 day?).  So the collection of
the time series data must be delegated to the device and it must be
retained there for a sufficiently long time that the NMS can be
reasonably expected to be able to collect it on its next polling
interval.

I believe that existing devices such as Smart PDUs already collect and
maintain time series measurements and retain them in just this manner
and for just this purpose.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

=20

> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20
> Behalf Of Juergen Quittek
> Sent: Wednesday, July 13, 2011 8:53 AM
> To: Mouli Chandramouli (moulchan)
> Cc: eman mailing list
> Subject: Re: [eman] new revision of eman requirements - open=20
> issue 12.3: time series of energy/power values
>=20
> Dear Mouli,
>=20
> Thank you for commenting on this issue. I would like to have=20
> a look at the following point of view:
>=20
> So far, storing time series of measurements on managed nodes=20
> is rarely standardized and rarely available as implementation.
>=20
> Typically, it is the job of a network management system to=20
> collect time series and store them.
>=20
> Take for example byte and packet counters at line cards. You=20
> see many curves showing time series of traffic rate/volume in=20
> the Internet, but almost all of them were collected at=20
> management stations or data collector modules, but not within=20
> MIB modules. (Please correct me if I'm wrong.)=20
>=20
> Now the question is: Is energy management so much different=20
> from other network management tasks, that we need the rarely=20
> used mechanism of storing time series in MIB modules?
>=20
> If not, it would be sufficient to just report the number of=20
> total energy consumed since the last re-start as you do it=20
> with packet and byte counters.
> This would be just a single managed object to be specified=20
> and implemented.
>=20
> Thanks,
>=20
>     Juergen
>=20
> Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):
>=20
> > Regarding the Time Series debate - the crucial question -=20
> where is the
> > data / measurements stored.=20
> > It would not be possible for small devices to store such data for a
> > sufficiently long time period.=20
> >=20
> > The NMS can store the values for a sufficiently long period=20
> of time, for
> > trending analysis.=20
> >=20
> > In the case of demand measurement, since the maximum over a=20
> window is
> > computed, it is important for the device store atleast a=20
> window length
> > of measurements.=20
> >=20
> > I am not sure about that Requirement 5.4.10 - Time Series of Power
> > Values - to be stored in the device
> >=20
> > Thanks
> > Mouli
> >=20
> >=20
> > -----Original Message-----
> > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org]=20
> On Behalf Of
> > Juergen Quittek
> > Sent: Tuesday, July 12, 2011 2:31 PM
> > To: eman mailing list
> > Subject: [eman] new revision of eman requirements
> >=20
> > Dear all,
> >=20
> > I posted a new version of the eman requirements yesterday.
> > Please find it at=20
> > http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/
> >=20
> >=20
> > Of course, feel free to also comment on the other open issues or to
> > raise
> > new ones. All such contributions are highly appreciated.
> >=20
> > Thanks,
> >=20
> >    Juergen
> >=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
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>=20
_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman

From ietf@quittek.at  Tue Jul 26 09:00:04 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40FD11E8108 for ; Tue, 26 Jul 2011 09:00:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 g18sMIiK7nfy for ; Tue, 26 Jul 2011 09:00:03 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id E097911E80C9 for ; Tue, 26 Jul 2011 09:00:02 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MOVST-1QpKXr2vLh-005lM1; Tue, 26 Jul 2011 18:00:00 +0200
References: <0131AC21C657A3418A5B6CA168C4C57E0A813EA6@USA7061MS04.na.xerox.net> <23E19EBD-1A1E-47AB-BA8F-47B8E919A2DE@quittek.at> <4E2C7E87.6060505@cisco.com>  <4E2CF747.6000800@cisco.com> <0ECE79A2-F1F9-41B1-92B6-804AD65E823F@quittek.at> <4E2E1D14.5040109@cisco.com>
In-Reply-To: <4E2E1D14.5040109@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-10-528832084
Message-Id: <09AD2D2D-E58A-44F3-A240-EAE0CA87496A@quittek.at>
From: Juergen Quittek 
Date: Tue, 26 Jul 2011 11:59:57 -0400
To: Benoit Claise 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:KXxkoXt2nDzIDsTatJQ4IUzDhWaNqVoTwMcc2DFohh4 JVgemWbnrb3qgrvrtrP66Rmm1QgG78ztv0zRdvF6TdVaoAEdVt osdsYXOPUmAa0oARPbzo/C0L17Bz8YeJjY78REtnE1bwdQzxTY 75Ebb4ODx3kPXIp1KMTZohggOgpN0I6YOlGsg0E/bCWKTCOBg3 pp5QG2nS0s8Bcz4geDwzzih9/9otDUnemEvP2IB+wc=
Cc: eman@ietf.org, "Ebner, Fritz" 
Subject: Re: [eman] IETF EMAN request to address printers... -> draft-ietf-eman-requirements-04
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 16:00:05 -0000

--Apple-Mail-10-528832084
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Benoit,

That is a question of the scope of the requirements draft.

Definitely the requirements draft should state requirements.

But should it also discuss how to meet them?
That's typically the task of a solution/framework/architecture draft.

If we have a requirement to use another standards it should be in the =
requirements draft
If we have a requirement NOT to use another standard, it should be in as =
well.
But so far we have not stated any requirement on other standards.

    Juergen


Am 25.07.2011 um 21:49 schrieb Benoit Claise:

> Hi Juergen,
>=20
> Keep in mind that we need a place to describe why what exists today is =
not good enough for our requirements
> For example, the ENTITY-SENSOR MIB.
> I believe the right place is the requirement draft.
>=20
> Regards, Benoit.
>> Hi Benoit,
>>=20
>> I think the entire Appendix can go away.=20
>> It does not contribute at all to the requirements. At least not so =
far.
>>=20
>> Analyzing what standard is available to meet a requirement=20
>> is rather the task of a solution draft, such as the framework=20
>> or the MIB modules, but not of a requirement draft.
>>=20
>> My proposal would be moving the standards analysis to the framework
>> and discuss there also=20
>>   - which of these standards are used for covering requirements, for =
example,=20
>>     Entity MIB for identification (if we do so)
>>   - which parts of these standards are supported, such as, for =
example,
>>     ACPI and DMTF power sets
>>   - to which standards our work is aligned, for example=20
>>     ODVA, IEEE-ISTO PWD, SBS, etc. and how we do so.
>>   - from which standards we deviate
>>=20
>> Thanks,
>>=20
>>     Juergen
>>=20
>> Am 25.07.2011 um 00:55 schrieb Benoit Claise:
>>=20
>>> Hi Juergen,
>>>=20
>>> So why is there an "IEEE-ISTO Printer WG" appendix if printers are =
not mentioned a single time in the document?
>>>=20
>>> Regards, Benoit.
>>>>=20
>>>> Hi Benoit,
>>>>=20
>>>> Currently, there is the following paragraph in section 1 of =
draft-ietf-eman-requirements-04:
>>>>=20
>>>> >   The main subject of energy management are powered entities that
>>>> >   consume electric energy.  Powered entities include devices that =
have
>>>> >   an IP address and can be addressed directly, such as hosts, =
routers,
>>>> >   and middleboxes, as well as devices indirectly connected to an =
IP
>>>> >   network, for which a proxy with an IP address provides a =
management
>>>> >   interface, for example, devices in a building management
>>>> >   infrastructure using BACNET or MODBUS protocols.
>>>>=20
>>>> You see that we already address all kinds of IP devices: hosts, =
routers, and middleboxes.
>>>> There is no list of special hosts, such as servers, PCs, smart =
phones, printers, webcams, etc.=20
>>>> I do not see a need to introduce it. Since a printer is a device =
that can either be directly addressed with IP or that can be addressed =
via a host connected to it, I see no need to add a special comment on =
it, particularly not since I do not see any special requirements for a =
printer compared to other hosts.
>>>>=20
>>>> Rather I see a need in the framework draft to discuss if and how =
alignment with the IEEE ISTO-PWG is realized.
>>>>=20
>>>> Thanks,
>>>>=20
>>>>     Juergen
>>>>=20
>>>>=20
>>>> Am 24.07.2011 um 16:20 schrieb Benoit Claise:
>>>>=20
>>>>> Juergen,
>>>>>=20
>>>>> Reading this old email, I believe that we should mention "printer" =
somewhere in the requirements draft, as a device type addressed by the =
EMAN WG, and not only in the appendix.
>>>>>=20
>>>>> Regards, Benoit.
>>>>>> Hi Fritz,
>>>>>>=20
>>>>>> Thank you for your input.
>>>>>>=20
>>>>>> We will consider printers and the document your referred to in =
the next revision of the requirements.
>>>>>> I don't think many changes will need to be made here.
>>>>>>=20
>>>>>> But for the MIB documents, we now have another set of PWG =
power/functional states next to DMTF and ACPI states.
>>>>>>=20
>>>>>> Thanks,
>>>>>>=20
>>>>>>     Juergen
>>>>>>=20
>>>>>>=20
>>>>>> Am 18.03.2011 um 19:11 schrieb Ebner, Fritz:
>>>>>>=20
>>>>>>> Hello,
>>>>>>> Please make sure that any power control or monitoring MIBs or =
drafts that the EMAN WG produces can cover the use cases, power =
controls, and power monitoring features provided in the printer working =
group.  Details are below:
>>>>>>> =20
>>>>>>> The IEEE/ISTO Printer Working Group has published their =
Candidate Standard for Power                                     =
Management and the associate protocol binding for SNMP.  Below are the =
links to the abstract model and MIB.
>>>>>>> =20
>>>>>>> PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0:
>>>>>>> =20
>>>>>>> The PWG Power Management Model for Imaging Systems 1.0 =
specification was=20
>>>>>>> recently approved as a PWG Candidate Standard and is now =
available at:
>>>>>>>=20
>>>>>>>  http://www.pwg.org/standards.html
>>>>>>>=20
>>>>>>> and
>>>>>>>=20
>>>>>>>  =
ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf =
/ doc
>>>>>>> =20
>>>>>>> PWG 5106-5 - PWG Imaging System Power MIB v1.0
>>>>>>> =20
>>>>>>> The PWG Imaging System Power MIB v1.0 specification was recently =
approved
>>>>>>> as a PWG Candidate Standard and is now available at:
>>>>>>>=20
>>>>>>>  http://www.pwg.org/standards.html
>>>>>>>=20
>>>>>>> and
>>>>>>>=20
>>>>>>>  =
ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf=
 /                                       doc / mib
>>>>>>>  - PDF, MS Word, and ASN.1 source in plaintext
>>>>>>>=20
>>>>>>>  =
ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib=
.pdf
>>>>>>>  - ASN.1 source in color highlighted PDF
>>>>>>> =20
>>>>>>> Thanks,
>>>>>>> Fritz Ebner
>>>>>>> _______________________________________________
>>>>>>> eman mailing list
>>>>>>> eman@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> eman mailing list
>>>>>> eman@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20


--Apple-Mail-10-528832084
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

Hi Benoit,

That is a question of the scope of the requirements draft.

Definitely the requirements draft should state requirements.

But should it also discuss how to meet them?
That's typically the task of a solution/framework/architecture draft.

If we have a requirement to use another standards it should be in the requirements draft
If we have a requirement NOT to use another standard, it should be in as well.
But so far we have not stated any requirement on other standards.

    Juergen


Am 25.07.2011 um 21:49 schrieb Benoit Claise:


  
    
  
  

    Hi Juergen,

    

    Keep in mind that we need a place to describe why what exists today
    is not good enough for our requirements

    For example, the ENTITY-SENSOR MIB.

    I believe the right place is the requirement draft.

    

    Regards, Benoit.

    
Hi Benoit,
      


      

      
I think the entire Appendix can go away. 

      
It does not contribute at all to the requirements. At least
        not so far.

      


      

      
Analyzing what standard is available to meet a requirement 

      
is rather the task of a solution draft, such as the
        framework 

      
or the MIB modules, but not of a requirement draft.

      


      

      
My proposal would be moving the standards analysis to the
        framework

      
and discuss there also 

      
  - which of these standards are used for covering
        requirements, for example, 

      
    Entity MIB for identification (if we do so)

      
  - which parts of these standards are supported, such as,
        for example,

      
    ACPI and DMTF power sets

      
  - to which standards our work is aligned, for example 

      
    ODVA, IEEE-ISTO PWD, SBS, etc. and how we do so.

      

        

          
  - from which standards we deviate

          


          

          
Thanks,

          


          

          
    Juergen

          


          

          
Am 25.07.2011 um 00:55 schrieb Benoit Claise:

          

          

            
            
 Hi Juergen,

              

              So why is there an "IEEE-ISTO Printer WG" appendix if
              printers are not mentioned a single time in the document?

              

              Regards, Benoit.
              

                
Hi Benoit,

                


                

                
Currently, there is the following paragraph in
                  section 1 of draft-ietf-eman-requirements-04:

                


                

                

                  
>   The main subject of energy management are
                    powered entities that

                  
>   consume electric energy.  Powered entities
                    include devices that have

                  
>   an IP address and can be addressed
                    directly, such as hosts, routers,

                  
>   and middleboxes, as well as devices
                    indirectly connected to an IP

                  
>   network, for which a proxy with an IP
                    address provides a management

                  
>   interface, for example, devices in a
                    building management

                  
>   infrastructure using BACNET or MODBUS
                    protocols.

                

                


                

                
You see that we already address all kinds of IP
                  devices: hosts, routers, and middleboxes.

                
There is no list of special hosts, such as servers,
                  PCs, smart phones, printers, webcams, etc. 

                
I do not see a need to introduce it. Since a
                  printer is a device that can either be directly
                  addressed with IP or that can be addressed via a host
                  connected to it, I see no need to add a special
                  comment on it, particularly not since I do not see any
                  special requirements for a printer compared to other
                  hosts.

                


                

                
Rather I see a need in the framework draft to
                  discuss if and how alignment with the IEEE ISTO-PWG is
                  realized.

                


                

                
Thanks,

                


                

                
    Juergen

                


                

                


                

                

                  
Am 24.07.2011 um 16:20 schrieb Benoit Claise:

                  

                  

                    
                    
 Juergen,

                      

                      Reading this old email, I believe that we should
                      mention "printer" somewhere in the requirements
                      draft, as a device type addressed by the EMAN WG,
                      and not only in the appendix.

                      

                      Regards, Benoit.

                      
Hi Fritz,
                        


                        

                        
Thank you for your input.

                        


                        

                        
We will consider printers and the document
                          your referred to in the next revision of the
                          requirements.

                        
I don't think many changes will need to be
                          made here.

                        


                        

                        
But for the MIB documents, we now have
                          another set of PWG power/functional states
                          next to DMTF and ACPI states.

                        


                        

                        
Thanks,

                        


                        

                        
    Juergen

                        


                        

                        


                          

                            
Am 18.03.2011 um 19:11 schrieb Ebner,
                              Fritz:

                            

                            

                              

                                

                                  
Hello,

                                  
Please make
                                    sure that any power control or
                                    monitoring MIBs or drafts that the
                                    EMAN WG produces can cover the use
                                    cases, power controls, and power
                                    monitoring features provided in the
                                    printer working group.  Details are
                                    below:

                                  
 

                                  
The IEEE/ISTO
                                    Printer Working Group has published
                                    their Candidate Standard for Power
                                    Management and the associate
                                    protocol binding for SNMP.  Below
                                    are the links to the abstract model
                                    and MIB.

                                  

                                    
 

                                  

                                  
PWG
                                      5106.4 - PWG Power Management
                                      Model for Imaging Systems 1.0:

                                  
 

                                  

                                    
The PWG Power
                                      Management Model for Imaging
                                      Systems 1.0 specification was 

                                      recently approved as a PWG Candidate Standard and

                                      is now available at:

                                      

                                       http://www.pwg.org/standards.html

                                      

                                      and

                                      

                                       ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf /
                                      doc

                                    
 

                                  

                                  
PWG
                                      5106-5 - PWG Imaging System Power
                                      MIB v1.0

                                  
 

                                  

                                    
The PWG
                                      Imaging System Power MIB v1.0
                                      specification was recently
                                      approved

                                      as a PWG Candidate Standard and

                                      is now available at:

                                      

                                       http://www.pwg.org/standards.html

                                      

                                      and

                                      

                                       ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf /
                                      doc / mib

                                       - PDF, MS Word, and ASN.1 source
                                      in plaintext

                                      

                                       ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.pdf

                                       - ASN.1 source in color
                                      highlighted PDF

                                  

                                  
 

                                  
Thanks,

                                  
Fritz Ebner

                                

_______________________________________________

                                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


                      

                      

                    

                  

                

                

              

              

            

          

        

        

      

    

    

  





--Apple-Mail-10-528832084--

From ietf@quittek.at  Tue Jul 26 09:31:55 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FF921F8BCC for ; Tue, 26 Jul 2011 09:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 xfTVXh3nBlvl for ; Tue, 26 Jul 2011 09:31:55 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9C52D21F89CC for ; Tue, 26 Jul 2011 09:31:54 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0Ltyl8-1RRrEk1uP0-011UoW; Tue, 26 Jul 2011 18:31:53 +0200
References:   <54ECD73F-B9A8-440F-970B-B9DD538CA186@quittek.at>  <4E2E2A61.6060503@cisco.com>
In-Reply-To: <4E2E2A61.6060503@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-11-530745944
Message-Id: 
From: Juergen Quittek 
Date: Tue, 26 Jul 2011 12:31:51 -0400
To: Benoit Claise 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:F/LSS3xwkAxiEYtc1D0yxXdHYH48OJlrDh+rK8qBrsF ZeytasZ2bQGKm7rUxVxbLYhfD5Ar8ZFfk8ui3BQQcFlViNKf/u nN0XgHY5mcX+lZ7VTvWGI464s2NUcZyUuKhMhC6M7amA6zBXmG FiUkEmGH/jogUyCGJGh3CdoR2q6Pblj39lu44pi1ak1TpI7QmE pt/TCktPj6Q3/Mo+vXTBCl116npmiR1SHmQZABQM3A=
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - open issue 12.3: time series of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 16:31:55 -0000

--Apple-Mail-11-530745944
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Dear all,

I think we are all in line with the statements made on the mailing list.

However, so far we haven't addressed the open issue as stated in the =
requirements draft:

> 12.3.  Power and energy time series?
>=20
>    We have requirements for reporting of time series of power and =
energy
>    values.  Do we need both or just one of them?  If just one, then
>    which one?
Requirement 5.4.10 asks for time series of power values and requirement =
5.5.4 asks for time series of energy values. Do we need both of them?

A second question would be: Do we need them to be exported by SNMP or =
rather by IPFIX or by both?

    Juergen



Am 25.07.2011 um 22:45 schrieb Benoit Claise:

> Dear Michael,
>=20
> This is exactly what's available in the EMAN monitoring MIB for the =
energy
> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09, =
section 5.5
>=20
> Regards, Benoit
>> Dear Juergen,
>>=20
>> The larger manufacturers of managed power distribution equipment =
(APC, Eaton, Raritan...) all provide circular buffers of time stamped =
power measurements.  Certification of our products for use with IBM =
System Director required this as well.
>>=20
>> The better products allow the polling interval to be specified and =
provide ability for events (under currents, circuit breaker trips, etc.) =
to be reported as traps.
>>=20
>> Our larger data center customers wanted this feature too as they =
realized polling thousands of devices minute by minute was inefficient =
and can yield unacceptable timing uncertainty.
>>=20
>> Our products are able to report accurate measurements - accuracy =
being defined as how close do two or more devices agree with a =
calibrated reference meter when measuring the same quantity.  This =
cannot be achieved without considering time.
>>=20
>> On Wed, Jul 13, 2011 at 8:52 AM, Juergen Quittek  =
wrote:
>> Dear Mouli,
>>=20
>> Thank you for commenting on this issue. I would like to have a look =
at the following point of view:
>>=20
>> So far, storing time series of measurements on managed nodes is =
rarely standardized and rarely available as implementation.
>>=20
>> Typically, it is the job of a network management system to collect =
time series and store them.
>>=20
>> Take for example byte and packet counters at line cards. You see many =
curves showing time series of traffic rate/volume in the Internet, but =
almost all of them were collected at management stations or data =
collector modules, but not within MIB modules. (Please correct me if I'm =
wrong.)
>>=20
>> Now the question is: Is energy management so much different from =
other network management tasks, that we need the rarely used mechanism =
of storing time series in MIB modules?
>>=20
>> If not, it would be sufficient to just report the number of total =
energy consumed since the last re-start as you do it with packet and =
byte counters.
>> This would be just a single managed object to be specified and =
implemented.
>>=20
>> Thanks,
>>=20
>>    Juergen
>>=20
>> Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):
>>=20
>> > Regarding the Time Series debate - the crucial question - where is =
the
>> > data / measurements stored.
>> > It would not be possible for small devices to store such data for a
>> > sufficiently long time period.
>> >
>> > The NMS can store the values for a sufficiently long period of =
time, for
>> > trending analysis.
>> >
>> > In the case of demand measurement, since the maximum over a window =
is
>> > computed, it is important for the device store atleast a window =
length
>> > of measurements.
>> >
>> > I am not sure about that Requirement 5.4.10 - Time Series of Power
>> > Values - to be stored in the device
>> >
>> > Thanks
>> > Mouli
>> >
>> >
>> > -----Original Message-----
>> > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On =
Behalf Of
>> > Juergen Quittek
>> > Sent: Tuesday, July 12, 2011 2:31 PM
>> > To: eman mailing list
>> > Subject: [eman] new revision of eman requirements
>> >
>> > Dear all,
>> >
>> > I posted a new version of the eman requirements yesterday.
>> > Please find it at
>> > http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/
>> >
>> >
>> > Of course, feel free to also comment on the other open issues or to
>> > raise
>> > new ones. All such contributions are highly appreciated.
>> >
>> > Thanks,
>> >
>> >    Juergen
>> >
>> > _______________________________________________
>> > eman mailing list
>> > eman@ietf.org
>> > https://www.ietf.org/mailman/listinfo/eman
>> > _______________________________________________
>> > eman mailing list
>> > eman@ietf.org
>> > https://www.ietf.org/mailman/listinfo/eman
>>=20
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>>=20
>>=20
>>=20
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>=20


--Apple-Mail-11-530745944
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

Dear all,

I think we are all in line with the statements made on the mailing list.

However, so far we haven't addressed the open issue as stated in the requirements draft:

> 12.3.  Power and energy time series?
> 
>    We have requirements for reporting of time series of power and energy
>    values.  Do we need both or just one of them?  If just one, then
>    which one?

Requirement 5.4.10 asks for time series of power values and requirement 5.5.4 asks for time series of energy values. Do we need both of them?

A second question would be: Do we need them to be exported by SNMP or rather by IPFIX or by both?

    Juergen



Am 25.07.2011 um 22:45 schrieb Benoit Claise:


  
    
  
  

    Dear Michael,

    

    This is exactly what's available in the EMAN monitoring MIB for the
    energy

    http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09,
    section 5.5

    

    Regards, Benoit

    
Dear Juergen,

      

      The larger manufacturers of managed power distribution equipment
      (APC, Eaton, Raritan...) all provide circular buffers of time
      stamped power measurements.  Certification of our products for use
      with IBM System Director required this as well.

      

      The better products allow the polling interval to be specified and
      provide ability for events (under currents, circuit breaker trips,
      etc.) to be reported as traps.

      

      Our larger data center customers wanted this feature too as they
      realized polling thousands of devices minute by minute was
      inefficient and can yield unacceptable timing uncertainty.

      

      Our products are able to report accurate measurements - accuracy
      being defined as how close do two or more devices agree with a
      calibrated reference meter when measuring the same quantity.  This
      cannot be achieved without considering time.

      

      
On Wed, Jul 13, 2011 at 8:52 AM, Juergen
        Quittek <ietf@quittek.at>
        wrote:

        

          Dear Mouli,

          

          Thank you for commenting on this issue. I would like to have a
          look at the following point of view:

          

          So far, storing time series of measurements on managed nodes
          is rarely standardized and rarely available as implementation.

          

          Typically, it is the job of a network management system to
          collect time series and store them.

          

          Take for example byte and packet counters at line cards. You
          see many curves showing time series of traffic rate/volume in
          the Internet, but almost all of them were collected at
          management stations or data collector modules, but not within
          MIB modules. (Please correct me if I'm wrong.)

          

          Now the question is: Is energy management so much different
          from other network management tasks, that we need the rarely
          used mechanism of storing time series in MIB modules?

          

          If not, it would be sufficient to just report the number of
          total energy consumed since the last re-start as you do it
          with packet and byte counters.

          This would be just a single managed object to be specified and
          implemented.

          

          Thanks,

          

             Juergen

          

          Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):

          

          > Regarding the Time Series debate - the crucial question -
          where is the

          > data / measurements stored.

          > It would not be possible for small devices to store such
          data for a

          > sufficiently long time period.

          >

          > The NMS can store the values for a sufficiently long
          period of time, for

          > trending analysis.

          >

          > In the case of demand measurement, since the maximum over
          a window is

          > computed, it is important for the device store atleast a
          window length

          > of measurements.

          >

          > I am not sure about that Requirement 5.4.10 - Time Series
          of Power

          > Values - to be stored in the device

          >

          > Thanks

          > Mouli

          >

          >

          > -----Original Message-----

          > From: eman-bounces@ietf.org
          [mailto:eman-bounces@ietf.org]
          On Behalf Of

          > Juergen Quittek

          > Sent: Tuesday, July 12, 2011 2:31 PM

          > To: eman mailing list

          > Subject: [eman] new revision of eman requirements

          >

          > Dear all,

          >

          > I posted a new version of the eman requirements
          yesterday.

          > Please find it at

          > http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/

          >

          >

          > Of course, feel free to also comment on the other open
          issues or to

          > raise

          > new ones. All such contributions are highly appreciated.

          >

          > Thanks,

          >

          >    Juergen

          >

          > _______________________________________________

          > eman mailing list

          > eman@ietf.org

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

          > _______________________________________________

          > eman mailing list

          > eman@ietf.org

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

          

          _______________________________________________

          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


    

    

  





--Apple-Mail-11-530745944--

From jparello@cisco.com  Tue Jul 26 09:35:33 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A78C21F8BF3 for ; Tue, 26 Jul 2011 09:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.813
X-Spam-Level: 
X-Spam-Status: No, score=-6.813 tagged_above=-999 required=5 tests=[AWL=3.785,  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 d6lc-YcXoHdm for ; Tue, 26 Jul 2011 09:35:32 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B060521F8BF2 for ; Tue, 26 Jul 2011 09:35:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=5174; q=dns/txt; s=iport; t=1311698131; x=1312907731; h=mime-version:subject:date:message-id:references:from:to; bh=kxN3+RFVa1RCQoRiCEDjo6+UN0d72+7tRw5ZFRNNAHg=; b=equ0wFfcefv0OXlm0MG0uyQHBQLvP5Zc4QD56yAH4NWiIqepPpVusxfH EkSpnKA56zLyD5ZywSvT6qTXmq4Nk1Q4G+lIM+MpHUpJeH8pqt/n4hvJ4 B6DGQsy2iXZ/cCeIXgm+ieyeN9rcP0+BSpPG2TVh+0Xyfmer36W66vXzN Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AukFAGLsLk6Q/khL/2dsb2JhbAA2AQEBAQMBAQERAQwSA0QXBQIBCQQNBAEBCwYkBgETGDEIAQEFARYMG58AASeIBneJAKMdnmaFYV8EhygvkCuLcA
X-IronPort-AV: E=Sophos;i="4.67,270,1309737600";  d="scan'208,217";a="104397478"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 26 Jul 2011 16:35:29 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6QGZ9IW023099 for ; Tue, 26 Jul 2011 16:35:29 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 26 Jul 2011 09:34:54 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4BB1.F2BAF00B"
Date: Tue, 26 Jul 2011 09:31:04 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] ISSUE #1 in EMAN: the terminology
Thread-Index: AcxLlmggHAWdUGwdRpuC4sVy6J1fcAAGwGIf
References: <4E2EBBD7.3020002@cisco.com> <4E2EBD8D.502@cisco.com>
From: "John Parello (jparello)" 
To: "Benoit Claise (bclaise)" , "eman mailing list" 
X-OriginalArrivalTime: 26 Jul 2011 16:34:54.0486 (UTC) FILETIME=[F2FCF360:01CC4BB1]
Subject: Re: [eman] ISSUE #1 in EMAN: the terminology
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, 26 Jul 2011 16:35:33 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4BB1.F2BAF00B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

The previous link is a cached link. Here's the link in our WG area.

http://tools.ietf.org/id/draft-parello-eman-definitions-00.txt

The draft is very much a WIP. What I'd like to accomplish is to have one =
area where we can collect and define terms with references. That will =
avoid us paraphrasing or inventing terms which I confess is very easy to =
do :)

Also since we have some 4-5 drafts it's a lot easier to defined a =
grammar in one place and discuss the terms outside the context of each =
draft.

We discussed this on the list in a few thread back in March. It seemed =
time to get a glossary going.

It is by no means considered complete or final. It's a place holder =
where we can all work and I'll help to collect terms etc.

Thanks so much and looking forward to getting many comments and new =
definitions!
Jp



-----Original Message-----
From: eman-bounces@ietf.org on behalf of Benoit Claise (bclaise)
Sent: Tue 7/26/2011 6:13 AM
To: eman mailing list
Subject: Re: [eman] ISSUE #1 in EMAN: the terminology
=20
And the draft is=20
http://wwwin-eng.cisco.com/rfc/DRAFTS/draft-parello-eman-definitions-00.t=
xt.

I should have some coffee before sending emails in the morning ;-)

Regards, Benoit.
> Dear all,
>
> Pretty happy that there are lively discussions on the list these days.
> It seems that the number 1 issue in the group these days is the=20
> terminology, which is discussed in multiple email threads, based on=20
> the content of different drafts. So this is pretty difficult to=20
> comment on, and obviously to follow.
>
> So I'm pretty happy that John Parello combined all the terminology in=20
> a single draft.
> Can you please comment on this draft, trying to reach a consensus.
>
> Regards, Benoit, co-chair hat on.
>
>

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


------_=_NextPart_001_01CC4BB1.F2BAF00B
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [eman] ISSUE #1 in EMAN: the terminology





Hi,



The previous link is a cached link. Here's the link in our WG area.



h=
ttp://tools.ietf.org/id/draft-parello-eman-definitions-00.txt



The draft is very much a WIP. What I'd like to accomplish is to have one =
area where we can collect and define terms with references. That will =
avoid us paraphrasing or inventing terms which I confess is very easy to =
do :)



Also since we have some 4-5 drafts it's a lot easier to defined a =
grammar in one place and discuss the terms outside the context of each =
draft.



We discussed this on the list in a few thread back in March. It seemed =
time to get a glossary going.



It is by no means considered complete or final. It's a place holder =
where we can all work and I'll help to collect terms etc.



Thanks so much and looking forward to getting many comments and new =
definitions!

Jp







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

From: eman-bounces@ietf.org on behalf of Benoit Claise (bclaise)

Sent: Tue 7/26/2011 6:13 AM

To: eman mailing list

Subject: Re: [eman] ISSUE #1 in EMAN: the terminology



And the draft is

http://wwwin-eng.cisco.com/rfc/DRAFTS/draft-parello-eman-defi=
nitions-00.txt.



I should have some coffee before sending emails in the morning ;-)



Regards, Benoit.

> Dear all,

>

> Pretty happy that there are lively discussions on the list these =
days.

> It seems that the number 1 issue in the group these days is the

> terminology, which is discussed in multiple email threads, based =
on

> the content of different drafts. So this is pretty difficult to

> comment on, and obviously to follow.

>

> So I'm pretty happy that John Parello combined all the terminology =
in

> a single draft.

> Can you please comment on this draft, trying to reach a =
consensus.

>

> Regards, Benoit, co-chair hat on.

>

>



_______________________________________________

eman mailing list

eman@ietf.org

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









------_=_NextPart_001_01CC4BB1.F2BAF00B--

From bill.mielke@alcatel-lucent.com  Tue Jul 26 10:00:13 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BECC11E811C for ; Tue, 26 Jul 2011 10:00:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihbhLeMqxtRW for ; Tue, 26 Jul 2011 10:00:12 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 20CC211E8075 for ; Tue, 26 Jul 2011 10:00:10 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p6QH08iU008091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Jul 2011 12:00:08 -0500 (CDT)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6QH05Pu014505 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 26 Jul 2011 12:00:08 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 26 Jul 2011 12:00:08 -0500
From: "Mielke, William F (Bill)" 
To: eman mailing list 
Date: Tue, 26 Jul 2011 12:00:05 -0500
Thread-Topic: [eman] new revision of eman requirements - open issue 12.3: time series of energy/power values
Thread-Index: AcxLsY528LDQ57dARfOVMEcoxZ7p5gAARF6w
Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7D6F4@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References:   <54ECD73F-B9A8-440F-970B-B9DD538CA186@quittek.at>  <4E2E2A61.6060503@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7D6F4USNAVSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:	time series of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 17:00:13 -0000

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

I believe that we should be reporting both energy and power.  Given Michael=
 Suchoff's comments thus far and based on my own experience the actual meas=
urements are typically (frequently?) provided by specialized metering chips=
 to insure accuracy.  We should seek to preserve this accuracy by reporting=
 all of the commonly monitored values for each measurement interval and del=
egate to the device how best to collect the actual data.  I am assuming tha=
t Min, Max, and Average values for the various parameters will be readily a=
vailable on the device so it should not be a large overhead to keep them.

Since some devices may be estimating rather than measuring these values the=
 table needs to provide a means of identifying which it is reporting.  It i=
s not clear to me whether this indication needs to be provided per field, p=
er tabular row, or per device.  Thoughts from others?

I also think that we need to take care to generalize things a bit to allow =
the devices to report parameters such as their reporting interval and the s=
ize of their on-board history cache.  In some cases these values may be det=
ermined statically by the device (and may vary from vendor to vendor), but =
we should also provide a means for configuring these parameters as well for=
 the devices which seek to be more flexible.

On the issue of Push vs. Pull models I suppose that each device manufacture=
r should be free to decide whether they want to support both, or just one o=
f the two, so we need to clearly identify which combinations are required. =
 From my perspective a compliant device needs to be able to support either =
one or both methods, but that supporting neither is not really a valid choi=
ce.  This is just my opinion though.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein



________________________________
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Jue=
rgen Quittek
Sent: Tuesday, July 26, 2011 12:32 PM
To: Benoit Claise
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3: ti=
me series of energy/power values

Dear all,

I think we are all in line with the statements made on the mailing list.

However, so far we haven't addressed the open issue as stated in the requir=
ements draft:


> 12.3.  Power and energy time series?
>
>    We have requirements for reporting of time series of power and energy
>    values.  Do we need both or just one of them?  If just one, then
>    which one?


Requirement 5.4.10 asks for time series of power values and requirement 5.5=
.4 asks for time series of energy values. Do we need both of them?

A second question would be: Do we need them to be exported by SNMP or rathe=
r by IPFIX or by both?

    Juergen



Am 25.07.2011 um 22:45 schrieb Benoit Claise:

Dear Michael,

This is exactly what's available in the EMAN monitoring MIB for the energy
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09, section 5=
.5

Regards, Benoit
Dear Juergen,

The larger manufacturers of managed power distribution equipment (APC, Eato=
n, Raritan...) all provide circular buffers of time stamped power measureme=
nts.  Certification of our products for use with IBM System Director requir=
ed this as well.

The better products allow the polling interval to be specified and provide =
ability for events (under currents, circuit breaker trips, etc.) to be repo=
rted as traps.

Our larger data center customers wanted this feature too as they realized p=
olling thousands of devices minute by minute was inefficient and can yield =
unacceptable timing uncertainty.

Our products are able to report accurate measurements - accuracy being defi=
ned as how close do two or more devices agree with a calibrated reference m=
eter when measuring the same quantity.  This cannot be achieved without con=
sidering time.

On Wed, Jul 13, 2011 at 8:52 AM, Juergen Quittek > wrote:
Dear Mouli,

Thank you for commenting on this issue. I would like to have a look at the =
following point of view:

So far, storing time series of measurements on managed nodes is rarely stan=
dardized and rarely available as implementation.

Typically, it is the job of a network management system to collect time ser=
ies and store them.

Take for example byte and packet counters at line cards. You see many curve=
s showing time series of traffic rate/volume in the Internet, but almost al=
l of them were collected at management stations or data collector modules, =
but not within MIB modules. (Please correct me if I'm wrong.)

Now the question is: Is energy management so much different from other netw=
ork management tasks, that we need the rarely used mechanism of storing tim=
e series in MIB modules?

If not, it would be sufficient to just report the number of total energy co=
nsumed since the last re-start as you do it with packet and byte counters.
This would be just a single managed object to be specified and implemented.

Thanks,

   Juergen

Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):

> Regarding the Time Series debate - the crucial question - where is the
> data / measurements stored.
> It would not be possible for small devices to store such data for a
> sufficiently long time period.
>
> The NMS can store the values for a sufficiently long period of time, for
> trending analysis.
>
> In the case of demand measurement, since the maximum over a window is
> computed, it is important for the device store atleast a window length
> of measurements.
>
> I am not sure about that Requirement 5.4.10 - Time Series of Power
> Values - to be stored in the device
>
> Thanks
> Mouli
>
>
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bo=
unces@ietf.org] On Behalf Of
> Juergen Quittek
> Sent: Tuesday, July 12, 2011 2:31 PM
> To: eman mailing list
> Subject: [eman] new revision of eman requirements
>
> Dear all,
>
> I posted a new version of the eman requirements yesterday.
> Please find it at
> http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/
>
>
> Of course, feel free to also comment on the other open issues or to
> raise
> new ones. All such contributions are highly appreciated.
>
> Thanks,
>
>    Juergen
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman

_______________________________________________
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




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







I believe that we should be reporting both energ=
y and=20
power.  Given Michael Suchoff's comments thus far and based on my own=
=20
experience the actual measurements are typically (frequently?) provided by=
=20
specialized metering chips to insure accuracy.  We should seek to pres=
erve=20
this accuracy by reporting all of the commonly monitored values for each=20
measurement interval and delegate to the device how best to collect the act=
ual=20
data.  I am assuming that Min, Max, and Average values for the various=
=20
parameters will be readily available on the device so it should not be a la=
rge=20
overhead to keep them.


 


Since some devices may be estimating rather than=
=20
measuring these values the table needs to provide a means of identifying wh=
ich=20
it is reporting.  It is not clear to me whether this indication needs =
to be=20
provided per field, per tabular row, or per device.  Thoughts from=20
others?


 


I also think that we need to take care to genera=
lize=20
things a bit to allow the devices to report parameters such as their report=
ing=20
interval and the size of their on-board history cache.  In some cases =
these=20
values may be determined statically by the device (and may vary from vendor=
 to=20
vendor), but we should also provide a means for configuring these parameter=
s as=20
well for the devices which seek to be more flexible.


 


On the issue of Push vs. Pull models I suppose t=
hat=20
each device manufacturer should be free to decide whether they want to supp=
ort=20
both, or just one of the two, so we need to clearly identify which combinat=
ions=20
are required.  From my perspective a compliant device needs to be able=
 to=20
support either one or both methods, but that supporting neither is not real=
ly a=20
valid choice.  This is just my opinion though.


William F.=20
Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200=
 East=20
Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email:=20
Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628Fax: 614=20
367 5965

"Live like you're going to die tomorrow.
 Learn lik=
e=20
you're going to live forever."

    - Albert=20
Einstein 


 



  

  

  From: eman-bounces@ietf.org=20
  [mailto:eman-bounces@ietf.org] On Behalf Of Juergen=20
  Quittek
Sent: Tuesday, July 26, 2011 12:32 PM
To: Ben=
oit=20
  Claise
Cc: eman mailing list
Subject: Re: [eman] new=
=20
  revision of eman requirements - open issue 12.3: time series of energy/po=
wer=20
  values


  
Dear all,
  


  
I think we are all in line with the statements made on the mailing=20
  list.

  


  
However, so far we haven't addressed the open issue as stated in the=
=20
  requirements draft:

  


  
> 12.3.  Power and energy time series?
>=20
>    We have requirements for reporting of time series of power and ener=
gy
>    values.  Do we need both or just one of them?  If just one, then
>    which one?


  
Requirement 5.4.10 asks for time series of power values and=20
  requirement 5.5.4 asks for time series of energy values. Do we need =
both=20
  of them?

  


  
A second question would be: Do we need them to be exported by SNMP o=
r=20
  rather by IPFIX or by both?

  


  
    Juergen

  


  


  


  

  

  
Am 25.07.2011 um 22:45 schrieb Benoit Claise:

  

    
Dear Michael,

This is =
exactly=20
    what's available in the EMAN monitoring MIB for the energy
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09,=20
    section 5.5

Regards, Benoit

    Dear Juergen,

The larger manufacturers of managed =
power=20
      distribution equipment (APC, Eaton, Raritan...) all provide circular=
=20
      buffers of time stamped power measurements.  Certification of ou=
r=20
      products for use with IBM System Director required this as=20
      well.

The better products allow the polling interval to be=20
      specified and provide ability for events (under currents, circuit bre=
aker=20
      trips, etc.) to be reported as traps.

Our larger data center=20
      customers wanted this feature too as they realized polling thousands =
of=20
      devices minute by minute was inefficient and can yield unacceptable t=
iming=20
      uncertainty.

Our products are able to report accurate measurem=
ents=20
      - accuracy being defined as how close do two or more devices agree wi=
th a=20
      calibrated reference meter when measuring the same quantity.  Th=
is=20
      cannot be achieved without considering time.


      
On Wed, Jul 13, 2011 at 8:52 AM, Juergen Qui=
ttek=20
      <ietf@quittek.at> wrote:

      Dear Mouli,

Thank you for commenting on th=
is=20
        issue. I would like to have a look at the following point of=20
        view:

So far, storing time series of measurements on managed=
=20
        nodes is rarely standardized and rarely available as=20
        implementation.

Typically, it is the job of a network manage=
ment=20
        system to collect time series and store them.

Take for examp=
le=20
        byte and packet counters at line cards. You see many curves showing=
 time=20
        series of traffic rate/volume in the Internet, but almost all of th=
em=20
        were collected at management stations or data collector modules, bu=
t not=20
        within MIB modules. (Please correct me if I'm wrong.)

Now th=
e=20
        question is: Is energy management so much different from other netw=
ork=20
        management tasks, that we need the rarely used mechanism of storing=
 time=20
        series in MIB modules?

If not, it would be sufficient to jus=
t=20
        report the number of total energy consumed since the last re-start =
as=20
        you do it with packet and byte counters.
This would be just a si=
ngle=20
        managed object to be specified and=20
        implemented.

Thanks,

   Juergen

Am=20
        13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):

&=
gt;=20
        Regarding the Time Series debate - the crucial question - where is=
=20
        the
> data / measurements stored.
> It would not be pos=
sible=20
        for small devices to store such data for a
> sufficiently lon=
g=20
        time period.
>
> The NMS can store the values for a=20
        sufficiently long period of time, for
> trending=20
        analysis.
>
> In the case of demand measurement, since =
the=20
        maximum over a window is
> computed, it is important for the=
=20
        device store atleast a window length
> of=20
        measurements.
>
> I am not sure about that Requirement=
=20
        5.4.10 - Time Series of Power
> Values - to be stored in the=
=20
        device
>
> Thanks
> Mouli
>
>
>=
=20
        -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of>=20
        Juergen Quittek
> Sent: Tuesday, July 12, 2011 2:31 PM
>=
; To:=20
        eman mailing list
> Subject: [eman] new revision of eman=20
        requirements
>
> Dear all,
>
> I posted a n=
ew=20
        version of the eman requirements yesterday.
> Please find it=
=20
        at
> http://datatracker.ietf.org/doc/draft-ietf=
-eman-requirements/
>
>
>=20
        Of course, feel free to also comment on the other open issues or=20
        to
> raise
> new ones. All such contributions are highl=
y=20
        appreciated.
>
> Thanks,
>
>  =20
         Juergen
>
>=20
        _______________________________________________
> eman mailin=
g=20
        list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman=

>=20
        _______________________________________________
> eman mailin=
g=20
        list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman=


_______________________________________________
eman=20
        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





--_000_0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7D6F4USNAVSXCHMBSA_--

From jparello@cisco.com  Tue Jul 26 10:02:18 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B2D11E811D for ; Tue, 26 Jul 2011 10:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.286
X-Spam-Level: 
X-Spam-Status: No, score=-3.286 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxFDdUzPdQGV for ; Tue, 26 Jul 2011 10:02:18 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0819D11E8075 for ; Tue, 26 Jul 2011 10:02:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=425; q=dns/txt; s=iport; t=1311699738; x=1312909338; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=/V18YeVd7TkQsfBNzwmSWMXB5N92TAnUM1MOtjowryQ=; b=PKrXV2uHvPDb1efLzPiiKrDNyxzeuh6C9N8KF9XkbCm0L7xJq8AVLMIu YeJ6ts3XtjgOqNSXdorB0uNlZc/GOELl//xTNYNfFSVfbiFFOn0PinCeM BeWAfDsdjY5ZDf4x9WaHRjc1mNEeZTft02x2DP+xF3BjU5ibhS3E9Xq8F Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EANXxLk6rRDoI/2dsb2JhbAA4AQEDFAEhClgBKwYkBxNSAQUjG6cud6pngSOeY4VhXwSHV5Ari3A
X-IronPort-AV: E=Sophos;i="4.67,270,1309737600";  d="scan'208";a="6558765"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 26 Jul 2011 17:02:16 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6QH2Guk001529 for ; Tue, 26 Jul 2011 17:02:16 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 26 Jul 2011 10:02:15 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Jul 2011 10:01:41 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] Agenda errata...
Thread-Index: AcxLtbDbFCHVwuOGRH+zpjOB9z14iQ==
From: "John Parello (jparello)" 
To: "eman mailing list" 
X-OriginalArrivalTime: 26 Jul 2011 17:02:16.0064 (UTC) FILETIME=[C571E000:01CC4BB5]
Subject: [eman]  Agenda errata...
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, 26 Jul 2011 17:02:19 -0000

Hello Chairs,

In the agenda you have:

    3.c. Power and Energy Monitoring MIB
    draft-ietf-eman-energy-aware-mib-02, 15 min, Mouli Chandramouli

Mouli is presenting draft-claise-energy-monitoring-mib-09 which is our
groups oldest draft.

Also considering the time and how the last meeting ran short  might I
suggest addressing wg items first and then non wg items later?

Thanks see you at the meeting
Jp


From jparello@cisco.com  Tue Jul 26 10:09:03 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6D021F8892 for ; Tue, 26 Jul 2011 10:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.21
X-Spam-Level: 
X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[AWL=-0.611,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V2zJwjMONqe for ; Tue, 26 Jul 2011 10:09:02 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA8221F8890 for ; Tue, 26 Jul 2011 10:09:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=3765; q=dns/txt; s=iport; t=1311700142; x=1312909742; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=K/gElYdn9dWuuXe8dP5q4teSwlgYH6cjRqHJjIILOvA=; b=fwOmwXfsddiLgNaDeZA45OersMoUVjbKfzUQBXcFihB3D8w8t8aJeSDr pJ3/uz/rlYfFqdI43Jts21hlgBcBUUz9hEIs/6a9pEsKv8yec+0Rb8LgD jwnymOoBZp7KEe8ofs88nqnnFnvx/7t1PDrA5zuFXwsP4BCSXvxXoUbE5 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuYAAN3zLk6rRDoG/2dsb2JhbAA2AQEBAQIBAQEBEQEhCjoLBQcFAgEJDgMEAQELBiMBBgETGCMOCAEBBQEWDBuXVI9ad4h8BKMEnmSFYV8Eh1eQK4tw
X-IronPort-AV: E=Sophos;i="4.67,270,1309737600";  d="scan'208";a="6560190"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 26 Jul 2011 17:09:02 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6QH91nm012104; Tue, 26 Jul 2011 17:09:01 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 26 Jul 2011 10:09:01 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Jul 2011 10:08:26 -0700
Message-ID: 
In-Reply-To: <54ECD73F-B9A8-440F-970B-B9DD538CA186@quittek.at>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - open issue 12.3:time series of energy/power values
Thread-Index: AcxBW9BdTp1Q+03xTEiIjnzhtkKD+QKWgA9g
References:  <54ECD73F-B9A8-440F-970B-B9DD538CA186@quittek.at>
From: "John Parello (jparello)" 
To: "Juergen Quittek" , "Mouli Chandramouli (moulchan)" 
X-OriginalArrivalTime: 26 Jul 2011 17:09:01.0335 (UTC) FILETIME=[B7015270:01CC4BB6]
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:time series of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 17:09:03 -0000

Hi Jeurgen,

I tend to agree, for simple devices an energy odometer(s) as describe
from the comments and what I presented from the ODVA suffices.

For time series of data like historical demand devices such as PDUs very
typically store this. Some our as long as a year's worth of data on the
device. For the very reason that Bill pointed out.

So it would seem that a power value and an energy odometer could be a
required minimum and then time series of power or demand can be
optional.=20

We specified a power value as required in the monitoring mib with time
series of power and demand as optional.

Jp

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Juergen Quittek
Sent: Wednesday, July 13, 2011 5:53 AM
To: Mouli Chandramouli (moulchan)
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue
12.3:time series of energy/power values

Dear Mouli,

Thank you for commenting on this issue. I would like to have a look at
the following point of view:

So far, storing time series of measurements on managed nodes is rarely
standardized and rarely available as implementation.

Typically, it is the job of a network management system to collect time
series and store them.

Take for example byte and packet counters at line cards. You see many
curves showing time series of traffic rate/volume in the Internet, but
almost all of them were collected at management stations or data
collector modules, but not within MIB modules. (Please correct me if I'm
wrong.)=20

Now the question is: Is energy management so much different from other
network management tasks, that we need the rarely used mechanism of
storing time series in MIB modules?

If not, it would be sufficient to just report the number of total energy
consumed since the last re-start as you do it with packet and byte
counters.
This would be just a single managed object to be specified and
implemented.

Thanks,

    Juergen

Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):

> Regarding the Time Series debate - the crucial question - where is the
> data / measurements stored.=20
> It would not be possible for small devices to store such data for a
> sufficiently long time period.=20
>=20
> The NMS can store the values for a sufficiently long period of time,
for
> trending analysis.=20
>=20
> In the case of demand measurement, since the maximum over a window is
> computed, it is important for the device store atleast a window length
> of measurements.=20
>=20
> I am not sure about that Requirement 5.4.10 - Time Series of Power
> Values - to be stored in the device
>=20
> Thanks
> Mouli
>=20
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
Of
> Juergen Quittek
> Sent: Tuesday, July 12, 2011 2:31 PM
> To: eman mailing list
> Subject: [eman] new revision of eman requirements
>=20
> Dear all,
>=20
> I posted a new version of the eman requirements yesterday.
> Please find it at=20
> http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/
>=20
>=20
> Of course, feel free to also comment on the other open issues or to
> raise
> new ones. All such contributions are highly appreciated.
>=20
> Thanks,
>=20
>    Juergen
>=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 ietf@quittek.at  Tue Jul 26 10:35:47 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4185811E810E for ; Tue, 26 Jul 2011 10:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 ktEj8PuT6jtN for ; Tue, 26 Jul 2011 10:35:46 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3372311E80FD for ; Tue, 26 Jul 2011 10:35:46 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MEaJJ-1QfNkV3IjZ-00FmQE; Tue, 26 Jul 2011 19:35:43 +0200
References:    <1127B34B-6899-4F1D-966E-ED841E25E554@quittek.at> <4E142A61.3010103@cisco.com> <20248561-E87E-4CD0-9E57-E031B00E479A@quittek.at> <4E2E2C4C.8070605@cisco.com>
In-Reply-To: <4E2E2C4C.8070605@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-12-534576660
Message-Id: <17230210-EA1F-4DF1-BF24-517929017044@quittek.at>
From: Juergen Quittek 
Date: Tue, 26 Jul 2011 13:35:41 -0400
To: Benoit Claise 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:mUkoKGShMhvgNm57bCtnvxHBBbAvHE1VsFGRyjKONjq HQmNQhKY5AqoUerHVCm8fKiNaE8NQZKdpsNobGjv1e3dWNC0pH PuimivRi0nj7+0oWgc86iSn7NqatyVQMPG/e/A+8d7u7KVTUB7 0EHbfCh58bw4nNrUaSIxNknsVgYvzobGCHoLqRBlE35ATn/dvo UohRZ6jIsdVSzK121A9ETRfVPvcaph1BzfaKpDT/qc=
Cc: eman mailing list 
Subject: Re: [eman] New draft on eman requirements  - issue 1 - Device type
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, 26 Jul 2011 17:35:47 -0000

--Apple-Mail-12-534576660
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Yes. done.

Sorry for missing this item.

    Juergen

Am 25.07.2011 um 22:54 schrieb Benoit Claise:

> Juergen,
>>=20
>> On 06.07.2011  11:26, Benoit Claise wrote:
>>=20
>>> On 01/07/2011 14:10, Juergen Quittek wrote:
>>>>=20
>>>> Hi Mouli,
>>>>=20
>>>> I'm glad you comment on this. It was too vague so far.
>>>> Please see plies inline.
>>>>=20
>>>> Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan):
>>>>=20
>>>>> Hello,
>>>>>=20
>>>>> As Juergen has mentioned, while the first version has been =
released to
>>>>> solicit feedback, some of the concepts are still debated.
>>>>> The perspectives from the email list would be useful to shape the =
draft.
>>>>>=20
>>>>> I shall post some of the discussion points.=20
>>>>>=20
>>>>> Thanks
>>>>> Mouli
>>>>>=20
>>>>> ------------
>>>>>=20
>>>>> There is a requirement -
>>>>> =
http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-03.txt
>>>>>=20
>>>>>=20
>>>>> 5.1.1.  Type of powered entity
>>>>>=20
>>>>>   The energy management standard must provide means to retrieve =
and
>>>>>   report the type of powered entities.
>>>>>=20
>>>>> I think it would be useful to expand this requirement. Device Type =
could
>>>>> be inferred as "IP Phone" or "Line Card 3", ...
>>>> Yes. The question is what is needed?
>>> We don't want we redo the ENTITY-MIB work, but  I believe that =
having a way to map to the ENTITY-MIB index is important.
>>> The more generic requirements should be something such as:
>>> The energy management standard must provide means to map the power =
entities=20
>>> to existing managed device inventory such as the ENTITY-MIB.
>>>=20
>>> The energy management standard must provide means to map the power =
entities=20
>>> to existing energy related MIBs such as the POE and LLPD MIBs
>>>=20
>>> Those two requirements should be in the section 4. Identification of =
Powered Entities
>>=20
>> I agree on moving it to section 4.  The discussion on the content is =
going on in another email thread.
> I would appreciate if you could either introduce this text in the =
draft, or list this as an open issue, instead of just ignoring it.
>=20
> Regards, Benoit (as a contributor)
>=20


--Apple-Mail-12-534576660
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

Yes. done.

Sorry for missing this item.

    Juergen

Am 25.07.2011 um 22:54 schrieb Benoit Claise:


  
    
  
  

    Juergen,
    

      

        
On 06.07.2011  11:26, Benoit Claise wrote:

        

        

          
 On 01/07/2011 14:10,
            Juergen Quittek wrote:
            

              
Hi Mouli,

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

Am 01.07.2011 um 13:08 schrieb Mouli Chandramouli (moulchan):



              

                
Hello,

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

I shall post some of the discussion points. 

Thanks
Mouli

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

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


5.1.1.  Type of powered entity

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

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


              

              
Yes. The question is what is needed?


            

            We don't want we redo the ENTITY-MIB work, but  I believe
            that having a way to map to the ENTITY-MIB index is
            important.

            The more generic requirements should be something such as:

            

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

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



            

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

          

        

        


        

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

      

    

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

    

    Regards, Benoit (as a contributor)

    

  





--Apple-Mail-12-534576660--

From ietf@quittek.at  Tue Jul 26 12:39:08 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B3811E80AB for ; Tue, 26 Jul 2011 12:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvVSDqFz0sDn for ; Tue, 26 Jul 2011 12:39:08 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id B1FDF11E809F for ; Tue, 26 Jul 2011 12:39:07 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MJCxO-1Qj3NT1RuM-002qAJ; Tue, 26 Jul 2011 21:39:06 +0200
References:  <54ECD73F-B9A8-440F-970B-B9DD538CA186@quittek.at> 
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <4299FFDD-DA45-41BD-803E-4606AB4AA284@quittek.at>
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Tue, 26 Jul 2011 15:39:04 -0400
To: "John Parello (jparello)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:q9/8TSxTuVpqoD1PxoX4Oiu6u7XTzw9l11E03dpEUoK CxXm9qoJuf0atIKrT0PHbRLTtCcNbnYMvcefpHTh4I8ACnbClT VpJGbpQ3Du7TptScWtFPrDYICsTcVjYIKytUsGrIAKc2v5O7mu EGtG5oS7/pCyDa7SrkemDEjZ1w5N9gpJnzyt4fsi0M77f+Aptc ORl+569bX5sadrGymLt9OYgZHpxQw4bGk0R4pqjE/s=
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:time series of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 19:39:08 -0000

Hi John,

We are currently not discussing optional or mandatory implementation.

The question is whether or not we have a requirement for specifying a =
standard for reporting both, energy time series and power time series, =
or just one of them. What compliant devices must implement is an issue =
to be discussed later.

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

Thanks,

    Juergen

Am 26.07.2011 um 13:08 schrieb John Parello (jparello):

> Hi Jeurgen,
>=20
> I tend to agree, for simple devices an energy odometer(s) as describe
> from the comments and what I presented from the ODVA suffices.
>=20
> For time series of data like historical demand devices such as PDUs =
very
> typically store this. Some our as long as a year's worth of data on =
the
> device. For the very reason that Bill pointed out.
>=20
> So it would seem that a power value and an energy odometer could be a
> required minimum and then time series of power or demand can be
> optional.=20
>=20
> We specified a power value as required in the monitoring mib with time
> series of power and demand as optional.
>=20
> Jp
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of
> Juergen Quittek
> Sent: Wednesday, July 13, 2011 5:53 AM
> To: Mouli Chandramouli (moulchan)
> Cc: eman mailing list
> Subject: Re: [eman] new revision of eman requirements - open issue
> 12.3:time series of energy/power values
>=20
> Dear Mouli,
>=20
> Thank you for commenting on this issue. I would like to have a look at
> the following point of view:
>=20
> So far, storing time series of measurements on managed nodes is rarely
> standardized and rarely available as implementation.
>=20
> Typically, it is the job of a network management system to collect =
time
> series and store them.
>=20
> Take for example byte and packet counters at line cards. You see many
> curves showing time series of traffic rate/volume in the Internet, but
> almost all of them were collected at management stations or data
> collector modules, but not within MIB modules. (Please correct me if =
I'm
> wrong.)=20
>=20
> Now the question is: Is energy management so much different from other
> network management tasks, that we need the rarely used mechanism of
> storing time series in MIB modules?
>=20
> If not, it would be sufficient to just report the number of total =
energy
> consumed since the last re-start as you do it with packet and byte
> counters.
> This would be just a single managed object to be specified and
> implemented.
>=20
> Thanks,
>=20
>    Juergen
>=20
> Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):
>=20
>> Regarding the Time Series debate - the crucial question - where is =
the
>> data / measurements stored.=20
>> It would not be possible for small devices to store such data for a
>> sufficiently long time period.=20
>>=20
>> The NMS can store the values for a sufficiently long period of time,
> for
>> trending analysis.=20
>>=20
>> In the case of demand measurement, since the maximum over a window is
>> computed, it is important for the device store atleast a window =
length
>> of measurements.=20
>>=20
>> I am not sure about that Requirement 5.4.10 - Time Series of Power
>> Values - to be stored in the device
>>=20
>> Thanks
>> Mouli
>>=20
>>=20
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
> Of
>> Juergen Quittek
>> Sent: Tuesday, July 12, 2011 2:31 PM
>> To: eman mailing list
>> Subject: [eman] new revision of eman requirements
>>=20
>> Dear all,
>>=20
>> I posted a new version of the eman requirements yesterday.
>> Please find it at=20
>> http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/
>>=20
>>=20
>> Of course, feel free to also comment on the other open issues or to
>> raise
>> new ones. All such contributions are highly appreciated.
>>=20
>> Thanks,
>>=20
>>   Juergen
>>=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
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From moulchan@cisco.com  Tue Jul 26 13:40:14 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F0211E812D for ; Tue, 26 Jul 2011 13:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.406
X-Spam-Level: 
X-Spam-Status: No, score=-3.406 tagged_above=-999 required=5 tests=[AWL=-0.808, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY+5CblWX9sh for ; Tue, 26 Jul 2011 13:40:12 -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 79EEB11E811E for ; Tue, 26 Jul 2011 13:40:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=26912; q=dns/txt; s=iport; t=1311712812; x=1312922412; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=9e7TyWEP/6gS0lxfZRAh2RpGhN7XHXHaCJ3DufhV8fQ=; b=F14nBU13nthVxb5nk87xprXQ/wbSLFhV5/9nzdzP3VW+WosiPhfohzKF n0lxvSJXWzzGrrw9XdxnkxtwLqS+kTw1FSIjJZ7AKu30VVfbDFS1VVR9/ FA90uEo1BSmo563Ri9mjpf3nspikFxcG1LLgTkhzetij8RVLAmMnUBeZq A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuYAAIUlL06tJXHA/2dsb2JhbAA1AQEBAQMUAQwIBAYDRQoRAgEHAhEEAQELBiMBAgICAQESOw4IAQEFARYMEQqCNoF5kx+OV4EFd4kAozGNI5EyhTEwXwSHV5Ari24
X-IronPort-AV: E=Sophos;i="4.67,271,1309737600"; d="scan'208,217";a="6638831"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 26 Jul 2011 20:40:12 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6QKeBNS002316 for ; Tue, 26 Jul 2011 20:40:11 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 26 Jul 2011 15:40:11 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4BD4.3761A192"
Date: Tue, 26 Jul 2011 15:40:09 -0500
Message-ID: 
In-Reply-To: <4E2C6D95.3020806@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] draft-ietf-eman-requirements-00 review -> applicability statement draft
Thread-Index: AcxKNRNVErV/rNbSQBO75PFM60hS5wBnjIEA
References: <32987825.7.1299160553893.JavaMail.pgrosset@rcdn-vpn-client-10-89-5-119.cisco.com> <4E2C6D95.3020806@cisco.com>
From: "Mouli Chandramouli (moulchan)" 
To: "Benoit Claise (bclaise)" , "Patrick Grossetete (pgrosset)" 
X-OriginalArrivalTime: 26 Jul 2011 20:40:11.0889 (UTC) FILETIME=[373E6E10:01CC4BD4]
Cc: eman@ietf.org
Subject: Re: [eman] draft-ietf-eman-requirements-00 review -> applicability statement draft
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 20:40:14 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4BD4.3761A192
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

SGkgUGF0cmljayBCZW5vaXQsDQoNCiANCg0KTG9hZCBzaGVkZGluZy9EZW1hbmQgcmVzcG9uc2Ug
aXMgYW4gaW1wb3J0YW50IGVuZXJneSBtYW5hZ2VtZW50IHNjZW5hcmlvIGFuZCBpbiBhIHNlbnNl
IHdvdWxkIGFwcGx5IGFjcm9zcyBtdWx0aXBsZSB1c2UgY2FzZSBzY2VuYXJpb3MgKCBsb2FkIHNo
ZWRkaW5nIGZvciBidWlsZGluZyBvciBEYXRhIGNlbnRlciDigKYpLiANCg0KIA0KDQpJIHNoYWxs
IHVwZGF0ZSB0aGUgZG9jdW1lbnQgdG8gcmVmbGVjdCB0aGlzIGFwcGxpY2F0aW9uIGFuZCBzaGFs
bCBhbHNvIGRpc2N1c3MgdGhpcyBpbiB0aGUgV0cgbWVldGluZy4gDQoNCiANCg0KVGhhbmtzDQoN
Ck1vdWxpDQoNCiANCg0KRnJvbTogZW1hbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZW1hbi1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVub2l0IENsYWlzZSAoYmNsYWlzZSkNClNl
bnQ6IFN1bmRheSwgSnVseSAyNCwgMjAxMSAzOjA4IFBNDQpUbzogUGF0cmljayBHcm9zc2V0ZXRl
IChwZ3Jvc3NldCkNCkNjOiBlbWFuQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2VtYW5dIGRyYWZ0
LWlldGYtZW1hbi1yZXF1aXJlbWVudHMtMDAgcmV2aWV3IC0+IGFwcGxpY2FiaWxpdHkgc3RhdGVt
ZW50IGRyYWZ0DQoNCiANCg0KRGVhciBhcHBsaWNhYmlsaXR5IGRyYWZ0IGF1dGhvcnMsDQoNClJl
YWRpbmcgYmFjayB0aGUgb2xkIEVNQU4gZW1haWwsIEkgYmVsaWV2ZSB0aGF0IExvYWQgc2hlZGRp
bmcgb3IgRGVtYW5kL1Jlc3BvbnNlIHNob3VsZCBiZSBtZW50aW9uZWQgaW4gdGhlIEVNQU4gYXBw
bGljYWJpbGl0eSBzdGF0ZW1lbnQuIE5vdCBzcGVjaWZpY2FsbHkgYXMgdXNlIGNhc2VzIHRoYXQg
RU1BTiBzaG91bGQgc29sdmUsIGJ1dCBhcyB1c2UgY2FzZXMgd2hlcmUgRU1BTiBjb3VsZCBoZWxw
Lg0KDQpSZWdhcmRzLCBCZW5vaXQgKGFzIGEgY29udHJpYnV0b3IpDQoNCg0KDQpCZW5vaXQsDQoN
Ckkgd291bGQgc2F5IHRoYXQgc2VydmljZXMgc3VjaCBhcyBMb2FkIHNoZWRkaW5nIG9yIERlbWFu
ZC9SZXNwb25zZSBzaG91bGQgZ28gYXMgZXhhbXBsZXMgaW4gdGhlIGFwcHJvcHJpYXRlIHNlY3Rp
b24gc3VjaCBhcw0KSG9tZSBFbmVyZ3ksIERhdGEgQ2VudGVyLC4uLg0KDQpQYXRyaWNrDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206ICJCZW5vaXQgQ2xhaXNlIiA8
YmNsYWlzZUBjaXNjby5jb20+IDxtYWlsdG86YmNsYWlzZUBjaXNjby5jb20+IA0KVG86ICJQYXRy
aWNrIEdyb3NzZXRldGUiIDxwZ3Jvc3NldEBjaXNjby5jb20+IDxtYWlsdG86cGdyb3NzZXRAY2lz
Y28uY29tPiANCkNjOiBlbWFuQGlldGYub3JnDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMywgMjAx
MSAyOjIyOjIyIFBNDQpTdWJqZWN0OiBSZTogZHJhZnQtaWV0Zi1lbWFuLXJlcXVpcmVtZW50cy0w
MCByZXZpZXcNCg0KSGkgUGF0cmljaywNCg0KVGhhbmtzIGZvciBhIGxvdCBmb3IgeW91ciByZXZp
ZXcuDQpTZWUgaW5saW5lIGZvciBvbmUgcGFydGljdWxhciBwb2ludC4NCg0KDQoNCg0KDQoNCg0K
QmVub2l0LA0KDQpQbGVhc2UsIGZpbmQgbXkgY29tbWVudHMgcmVnYXJkaW5nIGRyYWZ0LWlldGYt
ZW1hbi1yZXF1aXJlbWVudHMtMDAuIEkgd3JvdGUgdGhlbSB3aGlsZSByZWFkaW5nIHRoZSBkb2Ms
IHNvIHRoZXJlIGlzIG5vIHByaW9yaXR5IG9yZGVyLg0KDQpCZXN0IFJlZ2FyZHMNClBhdHJpY2sN
CiANCg0KLSBwYWdlIDQtNSwgaXQgc2hvdWxkIGJlIGFkZGVkIHRoYXQgZW52aXJvbm1lbnRhbCBj
b25kaXRpb25zIG1heSBhbHNvIGltcGFjdCB0aGUgcG90ZW50aWFsIHJlZHVjdGlvbiBvZiBwb3dl
ciBjb25zdW1wdGlvbi4gVGhlcmUgaXMgb2Z0ZW4gYSBsaW5rIGJldHdlZW4NCnRlbXBlcmF0dXJl
L1JIIGFuZCBwb3dlci4uLmZvciBleGFtcGxlLCBzZWUgQVNIUkFFIHNwZWNpZmljYXRpb25zIGZv
ciBEYXRhQ2VudGVyIChQVUUgYW5kIERDSUUgbWV0cmljcykuIEl0IG1heSBhbHNvIGJlIG5vdGlj
ZWQgdGhhdCBzaWRlIGVmZmVjdHMgbWF5IG9jY3VyLg0KRm9yIGV4YW1wbGUsIEkgaGF2ZSBzZWVu
IHBlb3BsZSBpbmNyZWFzaW5nIHRoZSB0ZW1wZXJhdHVyZSBpbiB0aGVpciBkYXRhY2VudGVyIHRv
IGNvbXBseSB3aXRoIFBVRSBtZXRyaWMgYnV0IGluIGZhY3QgZ2V0dGluZyBmYW4gc3BlZWQgaW5j
cmVhc2Ugb24gdGhlaXIgc2VydmVycw0KYW5kIGxlYWRpbmcgdG8gZmFsc2UgY29uY2x1c2lvbiBv
ZiBtZXRyaWNzIHNpbmNlIHRoZSBwb3dlciBjb25zdW1wdGlvbiB3YXMgc2VlbiBhcyAiZ29vZCIg
Zm9yIFBVRSBjb21wdXRhdGlvbi4gQ2xlYXJseSwgdGhlIGNhcGFiaWxpdHkgdG8gbW9uaXRvcg0K
ZW5lcmd5IGNvbnN1bXB0aW9uIG9mIHNlcnZlcnMgd291bGQgaGF2ZSBpbmRpY2F0ZWQgdGhhdC4N
Cg0KLSBwYWdlIDUsIG1vbml0b3JpbmcgZW5lcmd5IGNvbnN1bXB0aW9uIGNhbiBhbHNvIGhlbHAg
dG8gY2hlY2sgY29tcGxpYW5jeSB3aXRoIG1hbmRhdGVzL3JlZ3VsYXRpb25zL3JlY29tbWVuZGF0
aW9ucyBzdWNoIGFzIEFTSFJBRSBvciBOVElBDQoNCi0gcGFnZSA2LCBJIHdvdWxkIGhhdmUgc3Bs
aXQgdGhpcyBjYXRlZ29yeSBhcyAic2VydmVycyBhbmQgaG9zdHMiIGFscmVhZHkgaW1wbGVtZW50
IHNvbWUgcG93ZXIgY29uc3VtcHRpb24gbWV0cmljcyBzdWNoIGFzIElQTUkgb24gc2VydmVycywg
DQoNCglhbmQgbmV3IGdlbmVyYXRpb24gQ1BVIG9mZmVycyBkaWZmZXJlbnQgcG93ZXIgc3RhdGUg
bGV2ZWwgLg0KCVNlY3Rpb24gMiBpcyBpbmNvbXBsZXRlIGlmIHdlIGRvbid0IGludHJvZHVjZSBp
biB0aGUgc2NlbmFyaW8sIHNlcnZpY2VzIHN1Y2ggYXMgRGVtYW5kL1Jlc3BvbnNlIGFuZCBMb2Fk
IFNoZWRkaW5nIHdoaWNoIG1heSBhcHBseSB0byBkaWZmZXJlbnQgMi54IHNlY3Rpb25zDQoNClJp
Z2h0LCB3ZSBjb3VsZCBhZGQgdGhlbSBhcyB0aGV5IHdpbGwgaW5mbHVlbmNlIHRoZSBkaWZmZXJl
bnQgdXNlIGNhc2VzIGluIA0KDQogICAgIDIuMSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtaWV0Zi1lbWFuLXJlcXVpcmVtZW50cy0wMCNzZWN0aW9uLTIuMT4gLiAgU2NlbmFyaW8g
MTogUm91dGVycywgc3dpdGNoZXMsIG1pZGRsZWJveGVzLCBhbmQgaG9zdHMgIC4gLiAgNiA8aHR0
cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1lbWFuLXJlcXVpcmVtZW50cy0wMCNw
YWdlLTY+IA0KICAgICAyLjIuICBTY2VuYXJpbyAyOiBQb0Ugc291cmNpbmcgZXF1aXBtZW50IGFu
ZCBQb0UgcG93ZXJlZA0KICAgICAgICAgICBkZXZpY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1pZXRmLWVtYW4tcmVxdWlyZW1lbnRzLTAwI3BhZ2UtNz4gDQogICAgIDIuMyA8aHR0
cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1lbWFuLXJlcXVpcmVtZW50cy0wMCNz
ZWN0aW9uLTIuMz4gLiAgU2NlbmFyaW8gMzogUG93ZXIgcHJvYmVzIGFuZCBTbWFydCBtZXRlcnMg
IC4gLiAuIC4gLiAuIC4gLiAgNyA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0
Zi1lbWFuLXJlcXVpcmVtZW50cy0wMCNwYWdlLTc+IA0KICAgICAyLjQgPGh0dHA6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZW1hbi1yZXF1aXJlbWVudHMtMDAjc2VjdGlvbi0yLjQ+
IC4gIFNjZW5hcmlvIDQ6IE1pZC1sZXZlbCBtYW5hZ2VycyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gIDcgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZW1hbi1yZXF1
aXJlbWVudHMtMDAjcGFnZS03PiANCiAgICAgMi41IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1pZXRmLWVtYW4tcmVxdWlyZW1lbnRzLTAwI3NlY3Rpb24tMi41PiAuICBTY2VuYXJp
byA1OiBHYXRld2F5cyB0byBidWlsZGluZyBuZXR3b3JrcyAgLiAuIC4gLiAuIC4gLiAuICA3IDxo
dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWVtYW4tcmVxdWlyZW1lbnRzLTAw
I3BhZ2UtNz4gDQogICAgIDIuNiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0
Zi1lbWFuLXJlcXVpcmVtZW50cy0wMCNzZWN0aW9uLTIuNj4gLiAgU2NlbmFyaW8gNjogSG9tZSBl
bmVyZ3kgZ2F0ZXdheXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOCA8aHR0cDovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1lbWFuLXJlcXVpcmVtZW50cy0wMCNwYWdlLTg+IA0K
ICAgICAyLjcgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZW1hbi1yZXF1
aXJlbWVudHMtMDAjc2VjdGlvbi0yLjc+IC4gIFNjZW5hcmlvIDc6IERhdGEgY2VudGVyIGRldmlj
ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDggPGh0dHA6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWlldGYtZW1hbi1yZXF1aXJlbWVudHMtMDAjcGFnZS04PiANCiAgICAgMi44IDxo
dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWVtYW4tcmVxdWlyZW1lbnRzLTAw
I3NlY3Rpb24tMi44PiAuICBTY2VuYXJpbyA4OiBCYXR0ZXJ5IHBvd2VyZWQgZGV2aWNlcyAgLiAu
IC4gLiAuIC4gLiAuIC4gLiAuICA4IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p
ZXRmLWVtYW4tcmVxdWlyZW1lbnRzLTAwI3BhZ2UtOD4gDQogDQpCeSBpbmZsdWVuY2luZywgSSBt
ZWFuIHRoYXQgdGhlIGRlbWFuZC9yZXNwb25zZSBmb3IgcG9saWNpZXMgaW4gdGhlc2UgdXNlIGNh
c2VzIC4NCkhvd2V2ZXIsIEkgd291bGQgbm90IGxpc3QgZGVtYW5kL3Jlc3BvbnNlIGF0IHRoZSBz
YW1lIGxldmVsIGFzIHRoZXNlIHVzZSBjYXNlcywgYXMgdGhlIHNlY3Rpb24gMiBpbnRyb2R1Y3Rp
b24gZXhwbGFpbnM6DQoNCjIuICBTY2VuYXJpb3MgYW5kIHRhcmdldCBkZXZpY2VzDQoNCiANCiAg
IFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgYSBzZWxlY3Rpb24gb2Ygc2NlbmFyaW9zIGZvciB0aGUg
YXBwbGljYXRpb24NCiAgIG9mIGVuZXJneSBtYW5hZ2VtZW50LiAgRm9yIGVhY2ggc2NlbmFyaW8g
YSBsaXN0IG9mIHRhcmdldCBkZXZpY2VzIGlzDQogICBnaXZlbiBpbiB0aGUgaGVhZGxpbmUsIGZv
ciB3aGljaCBJRVRGIGVuZXJneSBtYW5hZ2VtZW50IHN0YW5kYXJkcyBhcmUNCiAgIG5lZWRlZC4N
Cg0KDQpBbmQgdGhlIEVNQU4gV0cgd2lsbCBub3QgYmUgc29sdmluZyB0aGUgZGVtYW5kL3Jlc3Bv
bnNlIHByb2JsZW06IGl0IHdpbGwgImp1c3QiIHByb2R1Y2Ugb25lIHBpZWNlIG9mIHRoZSBwdXp6
bGUNCg0KUmVnYXJkcywgQmVub2l0Lg0KDQoNCg0KCQ0KCS0gcGFnZSA4LCBzZWN0aW9uIDIuNyAt
IG9idmlvdXNseSBub3QgbWVudGlvbmluZyBBU0hSQUUgcmVjb21tZW5kYXRpb25zIChQVUUvRENJ
RSkgaXMgbm90IGFja25vd2xlZGdpbmcgaW5kdXN0cnkgc3RhbmRhcmRzIGZvciBlbmVyZ3kgbW9u
aXRvcmluZw0KCWluIGRhdGFjZW50ZXJzLg0KCQ0KCS0gcGFnZSA5LCBzZWN0aW9uIDMuMiAtIGFn
Z3JlZ2F0aW9uIG9mIGVuZXJneSBkYXRhIGlzIHJlYWxseSB3aGF0IGhlbHBzIGZhY2lsaXR5IG1h
bmFnZXJzIHRvIHVuZGVyc3RhbmQgd2hlcmUgdGhleSBjb3VsZCBzYXZlIG1vbmV5Lg0KCWluIGZh
Y3QsIHRoZXJlIHdvdWxkIGJlIGEgbmVlZCB0byBkaXNjdXNzIGhvdyBhZ2dyZWdhdGlvbiBjYW4g
YmUgZG9uZS4gSXQgY291bGQgYmUgYXMgc2ltcGxlIGFzIG1vbml0b3JpbmcgYWxsIHBoeXNpY2Fs
IGRpc3RyaWJ1dGlvbiBjaXJjdWl0cw0KCWJ1dCBjb3VsZCBhbHNvIGJlIGFnZ3JlZ2F0ZWQgYnkg
Y2F0ZWdvcmllcyBzdWNoIGFzIGVuZ2luZWVyaW5nL3NhbGVzL21hcmtldGluZyBkZXBhcnRtZW50
cyBvciBoZWF0aW5nL2Nvb2xpbmcvSVQvbGlnaHRzLC4uLg0KCVRvIGZ1bGx5IHVuZGVyc3RhbmQg
dGhlIGNvbnN1bXB0aW9uLCB5b3UgYWxzbyBuZWVkIHRvIGRlZmluZSB0aGUgImFnZ3JlZ2F0aW9u
IHBvaW50IiB0byBjb25zaWRlciB3aGF0IGlzIGNvdW50ZWQgZG93bnN0cmVhbSBhbmQgdXBzdHJl
YW0uDQoJRm9yIGV4YW1wbGUsIGRhdGEgcmV0cmlldmVkIG9uIGEgc2VydmVyIG9yIHJvdXRlciB3
aWxsIGJlIGEgcG9ydGlvbiBvZiBkYXRhIHJldHJpZXZlZCBvbiBhIHNtYXJ0IHBsdWcgY29ubmVj
dGluZyBhbGwgdGhlc2UgZGV2aWNlcyB3aGljaCB3aWxsIGJlIGEgcG9ydGlvbg0KCW9mIGRhdGEg
cmV0cmlldmVkIGF0IGEgc21hcnQgY2lyY3VpdCBicmVha2VyIGxldmVsLCBhbmQgc28gb24uDQoJ
DQoJLSBwYWdlIDExLCBzZWN0aW9uIDMuNC4yLCB5b3UgY291bGQgYWxzbyBpbmRpY2F0ZTogbGlu
ZSBmcmVxdWVuY3ksIHBvd2VyIGZhY3RvciwgYXBwYXJlbnQgcG93ZXIsIHJlYWN0aXZlIHBvd2Vy
LC4uLiBhcyBtZXRyaWNzIGJlaW5nIGF2YWlsYWJsZSBvbiBjZXJ0YWluDQoJY2F0ZWdvcnkgb2Yg
ZGV2aWNlcy4NCgkNCgktIHBhZ2UgMTIsIHNlY3Rpb24gMy40LjQsIHlvdSBtYXkgd2FudCB0byBj
b21wYXJlIHdpdGggZXhpc3RpbmcgTUlCIHN1Y2ggYXMgVVBTIHZlbmRvcidzIE1JQnMNCg0KIA0K
DQogDQoNCiANCg0K

------_=_NextPart_001_01CC4BD4.3761A192
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y
IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYg
IW1zb10+DQo8c3R5bGU+DQp2XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoq
IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1
bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+
DQo8IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQog
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg
MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x
OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29s
YXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRp
b25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn
aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KaDIN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMiBDaGFy
IjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTgu
MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6Ymxh
Y2s7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy
Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm
b250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZv
cm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K
CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0
ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSGVhZGlu
ZzJDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDIgQ2hhciI7DQoJbXNvLXN0eWxlLXBy
aW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMiI7DQoJZm9udC1mYW1pbHk6IkNh
bWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXdlaWdodDpib2xkO30NCnNw
YW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv
Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu
MHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp
biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQot
LT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzpp
ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb
ZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGJnY29sb3I9d2hpdGUgbGFuZz1FTi1VUyBsaW5r
PWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1N
c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+SGkg
UGF0cmljaw0KQmVub2l0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y
bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPkxvYWQNCnNoZWRkaW5nL0RlbWFuZCByZXNw
b25zZSBpcyBhbiBpbXBvcnRhbnQgZW5lcmd5IG1hbmFnZW1lbnQgc2NlbmFyaW8gYW5kIGluIGEN
CnNlbnNlIHdvdWxkIGFwcGx5IGFjcm9zcyBtdWx0aXBsZSB1c2UgY2FzZSBzY2VuYXJpb3MgKCBs
b2FkIHNoZWRkaW5nIGZvcg0KYnVpbGRpbmcgb3IgRGF0YSBjZW50ZXIg4oCmKS4gPG86cD48L286
cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFG
NDk3RCc+SSBzaGFsbCB1cGRhdGUNCnRoZSBkb2N1bWVudCB0byByZWZsZWN0IHRoaXMgYXBwbGlj
YXRpb24gYW5kIHNoYWxsIGFsc28gZGlzY3VzcyB0aGlzIGluIHRoZSBXRw0KbWVldGluZy4gPG86
cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29s
b3I6IzFGNDk3RCc+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29O
b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+TW91bGk8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQoNCjxkaXY+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg
I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz4NCg0KPHAgY2xhc3M9TXNv
Tm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv
bWEiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOndpbmRvd3RleHQnPkZyb206PC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCiJUYWhvbWEiLCJzYW5zLXNl
cmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz4gZW1hbi1ib3VuY2VzQGlldGYub3JnDQpbbWFpbHRvOmVt
YW4tYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5CZW5vaXQgQ2xhaXNlIChi
Y2xhaXNlKTxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEp1bHkgMjQsIDIwMTEgMzowOCBQTTxi
cj4NCjxiPlRvOjwvYj4gUGF0cmljayBHcm9zc2V0ZXRlIChwZ3Jvc3NldCk8YnI+DQo8Yj5DYzo8
L2I+IGVtYW5AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtlbWFuXSBkcmFmdC1p
ZXRmLWVtYW4tcmVxdWlyZW1lbnRzLTAwIHJldmlldyAtJmd0Ow0KYXBwbGljYWJpbGl0eSBzdGF0
ZW1lbnQgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0K
PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29O
b3JtYWw+RGVhciBhcHBsaWNhYmlsaXR5IGRyYWZ0IGF1dGhvcnMsPGJyPg0KPGJyPg0KUmVhZGlu
ZyBiYWNrIHRoZSBvbGQgRU1BTiBlbWFpbCwgSSBiZWxpZXZlIHRoYXQgTG9hZCBzaGVkZGluZyBv
cg0KRGVtYW5kL1Jlc3BvbnNlIHNob3VsZCBiZSBtZW50aW9uZWQgaW4gdGhlIEVNQU4gYXBwbGlj
YWJpbGl0eSBzdGF0ZW1lbnQuIE5vdA0Kc3BlY2lmaWNhbGx5IGFzIHVzZSBjYXNlcyB0aGF0IEVN
QU4gc2hvdWxkIHNvbHZlLCBidXQgYXMgdXNlIGNhc2VzIHdoZXJlIEVNQU4gY291bGQNCmhlbHAu
PGJyPg0KPGJyPg0KUmVnYXJkcywgQmVub2l0IChhcyBhIGNvbnRyaWJ1dG9yKTxicj4NCjxicj4N
CjxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h
cmdpbi1ib3R0b206MTIuMHB0Jz5CZW5vaXQsPGJyPg0KPGJyPg0KSSB3b3VsZCBzYXkgdGhhdCBz
ZXJ2aWNlcyBzdWNoIGFzIExvYWQgc2hlZGRpbmcgb3IgRGVtYW5kL1Jlc3BvbnNlIHNob3VsZCBn
byBhcw0KZXhhbXBsZXMgaW4gdGhlIGFwcHJvcHJpYXRlIHNlY3Rpb24gc3VjaCBhczxicj4NCkhv
bWUgRW5lcmd5LCBEYXRhIENlbnRlciwuLi48YnI+DQo8YnI+DQpQYXRyaWNrPG86cD48L286cD48
L3A+DQoNCjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGln
bjpjZW50ZXInPg0KDQo8aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgaWQ9endj
aHI+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+RnJvbTogPC9iPiZxdW90O0Jl
bm9pdCBDbGFpc2UmcXVvdDsgPGENCmhyZWY9Im1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbSI+Jmx0
O2JjbGFpc2VAY2lzY28uY29tJmd0OzwvYT48YnI+DQo8Yj5UbzogPC9iPiZxdW90O1BhdHJpY2sg
R3Jvc3NldGV0ZSZxdW90OyA8YSBocmVmPSJtYWlsdG86cGdyb3NzZXRAY2lzY28uY29tIj4mbHQ7
cGdyb3NzZXRAY2lzY28uY29tJmd0OzwvYT48YnI+DQo8Yj5DYzogPC9iPjxhIGhyZWY9Im1haWx0
bzplbWFuQGlldGYub3JnIj5lbWFuQGlldGYub3JnPC9hPjxicj4NCjxiPlNlbnQ6IDwvYj5UaHVy
c2RheSwgTWFyY2ggMywgMjAxMSAyOjIyOjIyIFBNPGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBk
cmFmdC1pZXRmLWVtYW4tcmVxdWlyZW1lbnRzLTAwIHJldmlldzxicj4NCjxicj4NCkhpIFBhdHJp
Y2ssPGJyPg0KPGJyPg0KVGhhbmtzIGZvciBhIGxvdCBmb3IgeW91ciByZXZpZXcuPGJyPg0KU2Vl
IGlubGluZSBmb3Igb25lIHBhcnRpY3VsYXIgcG9pbnQuPGJyPg0KPGJyPg0KPG86cD48L286cD48
L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48YnI+DQo8YnI+DQo8bzpwPjwvbzpw
PjwvcD4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPkJlbm9pdCw8YnI+
DQo8YnI+DQpQbGVhc2UsIGZpbmQgbXkgY29tbWVudHMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZW1h
bi1yZXF1aXJlbWVudHMtMDAuIEkgd3JvdGUNCnRoZW0gd2hpbGUgcmVhZGluZyB0aGUgZG9jLCBz
byB0aGVyZSBpcyBubyBwcmlvcml0eSBvcmRlci48YnI+DQo8YnI+DQpCZXN0IFJlZ2FyZHM8YnI+
DQpQYXRyaWNrPGJyPg0KJm5ic3A7PGJyPg0KPGJyPg0KLSBwYWdlIDQtNSwgaXQgc2hvdWxkIGJl
IGFkZGVkIHRoYXQgZW52aXJvbm1lbnRhbCBjb25kaXRpb25zIG1heSBhbHNvIGltcGFjdA0KdGhl
IHBvdGVudGlhbCByZWR1Y3Rpb24gb2YgcG93ZXIgY29uc3VtcHRpb24uIFRoZXJlIGlzIG9mdGVu
IGEgbGluayBiZXR3ZWVuPGJyPg0KdGVtcGVyYXR1cmUvUkggYW5kIHBvd2VyLi4uZm9yIGV4YW1w
bGUsIHNlZSBBU0hSQUUgc3BlY2lmaWNhdGlvbnMgZm9yDQpEYXRhQ2VudGVyIChQVUUgYW5kIERD
SUUgbWV0cmljcykuIEl0IG1heSBhbHNvIGJlIG5vdGljZWQgdGhhdCBzaWRlIGVmZmVjdHMgbWF5
DQpvY2N1ci48YnI+DQpGb3IgZXhhbXBsZSwgSSBoYXZlIHNlZW4gcGVvcGxlIGluY3JlYXNpbmcg
dGhlIHRlbXBlcmF0dXJlIGluIHRoZWlyIGRhdGFjZW50ZXINCnRvIGNvbXBseSB3aXRoIFBVRSBt
ZXRyaWMgYnV0IGluIGZhY3QgZ2V0dGluZyBmYW4gc3BlZWQgaW5jcmVhc2Ugb24gdGhlaXINCnNl
cnZlcnM8YnI+DQphbmQgbGVhZGluZyB0byBmYWxzZSBjb25jbHVzaW9uIG9mIG1ldHJpY3Mgc2lu
Y2UgdGhlIHBvd2VyIGNvbnN1bXB0aW9uIHdhcyBzZWVuDQphcyAmcXVvdDtnb29kJnF1b3Q7IGZv
ciBQVUUgY29tcHV0YXRpb24uIENsZWFybHksIHRoZSBjYXBhYmlsaXR5IHRvIG1vbml0b3I8YnI+
DQplbmVyZ3kgY29uc3VtcHRpb24gb2Ygc2VydmVycyB3b3VsZCBoYXZlIGluZGljYXRlZCB0aGF0
Ljxicj4NCjxicj4NCi0gcGFnZSA1LCBtb25pdG9yaW5nIGVuZXJneSBjb25zdW1wdGlvbiBjYW4g
YWxzbyBoZWxwIHRvIGNoZWNrIGNvbXBsaWFuY3kgd2l0aA0KbWFuZGF0ZXMvcmVndWxhdGlvbnMv
cmVjb21tZW5kYXRpb25zIHN1Y2ggYXMgQVNIUkFFIG9yIE5USUE8YnI+DQo8YnI+DQotIHBhZ2Ug
NiwgSSB3b3VsZCBoYXZlIHNwbGl0IHRoaXMgY2F0ZWdvcnkgYXMgJnF1b3Q7c2VydmVycyBhbmQg
aG9zdHMmcXVvdDsNCmFscmVhZHkgaW1wbGVtZW50IHNvbWUgcG93ZXIgY29uc3VtcHRpb24gbWV0
cmljcyBzdWNoIGFzIElQTUkgb24gc2VydmVycywgPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0K
DQo8L2Rpdj4NCg0KPGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYgaWQ9Im1jZV8wIj4NCg0KPHAgY2xhc3M9TXNv
Tm9ybWFsPmFuZCBuZXcgZ2VuZXJhdGlvbiBDUFUgb2ZmZXJzIGRpZmZlcmVudCBwb3dlciBzdGF0
ZSBsZXZlbCAuPGJyPg0KU2VjdGlvbiAyIGlzIGluY29tcGxldGUgaWYgd2UgZG9uJ3QgaW50cm9k
dWNlIGluIHRoZSBzY2VuYXJpbywgc2VydmljZXMgc3VjaCBhcw0KRGVtYW5kL1Jlc3BvbnNlIGFu
ZCBMb2FkIFNoZWRkaW5nIHdoaWNoIG1heSBhcHBseSB0byBkaWZmZXJlbnQgMi54IHNlY3Rpb25z
PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ibG9ja3F1b3RlPg0KDQo8
L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPlJpZ2h0LCB3ZSBjb3VsZCBhZGQgdGhlbSBhcyB0
aGV5IHdpbGwgPHU+aW5mbHVlbmNlIDwvdT50aGUNCmRpZmZlcmVudCB1c2UgY2FzZXMgaW4gPG86
cD48L286cD48L3A+DQoNCjxwcmU+wqDCoMKgIMKgPGENCmhyZWY9Imh0dHA6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWlldGYtZW1hbi1yZXF1aXJlbWVudHMtMDAjc2VjdGlvbi0yLjEiDQp0
YXJnZXQ9Il9ibGFuayI+Mi4xPC9hPi7CoCBTY2VuYXJpbyAxOiBSb3V0ZXJzLCBzd2l0Y2hlcywg
bWlkZGxlYm94ZXMsIGFuZCBob3N0c8KgIC4gLiDCoDxhDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWVtYW4tcmVxdWlyZW1lbnRzLTAwI3BhZ2UtNiINCnRhcmdl
dD0iX2JsYW5rIj42PC9hPjxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqDCoCAyLjIuwqAgU2Nl
bmFyaW8gMjogUG9FIHNvdXJjaW5nIGVxdWlwbWVudCBhbmQgUG9FIHBvd2VyZWQ8bzpwPjwvbzpw
PjwvcHJlPjxwcmU+wqDCoMKgwqDCoMKgwqDCoMKgwqAgZGV2aWNlc8KgIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gwqA8YQ0KaHJlZj0iaHR0cDovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1lbWFuLXJlcXVpcmVtZW50cy0wMCNwYWdlLTci
DQp0YXJnZXQ9Il9ibGFuayI+NzwvYT48bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoMKgIMKgPGEN
CmhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZW1hbi1yZXF1aXJl
bWVudHMtMDAjc2VjdGlvbi0yLjMiDQp0YXJnZXQ9Il9ibGFuayI+Mi4zPC9hPi7CoCBTY2VuYXJp
byAzOiBQb3dlciBwcm9iZXMgYW5kIFNtYXJ0IG1ldGVyc8KgIC4gLiAuIC4gLiAuIC4gLiDCoDxh
DQpocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWVtYW4tcmVxdWly
ZW1lbnRzLTAwI3BhZ2UtNyINCnRhcmdldD0iX2JsYW5rIj43PC9hPjxvOnA+PC9vOnA+PC9wcmU+
PHByZT7CoMKgwqAgwqA8YQ0KaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
aWV0Zi1lbWFuLXJlcXVpcmVtZW50cy0wMCNzZWN0aW9uLTIuNCINCnRhcmdldD0iX2JsYW5rIj4y
LjQ8L2E+LsKgIFNjZW5hcmlvIDQ6IE1pZC1sZXZlbCBtYW5hZ2VycyAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gwqA8YQ0KaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
aWV0Zi1lbWFuLXJlcXVpcmVtZW50cy0wMCNwYWdlLTciDQp0YXJnZXQ9Il9ibGFuayI+NzwvYT48
bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoMKgIMKgPGENCmhyZWY9Imh0dHA6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWlldGYtZW1hbi1yZXF1aXJlbWVudHMtMDAjc2VjdGlvbi0yLjUiDQp0
YXJnZXQ9Il9ibGFuayI+Mi41PC9hPi7CoCBTY2VuYXJpbyA1OiBHYXRld2F5cyB0byBidWlsZGlu
ZyBuZXR3b3Jrc8KgIC4gLiAuIC4gLiAuIC4gLiDCoDxhDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWVtYW4tcmVxdWlyZW1lbnRzLTAwI3BhZ2UtNyINCnRhcmdl
dD0iX2JsYW5rIj43PC9hPjxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqAgwqA8YQ0KaHJlZj0i
aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1lbWFuLXJlcXVpcmVtZW50cy0w
MCNzZWN0aW9uLTIuNiINCnRhcmdldD0iX2JsYW5rIj4yLjY8L2E+LsKgIFNjZW5hcmlvIDY6IEhv
bWUgZW5lcmd5IGdhdGV3YXlzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gwqA8YQ0KaHJlZj0i
aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1lbWFuLXJlcXVpcmVtZW50cy0w
MCNwYWdlLTgiDQp0YXJnZXQ9Il9ibGFuayI+ODwvYT48bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDC
oMKgIMKgPGENCmhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZW1h
bi1yZXF1aXJlbWVudHMtMDAjc2VjdGlvbi0yLjciDQp0YXJnZXQ9Il9ibGFuayI+Mi43PC9hPi7C
oCBTY2VuYXJpbyA3OiBEYXRhIGNlbnRlciBkZXZpY2VzwqAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiDCoDxhDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWVt
YW4tcmVxdWlyZW1lbnRzLTAwI3BhZ2UtOCINCnRhcmdldD0iX2JsYW5rIj44PC9hPjxvOnA+PC9v
OnA+PC9wcmU+PHByZT7CoMKgwqAgwqA8YQ0KaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtaWV0Zi1lbWFuLXJlcXVpcmVtZW50cy0wMCNzZWN0aW9uLTIuOCINCnRhcmdldD0i
X2JsYW5rIj4yLjg8L2E+LsKgIFNjZW5hcmlvIDg6IEJhdHRlcnkgcG93ZXJlZCBkZXZpY2VzwqAg
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIMKgPGENCmhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWlldGYtZW1hbi1yZXF1aXJlbWVudHMtMDAjcGFnZS04Ig0KdGFyZ2V0PSJfYmxh
bmsiPjg8L2E+PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHBy
ZT5CeSBpbmZsdWVuY2luZywgSSBtZWFuIHRoYXQgdGhlIGRlbWFuZC9yZXNwb25zZSBmb3IgcG9s
aWNpZXMgaW4gdGhlc2UgdXNlIGNhc2VzIC48bzpwPjwvbzpwPjwvcHJlPjxwcmU+SG93ZXZlciwg
SSB3b3VsZCBub3QgbGlzdCBkZW1hbmQvcmVzcG9uc2UgYXQgdGhlIHNhbWUgbGV2ZWwgYXMgdGhl
c2UgdXNlIGNhc2VzLCBhcyB0aGUgc2VjdGlvbiAyIGludHJvZHVjdGlvbiBleHBsYWluczo8bzpw
PjwvbzpwPjwvcHJlPg0KDQo8aDI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l
dyInPjIuwqAgU2NlbmFyaW9zIGFuZCB0YXJnZXQgZGV2aWNlczxvOnA+PC9vOnA+PC9zcGFuPjwv
aDI+DQoNCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPsKgwqAgVGhpcyBzZWN0aW9u
IGRlc2NyaWJlcyBhIHNlbGVjdGlvbiBvZiBzY2VuYXJpb3MgZm9yIHRoZSBhcHBsaWNhdGlvbjxv
OnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgIG9mIGVuZXJneSBtYW5hZ2VtZW50LsKgIEZvciBlYWNo
IHNjZW5hcmlvIGEgbGlzdCBvZiB0YXJnZXQgZGV2aWNlcyBpczxvOnA+PC9vOnA+PC9wcmU+PHBy
ZT7CoMKgIGdpdmVuIGluIHRoZSBoZWFkbGluZSwgZm9yIHdoaWNoIElFVEYgZW5lcmd5IG1hbmFn
ZW1lbnQgc3RhbmRhcmRzIGFyZTxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgIG5lZWRlZC48bzpw
PjwvbzpwPjwvcHJlPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPg0KQW5kIHRoZSBFTUFOIFdH
IHdpbGwgbm90IGJlIHNvbHZpbmcgdGhlIGRlbWFuZC9yZXNwb25zZSBwcm9ibGVtOiBpdCB3aWxs
DQomcXVvdDtqdXN0JnF1b3Q7IHByb2R1Y2Ugb25lIHBpZWNlIG9mIHRoZSBwdXp6bGU8YnI+DQo8
YnI+DQpSZWdhcmRzLCBCZW5vaXQuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQoNCjxkaXY+
DQoNCjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPg0KLSBwYWdl
IDgsIHNlY3Rpb24gMi43IC0gb2J2aW91c2x5IG5vdCBtZW50aW9uaW5nIEFTSFJBRSByZWNvbW1l
bmRhdGlvbnMNCihQVUUvRENJRSkgaXMgbm90IGFja25vd2xlZGdpbmcgaW5kdXN0cnkgc3RhbmRh
cmRzIGZvciBlbmVyZ3kgbW9uaXRvcmluZzxicj4NCmluIGRhdGFjZW50ZXJzLjxicj4NCjxicj4N
Ci0gcGFnZSA5LCBzZWN0aW9uIDMuMiAtIGFnZ3JlZ2F0aW9uIG9mIGVuZXJneSBkYXRhIGlzIHJl
YWxseSB3aGF0IGhlbHBzDQpmYWNpbGl0eSBtYW5hZ2VycyB0byB1bmRlcnN0YW5kIHdoZXJlIHRo
ZXkgY291bGQgc2F2ZSBtb25leS48YnI+DQppbiBmYWN0LCB0aGVyZSB3b3VsZCBiZSBhIG5lZWQg
dG8gZGlzY3VzcyBob3cgYWdncmVnYXRpb24gY2FuIGJlIGRvbmUuIEl0IGNvdWxkDQpiZSBhcyBz
aW1wbGUgYXMgbW9uaXRvcmluZyBhbGwgcGh5c2ljYWwgZGlzdHJpYnV0aW9uIGNpcmN1aXRzPGJy
Pg0KYnV0IGNvdWxkIGFsc28gYmUgYWdncmVnYXRlZCBieSBjYXRlZ29yaWVzIHN1Y2ggYXMgZW5n
aW5lZXJpbmcvc2FsZXMvbWFya2V0aW5nDQpkZXBhcnRtZW50cyBvciBoZWF0aW5nL2Nvb2xpbmcv
SVQvbGlnaHRzLC4uLjxicj4NClRvIGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGNvbnN1bXB0aW9uLCB5
b3UgYWxzbyBuZWVkIHRvIGRlZmluZSB0aGUNCiZxdW90O2FnZ3JlZ2F0aW9uIHBvaW50JnF1b3Q7
IHRvIGNvbnNpZGVyIHdoYXQgaXMgY291bnRlZCBkb3duc3RyZWFtIGFuZA0KdXBzdHJlYW0uPGJy
Pg0KRm9yIGV4YW1wbGUsIGRhdGEgcmV0cmlldmVkIG9uIGEgc2VydmVyIG9yIHJvdXRlciB3aWxs
IGJlIGEgcG9ydGlvbiBvZiBkYXRhDQpyZXRyaWV2ZWQgb24gYSBzbWFydCBwbHVnIGNvbm5lY3Rp
bmcgYWxsIHRoZXNlIGRldmljZXMgd2hpY2ggd2lsbCBiZSBhIHBvcnRpb248YnI+DQpvZiBkYXRh
IHJldHJpZXZlZCBhdCBhIHNtYXJ0IGNpcmN1aXQgYnJlYWtlciBsZXZlbCwgYW5kIHNvIG9uLjxi
cj4NCjxicj4NCi0gcGFnZSAxMSwgc2VjdGlvbiAzLjQuMiwgeW91IGNvdWxkIGFsc28gaW5kaWNh
dGU6IGxpbmUgZnJlcXVlbmN5LCBwb3dlcg0KZmFjdG9yLCBhcHBhcmVudCBwb3dlciwgcmVhY3Rp
dmUgcG93ZXIsLi4uIGFzIG1ldHJpY3MgYmVpbmcgYXZhaWxhYmxlIG9uDQpjZXJ0YWluPGJyPg0K
Y2F0ZWdvcnkgb2YgZGV2aWNlcy48YnI+DQo8YnI+DQotIHBhZ2UgMTIsIHNlY3Rpb24gMy40LjQs
IHlvdSBtYXkgd2FudCB0byBjb21wYXJlIHdpdGggZXhpc3RpbmcgTUlCIHN1Y2ggYXMgVVBTDQp2
ZW5kb3IncyBNSUJzPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ibG9j
a3F1b3RlPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwv
ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2
Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0K
DQo8L2JvZHk+DQoNCjwvaHRtbD4NCg==

------_=_NextPart_001_01CC4BD4.3761A192--

From jparello@cisco.com  Tue Jul 26 15:10:20 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAE621F87C7 for ; Tue, 26 Jul 2011 15:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30EeLu6UM5mw for ; Tue, 26 Jul 2011 15:10:19 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D261021F85FF for ; Tue, 26 Jul 2011 15:10:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=13253; q=dns/txt; s=iport; t=1311718219; x=1312927819; h=mime-version:subject:date:message-id:references:from:to: cc; bh=szoJvFEIwNkrWaVJdv3liTXTpoMnyiLMa9XwwWOIiic=; b=GZsFrX4cz5QhnmoMAEuuM0u87xNn6sX67Y5i0K5EJTSCX+jFAL4y1W2t lpVeqHLjU6S7FFGL8vwRj3SlACzoX2RGi221kBppKt/dBNkd4ZpOLJvLu QHDh7K0ndgCKySNmYwQft7vMp9LwORxhL46ME0wzyJPcBw9vnH0ePgqol c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiABACo6L06rRDoI/2dsb2JhbAA1AQEBAQIBAQEBEQEMEgNECwUHBQIBCQ4DBAEBCwYjAQYBExgjDggBAQUXDBuXTkWGZwGIL3eIfASjPp5QhWFfBIcoL5Ari3A
X-IronPort-AV: E=Sophos;i="4.67,271,1309737600"; d="scan'208,217";a="6672484"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-2.cisco.com with ESMTP; 26 Jul 2011 22:10:08 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6QMA8Iv007082; Tue, 26 Jul 2011 22:10:08 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 26 Jul 2011 15:10:07 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4BE0.C74CC8E6"
Date: Tue, 26 Jul 2011 15:10:07 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - open issue 12.3:time series of energy/power values
Thread-Index: AcxLy7MWR+zsK766QdO4q+9iKEAs2gAEpNN7
References:  <54ECD73F-B9A8-440F-970B-B9DD538CA186@quittek.at>  <4299FFDD-DA45-41BD-803E-4606AB4AA284@quittek.at>
From: "John Parello (jparello)" 
To: "Juergen Quittek" 
X-OriginalArrivalTime: 26 Jul 2011 22:10:07.0946 (UTC) FILETIME=[C78B62A0:01CC4BE0]
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:time series of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 22:10:20 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4BE0.C74CC8E6
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi Jeurgen,

We need to express power, energy as a measurement (scalar).

For time series (vector) IMO having the capability of providing power =
over time series (which is demand) or energy over time is valuable and =
should not be excluded.  Even though for energy an odometer can suffice =
I see no need to prevent this for devices that have this capability.


Please take a look at the draft-claise-energy-monitoring-mib.  I think =
they did a good job of providing time series modeling that covers this.

thanks
Jp








-----Original Message-----
From: Juergen Quittek [mailto:ietf@quittek.at]
Sent: Tue 7/26/2011 12:39 PM
To: John Parello (jparello)
Cc: Mouli Chandramouli (moulchan); eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue =
12.3:time series of energy/power values
=20
Hi John,

We are currently not discussing optional or mandatory implementation.

The question is whether or not we have a requirement for specifying a =
standard for reporting both, energy time series and power time series, =
or just one of them. What compliant devices must implement is an issue =
to be discussed later.

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

Thanks,

    Juergen

Am 26.07.2011 um 13:08 schrieb John Parello (jparello):

> Hi Jeurgen,
>=20
> I tend to agree, for simple devices an energy odometer(s) as describe
> from the comments and what I presented from the ODVA suffices.
>=20
> For time series of data like historical demand devices such as PDUs =
very
> typically store this. Some our as long as a year's worth of data on =
the
> device. For the very reason that Bill pointed out.
>=20
> So it would seem that a power value and an energy odometer could be a
> required minimum and then time series of power or demand can be
> optional.=20
>=20
> We specified a power value as required in the monitoring mib with time
> series of power and demand as optional.
>=20
> Jp
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of
> Juergen Quittek
> Sent: Wednesday, July 13, 2011 5:53 AM
> To: Mouli Chandramouli (moulchan)
> Cc: eman mailing list
> Subject: Re: [eman] new revision of eman requirements - open issue
> 12.3:time series of energy/power values
>=20
> Dear Mouli,
>=20
> Thank you for commenting on this issue. I would like to have a look at
> the following point of view:
>=20
> So far, storing time series of measurements on managed nodes is rarely
> standardized and rarely available as implementation.
>=20
> Typically, it is the job of a network management system to collect =
time
> series and store them.
>=20
> Take for example byte and packet counters at line cards. You see many
> curves showing time series of traffic rate/volume in the Internet, but
> almost all of them were collected at management stations or data
> collector modules, but not within MIB modules. (Please correct me if =
I'm
> wrong.)=20
>=20
> Now the question is: Is energy management so much different from other
> network management tasks, that we need the rarely used mechanism of
> storing time series in MIB modules?
>=20
> If not, it would be sufficient to just report the number of total =
energy
> consumed since the last re-start as you do it with packet and byte
> counters.
> This would be just a single managed object to be specified and
> implemented.
>=20
> Thanks,
>=20
>    Juergen
>=20
> Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):
>=20
>> Regarding the Time Series debate - the crucial question - where is =
the
>> data / measurements stored.=20
>> It would not be possible for small devices to store such data for a
>> sufficiently long time period.=20
>>=20
>> The NMS can store the values for a sufficiently long period of time,
> for
>> trending analysis.=20
>>=20
>> In the case of demand measurement, since the maximum over a window is
>> computed, it is important for the device store atleast a window =
length
>> of measurements.=20
>>=20
>> I am not sure about that Requirement 5.4.10 - Time Series of Power
>> Values - to be stored in the device
>>=20
>> Thanks
>> Mouli
>>=20
>>=20
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
> Of
>> Juergen Quittek
>> Sent: Tuesday, July 12, 2011 2:31 PM
>> To: eman mailing list
>> Subject: [eman] new revision of eman requirements
>>=20
>> Dear all,
>>=20
>> I posted a new version of the eman requirements yesterday.
>> Please find it at=20
>> http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/
>>=20
>>=20
>> Of course, feel free to also comment on the other open issues or to
>> raise
>> new ones. All such contributions are highly appreciated.
>>=20
>> Thanks,
>>=20
>>   Juergen
>>=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
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman



------_=_NextPart_001_01CC4BE0.C74CC8E6
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






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







Hi Jeurgen,



We need to express power, energy as a measurement (scalar).



For time series (vector) IMO having the capability of providing power =
over time series (which is demand) or energy over time is valuable and =
should not be excluded.  Even though for energy an odometer can =
suffice I see no need to prevent this for devices that have this =
capability.





Please take a look at the draft-claise-energy-monitoring-mib.  I =
think they did a good job of providing time series modeling that covers =
this.



thanks

Jp

















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

From: Juergen Quittek [mailto:ietf@quittek.at]

Sent: Tue 7/26/2011 12:39 PM

To: John Parello (jparello)

Cc: Mouli Chandramouli (moulchan); eman mailing list

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



Hi John,



We are currently not discussing optional or mandatory =
implementation.



The question is whether or not we have a requirement for specifying a =
standard for reporting both, energy time series and power time series, =
or just one of them. What compliant devices must implement is an issue =
to be discussed later.



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



Thanks,



    Juergen



Am 26.07.2011 um 13:08 schrieb John Parello (jparello):



> Hi Jeurgen,

>

> I tend to agree, for simple devices an energy odometer(s) as =
describe

> from the comments and what I presented from the ODVA suffices.

>

> For time series of data like historical demand devices such as PDUs =
very

> typically store this. Some our as long as a year's worth of data on =
the

> device. For the very reason that Bill pointed out.

>

> So it would seem that a power value and an energy odometer could be =
a

> required minimum and then time series of power or demand can be

> optional.

>

> We specified a power value as required in the monitoring mib with =
time

> series of power and demand as optional.

>

> Jp

>

> -----Original Message-----

> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] =
On Behalf Of

> Juergen Quittek

> Sent: Wednesday, July 13, 2011 5:53 AM

> To: Mouli Chandramouli (moulchan)

> Cc: eman mailing list

> Subject: Re: [eman] new revision of eman requirements - open =
issue

> 12.3:time series of energy/power values

>

> Dear Mouli,

>

> Thank you for commenting on this issue. I would like to have a look =
at

> the following point of view:

>

> So far, storing time series of measurements on managed nodes is =
rarely

> standardized and rarely available as implementation.

>

> Typically, it is the job of a network management system to collect =
time

> series and store them.

>

> Take for example byte and packet counters at line cards. You see =
many

> curves showing time series of traffic rate/volume in the Internet, =
but

> almost all of them were collected at management stations or =
data

> collector modules, but not within MIB modules. (Please correct me =
if I'm

> wrong.)

>

> Now the question is: Is energy management so much different from =
other

> network management tasks, that we need the rarely used mechanism =
of

> storing time series in MIB modules?

>

> If not, it would be sufficient to just report the number of total =
energy

> consumed since the last re-start as you do it with packet and =
byte

> counters.

> This would be just a single managed object to be specified and

> implemented.

>

> Thanks,

>

>    Juergen

>

> Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):

>

>> Regarding the Time Series debate - the crucial question - where =
is the

>> data / measurements stored.

>> It would not be possible for small devices to store such data =
for a

>> sufficiently long time period.

>>

>> The NMS can store the values for a sufficiently long period of =
time,

> for

>> trending analysis.

>>

>> In the case of demand measurement, since the maximum over a =
window is

>> computed, it is important for the device store atleast a window =
length

>> of measurements.

>>

>> I am not sure about that Requirement 5.4.10 - Time Series of =
Power

>> Values - to be stored in the device

>>

>> Thanks

>> Mouli

>>

>>

>> -----Original Message-----

>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] =
On Behalf

> Of

>> Juergen Quittek

>> Sent: Tuesday, July 12, 2011 2:31 PM

>> To: eman mailing list

>> Subject: [eman] new revision of eman requirements

>>

>> Dear all,

>>

>> I posted a new version of the eman requirements yesterday.

>> Please find it at

>> ht=
tp://datatracker.ietf.org/doc/draft-ietf-eman-requirements/

>>

>>

>> Of course, feel free to also comment on the other open issues =
or to

>> raise

>> new ones. All such contributions are highly appreciated.

>>

>> Thanks,

>>

>>   Juergen

>>

>> _______________________________________________

>> eman mailing list

>> eman@ietf.org

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

>> _______________________________________________

>> eman mailing list

>> eman@ietf.org

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

>

> _______________________________________________

> eman mailing list

> eman@ietf.org

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











------_=_NextPart_001_01CC4BE0.C74CC8E6--

From ietf@quittek.at  Tue Jul 26 16:08:20 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2ED711E80BE for ; Tue, 26 Jul 2011 16:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.504
X-Spam-Level: 
X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG6Jjejz0wzY for ; Tue, 26 Jul 2011 16:08:20 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id D4B3C11E809E for ; Tue, 26 Jul 2011 16:08:19 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MfB7K-1R52YF3WKQ-00OLuM; Wed, 27 Jul 2011 01:08:18 +0200
From: Juergen Quittek 
Content-Type: text/plain; charset=us-ascii
Message-Id: <0F0F2CC7-42B9-44E3-93A3-5ADFC48091BD@quittek.at>
Date: Tue, 26 Jul 2011 19:08:16 -0400
To: eman mailing list 
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:maLMVwd1wUhcHNh25qk5zLUyQ3Wpg9+KyrF25oroyvG zwIHfSVbR8lK7zk97ftdBP4mOe8yW8TWPRpgRnCbjax3ypnyQQ M/09jTUbaWwWLgBk1dMaDQNrtR8FlItfdAI4wglWV6a6cOJXJg kkOb8IaS12Dpz8vUwRH7BeMk2I913Ptvoh5TJYbSGb4gzC85/N laia9I+Qssb7HfbzaiAd2H3yB4q267xx18Rx6jVmXs=
Subject: [eman] comments on draft-parello-eman-definitions-00
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 23:08:20 -0000

Hi John and all,=20

Thank you for writing a draft on terminology. This will speed up the =
process of finding the right definitions of the terms we are using.

I have several issues that I want to address, but writing all in one =
email will probably lead to a confusing discussion. Therefore, I will =
send individual email per term that we need to define.

Thanks,

    Juergen


From ietf@quittek.at  Tue Jul 26 16:22:13 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA85711E80BE for ; Tue, 26 Jul 2011 16:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.149,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 F+74dT8kVtcp for ; Tue, 26 Jul 2011 16:22:13 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id E745611E809E for ; Tue, 26 Jul 2011 16:22:12 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0M3u5q-1RcAgk2e4w-00qnp3; Wed, 27 Jul 2011 01:22:09 +0200
From: Juergen Quittek 
Content-Type: multipart/alternative; boundary=Apple-Mail-13-555362542
Message-Id: <0E1278EA-66B1-4299-AAF6-C75B45F09BC8@quittek.at>
Date: Tue, 26 Jul 2011 19:22:07 -0400
To: eman mailing list 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:qoG/Ls/2HsiORD08tZ9TcAeR47a+pA3yrvcWC2pOgCi gjmXW+pvZAa8/1SW9J9GNna0LC8GcdyXv7c/e3ZdS2tFqkAePZ RpAHI+8m5sA5K/9ejx5eQywuIXVWKK7abhyXd4+4pIQBnVTZ8i nm/SE111lD5cYehZkMYD45di+fCCddK8wE2YeOqP81+sYDQBIS IskpaqXaa+HZYzoOW7bfwpg5O8Dp/mtxi44ws45rxI=
Subject: [eman] Terminology: energy management system (was: Re: comments on draft-parello-eman-definitions-00)
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 23:22:13 -0000

--Apple-Mail-13-555362542
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi John,

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

>      Energy Management System (EnMS)=20
>=20
>        An EnMS is a set of systems or procedures upon which=20
>        organizations can develop and implement an energy policy, set=20=

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

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

>        energy performance and demonstrate conformity to requirements,=20=

>        standards and/or legal requirements.  =20
>        Example: =20
>        A set of workflow procedures setup by an organization to track=20=

>        and archive utility billing records to ensure an auditable=20
>        history of targets.=20
>        Reference:=20
>        [ISO50001]=20


and

>      Energy Management Systems =20
>=20
>        An Energy Management System (EMS) is congruent to a Network=20
>        Management System (NMS) and is a combination of hardware and=20
>        software used to administer a network with the primarily =
purpose=20
>        being Energy Management.=20
>        Example:=20
>        Reference:=20
>        Derived from [1037C]=20


We cannot go with two definitions.=20
Shall we merge them or drop one of them?

For the acronym: I would prefer using EnMS, because it avoids confusion =
with an=20
element management system which is typically referred to as EMS.

Thanks,

    Juergen

=20


--Apple-Mail-13-555362542
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
John,

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

     Energy =
Management System (EnMS) 

      =
 An EnMS is a set of systems or procedures upon =
which 
       organizations can develop =
and implement an energy policy, set 
      =
 targets, action plans and take into account legal =
requirements 
       related to energy use. =
 An EnMS allows organizations to =
improve 
       energy performance and =
demonstrate conformity to requirements, 
      =
 standards and/or legal requirements. =
  
       Example: =
 
       A set of workflow =
procedures setup by an organization to =
track 
       and archive utility billing =
records to ensure an auditable 
      =
 history of targets. 
      =
 Reference: 
      =
 [ISO50001] 

=

and

     Energy Management Systems =
 

       An Energy Management System =
(EMS) is congruent to a Network 
      =
 Management System (NMS) and is a combination of hardware =
and 
       software used to administer =
a network with the primarily purpose 
      =
 being Energy Management. 
      =
 Example: 
      =
 Reference: 
       Derived from =
[1037C] 

We cannot go with two definitions. 
Shall we merge them =
or drop one of them?

For the acronym: I would =
prefer using EnMS, because it avoids confusion with =
an 
element management system which is typically referred =
to as =
EMS.

Thanks,

  =
  =
Juergen

 

=

--Apple-Mail-13-555362542--

From ietf@quittek.at  Tue Jul 26 16:22:26 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911B511E80D4 for ; Tue, 26 Jul 2011 16:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=-0.621,  BAYES_05=-1.11, HELO_EQ_DE=0.35, 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 cZMgTK8Hravb for ; Tue, 26 Jul 2011 16:22:26 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id D172D11E80CF for ; Tue, 26 Jul 2011 16:22:25 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MHrmH-1QiGab2z4n-004L8g; Wed, 27 Jul 2011 01:22:25 +0200
References: <0F0F2CC7-42B9-44E3-93A3-5ADFC48091BD@quittek.at>
From: Juergen Quittek 
Content-Type: multipart/alternative; boundary=Apple-Mail-14-555379844
In-Reply-To: <0F0F2CC7-42B9-44E3-93A3-5ADFC48091BD@quittek.at>
Message-Id: <688494E6-FFE4-43AD-8075-FD2D894B4C41@quittek.at>
Date: Tue, 26 Jul 2011 19:22:25 -0400
To: eman mailing list 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:k7MHtjq2We4R6Y8Ktumby+CZruPRTtsXr+V/YQmd1Jy /In1a7TsqAFDNiyDyxLKVhTGAQxLOV5oSRnp90dcmABAQl65SD 2R65K8Ui8yUHaAXn3oxAID14rRdSdrZYAgmZ0zIOyFjuJ4OPXR q2+jKvIpzOHLvZzs18d58jjV60Wq/RAM2Ri2fpu610BIRVQqUn 4p32VtSvKjwbVrHak3X1w6bVa5jNIfvD6zjXDqSm0Q=
Subject: [eman] Terminology: energy
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 23:22:26 -0000

--Apple-Mail-14-555379844
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Hi John,

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

>      Energy  
> 
>        Energy is the capacity of a system to produce external activity 
>        or perform work and can be electricity, fuels, steam, heat, 
>        compressed air, and other like media. Energy is typically 
>        expressed in watt hours or joules.  
>        Example: 
>        Reference: 
>        [ISO50001] 


This is certainly not taken from an IEEE or IEC dictionary: 
Energy is not steam, it is not fuel, it is not compressed air.
Let's take reasonable text from a dictionary.

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

    Juergen
--Apple-Mail-14-555379844
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
John,

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

     Energy =
 

       Energy is the capacity of a =
system to produce external activity 
      =
 or perform work and can be electricity, fuels, steam, =
heat, 
       compressed air, and other =
like media. Energy is typically 
      =
 expressed in watt hours or joules.  
      =
 Example: 
      =
 Reference: 
      =
 [ISO50001] 

=

This is certainly not taken from an IEEE or IEC =
dictionary: 
Energy is not steam, it is not fuel, it is =
not compressed air.
Let's take reasonable text from a =
dictionary.

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

    =
Juergen
=

--Apple-Mail-14-555379844--

From ietf@quittek.at  Tue Jul 26 16:26:29 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0868411E80C0 for ; Tue, 26 Jul 2011 16:26:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.035
X-Spam-Level: 
X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=0.213,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 YmN4Dm4NK7rP for ; Tue, 26 Jul 2011 16:26:28 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4A89611E80BE for ; Tue, 26 Jul 2011 16:26:28 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LeSQX-1RDFkN3PtV-00qaYp; Wed, 27 Jul 2011 01:26:27 +0200
From: Juergen Quittek 
Content-Type: multipart/alternative; boundary=Apple-Mail-15-555620558
Message-Id: 
Date: Tue, 26 Jul 2011 19:26:25 -0400
To: eman mailing list 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:VQrMq8/4hHJoJ9bPkKFkrS+HTnfnjt7pPImPsilxhM7 CQuicwha/12LQoGE49wUD3VCPZUBPQLPhoDdcCYYMNL6WFfMLF sNH8WD9DCCe0HrZQgFTvupBb8tT1FafDAhLXOR9uQ5/M8McYQI TBYI6geK+7t/gcBKS7wRfzw/L8L/xi6PYjE7COgCXIZ9SWobe7 9gX24ATc8HoAqCiuULOKPu0zaWfCdDHZZQ/vu0Lbt4=
Subject: [eman] Terminology: power
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 23:26:29 -0000

--Apple-Mail-15-555620558
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi John,

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

>      Power=20
>=20
>        Power is a rate of energy conversion.  As the unit of time=20
>        approaches zero a power measurement is called an instantaneous=20=

>        power reading.  Typically when implementing Power monitoring in=20=

>        hardware, a measuring device may have to compute an average=20
>        value per some unit of time to express a reading to approximate=20=

>        an instantaneous power measurement. =20
>        Example:=20
>        Reference:=20
>        Derived from [ISO50001]=20


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

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

    Juergen

--Apple-Mail-15-555620558
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


     Power 

      =
 Power is a rate of energy conversion.  As the unit of =
time 
       approaches zero a power =
measurement is called an instantaneous 
      =
 power reading.  Typically when implementing Power monitoring =
in 
       hardware, a measuring =
device may have to compute an average 
      =
 value per some unit of time to express a reading to =
approximate 
       an instantaneous power =
measurement.  
      =
 Example: 
      =
 Reference: 
       Derived from =
[ISO50001] 

=

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

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

    =
Juergen
=

--Apple-Mail-15-555620558--

From ietf@quittek.at  Tue Jul 26 16:33:45 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C3721F8557 for ; Tue, 26 Jul 2011 16:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.062
X-Spam-Level: 
X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 cuM5rQfHJ1gV for ; Tue, 26 Jul 2011 16:33:45 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0291A21F8556 for ; Tue, 26 Jul 2011 16:33:45 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LdcDS-1RBsE13e4Y-00i6yd; Wed, 27 Jul 2011 01:33:44 +0200
From: Juergen Quittek 
Content-Type: multipart/alternative; boundary=Apple-Mail-17-556057714
Message-Id: <40A7C674-CDAA-4643-959A-D0C71FFC5735@quittek.at>
Date: Tue, 26 Jul 2011 19:33:42 -0400
To: eman mailing list 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:QYCHLB4lc7s/S+8lpsY23yXABa9jvUmWnFOlYkInWod DAn0MGlaHrjJDKYLu4oPlwwLAql/WjDid1lZg5UVxmssF1iBg1 VtSP/xZKVOfgIRvRLDl7Md6bkgaUioO1bCYonth39Dd8zIpr4U XSOt7nDvz5TFP6d3h3DRW35Hamibj+nNd9eiwqia7ZqaOp7WOT qgxyVFLPSllcBf3lBo7eqNfyGmbWpzTq95cT5z9xpU=
Subject: [eman] Termiology:
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 23:33:45 -0000

--Apple-Mail-17-556057714
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi John,

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

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

>         attached to a communications network that is monitored,=20
>         controlled, or aids in the management of another device for=20
>         Energy Management.=20


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

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

Thanks,

    Juergen=

--Apple-Mail-17-556057714
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
John,

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

     Energy Managed Object =
 

        An Energy Managed Object =
(EMO) is a device that is part of or 
        =
attached to a communications network that is =
monitored, 
        controlled, or aids in the =
management of another device for 
        =
Energy =
Management. 

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

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

Thanks,

<=
/div>
    Juergen
=

--Apple-Mail-17-556057714--

From ietf@quittek.at  Tue Jul 26 16:38:36 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB9F21F869C for ; Tue, 26 Jul 2011 16:38:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.083
X-Spam-Level: 
X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.165,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Q3kNToKxwkna for ; Tue, 26 Jul 2011 16:38:36 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id D6DE521F8678 for ; Tue, 26 Jul 2011 16:38:35 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MaDyS-1R1B8E180m-00KUvd; Wed, 27 Jul 2011 01:38:34 +0200
References: <40A7C674-CDAA-4643-959A-D0C71FFC5735@quittek.at>
In-Reply-To: <40A7C674-CDAA-4643-959A-D0C71FFC5735@quittek.at>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-18-556348060
Message-Id: <9609D991-4E63-4B99-BAEB-B38F1B40AEFD@quittek.at>
From: Juergen Quittek 
Date: Tue, 26 Jul 2011 19:38:33 -0400
To: Juergen Quittek 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:mjaDIjYBnNE7icr6GU3ZUyBSGVXs6eBtaGBONdnJvOi 28BT7Ztde+Ltd50tn5J+OzNWlZOoeJxY/RGRT8qYNpSMk497d2 MO7u6HFYIEKJRuwBdsweGiJmLp6YEwFdIPWS6Kxh3puT9H8suD L84yMgzwq//FkwoO1QvCEWtZ4EBPCVlufy4s9hqPxzyhi2ted3 ngLqQAaF9AngTAbnu6dr4Bp6truS1ZuRzP+qPP07oo=
Cc: eman mailing list 
Subject: Re: [eman] Termiology: energy managed object
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, 26 Jul 2011 23:38:36 -0000

--Apple-Mail-18-556348060
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Sorry, there was an incomplete subject line in the previous email.
Also a constructive suggestion was missing. Please ignore it.
Here come the revised version of it.

Am 26.07.2011 um 19:33 schrieb Juergen Quittek:

> Hi John,
>=20
> In draft-parello-eman-definitions-00 you define 'energy managed =
object' as:
>=20
>>      Energy Managed Object =20
>>=20
>>         An Energy Managed Object (EMO) is a device that is part of or=20=

>>         attached to a communications network that is monitored,=20
>>         controlled, or aids in the management of another device for=20=

>>         Energy Management.=20
>=20
>=20
> I have two issues here:
> =20
> 1. the term "managed object" is already in common use for the objects =
defined in a MIB module. Since we are also defining MIB modules, we will =
run into ambiguities and risk confusion of readers if we re-use the term =
here.
>=20
> 2. The attribute "managed" is confusing, because the term refers also =
to "unmanaged" objects that are neither monitored or controlled, but =
just "aid" in the management of other devices. These seem to be rather =
"managing" objects than "managed" objects.

I would suggest the following:
Let's use the term 'powered device' or 'powered entity'.
Powered device would also be in line with terminology in IEEE PoE.

Thanks,

    Juergen



--Apple-Mail-18-556348060
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Hi =
John,

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

    =
 Energy Managed Object  

        An Energy Managed =
Object (EMO) is a device that is part of or 
        attached to a =
communications network that is monitored, 
        controlled, or =
aids in the management of another device =
for 
  =
      Energy =
Management. 

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

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

I would suggest =
the following:
Let's use the term 'powered device' or 'powered =
entity'.
Powered device would also be in line with terminology =
in IEEE =
PoE.

Thanks,

  =
  Juergen


=

--Apple-Mail-18-556348060--

From ietf@quittek.at  Tue Jul 26 16:46:37 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF5721F86A0 for ; Tue, 26 Jul 2011 16:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.149,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 QfaynYYQujLm for ; Tue, 26 Jul 2011 16:46:37 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 24BFF21F869E for ; Tue, 26 Jul 2011 16:46:37 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MFyy6-1Qfpj33Mb0-00EUSI; Wed, 27 Jul 2011 01:46:36 +0200
From: Juergen Quittek 
Content-Type: multipart/alternative; boundary=Apple-Mail-19-556829654
Message-Id: 
Date: Tue, 26 Jul 2011 19:46:34 -0400
To: eman mailing list 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:7T6m7fFbfQ+tX+5VIgEBSL2xAyNAZR7/eSxycl2204G BFaY7NnUN1EhpBa893Brl8008ARTV9hT+FEU8hRWa02NJ+Ca4A D/U+sT4AWNTBLd3qga+01n9B2J9ou6IFAFnfoD26dPgTw+Gst9 NpRA9V9o0Sl4AyUlW1Jm5dilqWBiR7LUPPj+6oAhH9tSXdyVnF 2ZQeynUU02K40MzIzsRq5EVhoumb+sqNsenf84dPFc=
Subject: [eman] Terminology: energy control
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 23:46:37 -0000

--Apple-Mail-19-556829654
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi John,

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

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

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

>        order to optimize or ensure its efficiency.=20


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

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

What about the following?:

    Energy Control is a part of Energy Management that deals wit =
influencing the
    consumption of energy in a network of energy consuming devices.

Thanks,

    Juergen



--Apple-Mail-19-556829654
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


     Energy =
Control 

       Energy Control is a part of =
Energy Management that deals with 
      =
 modifying or setting the state of an Energy Managed Object =
in 
       order to optimize or ensure =
its =
efficiency. 

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

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

What about the =
following?:

    Energy Control =
is a part of Energy Management that deals wit influencing =
the
    consumption of energy in a network of energy =
consuming =
devices.

Thanks,

  =
  Juergen


=

--Apple-Mail-19-556829654--

From moulchan@cisco.com  Tue Jul 26 20:59:39 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AECE11E8074 for ; Tue, 26 Jul 2011 20:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.366
X-Spam-Level: 
X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjzhZIfJQEIJ for ; Tue, 26 Jul 2011 20:59:38 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8C12E11E8070 for ; Tue, 26 Jul 2011 20:59:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=551; q=dns/txt; s=iport; t=1311739178; x=1312948778; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+SfAQuT0q5KtmIGwa/vL1rh8nGn6IF2i33qONJfZf78=; b=PL5MUcrplAKdVre9FmJr19PImRs7kJl7NFBJMGn8ImiY5r3Uozorn3tG r9389y2HAgxl1tWXraiJBnK56MPO5pPFoW21nPDit0AjKU+L1FiAyZjto wFlCQD7FTgC9A8dCONIPQAoKJ8+8YcrPjfyuyDaCfsCVNQ5TtdP3mFLce E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAHiML06tJXHA/2dsb2JhbAA1AQEBAQMUASEKVgIBCSIGJAYBE1EBAQUBIhunKXesK55PhWFfBIdXkCuLbg
X-IronPort-AV: E=Sophos;i="4.67,273,1309737600";  d="scan'208";a="6772174"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jul 2011 03:59:38 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6R3xcSi029122;  Wed, 27 Jul 2011 03:59:38 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 26 Jul 2011 22:59:37 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Jul 2011 22:59:36 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - Requirement 5.3.2
Thread-Index: AcxAcisSZRUzanmdsk2o6MS8wxG5wAA6apSAAq0hzWA=
References:  
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Quittek" , "eman mailing list" 
X-OriginalArrivalTime: 27 Jul 2011 03:59:37.0614 (UTC) FILETIME=[9A70CAE0:01CC4C11]
Subject: Re: [eman] new revision of eman requirements - Requirement 5.3.2
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 03:59:39 -0000

Hi Juergen,

The requirement of corresponding outlet does not seem clear to me.=20

Does every device or component of the device (in the scope of EMAN) have
a corresponding outlet ?=20
Secondly, it would be useful to understand if this requirement would
help in solving a Energy monitoring problem.=20
It is not apparent to me.=20

In fact, IMHO, the entire section - 5.3. Power inlet and power outlet -
while some requirements may be useful, it may be useful to reexamine and
double check some of the requirements.=20

Thanks
Mouli



From moulchan@cisco.com  Tue Jul 26 21:07:08 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899005E801F for ; Tue, 26 Jul 2011 21:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.33
X-Spam-Level: 
X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=-0.731,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvcmxeNhiLEa for ; Tue, 26 Jul 2011 21:07:08 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC6F5E801C for ; Tue, 26 Jul 2011 21:07:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=496; q=dns/txt; s=iport; t=1311739628; x=1312949228; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=tjXc06iWTUXjqCQl7K5auz8C/Wbas7vVzrmgPkE/log=; b=O+ZWDbJgw+FeSZxNYgLhgwSkepEtxD8WDBSKHx+WycAJhqwoIxjeraYd 4DPI/DB/1uxPJBZZ3jShbPjNghbkGKJLC6trPG00krlxskYI93uBrKY8H jYckWDB5ttZPMfJd4e9oua5HUBLbAPV0DL1QvqRu6z7VBHp8LeQQq9llz k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAAuOL06tJXG//2dsb2JhbAA1AQEBAQMUASEKOhwCAQkiBiQGARNRAQEFASIbpyl3rAKeT4VhXwSHV5Ari24
X-IronPort-AV: E=Sophos;i="4.67,273,1309737600";  d="scan'208";a="6773649"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 27 Jul 2011 04:07:07 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6R477ix016723;  Wed, 27 Jul 2011 04:07:07 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 26 Jul 2011 23:07:07 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Jul 2011 23:07:06 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - Requirement 5.4.2
Thread-Index: AcxAcisSZRUzanmdsk2o6MS8wxG5wAA6apSAAq0hzWAAAFiHwA==
References:  
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Quittek" , "eman mailing list" 
X-OriginalArrivalTime: 27 Jul 2011 04:07:07.0011 (UTC) FILETIME=[A64D5530:01CC4C12]
Subject: Re: [eman] new revision of eman requirements - Requirement 5.4.2
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 04:07:08 -0000

Hi Juergen,

The requirement 5.4.2 of Power measurement interval needs to be
revisited.=20

There is a good discussion on the mailing list on what is instantaneous
power.=20

I presume, the power meter chip set shall make power measurements based
on "some" sampling scheme over a fixed interval.=20
But this sampling scheme would not change for measurement collected
every 10 minutes or so.=20

So, should this value be reported for every power measurement ? =20

Thanks
Mouli

From moulchan@cisco.com  Tue Jul 26 21:10:47 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BAE21F8584 for ; Tue, 26 Jul 2011 21:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.297
X-Spam-Level: 
X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0hBYBA3A656 for ; Tue, 26 Jul 2011 21:10:47 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F062221F8571 for ; Tue, 26 Jul 2011 21:10:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=172; q=dns/txt; s=iport; t=1311739847; x=1312949447; h=mime-version:content-transfer-encoding:subject:date: message-id:references:from:to; bh=78PhAy37w8HGVivmDkc5ZVgdEcIGGGzjb8S5ah/d+AY=; b=TCkRZAsOnl0Lz05G87ihXWqsFeco4oSU3qmPrtqs4j5Juo+8Awegy4sv XeIxxPX+Azwo5zzaZQ/hzccXF/Q13rZ8bKnScAb0gX/qCDAgrkEPlkD9x Z6zsy1BypRA11sfRHS+LvRcU79Zk/RCMB/wA5GoDXFgZWaDtEeD4Ew3OO s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EABSPL06tJV2Y/2dsb2JhbAA1AQEBAQMUASEKVgIBCSIGJAYBE1EBAQUBIhunKXesFp5PhWFfBIdXkCuLbg
X-IronPort-AV: E=Sophos;i="4.67,273,1309737600";  d="scan'208";a="6779651"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 27 Jul 2011 04:10:46 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6R4Akn6030405;  Wed, 27 Jul 2011 04:10:46 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 26 Jul 2011 23:10:45 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Jul 2011 23:10:44 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - Requirement 5.4.3
Thread-Index: AcxAcisSZRUzanmdsk2o6MS8wxG5wAA6apSAAq0hzWAAAFiHwAAAQMgQ
References:  
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Quittek" , "eman mailing list" 
X-OriginalArrivalTime: 27 Jul 2011 04:10:46.0002 (UTC) FILETIME=[28D4B520:01CC4C13]
Subject: Re: [eman] new revision of eman requirements - Requirement 5.4.3
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 04:10:47 -0000

The requirement title  5.4.3. Confidence in power values

Ccan be rephrased as 5.4.3. Measurement method=20

to be actual or estimated or unknown ...

Thanks
Mouli

From moulchan@cisco.com  Tue Jul 26 21:16:05 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4BE21F88A1 for ; Tue, 26 Jul 2011 21:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.266
X-Spam-Level: 
X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOCe8tQIPf4E for ; Tue, 26 Jul 2011 21:16:05 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id ED83521F8892 for ; Tue, 26 Jul 2011 21:16:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=435; q=dns/txt; s=iport; t=1311740165; x=1312949765; h=mime-version:content-transfer-encoding:subject:date: message-id:references:from:to; bh=f5vz6aACv24ayfw1nZQL7evNvP70t2N0rRfDz3QSN6s=; b=QteJOSdqWNRjKIHaqB+d3XQcJcH3avqR9Rfi8wuXW09IhD6Bg++YRNWO eBM/Du00iR6TO7eUa2vgZuAKq32gLWFsNoA9OO2BzXFiIJKEEB90zI2GE 1QLTWGPRzxRO9x2qcYM56kezJiguulGiuqYCcgYp/+Gie7rNjyq4Z+b5E M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAG6QL06tJXG+/2dsb2JhbAA1AQEBAQMUASEKVgIBCSIGBx0GARNRAQEFASIbpyl3rCieT4Mkgj1fBIdXkCuLbg
X-IronPort-AV: E=Sophos;i="4.67,273,1309737600";  d="scan'208";a="6775529"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 27 Jul 2011 04:16:04 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6R4G4G8003818;  Wed, 27 Jul 2011 04:16:04 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 26 Jul 2011 23:16:03 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Jul 2011 23:16:02 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - Requirement 7.2 
Thread-Index: AcxAcisSZRUzanmdsk2o6MS8wxG5wAA6apSAAq0hzWAAAFiHwAAAQMgQAAAeVXA=
References:  
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Quittek" , "eman mailing list" 
X-OriginalArrivalTime: 27 Jul 2011 04:16:03.0905 (UTC) FILETIME=[E650DB10:01CC4C13]
Subject: Re: [eman] new revision of eman requirements - Requirement 7.2
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 04:16:06 -0000

Hi Juergen,

Requirement 7.2. Identity of other powered entities on which is reported

Focuses on the Parent having knowledge of the children.=20

It is also useful to add a requirement - in the other direction also.=20

The energy management standard must provide means for specifying the
identity of the powered entity=20
Which shall monitor and report the power consumption of a given powered
entity.

Thanks
Mouli

From bnordman@lbl.gov  Tue Jul 26 21:59:41 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601B05E8023 for ; Tue, 26 Jul 2011 21:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level: 
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0kOTJE4p669 for ; Tue, 26 Jul 2011 21:59:39 -0700 (PDT)
Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id D101B5E801F for ; Tue, 26 Jul 2011 21:59:39 -0700 (PDT)
X-Ironport-SBRS: 4.4
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Al4CAPyZL05KfVM0kGdsb2JhbABQAmgvJAgvExMBBQErFw0agjaVWgGGaQGHM3MIFAEBAQEJCQ0HFAQhiQCiAYJSCp0agyQZgwMEknWMSjyDeA
X-IronPort-AV: E=Sophos;i="4.67,273,1309762800"; d="scan'208";a="46989103"
Received: from mail-gw0-f52.google.com ([74.125.83.52]) by ironport4.lbl.gov with ESMTP; 26 Jul 2011 21:59:38 -0700
Received: by gwj15 with SMTP id 15so1197482gwj.39 for ; Tue, 26 Jul 2011 21:59:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.116.5 with SMTP id o5mr5727928anc.60.1311742776944; Tue, 26 Jul 2011 21:59:36 -0700 (PDT)
Received: by 10.100.241.8 with HTTP; Tue, 26 Jul 2011 21:59:36 -0700 (PDT)
Date: Wed, 27 Jul 2011 00:59:36 -0400
Message-ID: 
From: Bruce Nordman 
To: eman mailing list 
Content-Type: multipart/alternative; boundary=0016e644d62a41a83a04a905ea1f
Subject: [eman] Terminology comments
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 04:59:41 -0000

--0016e644d62a41a83a04a905ea1f
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

John--

   Thanks much for putting together the Terminology draft.

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

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

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

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

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

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

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

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

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

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

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

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


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

--0016e644d62a41a83a04a905ea1f
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

John--

=A0=A0 Thanks much for putting together the Terminology draft=
.

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

the definition and comments.

Energy Monitoring 
--Add "Class=
ification," before context (this to speak to the topic of 
"Id=
entity" I have raised previously but which seems to be an overloaded t=
erm).


Energy and Power
--http://www.ietf.org/mail-archive/web/eman/curren=
t/msg00562.html
I posted some IEEE definitions in this message.=A0 I=
EEE seems closer to

energy than ISO.=A0 IEC is also an alternative.=A0 The IEC conveniently pro=
vides:
=A0 http://www.electropedia.org/iev/iev.nsf/welcome?openform
Unf=
ortunately, the "energy" and "power definitions from this ar=
e not

particularly useful, so I would stick with IEEE.=A0 It does define:
&quo=
t;(electrical) energy" as "the magnitude of an electricity supply=
, 
expressed in kilowatthours"

Energy Control
--"in =
order to optimize or ensure its efficiency" - this is one important re=
ason

for control but not the only one.=A0 I would move this to a comment and inc=
lude
other reasons, such as basic functionality, emergency conditions, e=
tc.

Energy Managed Object 
--Change to "Powered Device"=
.=A0 The definition says it is a device (and not a

component).=A0 We care about it because it is powered.

Energy Manage=
d Object Identification
--Move classification into its own term, separat=
e from identity.=A0 As the 
definition notes, identity is unique (or at =
least ideally so) parameters.

Classification is about membership in a group of devices.

Energy Man=
agement Domain
--Change to "Power Domain".=A0 Change definitio=
n to "An Power Domain is a 
name or name space that groups Powered =
Devices according to common

power delivery infrastructure so that they share a common fate and
their=
 consumption is aggregated."
--A note should observe that devices w=
ith multiple power inlets will not
have a defined Power Domain, but that=
 each power interface will be labeled

with the Power Domain that it is part of.
--The example is consistent as=
-is with the above edits.

Dependency Relationship
--This definiti=
on says that an EMO may be a component, whereas the EMO
definition says =
it is a device.=A0 Some EMAN capabilities apply to devices,

some to components, and many to both.=A0 The term "entity" is sui=
table for
referring to the combination of devices and components.=A0 We =
need to be clear
about which we are covering when any of these terms are=
 use.


Power State
--"A Power State can be viewed as" to "Se=
tting a Power State is".
--Or better yet, adopt the first sentence =
from IEEE 1621:
=A0=A0=A0 3.1.7 power state: A condition or mode of a de=
vice that broadly 

=A0=A0=A0 characterizes its capabilities, power consumption, power indicato=
r 
=A0=A0=A0 coding, and responsiveness to input. 
For reference, the=
 rest of the definition is:
=A0=A0=A0 Basic power states are on, sleep, =
and off. Devices may have multiple 

=A0=A0=A0 instances of one or more of the basic states (e.g. light sleep, d=
eep 
=A0=A0=A0 sleep), and need not have any sleep states. All devices h=
ave at least 
=A0=A0=A0 one on state, and at least one off state (unplug=
ged). The term =93power 

=A0=A0=A0 mode=94 may be substituted and has identical meaning.

Name=
plate Power
--In my line of work, this refers literally to the power lev=
el put on the
nameplate on the back of the products, sometimes specified=
 in W, and sometimes

only in amps.=A0 I have often been told that this is sometimes the safetyrating of the chassis, sometimes the safety rating of the power supply,or something else.=A0 I would go with some text saying it is the maximum<=
br>
power level declared by the manufacturer, leaving it open as to where tofind it (since some products do not have nameplates).
--The definition =
offered may be a useful value to have, but I would
choose a different na=
me.


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

Simple Device
--A network-connected Powered Device w=
ith a single power inlet and no 
power outlets.
(The point of adding =
this definition is that the vast majority of energy

use will be from devices like this but most complexity in EMAN is from non-=
simple
devices).


-- 
Bru=
ce Nordman
Lawrence Berk=
eley National Laboratory

eetd.lbl.gov/e=
a/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943


--0016e644d62a41a83a04a905ea1f--

From bill.mielke@alcatel-lucent.com  Tue Jul 26 22:13:15 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C97121F8A58 for ; Tue, 26 Jul 2011 22:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkwE-97EbOFW for ; Tue, 26 Jul 2011 22:13:14 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8B90821F8A51 for ; Tue, 26 Jul 2011 22:13:14 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p6R5DAn9011819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Jul 2011 00:13:11 -0500 (CDT)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6R5DA0i028978 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 27 Jul 2011 00:13:10 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 27 Jul 2011 00:13:10 -0500
From: "Mielke, William F (Bill)" 
To: eman mailing list 
Date: Wed, 27 Jul 2011 00:13:07 -0500
Thread-Topic: Comments on draft-ietf-eman-framework-02
Thread-Index: AcxMG96vtMXWJqcnRJqCzFNHY9fx7w==
Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7D8CA@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
Subject: [eman] Comments on draft-ietf-eman-framework-02
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 05:13:15 -0000

Provided below.  I will forward a copy of my annotated PDF file to the auth=
ors.  The PDF version also includes some minor corrections/suggestions whic=
h are not reproduced below.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

----------------------------------------------------------------
Comments on draft-ietf-eman-framework-02
----------------------------------------------------------------

General Comments:

1. Some portions of this document call out communications networks as a sub=
set of the larger energy management problem space.  It is not clear to me w=
hy we are doing so.  Perhaps we should be writing from a less communication=
s network developer frame of mind?

2. What is the intended relationship between this document and the Referenc=
e Model that Juergen and Bruce have been developing?  Does their's replace =
this?  Augment it somehow?  What?  They seem to be covering similar ground =
unless there is a nuance I am missing.

Deatiled Comments:

> - IPFIX or not? (Page 3)

I am OK with IPFIX being identified as an appropriate choice for PUSH mode =
time series data.  I would prefer not to preclude other options for that as=
 well, but I have none to offer at this time.  I feel that the standard can=
not mandate that compliant implementations include the use of IPFIX so any =
mention of it must be considered optional, IMHO.  It's use in diagrams as a=
n example it likewise fine as long as this is made clear.

> EDITOR'S NOTE: [EMAN-MON-MIB] and [EMAN-AS] are not EMAN working
> group documents. Hence, these references will be changed in the
> future. (Page 5)

I am confused by this statement.  What are the implications here?  Will the=
se eventually become WG documents even though they are not officially so no=
w, or does it mean that their contents will be merged into something else t=
hat IS a WG document?

> For an Energy Management framework to be useful, it should also
> apply to these types of separate networks as they connect and
> interact with a communications network. (Page 6)

I understand the point being made here but I believe the presentation can b=
e simplified by simply declaring that there are two separate networks: the =
power distribution network which is responsible for the supply of electrica=
l energy to various devices and their components, and the control network w=
hich is used to to monitor and control the flow of energy throughout the po=
wer distribution network.

In network management systems we frequently talk about there being a "Data =
Plane" and a "Control Plan".  This is a similar concept to what we have as =
well.

> 3. Terminology (Page 6)

There seems to be an effort underway to standardize on some of this termino=
logy.  I assume that this section will be updated to be consistent with the=
 outcome of that effort.

> An Energy Managed Object (EMO) is a device that is part of or
> attached to a communications network that is monitored,
> controlled, or aids in the management of another device for
> Energy Management. (Page 8)

We seem to be focusing on the communications connectivity here rather than =
the fact that and EMO is a powered device (i.e. connected to a Power Distri=
bution Network) whose energy consumption can be monitored and controlled vi=
a a communications network (Control Network).

> Energy Managed Object Parent (Page 10)

As they are currently defined EMO Parent and EMO Child represent a type of =
proxy relationship.  What is the difference between being a proxy for an EM=
O and being an EMO Parent?  This distinction needs to be clarified somehow.=
=20

> An Energy Managed Object Parent is an Energy Managed Object that
> provides one or more of the Energy Managed Object Relationships
> capabilities.  (Page 11)

I find this notion of "providing a capability" confusing.  What does it mea=
n for one EMO to "provide" a "capability" to (for?) another EMO.  I don't u=
nderstand the intended meaning here.

> The framework addresses Energy Management but excludes Energy
> Procurement and the environmental impact of energy use. As such
> the framework does not include: (Page 14)

The energy management systems can be reasonably be envisioned to become the=
 central point for corporate reporting for both cost and environmental impa=
ct especially where compliance to regulations is concerned. We should have =
a plan for how these dimensions will be accommodated.  At a minimum the EMO=
 should optionally allow for the setting and retention of an applicable set=
 of attributes which can then be read by other EnMS applications.

> An Energy Managed Object Child may inherit the domain value from an Energ=
y
> Managed Object Parent (Page 15)

I think that sub-domains need to be better thought out or clarified here.  =
If an EMO is part of a subdomain it is not also part of the encompassing do=
main as well?  This means that each EMO may actually be part of multiple En=
ergy Domains.  This seems to assume that the EMO is only part of a single d=
omain which will be determined by its closest meter in the power distributi=
on tree.  It is not yet clear to me that this is the only and/or the correc=
t way to look at it.

> Energy Managed Objects establish a parent and child relationship
> when one Energy Managed Object provides capabilities for another
> Energy Managed Object. (Page 18)

The notion of "capability" here seems ill defined, or at least not intuitiv=
ely obvious to me.  The relationships (capabilities?) mentioned thus far ar=
e: Aggregation, Metering, Power Source, Proxy and Dependency.  I do not thi=
nk of Aggregation, Proxy, or Dependency as being "capabilities" which are p=
rovided.  I think we need to find a better way of describing what it intend=
ed.

> Energy Managed Objects may have Manufacturer Power States Sets
> and can map these to the EMAN Power State Sets. (Page 26)

Given the introduction of IANA registered power state series I think that t=
his manufacturer power state sets discussion can be removed as it appears t=
o be no longer necessary or applicable.  Agreed?

> powerMonitorId | UUID (Page 29)

Needs to be adjusted given the changes in terminology section(s) ... e.g. w=
e have done away with the term Power Monitor.

> | manufacturerLevels[0..n]: State |
> | emanLevels[0..11] : State | (Page 33)

These require some adjustment given the adoption of power state series.

> When an Energy Managed Object requires a mapping with the
> Manufacturer Power State, the Energy Managed Object
> configuration is done via the Power State settings, and not
> directly via the Manufacturer Power States, which are read-only.
> Taking into account Figure 7, where the LowMinus Power State
> corresponds to three different Manufacturer Power States (11 for
> 1%, 12 for 2%, and 13 for 3%), the implication is that this
> framework will not set the Manufacturer Power State to one
> percent granularity without communicating over or configuring
> the proprietary protocol for this Energy Managed Object. (Page 34)

I think that this section can be removed given the introduction of the IANA=
 registered Power State Series.  I believe that this is no longer relevant.

> Note that the Wake-up-on-Lan (WoL)
> mechanism allows to transition a device out of the Off Power
> State. (Page 34)

Seems out of place somehow.  It seem logically unconnected with the rest of=
 the paragraph.

> 8. Fault Management (Page 34)

I am not clear on what this section is trying to convey.  Additional clarif=
ication is required.=

From ietf@quittek.at  Wed Jul 27 06:29:17 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A1621F8658 for ; Wed, 27 Jul 2011 06:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.113
X-Spam-Level: 
X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7XRvCb6sm1F for ; Wed, 27 Jul 2011 06:29:17 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id F273821F85B2 for ; Wed, 27 Jul 2011 06:29:16 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0M2u1e-1ReilD0X5C-00scrU; Wed, 27 Jul 2011 15:29:13 +0200
References:   
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <7E692F39-2472-4375-9A91-E9F8169C692A@quittek.at>
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Wed, 27 Jul 2011 09:29:12 -0400
To: "Mouli Chandramouli (moulchan)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:NEIoDHxqT0R0q5mmnuG3cQKFbXzvc5M57EM3Hhndoqf +jSBALUpi0xLGaTuX+O6CkRzP/EJWVW2I9W/UCNepcrV+H7g3r V8q+oM/E2XAGqLMtaVEvUJL+pgTUrpS/eRewN4wNT4Zrz/9/Bq /pO1MZPsRB7XudigJ89rmIJDBcWYG+zLkODxws4FMbe3SrXczZ 28jUWt+yOfuHPpixKQejAl5Vei4vVOp9elaJ+RyLT4=
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - Requirement 5.3.2
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 13:29:17 -0000

Hi Mouli,

Am 26.07.2011 um 23:59 schrieb Mouli Chandramouli (moulchan):

>=20
> Hi Juergen,
>=20
> The requirement of corresponding outlet does not seem clear to me.=20
>=20
> Does every device or component of the device (in the scope of EMAN) =
have
> a corresponding outlet ?=20

Most devices will have a power inlet except they live from energy =
harvesting.
Only a minority of the devices will have power outlets. Examples are =
power distribution units (PDUs) or PoE switches.=20

The requirement states that the standard we are developing must provide =
means for devices with power outlets to report power measured at their =
outlets. Obviously only devices capable of measuring power at their =
outlets can implement it.

Would you challenge this requirement?

> Secondly, it would be useful to understand if this requirement would
> help in solving a Energy monitoring problem.=20
> It is not apparent to me.=20

Why would you think it is useless providing a power distribution unit =
means to report power that it delivers at its power outlets? I think =
this is essential for energy monitoring.

Thanks,

    Juergen

>=20
> In fact, IMHO, the entire section - 5.3. Power inlet and power outlet =
-
> while some requirements may be useful, it may be useful to reexamine =
and
> double check some of the requirements.=20
>=20
> Thanks
> Mouli
>=20
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From ietf@quittek.at  Wed Jul 27 06:42:58 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE03C21F8A4E for ; Wed, 27 Jul 2011 06:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.125
X-Spam-Level: 
X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.124,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huCMT0bI3Nld for ; Wed, 27 Jul 2011 06:42:58 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1054321F85C7 for ; Wed, 27 Jul 2011 06:42:58 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LrIS4-1RXbwB3484-013Z1F; Wed, 27 Jul 2011 15:42:57 +0200
References:   
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <73C07568-0F09-4899-9717-A80D050A1760@quittek.at>
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Wed, 27 Jul 2011 09:42:55 -0400
To: "Mouli Chandramouli (moulchan)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:oZlBXZMOsEKz8g67W2h/1NL8sDkYDOzzvL0YR5s9bUM hgpkK9pw0RBqB2wILF953PaXUksTQYDpqksgv5PCBYu+UDrKHU MM05B05EI5JdDqx8Tbui4FkHYHhqJ6eEziuJQfs2dPbNkN5crE Rks8JmIkxFmmrxERFA+RFZh0ZJ3zIubzOJHgqqimAgqiEbY/Di YQWihfkl20eGh8L3kkGyutsvW+XOUrwhCuixKiGt8k=
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - Requirement 5.4.2
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 13:42:58 -0000

Dear Mouli,

Am 27.07.2011 um 00:07 schrieb Mouli Chandramouli (moulchan):

>=20
> Hi Juergen,
>=20
> The requirement 5.4.2 of Power measurement interval needs to be
> revisited.=20
>=20
> There is a good discussion on the mailing list on what is =
instantaneous
> power.=20
>=20
> I presume, the power meter chip set shall make power measurements =
based
> on "some" sampling scheme over a fixed interval.=20
> But this sampling scheme would not change for measurement collected
> every 10 minutes or so.=20
>=20
> So, should this value be reported for every power measurement ? =20

No, of course not. This would be useless information in cases=20
where the interval would be constant.

But I do not see what problem you would have with requirement 5.4.2:

> 5.4.2.  Power measurement interval
>=20
>    The energy management standard must provide means for reporting the
>    corresponding time or time interval for which a power value is
>    reported.  The power value can be measured at the corresponding =
time
>    or averaged over the corresponding time interval.
This says that for power measurements you must be able to either report =
the time of the measurement or the interval over which you measured =
power.

Reporting just the time of measurement may not 100% precise, because for =
AC you would average over at least half a power cycle. But for energy =
management just reporting one time value should be sufficiently precise.

If you measure power over a longer time interval, for example, if you =
want to report demand then it is useful to be able to report the time =
interval for which you report power. Of course, this can be done in =
different ways. You can always report two time stamps (start and stop), =
or if you have a fixed interval length it is enough to report just one =
of them (start or stop time). And certainly there are more ways to do =
so.

What is wrong about this requirement?

Thanks,

    Juergen

>=20
> Thanks
> Mouli
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From ietf@quittek.at  Wed Jul 27 06:44:11 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B70921F8A4E for ; Wed, 27 Jul 2011 06:44:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.134
X-Spam-Level: 
X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.115,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cogXqrxNXC03 for ; Wed, 27 Jul 2011 06:44:10 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8461921F8B17 for ; Wed, 27 Jul 2011 06:44:10 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MUlzw-1QtrNk3V8e-00Yutr; Wed, 27 Jul 2011 15:44:02 +0200
References:   
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <1153EFBA-6A73-4815-A912-579E2D526FF3@quittek.at>
Content-Transfer-Encoding: 7bit
From: Juergen Quittek 
Date: Wed, 27 Jul 2011 09:44:00 -0400
To: "Mouli Chandramouli (moulchan)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:iUfO/Kz3NqxTWfmKMyEC+QuHM4vWyaQy6C1tpoZtYtM mVlok3CAysJKBCOzAPGrCDlw7T0EZRPECIvF2YkDRio7Qa2laX 2SYknHy853VZGGEVkumLSj0OyxsjNDdZOdlufGU/SZaieXpUdK WxuKEO+ok775VjXnUeL+7upNbGxtDFLVnqCWvzvOcE21NZiX56 YPXuByPFea0Oe6LTi+L9l83zggO4/DXb9Op8z68G9M=
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - Requirement 5.4.3
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 13:44:11 -0000

Hi Mouli,

I agree. This is a good alternative title for this requirement.

Thanks,

    Juergen

Am 27.07.2011 um 00:10 schrieb Mouli Chandramouli (moulchan):

> The requirement title  5.4.3. Confidence in power values
> 
> Ccan be rephrased as 5.4.3. Measurement method 
> 
> to be actual or estimated or unknown ...
> 
> Thanks
> Mouli
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From ietf@quittek.at  Wed Jul 27 06:51:26 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7631811E80AE for ; Wed, 27 Jul 2011 06:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.142
X-Spam-Level: 
X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.107,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNCbOZIHmVNG for ; Wed, 27 Jul 2011 06:51:26 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id C041511E80A0 for ; Wed, 27 Jul 2011 06:51:25 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MI6Uo-1QpvKn0HeQ-003y4B; Wed, 27 Jul 2011 15:51:23 +0200
References:   
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Juergen Quittek 
Date: Wed, 27 Jul 2011 09:51:22 -0400
To: "Mouli Chandramouli (moulchan)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:s7AOTHkbe438eBsvrRMmTH9ObLdtqzmcj2JRZNQVjDg 7Il7zywt0wSldtgLlHWo+oYwMrwIqRz8QILsXzzNbvl/3nxssG uZQxbFHkoWyEewRT+u2E2pn1qzxyGV0Ntsr1U73qNko9pmmp/G 8MBHIA7QdHwl6a7LXL47eczp1zMDYPkJieJ6/CGp69Q1XM+eq3 5RR/KHRFbLh+EN8dzuWkA0J7uuP06AQzy4FR/eIDQ0=
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - Requirement 7.2
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 13:51:26 -0000

Hi Mouli,

All that you miss is in requirement 7.6.

Thanks,

    Juergen


Am 27.07.2011 um 00:16 schrieb Mouli Chandramouli (moulchan):

> 
> Hi Juergen,
> 
> Requirement 7.2. Identity of other powered entities on which is reported
> 
> Focuses on the Parent having knowledge of the children. 
> 
> It is also useful to add a requirement - in the other direction also. 
> 
> The energy management standard must provide means for specifying the
> identity of the powered entity 
> Which shall monitor and report the power consumption of a given powered
> entity.
> 
> Thanks
> Mouli
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From moulchan@cisco.com  Wed Jul 27 06:55:15 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7A3228010 for ; Wed, 27 Jul 2011 06:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.238
X-Spam-Level: 
X-Spam-Status: No, score=-3.238 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gr9Aj4YwiUwW for ; Wed, 27 Jul 2011 06:55:12 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD60228006 for ; Wed, 27 Jul 2011 06:55:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=2862; q=dns/txt; s=iport; t=1311774912; x=1312984512; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=i+lFIBper9/hkqKgejmCkYyopzKBkRCUnHuK3cH1hbw=; b=VcqLfLiXeq24vWvyAyIIl3nmjFmzre/HIuX7Kmd6kasyfuOW0bH0WALl +V75DoKkWOPx2NNth9BZcmAlWkMKRNvbQ7fbMJtoZM9tFDBCIYDbkFzwS eF7NjWeyPpl2kbeGNF6VaGB1BWXKZFhGXewRvT07cbJfDUxU3SHFHULN7 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AucAACwYME6tJV2c/2dsb2JhbAA1AQEBAQIBAQEBEQEhCjoLBQcFAgEJDgMEAQELBiMBBgETGCMOCAEBBRcMG5dQj0h3iHwEoxSeYIVhXwSHV5Aui3A
X-IronPort-AV: E=Sophos;i="4.67,276,1309737600";  d="scan'208";a="6977281"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 27 Jul 2011 13:55:11 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6RDtBYp014959;  Wed, 27 Jul 2011 13:55:11 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 27 Jul 2011 08:55:11 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Jul 2011 08:55:08 -0500
Message-ID: 
In-Reply-To: <73C07568-0F09-4899-9717-A80D050A1760@quittek.at>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - Requirement 5.4.2
Thread-Index: AcxMYx0akv6ClzPaSQugXRxB9Coj9QAARrQA
References:    <73C07568-0F09-4899-9717-A80D050A1760@quittek.at>
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Quittek" 
X-OriginalArrivalTime: 27 Jul 2011 13:55:11.0837 (UTC) FILETIME=[CDB280D0:01CC4C64]
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - Requirement 5.4.2
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 13:55:15 -0000

Hi Juergen,

If you take a step back, it would be useful to monitor information
(using SNMP, ...)  that is dynamic which changes over time.=20

Some of the parameters in my view are so constant (unless the metering
mechanism changes) and  I would presume would never change such as the
power measurement interval.

>From a MIB module point of view, adding "nearly constant" variables
might add to MIB walk time of the table ?

Thanks
Mouli

-----Original Message-----
From: Juergen Quittek [mailto:ietf@quittek.at]=20
Sent: Wednesday, July 27, 2011 9:43 AM
To: Mouli Chandramouli (moulchan)
Cc: Juergen Quittek; eman mailing list
Subject: Re: [eman] new revision of eman requirements - Requirement
5.4.2

Dear Mouli,

Am 27.07.2011 um 00:07 schrieb Mouli Chandramouli (moulchan):

>=20
> Hi Juergen,
>=20
> The requirement 5.4.2 of Power measurement interval needs to be
> revisited.=20
>=20
> There is a good discussion on the mailing list on what is
instantaneous
> power.=20
>=20
> I presume, the power meter chip set shall make power measurements
based
> on "some" sampling scheme over a fixed interval.=20
> But this sampling scheme would not change for measurement collected
> every 10 minutes or so.=20
>=20
> So, should this value be reported for every power measurement ? =20

No, of course not. This would be useless information in cases=20
where the interval would be constant.

But I do not see what problem you would have with requirement 5.4.2:

> 5.4.2.  Power measurement interval
>=20
>    The energy management standard must provide means for reporting the
>    corresponding time or time interval for which a power value is
>    reported.  The power value can be measured at the corresponding
time
>    or averaged over the corresponding time interval.
This says that for power measurements you must be able to either report
the time of the measurement or the interval over which you measured
power.

Reporting just the time of measurement may not 100% precise, because for
AC you would average over at least half a power cycle. But for energy
management just reporting one time value should be sufficiently precise.

If you measure power over a longer time interval, for example, if you
want to report demand then it is useful to be able to report the time
interval for which you report power. Of course, this can be done in
different ways. You can always report two time stamps (start and stop),
or if you have a fixed interval length it is enough to report just one
of them (start or stop time). And certainly there are more ways to do
so.

What is wrong about this requirement?

Thanks,

    Juergen

>=20
> Thanks
> Mouli
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From j.schoenwaelder@jacobs-university.de  Wed Jul 27 07:00:59 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A7C21F8681 for ; Wed, 27 Jul 2011 07:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.019
X-Spam-Level: 
X-Spam-Status: No, score=-103.019 tagged_above=-999 required=5 tests=[AWL=0.230, 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 Jv6iqEQT6wLI for ; Wed, 27 Jul 2011 07:00:58 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8811E21F8680 for ; Wed, 27 Jul 2011 07:00:58 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA21420C53; Wed, 27 Jul 2011 16:00:57 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RPvr3qhhx2Gl; Wed, 27 Jul 2011 16:00:56 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74BFB20C52; Wed, 27 Jul 2011 16:00:56 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 9A14E1A1AA96; Wed, 27 Jul 2011 16:00:55 +0200 (CEST)
Date: Wed, 27 Jul 2011 16:00:54 +0200
From: Juergen Schoenwaelder 
To: "Mouli Chandramouli (moulchan)" 
Message-ID: <20110727140053.GA10796@elstar.local>
Mail-Followup-To: "Mouli Chandramouli (moulchan)" , Juergen Quittek , eman mailing list 
References:     <73C07568-0F09-4899-9717-A80D050A1760@quittek.at> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - Requirement 5.4.2
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 14:00:59 -0000

On Wed, Jul 27, 2011 at 08:55:08AM -0500, Mouli Chandramouli (moulchan) wrote:
 
> From a MIB module point of view, adding "nearly constant" variables
> might add to MIB walk time of the table ?

Blindly walking complete tables or subtrees is in general not a
particularly smart implementation strategy for anything that wants to
be efficient and scale and play nice with additions that can happen
over time.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From bnordman@lbl.gov  Wed Jul 27 07:09:13 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F50A21F8B36 for ; Wed, 27 Jul 2011 07:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.79
X-Spam-Level: 
X-Spam-Status: No, score=-5.79 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTvtpYcn8uL0 for ; Wed, 27 Jul 2011 07:09:12 -0700 (PDT)
Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 772E821F8B20 for ; Wed, 27 Jul 2011 07:09:12 -0700 (PDT)
X-Ironport-SBRS: 4.4
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AloAAAIbME7RVaC0kGdsb2JhbAA1AQEBAQIBAQEBEQJkCwUHBQwLBgQBASAUBxQTBQ4BBQEODggHFyeCNpUbhywBhzRfCBQBAQEBCQkNBxQEIYh8BKRmCp0rgz2DAwSSdYxKPIN4
X-IronPort-AV: E=Sophos;i="4.67,276,1309762800"; d="scan'208";a="47009030"
Received: from mail-gy0-f180.google.com ([209.85.160.180]) by ironport4.lbl.gov with ESMTP; 27 Jul 2011 07:09:11 -0700
Received: by gyg4 with SMTP id 4so1594958gyg.39 for ; Wed, 27 Jul 2011 07:09:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.116.5 with SMTP id o5mr80127anc.60.1311775750876; Wed, 27 Jul 2011 07:09:10 -0700 (PDT)
Received: by 10.100.241.8 with HTTP; Wed, 27 Jul 2011 07:09:10 -0700 (PDT)
In-Reply-To: 
References:     <73C07568-0F09-4899-9717-A80D050A1760@quittek.at> 
Date: Wed, 27 Jul 2011 10:09:10 -0400
Message-ID: 
From: Bruce Nordman 
To: "Mouli Chandramouli (moulchan)" 
Content-Type: multipart/alternative; boundary=0016e644d62aa7eeaa04a90d974e
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - Requirement 5.4.2
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 14:09:13 -0000

--0016e644d62aa7eeaa04a90d974e
Content-Type: text/plain; charset=ISO-8859-1

I have also wondered about near-constant variables.
How about identifying a group of these and put a time
stamp on the last time any of them changed.  That
way on each reading of energy/power data, just the
one time stamp needs to be reported and if it is not
what the NMS has, it knows it needs to re-request the
nearly-constant data, but otherwise it knows that none
of these have changed.

An example of this is the set of devices downstream of
a PoE switch or PDU  Adding or removing a device from
the list would trigger an update of this timestamp.
Adding or removing a component (if components are
modeled) would similarly trigger an update.

--Bruce

On Wed, Jul 27, 2011 at 9:55 AM, Mouli Chandramouli (moulchan) <
moulchan@cisco.com> wrote:

> Hi Juergen,
>
> If you take a step back, it would be useful to monitor information
> (using SNMP, ...)  that is dynamic which changes over time.
>
> Some of the parameters in my view are so constant (unless the metering
> mechanism changes) and  I would presume would never change such as the
> power measurement interval.
>
> From a MIB module point of view, adding "nearly constant" variables
> might add to MIB walk time of the table ?
>
> Thanks
> Mouli
>
> -----Original Message-----
> From: Juergen Quittek [mailto:ietf@quittek.at]
> Sent: Wednesday, July 27, 2011 9:43 AM
> To: Mouli Chandramouli (moulchan)
> Cc: Juergen Quittek; eman mailing list
> Subject: Re: [eman] new revision of eman requirements - Requirement
> 5.4.2
>
> Dear Mouli,
>
> Am 27.07.2011 um 00:07 schrieb Mouli Chandramouli (moulchan):
>
> >
> > Hi Juergen,
> >
> > The requirement 5.4.2 of Power measurement interval needs to be
> > revisited.
> >
> > There is a good discussion on the mailing list on what is
> instantaneous
> > power.
> >
> > I presume, the power meter chip set shall make power measurements
> based
> > on "some" sampling scheme over a fixed interval.
> > But this sampling scheme would not change for measurement collected
> > every 10 minutes or so.
> >
> > So, should this value be reported for every power measurement ?
>
> No, of course not. This would be useless information in cases
> where the interval would be constant.
>
> But I do not see what problem you would have with requirement 5.4.2:
>
> > 5.4.2.  Power measurement interval
> >
> >    The energy management standard must provide means for reporting the
> >    corresponding time or time interval for which a power value is
> >    reported.  The power value can be measured at the corresponding
> time
> >    or averaged over the corresponding time interval.
> This says that for power measurements you must be able to either report
> the time of the measurement or the interval over which you measured
> power.
>
> Reporting just the time of measurement may not 100% precise, because for
> AC you would average over at least half a power cycle. But for energy
> management just reporting one time value should be sufficiently precise.
>
> If you measure power over a longer time interval, for example, if you
> want to report demand then it is useful to be able to report the time
> interval for which you report power. Of course, this can be done in
> different ways. You can always report two time stamps (start and stop),
> or if you have a fixed interval length it is enough to report just one
> of them (start or stop time). And certainly there are more ways to do
> so.
>
> What is wrong about this requirement?
>
> Thanks,
>
>    Juergen
>
> >
> > Thanks
> > Mouli
> > _______________________________________________
> > eman mailing list
> > eman@ietf.org
> > https://www.ietf.org/mailman/listinfo/eman
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>



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

--0016e644d62aa7eeaa04a90d974e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I have also wondered about near-constant variables.
How about identifyin=
g a group of these and put a time
stamp on the last time any of them cha=
nged.=A0 That
way on each reading of energy/power data, just the
one =
time stamp needs to be reported and if it is not

what the NMS has, it knows it needs to re-request the
nearly-constant da=
ta, but otherwise it knows that none
of these have changed.=A0 

A=
n example of this is the set of devices downstream of
a PoE switch or PD=
U=A0 Adding or removing a device from

the list would trigger an update of this timestamp.
Adding or removing a=
 component (if components are
modeled) would similarly trigger an update=
.

--Bruce

On Wed, Jul 27, 2011 at =
9:55 AM, Mouli Chandramouli (moulchan) <moulchan@cisco.com> wrote:


Hi Juergen,



If you take a step back, it would be useful to monitor information

(using SNMP, ...) =A0that is dynamic which changes over time.



Some of the parameters in my view are so constant (unless the metering

mechanism changes) and =A0I would presume would never change such as the
power measurement interval.



>From a MIB module point of view, adding "nearly constant" variabl=
es

might add to MIB walk time of the table ?



Thanks

Mouli



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

From: Juergen Quittek [mailto:ietf@quitt=
ek.at]

Sent: Wednesday, July 27, 2011 9:43 AM

To: Mouli Chandramouli (moulchan)

Cc: Juergen Quittek; eman mailing list

Subject: Re: [eman] new revision of eman requirements - Requirement

5.4.2




Dear Mouli,



Am 27.07.2011 um 00:07 schrieb Mouli Chandramouli (moulchan):



>

> Hi Juergen,

>

> The requirement 5.4.2 of Power measurement interval needs to be

> revisited.

>

> There is a good discussion on the mailing list on what is

instantaneous

> power.

>

> I presume, the power meter chip set shall make power measurements

based

> on "some" sampling scheme over a fixed interval.

> But this sampling scheme would not change for measurement collected
> every 10 minutes or so.

>

> So, should this value be reported for every power measurement ?



No, of course not. This would be useless information in cases

where the interval would be constant.



But I do not see what problem you would have with requirement 5.4.2:



> 5.4.2. =A0Power measurement interval

>

> =A0 =A0The energy management standard must provide means for reporting=
 the

> =A0 =A0corresponding time or time interval for which a power value is<=
br>
> =A0 =A0reported. =A0The power value can be measured at the correspondi=
ng

time

> =A0 =A0or averaged over the corresponding time interval.

This says that for power measurements you must be able to either report

the time of the measurement or the interval over which you measured

power.



Reporting just the time of measurement may not 100% precise, because for
AC you would average over at least half a power cycle. But for energy

management just reporting one time value should be sufficiently precise.


If you measure power over a longer time interval, for example, if you

want to report demand then it is useful to be able to report the time

interval for which you report power. Of course, this can be done in

different ways. You can always report two time stamps (start and stop),

or if you have a fixed interval length it is enough to report just one

of them (start or stop time). And certainly there are more ways to do

so.



What is wrong about this requirement?



Thanks,



 =A0 =A0Juergen



>

> Thanks

> Mouli

> _______________________________________________

> eman mailing list

> eman@ietf.org

> https://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
eetd.lbl.gov/ea/nordman

BNordman@LBL.gov
510-486-7089
m: 510-501-7943



--0016e644d62aa7eeaa04a90d974e--

From Quittek@neclab.eu  Wed Jul 27 07:13:51 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D759921F8B86 for ; Wed, 27 Jul 2011 07:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.357
X-Spam-Level: 
X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 ve2d00lf1f5f for ; Wed, 27 Jul 2011 07:13:51 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 01E9921F8B38 for ; Wed, 27 Jul 2011 07:13:51 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E4A9B28000329; Wed, 27 Jul 2011 16:13:49 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WA2HGyBE85i2; Wed, 27 Jul 2011 16:13:49 +0200 (CEST)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id C28FD280001AA; Wed, 27 Jul 2011 16:13:34 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.20]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Wed, 27 Jul 2011 16:13:34 +0200
From: Juergen Quittek 
To: "John Parello (jparello)" , Juergen Quittek 
Thread-Topic: [eman] new revision of eman requirements - open issue 12.3:time series of energy/power values
Thread-Index: AQHMTGdebe5iwHf9hECy9RtMmcgg7g==
Date: Wed, 27 Jul 2011 14:13:34 +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.12.0.110505
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] new revision of eman requirements - open issue 12.3:time series of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 14:13:52 -0000

Hi John,

my Question was=20

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


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

Thanks,

    Juergen


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

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


From ietf@quittek.at  Wed Jul 27 07:35:01 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0A021F8574 for ; Wed, 27 Jul 2011 07:35:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.814
X-Spam-Level: 
X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.435,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NITuLpZXcpNh for ; Wed, 27 Jul 2011 07:35:00 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 4B04E21F859E for ; Wed, 27 Jul 2011 07:35:00 -0700 (PDT)
Received: from [10.7.0.92] (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0LbxOG-1RDgn01DAC-00jkp4; Wed, 27 Jul 2011 16:34:52 +0200
References:    <73C07568-0F09-4899-9717-A80D050A1760@quittek.at> 
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: 
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Wed, 27 Jul 2011 10:34:47 -0400
To: "Mouli Chandramouli (moulchan)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:uqaXzAfoanhtNEe31w5S8k6E83vnWw0wx5z+aui9cP9 cXjWGI8SyNcFBZqhkjbcRVyT6fHrah7A2TUOa6+vTA2xwYKXPS F74qTablPaoQAuyryenjShQuf3POmqVt8yoz8NxbE/QxZXZRAA Eve7Xr3NZEtvdX+LB960nFZOTIBHfMALuTrjDM1pfoVUaXqtBM UKP0VsjCmPQp2+wFxa066o7D/McJKKlOYxpfjHnYSw=
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - Requirement 5.4.2
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 14:35:01 -0000

Hi Mouli,

I am not sure if I get you right.
I did not talk about any MIB variables.
You asked me to take a step back.
Now I ask you to do the same thing.
Let's not look at MIB variables:

If you report power, would it be useful at all if the management system =
does not know for which time the power was measured?

Talking about implementations:
If you read a MIB variable "actualPower" then the time is the time of =
reading and implicitly known to the management system.

If you read a power value from a circular buffer, then for each value =
you read you must know for which time interval it was measured. This =
dies not mean you have to read a time stamp for each of them: A possible =
implementation could be to measure power for constant time intervals: =
Then you once read the time stamp for the starting time of the first =
buffered value and then read once the constant interval length and then =
all the power values in the buffer. A standard defined this way meets =
requirement 5.4.2. because for each power value the start and stop time =
has been reported to the management system.

Does this solve your concern?

    Juergen
=20
Am 27.07.2011 um 09:55 schrieb Mouli Chandramouli (moulchan):

> Hi Juergen,
>=20
> If you take a step back, it would be useful to monitor information
> (using SNMP, ...)  that is dynamic which changes over time.=20
>=20
> Some of the parameters in my view are so constant (unless the metering
> mechanism changes) and  I would presume would never change such as the
> power measurement interval.
>=20
> =46rom a MIB module point of view, adding "nearly constant" variables
> might add to MIB walk time of the table ?
>=20
> Thanks
> Mouli
>=20
> -----Original Message-----
> From: Juergen Quittek [mailto:ietf@quittek.at]=20
> Sent: Wednesday, July 27, 2011 9:43 AM
> To: Mouli Chandramouli (moulchan)
> Cc: Juergen Quittek; eman mailing list
> Subject: Re: [eman] new revision of eman requirements - Requirement
> 5.4.2
>=20
> Dear Mouli,
>=20
> Am 27.07.2011 um 00:07 schrieb Mouli Chandramouli (moulchan):
>=20
>>=20
>> Hi Juergen,
>>=20
>> The requirement 5.4.2 of Power measurement interval needs to be
>> revisited.=20
>>=20
>> There is a good discussion on the mailing list on what is
> instantaneous
>> power.=20
>>=20
>> I presume, the power meter chip set shall make power measurements
> based
>> on "some" sampling scheme over a fixed interval.=20
>> But this sampling scheme would not change for measurement collected
>> every 10 minutes or so.=20
>>=20
>> So, should this value be reported for every power measurement ? =20
>=20
> No, of course not. This would be useless information in cases=20
> where the interval would be constant.
>=20
> But I do not see what problem you would have with requirement 5.4.2:
>=20
>> 5.4.2.  Power measurement interval
>>=20
>>   The energy management standard must provide means for reporting the
>>   corresponding time or time interval for which a power value is
>>   reported.  The power value can be measured at the corresponding
> time
>>   or averaged over the corresponding time interval.
> This says that for power measurements you must be able to either =
report
> the time of the measurement or the interval over which you measured
> power.
>=20
> Reporting just the time of measurement may not 100% precise, because =
for
> AC you would average over at least half a power cycle. But for energy
> management just reporting one time value should be sufficiently =
precise.
>=20
> If you measure power over a longer time interval, for example, if you
> want to report demand then it is useful to be able to report the time
> interval for which you report power. Of course, this can be done in
> different ways. You can always report two time stamps (start and =
stop),
> or if you have a fixed interval length it is enough to report just one
> of them (start or stop time). And certainly there are more ways to do
> so.
>=20
> What is wrong about this requirement?
>=20
> Thanks,
>=20
>    Juergen
>=20
>>=20
>> Thanks
>> Mouli
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>=20


From ietf@quittek.at  Wed Jul 27 08:07:30 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E6821F8B98 for ; Wed, 27 Jul 2011 08:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level: 
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.099,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 K4sT120OU8O4 for ; Wed, 27 Jul 2011 08:07:29 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2141621F84E9 for ; Wed, 27 Jul 2011 08:07:29 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0Lib0L-1ROzkw2eGT-00cuRJ; Wed, 27 Jul 2011 17:07:28 +0200
From: Juergen Quittek 
Content-Type: multipart/alternative; boundary=Apple-Mail-2-612080950
Message-Id: 
Date: Wed, 27 Jul 2011 11:07:26 -0400
To: eman mailing list 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:4R5qUS06iWXTKt2hmqsiF/X2kzeenkiaBGpU6v1Wevp bKwzul2nV5HPtzBhIqwC4krTylDKw4SXvxxD1QYu8HcTiOdFp/ e0Epwx1sdnRj4yG6AUtrNo8yRN43mSQUvp3A90GlvaTH75KP2d YzvVKuSfVoXB6yT30No+P75qUsDb/7JLZUi44qBS7un4BVL8MH hOXsLn4rQqhh5eJ15QmII3IZ+iuAgBMXjyi3GWmJU4=
Subject: [eman] Terminology: demand
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 15:07:30 -0000

--Apple-Mail-2-612080950
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi John,

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

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


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

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

>        of time and typically expressed in kilowatt hours.  This=20
>        measurement is significant because some utilities or energy=20

remove "This measurement is significant because"

>        providers bill by Demand measurements as well as for maximum=20
>        Demand per billing periods.  Power values may spike during=20
>        short-terms by devices, but Demand measurements recognize that=20=

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



Thanks,

    Juergen=

--Apple-Mail-2-612080950
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
John,

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

    =
 Demand 

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

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

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

       of time and =
typically expressed in kilowatt hours. =
 This 
  =
     measurement is significant because some utilities or =
energy 

remove "This =
measurement is significant because"

      =
 providers bill by Demand measurements as well as for =
maximum 
  =
     Demand per billing periods.  Power values may =
spike during 
       short-terms by =
devices, but Demand measurements recognize =
that 
  =
     maximum Demand does not equal maximum Power during =
an =
interval. 

<=
div>Thanks,

    =
Juergen
=

--Apple-Mail-2-612080950--

From jparello@cisco.com  Wed Jul 27 11:09:35 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B0321F8B93 for ; Wed, 27 Jul 2011 11:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47KM96fyIxXk for ; Wed, 27 Jul 2011 11:09:34 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 43CD321F8B8B for ; Wed, 27 Jul 2011 11:09:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=2632; q=dns/txt; s=iport; t=1311790174; x=1312999774; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=vecrohyRToYCARjDz7QSwJdK7w/HHffyabuogeZchJM=; b=KeIf+gpUXsjyDFiviZ8BRx1sOK3o9OdCmeRxTG3xSBeOcR9Dwxz0xYDa IwjUlvBXwR/cKqsaY1RtYgFZ0JdaBm+O+QEBqcy5aPg4thyNauRIEVpX1 Nzprv4Xy+ZfipJLNbSDU3c/XJK7/aYMHPrrLKTvQ+mMBV3CIJGrZ7KhoV o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuAAAClTME6rRDoI/2dsb2JhbAA1AQEBAQMUARgJCj4TBQIBCREEAQELBiMBBgETOw4IAQEFARYMG5dbj0h3rFiebIVhXwSHV5Aui3I
X-IronPort-AV: E=Sophos;i="4.67,277,1309737600";  d="scan'208";a="7090861"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-7.cisco.com with ESMTP; 27 Jul 2011 18:09:33 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6RI9XJ1001009; Wed, 27 Jul 2011 18:09:33 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 27 Jul 2011 11:09:33 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Jul 2011 11:08:52 -0700
Message-ID: 
In-Reply-To: <20110304190215.GA5072@cslinux-build01.cyberswitching.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00
Thread-Index: Acvanr9VeA9wAs90TkyWsZkuv1Etphx6STdA
References: <20110304190215.GA5072@cslinux-build01.cyberswitching.local>
From: "John Parello (jparello)" 
To: , 
X-OriginalArrivalTime: 27 Jul 2011 18:09:33.0014 (UTC) FILETIME=[56114F60:01CC4C88]
Subject: Re: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 18:09:35 -0000

Hi Chris, and list...

Following up on this wrt to the new framework draft and recent activity
on the list. We've added a set of relationships like metering, powered
by.

Do you think it would be good to add a relationship like 'ganged' to map
managed elements to the same gang?

The relationship methphor is quite simple and if we cal this out it
could model what you have in mind.

Jp

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
chrisv@cyberswitching.com
Sent: Friday, March 04, 2011 11:02 AM
To: eman@ietf.org
Subject: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00

Hi Juergen,

I wrote an additon to the various scenarios described in
draft-ietf-eman-requirements-00 to address the "Outlet Gang" scenario
found on Smart PDUs.  Please let me know if you have any questions while
integrating it.

$ diff draft-ietf-eman-requirements-00.txt
draft-ietf-eman-requirements-01.txt
416a417,449
> 2.9.  Scenario 9: Ganged outlets on a Smart Power Strip
>
>    Some PDUs allow physical entities like outlets to be "ganged"
together as a
>    logical entity for simplified management purposes.  This is
particularly
>    useful for servers with multiple power supplies, where each power
supply is
>    connected to a different physical outlet.  Other implementations
allow
>    "gangs" to be created based on common ownership of outlets, such as
>    business units or load shed priority or other non-physical
relationships.
>
>    Current implementations allow for an "M-to-N" mapping between
outlet
>    "gangs" and physical outlets.  An example of this mapping includes
the
>    following:
>
>       Outlet 1             (physical entity)
>       Outlet 2             (physical entity)
>       Outlet 3             (physical entity)
>       Outlet 4             (physical entity)
>       Outlet Gang A        (virtual entity)
>       Outlet Gang B        (virtual entity)
>
>       Gang A -> Outlets 1, 2 and 3
>       Gang B -> Outlets 3 and 4
>
>    Note the allowed overlap on Outlet 3, where Outlet 3 belongs to
both
>    "gangs."
>
>    Each "Outlet Gang" entity reports the aggregated data from the
individual
>    outlet entities that comprise it and enables a single point of
control for
>    all the individual outlet entities.  For example, turning "Outlet
Gang A"
>    to the "off" state would turn outlets 1, 2, and 3 "off" in some
>    implementations.  (The impact of this action on "Outlet Gang B" is
to be
>    defined by the equipment manufacturer.)
>

Thanks,
Chris

From ietf@quittek.at  Wed Jul 27 11:13:59 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9F921F8BE1 for ; Wed, 27 Jul 2011 11:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.832
X-Spam-Level: 
X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.417,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J58W-3SrO2D for ; Wed, 27 Jul 2011 11:13:58 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id BB0AD21F84C5 for ; Wed, 27 Jul 2011 11:13:57 -0700 (PDT)
Received: from [10.7.0.92] (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MHMPb-1QZmXg1Sz5-00DfTb; Wed, 27 Jul 2011 20:13:56 +0200
References: <20110304190215.GA5072@cslinux-build01.cyberswitching.local> 
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: 
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Wed, 27 Jul 2011 14:13:51 -0400
To: John Parello (jparello) 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:CXRXdS9LW4UIiUrlfQOpUf1WRO5AC0eSMJ1FpJtm66s kEUK1JL5CK//TI6hXbwoIpS7U4OLV8UooS0aMcwYaKWuH7irXw tht/dOCqOfdYRb15qeyzoMUcxMP5RWJpBWLBj0bB1BTcureIUY 0W3wKMGVecLj8kfTQsukzS3bj+b0rokLUoSkspm8bKlyfP5lmG HIKGGFDvPHDPpY1ziMYcS5V5sB7rKvNL4AOVuPq7HA=
Cc: chrisv@cyberswitching.com, eman@ietf.org
Subject: Re: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 18:13:59 -0000

Dear all,

Would we have a requirement for output gangs to be added to the =
requirements draft?

Thanks,

    Juergen


Am 27.07.2011 um 14:08 schrieb John Parello (jparello):

> Hi Chris, and list...
>=20
> Following up on this wrt to the new framework draft and recent =
activity
> on the list. We've added a set of relationships like metering, powered
> by.
>=20
> Do you think it would be good to add a relationship like 'ganged' to =
map
> managed elements to the same gang?
>=20
> The relationship methphor is quite simple and if we cal this out it
> could model what you have in mind.
>=20
> Jp
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of
> chrisv@cyberswitching.com
> Sent: Friday, March 04, 2011 11:02 AM
> To: eman@ietf.org
> Subject: [eman] Outlet Gang addition to =
draft-ietf-eman-requirements-00
>=20
> Hi Juergen,
>=20
> I wrote an additon to the various scenarios described in
> draft-ietf-eman-requirements-00 to address the "Outlet Gang" scenario
> found on Smart PDUs.  Please let me know if you have any questions =
while
> integrating it.
>=20
> $ diff draft-ietf-eman-requirements-00.txt
> draft-ietf-eman-requirements-01.txt
> 416a417,449
>> 2.9.  Scenario 9: Ganged outlets on a Smart Power Strip
>>=20
>>   Some PDUs allow physical entities like outlets to be "ganged"
> together as a
>>   logical entity for simplified management purposes.  This is
> particularly
>>   useful for servers with multiple power supplies, where each power
> supply is
>>   connected to a different physical outlet.  Other implementations
> allow
>>   "gangs" to be created based on common ownership of outlets, such as
>>   business units or load shed priority or other non-physical
> relationships.
>>=20
>>   Current implementations allow for an "M-to-N" mapping between
> outlet
>>   "gangs" and physical outlets.  An example of this mapping includes
> the
>>   following:
>>=20
>>      Outlet 1             (physical entity)
>>      Outlet 2             (physical entity)
>>      Outlet 3             (physical entity)
>>      Outlet 4             (physical entity)
>>      Outlet Gang A        (virtual entity)
>>      Outlet Gang B        (virtual entity)
>>=20
>>      Gang A -> Outlets 1, 2 and 3
>>      Gang B -> Outlets 3 and 4
>>=20
>>   Note the allowed overlap on Outlet 3, where Outlet 3 belongs to
> both
>>   "gangs."
>>=20
>>   Each "Outlet Gang" entity reports the aggregated data from the
> individual
>>   outlet entities that comprise it and enables a single point of
> control for
>>   all the individual outlet entities.  For example, turning "Outlet
> Gang A"
>>   to the "off" state would turn outlets 1, 2, and 3 "off" in some
>>   implementations.  (The impact of this action on "Outlet Gang B" is
> to be
>>   defined by the equipment manufacturer.)
>>=20
>=20
> Thanks,
> Chris
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From jparello@cisco.com  Wed Jul 27 11:15:16 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3557E21F8BE4 for ; Wed, 27 Jul 2011 11:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.057
X-Spam-Level: 
X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8yrDLe5g96u for ; Wed, 27 Jul 2011 11:15:15 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1D921F8BE1 for ; Wed, 27 Jul 2011 11:15:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=1303; q=dns/txt; s=iport; t=1311790515; x=1313000115; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=jmYmPsETDty6aSfh9KDalpopCBsGBGZklYeFmhE/OKI=; b=gQGaAfBkY+1NZRrUr7uafD6vtA1fOUWDyGF+mOqD/XB6WFsRU+HCs77D WpihMb2LdfzUA27YbkJqYDxOfeVhZsngrJQNAcXgIKVbTB3ExWyvaHa7+ qYwnkEjE7tdgzC8Y57PMQh7S+6yee2V1j+pBTHez7pLGqr6NRUcx050R1 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuAAAEhVME6rRDoG/2dsb2JhbAA1AQEBAQMBAQERASEKOhcFAgEJDgMEAQELBiMBBgETGCMOCAEBBQEWDBuXW49Id4kAo1yebIVhXwSHV5Aui3I
X-IronPort-AV: E=Sophos;i="4.67,277,1309737600";  d="scan'208";a="7086828"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jul 2011 18:15:13 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6RIFDdk029019; Wed, 27 Jul 2011 18:15:13 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 27 Jul 2011 11:15:13 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Jul 2011 11:14:33 -0700
Message-ID: 
In-Reply-To: <0F0F2CC7-42B9-44E3-93A3-5ADFC48091BD@quittek.at>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] comments on draft-parello-eman-definitions-00
Thread-Index: AcxL6O2dLREf6Z77QCWiJNBiIoNdUgAn4PGA
References: <0F0F2CC7-42B9-44E3-93A3-5ADFC48091BD@quittek.at>
From: "John Parello (jparello)" 
To: "Juergen Quittek" , "eman mailing list" 
X-OriginalArrivalTime: 27 Jul 2011 18:15:13.0187 (UTC) FILETIME=[20D39730:01CC4C89]
Subject: Re: [eman] comments on draft-parello-eman-definitions-00
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 18:15:16 -0000

Thanks!

Jeurgen,

I'm going through the ones you've sent and from others so stay tuned.

For all reviewers,

I'd ask if you can provide a specific reference and alternate definition
when replying.

Got great feedback and it's a pile for me to go through those plus the
EMAN drafts.=20

The ones I've gotten with specific language and source really help.
Things like I don't like this find another don't help but the ones with
terms and a source to check are awesome.

Thanks I'll be replying to them all shortly.

Jp


-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Juergen Quittek
Sent: Tuesday, July 26, 2011 4:08 PM
To: eman mailing list
Subject: [eman] comments on draft-parello-eman-definitions-00

Hi John and all,=20

Thank you for writing a draft on terminology. This will speed up the
process of finding the right definitions of the terms we are using.

I have several issues that I want to address, but writing all in one
email will probably lead to a confusing discussion. Therefore, I will
send individual email per term that we need to define.

Thanks,

    Juergen

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

From jparello@cisco.com  Wed Jul 27 11:18:08 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4DA21F8C0B for ; Wed, 27 Jul 2011 11:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.021
X-Spam-Level: 
X-Spam-Status: No, score=-3.021 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+l6wbpv890N for ; Wed, 27 Jul 2011 11:18:04 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 01A5B21F8BFE for ; Wed, 27 Jul 2011 11:18:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=24932; q=dns/txt; s=iport; t=1311790684; x=1313000284; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=yxTBg7BKQf8bIhJVEhAJlwp2gczyunhV/S8HtqjvaPs=; b=N8V/+jOP6XBY0LuJN45czdaT+GDwMQPxrOj5P6dLYEXH+CQihYS8st3D 1P7F72wa+xsExL4FBMskjCtkauLfFrK617Lp6A41Mh5HYgXxfddaUMWgm tBuZrnt98e+q7HriHzCwa2kh6bFisNSgROuXF5QEl1iRdY7N7xK31uOnV g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Au0AAAxWME6rRDoI/2dsb2JhbAA1AQEBAQIBAQEBEQEMEgNEEAcDAgIBCREEAQELBgYJDQcBBgETDAwjDggBAQUBFgwbgjaVJUWGZwGIG3eIfASjXp5rAoMhGoIkXwSHV5Aui3I
X-IronPort-AV: E=Sophos;i="4.67,277,1309737600"; d="scan'208,217";a="7087675"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-2.cisco.com with ESMTP; 27 Jul 2011 18:18:02 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6RII16b010823; Wed, 27 Jul 2011 18:18:02 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 27 Jul 2011 11:17:56 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4C89.81BF824B"
Date: Wed, 27 Jul 2011 11:17:16 -0700
Message-ID: 
In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7D6F4@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - open issue12.3:	time series of energy/power values
Thread-Index: AcxLsY528LDQ57dARfOVMEcoxZ7p5gAARF6wADWeSWA=
References: <54ECD73F-B9A8-440F-970B-B9DD538CA186@quittek.at><4E2E2A61.6060503@cisco.com> <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7D6F4@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
From: "John Parello (jparello)" 
To: "Mielke, William F (Bill)" , "eman mailing list" 
X-OriginalArrivalTime: 27 Jul 2011 18:17:56.0013 (UTC) FILETIME=[81E0DDD0:01CC4C89]
Subject: Re: [eman] new revision of eman requirements - open issue12.3:	time series of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 18:18:09 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4C89.81BF824B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1 on this.

=20

We need power, energy and demand as a measured scalar value but there's
no reason to exclude a vector or log of readings if the device can
support it. My experience as well is that the poll periods are too long
for the data desired. Some peak demands can be down to the minute so
some local accumulation is definitely helpful and quite common.

=20

=20

=20

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Mielke, William F (Bill)
Sent: Tuesday, July 26, 2011 10:00 AM
To: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue12.3:
time series of energy/power values

=20

I believe that we should be reporting both energy and power.  Given
Michael Suchoff's comments thus far and based on my own experience the
actual measurements are typically (frequently?) provided by specialized
metering chips to insure accuracy.  We should seek to preserve this
accuracy by reporting all of the commonly monitored values for each
measurement interval and delegate to the device how best to collect the
actual data.  I am assuming that Min, Max, and Average values for the
various parameters will be readily available on the device so it should
not be a large overhead to keep them.

=20

Since some devices may be estimating rather than measuring these values
the table needs to provide a means of identifying which it is reporting.
It is not clear to me whether this indication needs to be provided per
field, per tabular row, or per device.  Thoughts from others?

=20

I also think that we need to take care to generalize things a bit to
allow the devices to report parameters such as their reporting interval
and the size of their on-board history cache.  In some cases these
values may be determined statically by the device (and may vary from
vendor to vendor), but we should also provide a means for configuring
these parameters as well for the devices which seek to be more flexible.

=20

On the issue of Push vs. Pull models I suppose that each device
manufacturer should be free to decide whether they want to support both,
or just one of the two, so we need to clearly identify which
combinations are required.  From my perspective a compliant device needs
to be able to support either one or both methods, but that supporting
neither is not really a valid choice.  This is just my opinion though.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com 

Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein=20

=20

	=20

________________________________

	From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On
Behalf Of Juergen Quittek
	Sent: Tuesday, July 26, 2011 12:32 PM
	To: Benoit Claise
	Cc: eman mailing list
	Subject: Re: [eman] new revision of eman requirements - open
issue 12.3: time series of energy/power values

	Dear all,=20

	=20

	I think we are all in line with the statements made on the
mailing list.

	=20

	However, so far we haven't addressed the open issue as stated in
the requirements draft:

	=20

	> 12.3.  Power and energy time series?
	>=20
	>    We have requirements for reporting of time series of power
and energy
	>    values.  Do we need both or just one of them?  If just one,
then
	>    which one?

	Requirement 5.4.10 asks for time series of power values and
requirement 5.5.4 asks for time series of energy values. Do we need both
of them?

	=20

	A second question would be: Do we need them to be exported by
SNMP or rather by IPFIX or by both?

	=20

	    Juergen

	=20

	=20

	=20

	Am 25.07.2011 um 22:45 schrieb Benoit Claise:

=09
=09
=09

	Dear Michael,
=09
	This is exactly what's available in the EMAN monitoring MIB for
the energy
=09
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09,
section 5.5
=09
	Regards, Benoit
=09
=09

	Dear Juergen,
=09
	The larger manufacturers of managed power distribution equipment
(APC, Eaton, Raritan...) all provide circular buffers of time stamped
power measurements.  Certification of our products for use with IBM
System Director required this as well.
=09
	The better products allow the polling interval to be specified
and provide ability for events (under currents, circuit breaker trips,
etc.) to be reported as traps.
=09
	Our larger data center customers wanted this feature too as they
realized polling thousands of devices minute by minute was inefficient
and can yield unacceptable timing uncertainty.
=09
	Our products are able to report accurate measurements - accuracy
being defined as how close do two or more devices agree with a
calibrated reference meter when measuring the same quantity.  This
cannot be achieved without considering time.

	On Wed, Jul 13, 2011 at 8:52 AM, Juergen Quittek
 wrote:

	Dear Mouli,
=09
	Thank you for commenting on this issue. I would like to have a
look at the following point of view:
=09
	So far, storing time series of measurements on managed nodes is
rarely standardized and rarely available as implementation.
=09
	Typically, it is the job of a network management system to
collect time series and store them.
=09
	Take for example byte and packet counters at line cards. You see
many curves showing time series of traffic rate/volume in the Internet,
but almost all of them were collected at management stations or data
collector modules, but not within MIB modules. (Please correct me if I'm
wrong.)
=09
	Now the question is: Is energy management so much different from
other network management tasks, that we need the rarely used mechanism
of storing time series in MIB modules?
=09
	If not, it would be sufficient to just report the number of
total energy consumed since the last re-start as you do it with packet
and byte counters.
	This would be just a single managed object to be specified and
implemented.
=09
	Thanks,
=09
	   Juergen
=09
	Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):
=09
	> Regarding the Time Series debate - the crucial question -
where is the
	> data / measurements stored.
	> It would not be possible for small devices to store such data
for a
	> sufficiently long time period.
	>
	> The NMS can store the values for a sufficiently long period of
time, for
	> trending analysis.
	>
	> In the case of demand measurement, since the maximum over a
window is
	> computed, it is important for the device store atleast a
window length
	> of measurements.
	>
	> I am not sure about that Requirement 5.4.10 - Time Series of
Power
	> Values - to be stored in the device
	>
	> Thanks
	> Mouli
	>
	>
	> -----Original Message-----
	> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On
Behalf Of
	> Juergen Quittek
	> Sent: Tuesday, July 12, 2011 2:31 PM
	> To: eman mailing list
	> Subject: [eman] new revision of eman requirements
	>
	> Dear all,
	>
	> I posted a new version of the eman requirements yesterday.
	> Please find it at
	> http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/
	>
	>
	> Of course, feel free to also comment on the other open issues
or to
	> raise
	> new ones. All such contributions are highly appreciated.
	>
	> Thanks,
	>
	>    Juergen
	>
	> _______________________________________________
	> eman mailing list
	> eman@ietf.org
	> https://www.ietf.org/mailman/listinfo/eman
	> _______________________________________________
	> eman mailing list
	> eman@ietf.org
	> https://www.ietf.org/mailman/listinfo/eman
=09
	_______________________________________________
	eman mailing list
	eman@ietf.org
	https://www.ietf.org/mailman/listinfo/eman

=09
=09
=09
=09
=09

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

	=20

	=20


------_=_NextPart_001_01CC4C89.81BF824B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















+1 on this.



 



We need power, energy and demand as a measured scalar =
value but
there’s no reason to exclude a vector or log of readings if the =
device
can support it. My experience as well is that the poll periods are too =
long for
the data desired. Some peak demands can be down to the minute so some =
local accumulation
is definitely helpful and quite common.



 



 



 









From:=

eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of =
Mielke,
William F (Bill)

Sent: Tuesday, July 26, 2011 10:00 AM

To: eman mailing list

Subject: Re: [eman] new revision of eman requirements - open =
issue12.3:
time series of energy/power values









 



I believe that we should be reporting both energy and =
power. 
Given Michael Suchoff's comments thus far and based on my own experience =
the
actual measurements are typically (frequently?) provided by specialized
metering chips to insure accuracy.  We should seek to preserve this
accuracy by reporting all of the commonly monitored values for each =
measurement
interval and delegate to the device how best to collect the actual =
data. 
I am assuming that Min, Max, and Average values for the various =
parameters will
be readily available on the device so it should not be a large overhead =
to keep
them.



 



Since some devices may be estimating rather than measuring =
these
values the table needs to provide a means of identifying which it is
reporting.  It is not clear to me whether this indication needs to =
be
provided per field, per tabular row, or per device.  Thoughts from =
others?



 



I also think that we need to take care to generalize things =
a bit
to allow the devices to report parameters such as their reporting =
interval and
the size of their on-board history cache.  In some cases these =
values may
be determined statically by the device (and may vary from vendor to =
vendor),
but we should also provide a means for configuring these parameters as =
well for
the devices which seek to be more flexible.



 



On the issue of Push vs. Pull models I suppose that each =
device
manufacturer should be free to decide whether they want to support both, =
or just
one of the two, so we need to clearly identify which combinations are
required.  From my perspective a compliant device needs to be able =
to
support either one or both methods, but that supporting neither is not =
really a
valid choice.  This is just my opinion =
though.



William F. =
Mielke

Alcatel-Lucent

Distinguished Member of Technical Staff

6200 East Broad Street

Room: 4B01-1V

Columbus, OH  43213-1530

Email: Bill.Mielke@alcatel-lucent.com

Phone: 614 =
367 5628

Fax: 614 367 5965



"Live like you're going to die tomorrow.

 Learn like you're going to live forever."



    - Albert Einstein 






 









 












From: eman-bounces@ietf.org
[mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek

Sent: Tuesday, July 26, 2011 12:32 PM

To: Benoit Claise

Cc: eman mailing list

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



Dear all, 






 









I think we are all in line with the statements made =
on the
mailing list.









 









However, so far we haven't addressed the open issue =
as
stated in the requirements draft:









 






> 12.3.  Power and energy time =
series?
> =

>    We have requirements for =
reporting of time series of power and =
energy
>    values.  Do we =
need both or just one of them?  If just one, =
then
>    which =
one?






Requirement 5.4.10 asks for time series of =
power values
and requirement 5.5.4 asks for time series of energy values. Do we =
need
both of them?









 









A second question would be: Do we need them to be =
exported
by SNMP or rather by IPFIX or by both?









 









    Juergen









 









 









 















Am 25.07.2011 um 22:45 schrieb Benoit =
Claise:

















Dear Michael,



This is exactly what's available in the EMAN monitoring MIB for the =
energy

http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09,
section 5.5



Regards, Benoit







Dear Juergen,



The larger manufacturers of managed power distribution equipment (APC, =
Eaton,
Raritan...) all provide circular buffers of time stamped power
measurements.  Certification of our products for use with IBM =
System
Director required this as well.



The better products allow the polling interval to be specified and =
provide
ability for events (under currents, circuit breaker trips, etc.) to be =
reported
as traps.



Our larger data center customers wanted this feature too as they =
realized
polling thousands of devices minute by minute was inefficient and can =
yield
unacceptable timing uncertainty.



Our products are able to report accurate measurements - accuracy being =
defined
as how close do two or more devices agree with a calibrated reference =
meter
when measuring the same quantity.  This cannot be achieved without
considering time.






On Wed, Jul 13, 2011 at 8:52 AM, Juergen Quittek =
<ietf@quittek.at> =
wrote:



Dear Mouli,



Thank you for commenting on this issue. I would like to have a look at =
the
following point of view:



So far, storing time series of measurements on managed nodes is rarely =
standardized
and rarely available as implementation.



Typically, it is the job of a network management system to collect time =
series
and store them.



Take for example byte and packet counters at line cards. You see many =
curves
showing time series of traffic rate/volume in the Internet, but almost =
all of
them were collected at management stations or data collector modules, =
but not
within MIB modules. (Please correct me if I'm wrong.)



Now the question is: Is energy management so much different from other =
network
management tasks, that we need the rarely used mechanism of storing time =
series
in MIB modules?



If not, it would be sufficient to just report the number of total energy
consumed since the last re-start as you do it with packet and byte =
counters.

This would be just a single managed object to be specified and =
implemented.



Thanks,



   Juergen



Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):



> Regarding the Time Series debate - the crucial question - where is =
the

> data / measurements stored.

> It would not be possible for small devices to store such data for =
a

> sufficiently long time period.

>

> The NMS can store the values for a sufficiently long period of =
time, for

> trending analysis.

>

> In the case of demand measurement, since the maximum over a window =
is

> computed, it is important for the device store atleast a window =
length

> of measurements.

>

> I am not sure about that Requirement 5.4.10 - Time Series of =
Power

> Values - to be stored in the device

>

> Thanks

> Mouli

>

>

> -----Original Message-----

> From: eman-bounces@ietf.org
[mailto:eman-bounces@ietf.org] On
Behalf Of

> Juergen Quittek

> Sent: Tuesday, July 12, 2011 2:31 PM

> To: eman mailing list

> Subject: [eman] new revision of eman requirements

>

> Dear all,

>

> I posted a new version of the eman requirements yesterday.

> Please find it at

> http://datatracker.ietf.org/doc/draft-ietf-eman-require=
ments/

>

>

> Of course, feel free to also comment on the other open issues or =
to

> raise

> new ones. All such contributions are highly appreciated.

>

> Thanks,

>

>    Juergen

>

> _______________________________________________

> eman mailing list

> eman@ietf.org

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

> _______________________________________________

> eman mailing list

> eman@ietf.org

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



_______________________________________________

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



 









 


















------_=_NextPart_001_01CC4C89.81BF824B--

From jparello@cisco.com  Wed Jul 27 11:19:36 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A267721F8C04 for ; Wed, 27 Jul 2011 11:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.991
X-Spam-Level: 
X-Spam-Status: No, score=-2.991 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoCaMseLQ1K0 for ; Wed, 27 Jul 2011 11:19:27 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCB121F8BE9 for ; Wed, 27 Jul 2011 11:19:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=218180; q=dns/txt; s=iport; t=1311790765; x=1313000365; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=CEUcDtdCKfW3vqKVB44fevE8oh7xG+t3mBGLlf4ATxc=; b=KTyzZsXczC1RULZ11D2nqAbdLvaFKIDBvFN5hNcKVefE5X2bA3A34nHR eXK329ReAiVl6K82KyCRJbzy+rkvrBBHNj1m/8l4Spo00kPVA5t6QFWgi NzutCQyRNZrEoES7nbTVK1iF12OvLMQFWhu2RZw4DyMOvBrLaojUFfeCl Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Au0AAAxWME6rRDoH/2dsb2JhbAA1AQEBAQMUAQoBAQwGA0QEFgICAQkRBAEBCwYGAQcOAQYBBgETDC8OCAEBBQERBQwUB4I2lSVFhmcBiBt3iQCjXp5rAoMhARKCK18Eh1eQLotyHA
X-IronPort-AV: E=Sophos;i="4.67,277,1309737600"; d="scan'208,217";a="7089012"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jul 2011 18:19:23 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6RIJM5c015161 for ; Wed, 27 Jul 2011 18:19:22 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 27 Jul 2011 11:19:22 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4C89.B512C1C1"
Date: Wed, 27 Jul 2011 11:18:42 -0700
Message-ID: 
In-Reply-To: <4E2E5C6C.6070502@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] feedback on the eman-ietf-eman-requirements-04
Thread-Index: AcxLXDjjsr/e+cmhRhKVia7OhvhUFgBLUJqw
References: <4E2E1729.3070600@cisco.com> <4E2E5C6C.6070502@cisco.com>
From: "John Parello (jparello)" 
To: "Benoit Claise (bclaise)" , "eman mailing list" 
X-OriginalArrivalTime: 27 Jul 2011 18:19:22.0339 (UTC) FILETIME=[B5552B30:01CC4C89]
Subject: Re: [eman] feedback on the eman-ietf-eman-requirements-04
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 18:19:36 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4C89.B512C1C1
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

HI Benoit,

=20

We have the notion of relationships setup in the framework. I sent a
note to Chris on perhaps using this scheme for modeling gangs.

=20

Jp

=20

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Benoit Claise (bclaise)
Sent: Monday, July 25, 2011 11:19 PM
To: eman mailing list
Subject: [eman] feedback on the eman-ietf-eman-requirements-04

=20

Dear all,

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

A couple of big points
- the outlet gang was mentioned by Chris Verges as a requirement. I
don't think I've seen it mentioned.
    Note: this could be solved by a specificEnergy Managed Object
Relationships  (Metering, Power Source, Proxy, Dependency)
- we would need some requirements about producer and/or consumer
- I've been thinking about the following requirement some more

7.3.  Reporting quantities accumulated over multiple powered entities=20

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

And I wonder if we're not trying to make EMAN too complex by adding this
aggregation function.
Note: I've been involved in aggregation scheme (See RFC 5982, RFC 6183,
and http://tools.ietf.org/html/draft-trammell-ipfix-a9n-03) and this is
not straight forward to list all powered entities for which there is an
aggregation.
My point is that there is some debate whether or not a switch should
aggregate all values for children, or if this is a NMS issue.
Feedback?

See inline



Network Working Group                                    J. Quittek, Ed.

Internet-Draft                                                 R. Winter

Intended status: Informational                                  T. Dietz

Expires: January 12, 2012                                NEC Europe Ltd.

                                                               B. Claise

                                                         M. Chandramouli

                                                     Cisco Systems, Inc.

                                                           July 11, 2011



                   Requirements for Energy Management=20
                    draft-ietf-eman-requirements-04=20

Abstract=20

   This document defines requirements for standards specifications for=20
   energy management.  Defined requirements concern monitoring functions

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

This misses the power quality, or whatever name we want to call it.
For example "power characteristics)"




Status of this Memo=20

   This Internet-Draft is submitted in full conformance with the=20
   provisions of BCP 78 and BCP 79.=20

   Internet-Drafts are working documents of the Internet Engineering=20
   Task Force (IETF).  Note that other groups may also distribute=20
   working documents as Internet-Drafts.  The list of current Internet-=20
   Drafts is at http://datatracker.ietf.org/drafts/current/.=20

   Internet-Drafts are draft documents valid for a maximum of six months

   and may be updated, replaced, or obsoleted by other documents at any=20
   time.  It is inappropriate to use Internet-Drafts as reference=20
   material or to cite them other than as "work in progress."=20

   This Internet-Draft will expire on January 12, 2012.=20

Copyright Notice=20

   Copyright (c) 2011 IETF Trust and the persons identified as the=20
   document authors.  All rights reserved.=20




Quittek, et al.         Expires January 12, 2012                [Page 1]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   This document is subject to BCP 78 and the IETF Trust's Legal=20
   Provisions Relating to IETF Documents=20
   (http://trustee.ietf.org/license-info) in effect on the date of=20
   publication of this document.  Please review these documents=20
   carefully, as they describe your rights and restrictions with respect

   to this document.  Code Components extracted from this document must=20
   include Simplified BSD License text as described in Section 4.e of=20
   the Trust Legal Provisions and are provided without warranty as=20
   described in the Simplified BSD License.=20


Table of Contents=20

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

     1.1.   Conventional requirements for energy management . . . . .  4

     1.2.   Specific requirements for energy management . . . . . . .  5


   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6


   3.  General Objectives of Energy Management  . . . . . . . . . . .  8

     3.1.   Power states  . . . . . . . . . . . . . . . . . . . . . .  8

     3.2.   Trade-offs  . . . . . . . . . . . . . . . . . . . . . . .  8

     3.3.   Local and network-wide energy management  . . . . . . . .  8

     3.4.   Energy monitoring . . . . . . . . . . . . . . . . . . . .  9

     3.5.   Overview of energy management requirements  . . . . . . . 10


   4.  Identification of Powered Entities . . . . . . . . . . . . . . 10


   5.  Information on Powered Entities  . . . . . . . . . . . . . . . 11

     5.1.   General information on powered entities . . . . . . . . . 11

     5.2.   Power state . . . . . . . . . . . . . . . . . . . . . . . 12

     5.3.   Power inlet and power outlet  . . . . . . . . . . . . . . 14

     5.4.   Power . . . . . . . . . . . . . . . . . . . . . . . . . . 16

     5.5.   Energy  . . . . . . . . . . . . . . . . . . . . . . . . . 18

     5.6.   Battery State . . . . . . . . . . . . . . . . . . . . . . 19


   6.  Control of Powered Entities  . . . . . . . . . . . . . . . . . 21


   7.  Reporting on Other Powered Entities  . . . . . . . . . . . . . 22


   8.  Controlling Other Powered Entities . . . . . . . . . . . . . . 23

     8.1.   Controlling power states of other powered entities  . . . 23

     8.2.   Controlling power supply of other powered entities  . . . 24


   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25


   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26





Quittek, et al.         Expires January 12, 2012                [Page 2]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26


   12. Open issues  . . . . . . . . . . . . . . . . . . . . . . . . . 26

     12.1.  Revise security considerations  . . . . . . . . . . . . . 26

     12.2.  High/Low power notifications  . . . . . . . . . . . . . . 26

     12.3.  Power and energy time series? . . . . . . . . . . . . . . 26

     12.4.  Inlet/outlet combinations . . . . . . . . . . . . . . . . 26

     12.5.  Aggregation functions . . . . . . . . . . . . . . . . . . 27

     12.6.  Add a definition of 'demand'  . . . . . . . . . . . . . . 27

     12.7.  IEC references  . . . . . . . . . . . . . . . . . . . . . 27

     12.8.  Standard references for BACNET or MODBUS  . . . . . . . . 27

     12.9.  IEEE 1621 and 802.3az references  . . . . . . . . . . . . 27

     12.10. DC power quality covered by IEC standard? . . . . . . . . 27

     12.11. Introduce 'disconnected from power' as power state  . . . 27

     12.12. Need for basic state 'reduced power'? . . . . . . . . . . 27

     12.13. Local and network-wide energy management  . . . . . . . . 28

     12.14. Do we need entity types?  . . . . . . . . . . . . . . . . 28

     12.15. Power availability mode 'minimum' or 'ready'? . . . . . . 28

     12.16. Is there a need for metering power supply inpedance?  . . 28

     12.17. Confidence in power values  . . . . . . . . . . . . . . . 28

     12.18. Terminology for reporting on other entitites  . . . . . . 28


   13. Informative References . . . . . . . . . . . . . . . . . . . . 29


   Appendix A.  Existing Standards  . . . . . . . . . . . . . . . . . 30

     A.1.   Existing IETF Standards . . . . . . . . . . . . . . . . . 30

       A.1.1.  ENTITY MIB . . . . . . . . . . . . . . . . . . . . . . 30

       A.1.2.  ENTITY STATE MIB . . . . . . . . . . . . . . . . . . . 31

       A.1.3.  ENTITY SENSOR MIB  . . . . . . . . . . . . . . . . . . 31

       A.1.4.  UPS MIB  . . . . . . . . . . . . . . . . . . . . . . . 32

       A.1.5.  POWER ETHERNET MIB . . . . . . . . . . . . . . . . . . 32

       A.1.6.  LLDP MED MIB . . . . . . . . . . . . . . . . . . . . . 33

     A.2.   Existing standards of other bodies  . . . . . . . . . . . 33

       A.2.1.  DMTF . . . . . . . . . . . . . . . . . . . . . . . . . 33

       A.2.2.  OVDA . . . . . . . . . . . . . . . . . . . . . . . . . 33

       A.2.3.  IEEE-ISTO Printer WG . . . . . . . . . . . . . . . . . 33


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34














Quittek, et al.         Expires January 12, 2012                [Page 3]

=20
Internet-Draft     Requirements for Energy Management          July 2011



1.  Introduction=20

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

   This document defines requirements for standards specifications for=20
   energy management.  Defined requirements concern monitoring functions

   as well as control functions.  Covered functions include=20
   identification of powered entities, monitoring of their power state,=20
   power inlets, power outlets, actual power, consumed energy, and=20
   contained batteries.  Further included is control of powered=20
   entities' power supply and power state.  Note that this document does

   not specify the features that must be implemented by compliant=20
   implementations but rather features that must be supported by=20
   standards for energy management.=20

Same remark about power quality




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

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

   This document first discusses general objectives of energy management

   in Section 3.  Requirements for an energy management standard are=20
   specified in Sections 4 to 8.=20

1.1.  Conventional requirements for energy management=20

I don't know what "conventional" is supposed to mean.




   The specification of requirements for an energy management standard=20
   starts with Section 4 addressing the identification of powered=20
   entities and the granularity of reporting of energy-related=20
   information. =20

I don't understand why we have that sentence here and not in the
identifier in section 4.



A standard must support unique identification of=20
   powered entities.  Furthermore, it must support more than just=20
   reporting per powered device.  Support is required for also reporting

   energy-related information on individual components of a device or=20



Quittek, et al.         Expires January 12, 2012                [Page 4]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   subtended devices.  This is why this draft uses the more general term

   "powered entity" rather than "powered device".  A powered entity may=20
   be a device or a component of a device.=20

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

1.2.  Specific requirements for energy management=20

   At first glance the rather conventional requirements summarized above

   seem to be all that would be needed for energy management.  But it=20
   turns out that there are some significant differences between energy=20
   management and most of the well known conventional network management

   functions.  The most significant difference from many other=20
   management functions is the need for some devices to report on other=20
   entities.  There are three major reasons for this.=20
   o  For monitoring and controlling a particular powered entity in=20
      general it is not sufficient to communicate with the powered=20

"sufficient" is not the right wording.
In some cases, this is just impossible to communicate with the powered
entity.
Example: proxy.




      entity only, but in many cases also communication with other=20
      powered entities along the power distribution path may be=20
      necessary, for example, with power switches and power meters.=20
      Indeed, there are situations where a power or energy meter is not=20
      located in the powered entity, but in a different physical=20
      location.  For example, a Power Distribution Unit (PDU), which=20
      supplies power for a server connected to a PDU socket, would meter

      the power supplied, while the server may not have the capability=20
      to measure its power consumption. =20

new text: In specific cases, the monitoring and controlling of powered
entities must be done by another entity along the power distribution
domain. For example.=20
And you remove "a second example" below



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

      a scalable approach to communicate directly with all the powered=20
      entities directly from a central energy management system as the=20
      number of powered entities keeps increasing.=20

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





Quittek, et al.         Expires January 12, 2012                [Page 5]

=20
Internet-Draft     Requirements for Energy Management          July 2011



2.  Terminology=20

2.1.  Energy=20

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

   The term 'energy consumption' is commonly used for both, for=20
   referring to the amount of consumed energy and also for referring to=20
   the rate of consuming energy.  In the first case it addresses=20
   consumed energy measured by joule, watthour, or another energy unit,=20
   in the second one it addresses power, typically an average power=20
   measured by watt.=20

   However, in this document the term "consumed energy" always refers to

   an energy quantity (measured in joule, watthour, etc.) and not to a=20
   power quantity (measured in watt, etc.).=20

2.2.  Power=20

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

2.3.  Powered entity=20

   A powered entity is a consumer of energy that is subject to energy=20
   management.  In general, all managed physical entities in a=20
   communication network consume electric energy and thus are subject to

   energy management including particularly energy monitoring and energy

   control.=20

   A powered entity can be a managed device or a component of a managed=20
   device, which is monitored or controlled individually.=20

2.4.  Power state=20

   Power state of a powered entitiy is defined as a specific settings of

   a powered entitiy that influences its power.  Examples of power=20
   states of a powered entitiy are on, off, and sleep.=20

2.5.  Power monitor=20

   Energy management requires retrieving energy-related information on=20
   powered entities.  In many cases this information is not available at

   the powered entities themselves, but at other powered entities.  For=20
   example measurement of power and energy consumption can be conducted=20
   by power meters at other locations along the power distribution tree=20
   for the powered entity.=20

   A power monitor is a module that reports energy-related information=20



Quittek, et al.         Expires January 12, 2012                [Page 6]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   on powered entities.  A power monitor may be integrated into a=20
   powered entity or located remotely of the powered entity.  Instances=20
   of power monitors may report information on, for example, power=20
   supply, power, and power state of a powered entity.  There may be=20
   multiple power monitors reporting information on the same powered=20
   entity.=20

2.6.  Power inlet=20

   Powered entities receive power at their power inlets.  Powered=20
   entities may have multiple inlets, for example, servers with=20
   redundant power supply.  Examples for power inlets are AC power cords

   of a powered entity or an Ethernet port at which the powered entity=20
   receives DC Power over Ethernet (PoE).=20

2.7.  Power outlet=20

   Powered entities may have means to supply others with electrical=20
   power.  Power is delivered to other powered entities through power=20
   outlets.  Power sourcing entities often have more than one power=20
   outlet.  Examples for power outlets are AC power sockets at a Power=20
   Distribution Unit (PDU) and Ethernet ports at a Power over Ethernet=20
   (PoE) Power Sourcing Equipment (PSE), that can supply powered=20
   entities with DC power using the Ethernet cable.=20

2.8.  Energy management=20

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

2.9.  Energy management standard=20

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




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

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

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









Quittek, et al.         Expires January 12, 2012                [Page 7]

=20
Internet-Draft     Requirements for Energy Management          July 2011



3.  General Objectives of Energy Management=20

Rename to "general considerations related to energy management"




   The basic objective of energy management is operating communication=20
   networks and other equipment with minimal amount of energy, while=20
   maintaining a certain level of service.  A set of use cases for=20
   energy management can be found in=20
   [I-D.tychon-eman-applicability-statement].=20

It would read better if the content of section about trade-offs was next
in this introduction (without having a specific section)
Then=20
    3.1. Power States
    3.2 Energy Monitoring versus Energy Savings
    3.3 Local versus network-wide energy management
    3.4. Overview of the energy management requirements





3.1.  Power states=20

   One approach to achieve this goal is by setting all powered entities=20
   to an operational state that results in lower energy consumption, but

   still meets the service level performance objectives.  The sufficient

   performance level may vary over time and can depend on several=20
   factors.  In principle, there are four basic types of power states=20
   for a powered entity or for a whole system:=20
   o  full power state=20
   o  reduced power states (lower clock rate for processor, lower data=20
      rate on a link, etc.)=20
   o  sleep state (not functional, but immediately available)=20
   o  off state (may imply requiring significant time for becoming=20
      operational)=20
   In actual implementations the number of power states and their=20
   properties vary a lot.  Very simple powered entities may just have=20
   only the extreme states, full power and off state.  Some=20
   implementations might use IEEE1621 model of three states on, off, and

   sleep.  However, more granular power states can be implemented with=20
   many levels of off, sleep, and reduced power states.=20

3.2.  Trade-offs=20

   While the general objective of energy management is quite clear, the=20
   way to attain that goal is often difficult.  In many cases there is=20
   no way of reducing power consumption without the consequence of a=20
   potential performance, service, or capacity degradation.  Then a=20
   trade-off needs to be dealt with between service level objectives and

   energy efficiency.  In other cases a reduction of energy consumption=20
   can easily be achieved while still maintaining sufficient service=20
   level performance, for example, by switching powered entities to=20
   lower power states when higher performance is not needed.=20

3.3.  Local and network-wide energy management=20

   Many energy saving functions can be executed locally by a powered=20
   entitiy.  The basic principle is that a powered entitiy monitors its=20
   usage and dynamically adapts its energy consumption according to the=20
   required performance.  It may switch to a sleep state when it is not=20
   in use at all. =20

Well, not only when it's not in use.
It could be based on the time of day, or any other energy saving
policies.



Potential interactions with an energy management=20



Quittek, et al.         Expires January 12, 2012                [Page 8]

=20
Internet-Draft     Requirements for Energy Management          July 2011



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

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

   Both methods, network-wide and local energy management, have=20
   advantages and disadvantages.  Most buildings use both of them.  In=20
   some cases for example, significant energy savings can be achieved by

   simply setting all powered entities in a network to sleep, when the=20
   network is not needed.  However, in general it is dangerous to set=20
   all powered entities of a group to the same state, because there is a

   risk that such actions ignore specifics of individual powered=20
   entities or violate local service level agreements.=20

Can you please expand the previous sentence.
I'm not sure that I agree.




3.4.  Energy monitoring=20

rename to "energy monitoring versus energy savings"




   It should be noted that only monitoring energy consumption and power=20
   states is obviously not a means to reduce the energy consumption of a

   powered entitiy.  In fact, it is likely to increase the power=20
   consumption of a powered entitiy slightly because monitoring energy=20
   may require instrumentation that consumes energy when in use.  And=20
   also reporting of measured quantities over the network consumes=20
   energy.  However, the acquired energy consumption and power state=20
   information is essential for defining energy saving policies and can=20
   be used as input to power state control loops that in total can lead=20
   to energy savings.=20

   Monitoring operational power states and energy consumption can also=20
   be required for other energy management purposes including but not=20
   limited to:=20
   o  investigating power saving potential=20
   o  evaluating the effectiveness of energy saving policies and=20
      measures=20
   o  deriving, implementing, and testing power management strategies=20
   o  accounting for the total power consumption of a powered entity, a=20
      network, or a service=20
   o  predicting a powered entitiy's reliability based on power usage=20
   o  choosing time of next maintenance cycle for a powered entitiy=20







Quittek, et al.         Expires January 12, 2012                [Page 9]

=20
Internet-Draft     Requirements for Energy Management          July 2011



3.5.  Overview of energy management requirements=20

   From the considerations described above the following basic=20
   management functions appear to be required for energy management:=20
   o  monitoring power states=20
   o  monitoring power (energy consumption rate)=20
   o  monitoring (accumulated) energy consumption=20
   o  setting power states=20
   o  setting and enforcing power saving policies=20

And again the comment about the power quality




   It should be noted that active power control is complementary (but=20

what does the "active" power control mean?



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


4.  Identification of Powered Entities=20

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

add a comma



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

   Also stated already in Section 1.1 is the requirement of providing=20
   means for reporting energy-related information on components of a=20
   managed device.  An entity in this document may be an entire managed=20
   device or just a component of it.  Examples of components of interest

   are a hard drive, a battery, or a line card.  For controlling=20
   entities it may be required to be able to address individual=20
   components in order to save energy.  For example, server blades can=20
   be switched off when the overall load is low or line cards at=20
   switches may be powered down at night times.=20

   Instrumentation for measuring energy consumption of a device is=20
   typically more expensive than instrumentation for retrieving the=20
   devices power state.  It may be a reasonable compromise in many cases

   to provide power state information for all individually switchable=20
   components of a device separately, while the energy consumption is=20
   only measured for the entire device.=20

   Detailed Requirements:=20




Quittek, et al.         Expires January 12, 2012               [Page 10]

=20
Internet-Draft     Requirements for Energy Management          July 2011



4.1.  Identifying powered entities=20

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

   potential receivers of monitored information.=20

We want to remove "and persistently" from the sentence, as this is
covered in 4.3

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




4.2.  Identifying components of powered devices=20

   The energy management standard must provide means for identifying not

   just entire devices as powered entities, but also individual=20
   components of powered devices.=20

4.3.  Persistency of Identifiers=20

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


5.  Information on Powered Entities=20

   This section describes energy-related information on powered entities

   for which an energy management standard must provide means for=20
   retrieving and reporting.=20

   Note that the fact that an energy management standard provides=20
   required means does not imply that all of them must be implemented by

   every compliant implementation.  The concrete specification of=20
   standards based on these requirements may label individual features=20
   as mandatory, recommended, or optional.=20

Remove this paragraph above, as this is already covered before, and this
is not specific to this section 5.




   Required information on powered entities can be structured into six=20
   groups.  Section 5.1 specifies requirements for general information=20
   on powered entities, such as type of powered entity or context=20
   information.  Section 5.2 covers requirements related to entities'=20
   power states.  Requirements for information on power inlets and power

   outlets of powered entities are specified in Section 5.3.  Monitoring

   of power and energy is covered by Sections 5.4 and 5.5, respectively.

   Finally, Section 5.6 specified requirements for monitoring batteries.


5.1.  General information on powered entities=20

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



Quittek, et al.         Expires January 12, 2012               [Page 11]

=20
Internet-Draft     Requirements for Energy Management          July 2011



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

   Detailed Requirements:=20

5.1.1.  Type of powered entity=20

   The energy management standard must provide means to retrieve and=20
   report the type of powered entities according to a standrdized=20
   classification scheme.=20

see the email thread on the mailing list.




5.1.2.  Context information on powered entities=20

   The energy management standard must provide means for retrieving and=20
   reporting context information on powered entities, for example tags=20
   associated with a powered entity that indicate the powered entitiy's=20
   role, or importance.=20

5.1.3.  Grouping of powered entities=20

   The energy management standard must provide means for grouping=20
   powered entities, for example, into energy monitoring domains, energy

   control domains, power supply domains, groups of powered entities of=20
   the same type, etc.=20

5.2.  Power state=20

   Many powered entities have a limited number of discrete power states,

   such as, for example, full power, low power, sleep, and off.=20

   Obviously, there is a need to report the actual power state of a=20
   powered entitiy.  Beyond that, there is also a requirement for=20
   standardizing means for retrieving the list of all supported power=20
   states of a powered entitiy.=20

   Different standards bodies have already defined their own sets of=20
   power states for powered entities.  Further organizations are in the=20
   process of adding more of these sets.  In order to support multiple=20
   management systems possibly using different power state sets, while=20
   simultaneously interfacing with a particular powered entity, the=20
   energy management standard must provide means for supporting multiple

   power state sets used simultaneously at a powered entity.=20

   Power states have parameters that describe its properties It is=20
   required to have standardized means for reporting some key=20
   properties, such as mean power and maximum power of a powered entitiy

   in a certain state.=20




Quittek, et al.         Expires January 12, 2012               [Page 12]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   There also is a need to report statistics on power states including=20
   the time spent an the energy consumed in a power state.=20

   For some network management tasks, it may be desirable to receive=20
   notifications from powered entities, for example, when the components

   or the entire entity change their power state.=20

   Detailed Requirements:=20

5.2.1.  Actual power state=20

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

5.2.2.  List of supported power states=20

=09
	   The energy management standard must provide means for
retrieving the=20
	   list of all potential power states of a powered entitiy.=20
=09
	5.2.3.  Multiple power state sets=20
=09
	   The energy management standard must provide means for
supporting=20
	   multiple power state sets simultaneously at a powered entity.

=09
	5.2.4.  List of supported power state sets=20
=09
	   The energy management standard must provide means for
retrieving the=20
	   list of all power state sets supported by a powered entitiy.=20
=09
	5.2.5.  List of supported power states=20

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




   Referring to the "list of supported power state sets" requirement,=20
   the energy management standard must provide means for retrieving the=20
   list of all potential power states of a powered entitiy that belong=20
   to a given power state set.=20

new text.
    For the rest of the document, when the Power State term is used, it
implicitly refers to a power state within a power state set.

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




5.2.6.  Maximum and average power per power state=20

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

5.2.7.  Power state statistics=20

   The energy management standard must provide means for monitoring=20
   statistics per power state including at least the total time spent in

   a power state, the number of times a state was entered and the last=20
   time a state was entered.  More power state statistics are addressed=20



Quittek, et al.         Expires January 12, 2012               [Page 13]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   by requirement 5.5.3.=20

5.2.8.  Power state changes=20

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


5.3.  Power inlet and power outlet=20

   Powered entities have power inlets at which they are supplied with=20
   electric power.  Most powered entities just have a single power=20
   inlet, while some have multiple ones.  Often different power inlets=20
   are connected to separate power distribution trees.  For energy=20
   monitoring, it is important information which power inlets a powered=20
   entitiy has,=20

what do you mean? the type, the number, or something else?



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

   Some powered entities have power outlets for supplying other powered=20
   entities with electric power.  A powered entitiy may have multiple=20
   power outlets.  Examples are Power Distribution Units (PDUs) and=20
   Power over Ethernet (PoE) Power Sourcing Equipment (PSE).=20

Remove the previous sentence, as this is already in the terminology
section.




   For identifying and potentially controlling the source of power=20
   received at an inlet, it may be required to identify the power outlet

   of another powered entity at which the received power is provided.=20
   Analogously, for each outlet it is of interest to identify the power=20
   inlets that receive the power provided at a certain outlet.=20

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

So "static properties" is what we called "power quality"?




   Detailed Requirements:=20

5.3.1.  List of power inlets and power outlets=20

   The energy management standard must provide means for monitoring the=20
   list of power inlets and power outlets at a powered entitiy.=20

5.3.2.  Corresponding power outlet=20

   The energy management standard must provide means for identifying the

   power outlet that provides the power received at a power inlet.=20






Quittek, et al.         Expires January 12, 2012               [Page 14]

=20
Internet-Draft     Requirements for Energy Management          July 2011



5.3.3.  Corresponding power inlets=20

   The energy management standard must provide means for identifying the

   list of power inlets that receive the power provided at a power=20
   outlet.=20

5.3.4.  Availability of power=20

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

5.3.5.  Use of power=20

   The energy management standard must provide means for monitoring for=20
   each power inlet and each power outlet if it is in actual use.  For=20
   the inlet this means that the powered entitiy actually receives power

   at the inlet.  For the outlet this means that actually power is=20
   provided to one or more powered entities at the outlet.=20

5.3.6.  Type of current=20

   The energy management standard must provide means for reporting the=20
   type of current (Alternating Current (AC) or Direct Current (DC)) for

   each power inlet and each power outlet of a powered entity.=20

5.3.7.  Nominal voltage=20

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

5.3.8.  Nominal AC frequency=20

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

5.3.9.  number of AC phases=20

number -> Number




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







Quittek, et al.         Expires January 12, 2012               [Page 15]

=20
Internet-Draft     Requirements for Energy Management          July 2011



5.4.  Power=20

   Power is a quantity measured as instantaneous power or as average=20
   power over a time interval.  In contrast to power state values, this=20
   quantity may change continuously.=20

   Obtaining highly accurate values for power and energy may be costly.=20
   Often dedicated metering hardware is needed for this purpose.=20
   Powered entities without the ability to measure their power and=20
   energy consumption with high accuracy may just report estimated=20
   values, for example based on load monitoring or even just the entity=20
   type.=20

   Depending on how power and energy consumption values are obtained the

   confidence in the reported value and its accuracy may vary.  Powered=20
   entities reporting such values should qualify the confidence in the=20
   reported values and quantify the accuracy of measurements.  For=20
   reporting accuracy, the accuracy classes specified in IEC 62053-21=20
   [IEC.62053-21] and IEC 62053-22 [IEC.62053-22] should be considered.=20

   In addition to the plain real power value, also further properties of

   the supplied power are subject to monitoring.  In case of AC power=20
   supply, there are more power values beyond the real power to be=20
   reported including the apparent power, the reactive power, and the=20
   phase angle of the current or the power factor.  For both AC and DC=20
   power the power quality is also subject of monitoring.=20

So "power quality" is mentioned.



Power quality=20
   parameters include the actual voltage, the actual frequency, the=20
   Total Harmonic Distortion (THD) of voltage and current, the impedance

   of an AC phase or of the DC supply.  Power quality monitoring should=20
   be in line with existing standards, such as [IEC.61850-7-4].=20

   For some network management tasks, it is required to obtain time=20
   series of power values (or energy consumption values).  In general=20
   these could be obtained in many different ways.  It should be avoided

   that such time series can only be obtained by regular polling by the=20
   energy management system.  Means should be provided to either push=20
   such values from the place they are available to the management=20
   system or to have them stored at the powered entitiy for a=20
   sufficiently long period of time such that a management system can=20
   retrieve a stored time series of values.=20

   Detailed Requirements:=20

5.4.1.  Real power=20

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



Quittek, et al.         Expires January 12, 2012               [Page 16]

=20
Internet-Draft     Requirements for Energy Management          July 2011



5.4.2.  Power measurement interval=20

   The energy management standard must provide means for reporting the=20
   corresponding time or time interval for which a power value is=20
   reported.  The power value can be measured at the corresponding time=20
   or averaged over the corresponding time interval.=20

5.4.3.  Confidence in power values=20

   The energy management standard must provide means for reporting the=20
   confidence in reported power values by indicating the way these=20
   values have been obtained. for example, by power measurement, by=20
   estimation based on performance values, or hard coding average power=20
   values for a powered entity.=20

5.4.4.  Accuracy of power and energy values=20

   The energy management standard must provide means for reporting the=20
   accuracy of reported power values.=20

5.4.5.  Complex power=20

   The energy management standard must provide means for reporting the=20
   complex power for each power inlet and each power outlet of a powered

   entity.  Besides the real power, at least two out of the following=20
   three quantities need to be reported: apparent power, reactive power,

   phase angle.  The phase angle can be substituted by the power factor.

   In case of AC power supply, means must be provided for reporting the=20
   complex power per phase.=20

5.4.6.  Actual voltage and current=20

   The energy management standard must provide means for reporting the=20
   actual voltage and actual current for each power inlet and each power

   outlet of a powered entity.  In case of AC power supply, means must=20
   be provided for reporting the actual voltage and actual current per=20
   phase.=20

5.4.7.  Actual AC frequency=20

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

5.4.8.  Total harmonic distortion=20

   The energy management standard must provide means for reporting the=20
   Total Harmonic Distortion (THD) of voltage and current for each power




Quittek, et al.         Expires January 12, 2012               [Page 17]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   inlet and each power outlet of a powered entity.  In case of AC power

   supply, means must be provided for reporting the THD per phase.=20

5.4.9.  Power supply impedance=20

   The energy management standard must provide means for reporting the=20
   impedance of power supply for each power inlet and each power outlet=20
   of a powered entity.  In case of AC power supply, means must be=20
   provided for reporting the impedance per phase.=20

5.4.10.  Time series of power values=20

   The energy management standard must provide means for collecting time

   series of real power values for each power inlet and for each power=20
   outlet of a powered entitiy without requiring to regularly poll the=20
   powered entitiy from an energy management station.  A solution for=20
   this is that the concerned powered entity or another powered entity=20
   closely interacting with the concerned powered entity collect time=20
   series of power values and make them available via push or pull=20
   mechanisms to receivers of the information.=20

5.5.  Energy=20

   Monitoring of electrical energy consumed (or converted) at a powered=20
   entitiy can be done in various ways.  One is collecting time series=20
   of power values for the powered entitiy and calculating the consumed=20
   energy from these values.  An alternative is the powered entity=20
   itself or another powered entity taking care of energy measurement=20
   and reporting energy consumption values for certain time intervals.=20
   Time intervals of interest are the time from the last restart of the=20
   powered entitiy to the reporting time, the time from another past=20
   event to the reporting time, or the last given amount of time before=20
   the reporting time.=20

   In order to monitor energy consumption in different power states, it=20
   is useful if powered entities record their energy consumption per=20
   power state and report these quantities.=20

   For some network management tasks, it is required to obtain time=20
   series of energy values.  In general these could be obtained in many=20
   different ways.  It should be avoided that such time series can only=20
   be obtained by regular polling by the energy management system.=20
   Means should be provided to either push such values from the place=20
   they are available to the management system or to have them stored at

   the powered entitiy for a sufficiently long period of time such that=20
   a management system can retrieve a stored time series of values.=20

   Detailed Requirements:=20



Quittek, et al.         Expires January 12, 2012               [Page 18]

=20
Internet-Draft     Requirements for Energy Management          July 2011



5.5.1.  Energy=20

   The energy management standard must provide means for reporting the=20
   consumed energy received at a power input or provided at a power=20
   outlet of a powered entitiy.  Reports must be made for a clearly=20
   specified time interval.=20

5.5.2.  Time intervals=20

   The energy management standard must provide means for reporting the=20
   consumed energy of a powered entitiy for certain time intervals.=20
   o  Reports must be supported for the time interval starting at the=20
      last restart of the powered entitiy and ending at a certain point=20
      in time, such as the time when a report was delivered.=20
   o  Reports must be supported for a sequence of consecutive non-=20
      overlapping time intervals of fixed size (periodic reports).=20
   o  Reports must be supported for a sequence of consecutive=20
      overlapping time intervals of fixed size (periodic reports).=20
   o  Reports must be supported for an interval of given length ending=20
      at a certain point in time, such as the time when a report was=20
      delivered (sliding window)=20

5.5.3.  Energy per power state=20

   The energy management standard must provide means for reporting the=20
   consumed energy individually for each power state.  This extends the=20
   requirement 5.2.7 on power state statistics.=20

5.5.4.  Time series of energy values=20

   The energy management standard must provide means for collecting time

   series of energy values for each power inlet and for each power=20
   outlet of a powered entitiy without requiring to regularly poll the=20
   powered entitiy from an energy management station.  A solution for=20
   this is that the concerned powered entity or another powered entity=20
   closely interacting with the concerned powered entity collect time=20
   series of energy values and make them available via push or pull=20
   mechanisms to receivers of the information.=20

5.6.  Battery State=20

   Today more and more powered entities contain batteries that supply=20
   them with power when disconnected from electrical power distribution=20
   grids.  Common examples are nomadic and mobile devices, such as=20
   notebook computers, netbooks, and smart phones.  The status of=20
   batteries in such an powered entity, particularly the charging status

   is typically controlled by automatic functions that act locally on=20
   the powered entitiy and manually by users of the powered entity.  In=20



Quittek, et al.         Expires January 12, 2012               [Page 19]

=20
Internet-Draft     Requirements for Energy Management          July 2011



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

   The management requirements discussed above in Sections 5.1 to 5.5=20
   concern energy-related information on powered entities.  Powered=20
   entities may be powered devices or components of powered devices.=20

I  believe that we mentioned that sentence already.



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

   In both cases further information on batteries is of interest for=20
   energy management, such as the current charge of the battery, the=20
   number of completed charging cycles, the charging state of the=20
   battery, and further static and dynamic battery properties.  Also=20
   desirable is to receive notifications if the charge of a battery=20
   becomes very low or if a battery needs to be replaced.=20

   Detailed Requirements:=20

5.6.1.  Battery charge=20

   The energy management standard must provide means for reporting the=20
   current charge of a battery.=20

5.6.2.  Battery charging state=20

   The energy management standard must provide means for reporting the=20
   charging state (charged, discharged, etc.) of a battery.=20

5.6.3.  Battery charging cycles=20

   The energy management standard must provide means for reporting the=20
   number of completed charging cycles of a battery.=20

5.6.4.  Actual battery capacity=20

   The energy management standard must provide means for reporting the=20
   actual capacity of a battery.=20

5.6.5.  Static battery properties=20

   The energy management standard must provide means for reporting=20
   static properties of a battery, including the nominal capacity, the=20
   number of cells, the nominal voltage, and the battery technology.=20




Quittek, et al.         Expires January 12, 2012               [Page 20]

=20
Internet-Draft     Requirements for Energy Management          July 2011



5.6.6.  Low battery charge notification=20

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

remove "a"




5.6.7.  Battery replacement notification=20

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

5.6.8.  Multiple batteries=20

   The energy management standard must provide means for meeting=20
   requirements 5.6.1 to 5.6.7 for each individual battery contained in=20
   a single powered entity.=20


6.  Control of Powered Entities=20

   Many powered entities control their power state locally by self-=20
   managed dynamic adaptation to the environment.  But other powered=20
   entities without that capability need interfaces for a energy=20
   management system to control their power states in order to save=20
   energy.  Even for self-managed powered entities such interface may be

   required for overruling local policy decisions by global ones from an

   energy management system.=20

   Power supply is typically not self-managed by powered entities.  And=20
   controlling power supply is typically not conducted as interaction=20
   between energy management system and the powered entity itself.  It=20
   is rather an interaction between the management system and an entity=20
   providing power at its power outlets.  Still, requirements for power=20
   state control apply accordingly to power supply control.=20

   Note that shutting down the power supply abruptly may have severe=20
   consequences for the powered entity.=20

   Detailed Requirements:=20

6.1.  Controlling power states=20

   The energy management standard must provide means for setting power=20
   states of powered entities.=20






Quittek, et al.         Expires January 12, 2012               [Page 21]

=20
Internet-Draft     Requirements for Energy Management          July 2011



6.2.  Controlling power supply=20

   The energy management standard must provide means for switching power

   supply off or turning power supply on at power outlets providing=20
   power to one or more powered entity.=20


7.  Reporting on Other Powered Entities=20

   As already discussed in the introduction of Section 5, not all=20
   energy-related information may be available at the concerned powered=20
   entity.  Such information may be provided by other powered entities,=20
   such as a Power Distribution Unit (PDU), external power meter, or a=20
   Power over Ethernet (PoE) Power Sourcing Equipment (PSE).  Some of=20
   these entities (PDU, PSE) can also control the power provided to the=20
   other powered entities, while some can just report on the remote=20
   powered entities (external power meter).  This section covers=20
   reporting of information (monitoring) only.  See Section 8 for=20
   requirements on controlling other powered entities.=20

   There are cases where a power supply unit switches power for several=20
   powered entities by turning power on or off at a single power outlet=20
   or where a power meter measures the accumulated power of several=20
   powered entities at a single power line.  Consequently, it should be=20
   possible to report that a monitored value does not relate to just a=20
   single powered entity, but is an accumulated value for a set of=20
   powered entities.  All of these powered entities belonging to that=20
   set need to be identified.=20

   If a powered entity has information about where energy-related=20
   information on itself can be retrieved, then it would be very useful=20
   if it has a way to communicate this information to an energy=20
   management system.  This applies even if the information only=20
   provides accumulated quantities for several powered entities.=20

   Detailed Requirements:=20

7.1.  Reports on other powered entities=20

   The energy management standard must provide means for a powered=20
   entitiy to report energy-related information on another powered=20
   entity.=20

7.2.  Identity of other powered entities on which is reported=20

   The energy management standard must provide means for reporting the=20
   identity of another powered entity on which energy-related=20
   information is reported.=20



Quittek, et al.         Expires January 12, 2012               [Page 22]

=20
Internet-Draft     Requirements for Energy Management          July 2011



7.3.  Reporting quantities accumulated over multiple powered entities=20

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

See my comments at the beginning of the email




7.4.  List of all powered entities on which is reported=20

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

7.5.  Content of reports on other powered entities=20

   The energy management standard must provide means for a powered=20
   entitiy to indicate for each other powered entity on which it can=20
   provide energy-related information which energy-related information=20
   can be provided for this powered entity.=20

7.6.  Indicating source of remote information=20

   The energy management standard must provide means for a powered=20
   entity to indicate another powered entity at which energy-related=20
   information on itself can be retrieved.=20

7.7.  Indicating source of remote information=20

   For a powered entity that has another powered entity at which energy-

   related information on itself can be retrieved, the energy management

   standard must provide means for indicating the information that is=20
   available at other powered entities per other powered entity.=20


8.  Controlling Other Powered Entities=20

   This section specifies requirements for controlling power states and=20
   power supply of powered entities by communicating not with these=20
   powered entities themselves, but with other powered entities that=20
   have means for controlling power state or power supply of others.=20

8.1.  Controlling power states of other powered entities=20

   Some powered entities may have control of power states of other=20
   powered entities.  For example a gateway to a building network may=20
   have means to control the power state of powered entities in the=20
   building that do not have an IP interface.  For this and similar=20
   cases means are needed to make this control accessible to the energy=20



Quittek, et al.         Expires January 12, 2012               [Page 23]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   management system.=20

   In addition to this, it is required that a powered entitiy that has=20
   its state controlled by other powered entities has means to report=20
   the list of these other powered entities.=20

   Detailed Requirements:=20

8.1.1.  Control of power states of other powered entities=20

   The energy management standard must provide means for an energy=20
   management system to send power state control commands to a powered=20
   entity that concern the power states of other powered entities than=20
   the one the command was send to.=20

8.1.2.  Identity of other power state controlled entities=20

   The energy management standard must provide means for reporting the=20
   identity of another powered entity for which the reporting powered=20
   entity has means to control the power state.=20

8.1.3.  List of all power state controlled entities=20

   The energy management standard must provide means for a powered=20
   entitiy to report the list of all powered entities for which it can=20
   control the power state.=20

8.1.4.  List of all power state controllers=20

   The energy management standard must provide means for a powered=20
   entitiy that receives commands controlling its power state from other

   powered entities to report the list of all those entities.=20

8.2.  Controlling power supply of other powered entities=20

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

   energy management system.=20

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

very required -> required



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

   Detailed Requirements:=20





Quittek, et al.         Expires January 12, 2012               [Page 24]

=20
Internet-Draft     Requirements for Energy Management          July 2011



8.2.1.  Control of power supply of other powered entities=20

   The energy management standard must provide means for an energy=20
   management system to send power supply control commands to a powered=20
   entity that concern the power supply of other powered entities than=20
   the one the command was send to.=20

8.2.2.  Identity of other power supply controlled powered entities=20

   The energy management standard must provide means for reporting the=20
   identity of another powered entity for which the reporting powered=20
   entity has means to control the power supply.=20

8.2.3.  List of all power supply controlled powered entities=20

   The energy management standard must provide means for a powered=20
   entitiy to report the list of all other powered entities for which it

   can control the power supply.=20

8.2.4.  List of all power supply controllers=20

   The energy management standard must provide means for a powered=20
   entitiy that has other powered entities controlling its power supply=20
   to report the list of all those powered entities.=20


9.  Security Considerations=20

   The typical security threats for the management protocol for energy=20
   monitoring are similar to the ones specified in the SNMP security=20
   framework.  In other words, from an energy monitoring point of view,=20
   no additional security requirements have been imposed.=20

   Link layer discovery mechanisms need to ensure that only the trusted=20
   powered entities shall be discovered during discovery and detect/=20
   discard powered entities without a trusted relationship to be=20
   included among the powered entities for energy monitoring.=20

   In terms of monitoring, considering that there can be some network=20
   entities which shall be entitled to collect the measured data on=20
   behalf of other powered entities, then it is important to=20
   authenticate and/or authorize such powered entities.  In addition, in

   the case of control of other powered entities, it would be highly=20
   desirable to have some form of an authentication mechanism to ensure=20
   that only the designated powered entities shall control the powered=20
   entities within its control domain.  It should be possible to prevent

   a powered entity which does not have the appropriate authorization=20
   and authority to control or configure powered entities in its control




Quittek, et al.         Expires January 12, 2012               [Page 25]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   domain/purview.  Secondly, it should be possible to prevent malicious

   powered entities from exercising control over entities.=20


10.  IANA Considerations=20

   This document has no actions for IANA.=20


11.  Acknowledgements=20

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

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

Regards, Benoit.




12.  Open issues=20

12.1.  Revise security considerations=20

   A discussion of the sensitivity of the content of the monitoring data

   is missing.=20

12.2.  High/Low power notifications=20

   For some network management tasks it may be desirable to receive=20
   notifications from entities when the power of an powered entity=20
   exceeds or falls below certain thresholds.  Do we want to make this a

   requirement?=20

   Proposal: added "for example" so that we don't restrict the framework

   to only this notification=20

12.3.  Power and energy time series?=20

   We have requirements for reporting of time series of power and energy

   values.  Do we need both or just one of them?  If just one, then=20
   which one?=20

12.4.  Inlet/outlet combinations=20

   How to model the case that an inlet or outlet changes during=20
   operation from one kind to the other.  An example is a battery that=20
   receives power at a socket at one time.  Then the socket is an inlet.

   At another time the battery provides power at the same socket.  Then=20
   it's an outlet.  The same holds for entities with integrated power=20
   generators.=20



Quittek, et al.         Expires January 12, 2012               [Page 26]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   One solution would be to introduce a new kind of hybrid in/outlets.=20
   Another one would be to model the same socket as inlet as well as as=20
   outlet.  It would appear twice in the list of all inlets and outlets.

   Then received power/energy would be reported under the inlet entry=20
   and provided power/energy would be reported under the outlet entry.=20

   These would be two solutions.  What would be the concrete requirement

   behind them?=20

12.5.  Aggregation functions=20

   Aggregation functions are not covered (yet).  Are there requirements=20
   on aggregation?  Which are they?=20

12.6.  Add a definition of 'demand'=20

12.7.  IEC references=20

   References to mentioned IEC standards are missing.  Also these=20
   references should be double checked.=20

12.8.  Standard references for BACNET or MODBUS=20

   Section 1 mentions BACNET or MODBUS as examples for building network=20
   protocols.  We need references to the standards specifications for=20
   these protocols.=20

12.9.  IEEE 1621 and 802.3az references=20

   A reference to the IEEE 1621 standard is missing in section 3.1 and a

   reference to IEEE 802.3az is missing in section 3.4.  The references=20
   should be double checked if they are well applicable in the=20
   respective section.=20

12.10.  DC power quality covered by IEC standard?=20

   Is there an IEC standard on DC power quality?=20

12.11.  Introduce 'disconnected from power' as power state=20

   We need to introduce the concept of a device being "disconnected"=20
   from power.  This is a subset of the Off state.  Shall we do it here=20
   or rather in the framework draft?=20

12.12.  Need for basic state 'reduced power'?=20

   Are "full power" and "reduced power" really different basic types of=20
   power states?  Both may be forms of the on state.  Identifying "full"




Quittek, et al.         Expires January 12, 2012               [Page 27]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   separately is arbitrary.  (For something like a computer, "idle" is=20
   the most common state so would be the one to call out separately=20
   rather than "full".)=20

12.13.  Local and network-wide energy management=20

   All but first sentence of the third paragraph in section 3.3 seem to=20
   be true not needed here.  Proposal: remove them.=20

12.14.  Do we need entity types?=20

   Or shall we remove Section 5.1.1?=20

12.15.  Power availability mode 'minimum' or 'ready'?=20

   Do we need an additional mode for power availability called "minimum"

   or "ready" for power availability in xref target=3D"availability"/>?=20
   This would reflect a PoE state at which the PSE is ready to serve the

   PD.=20

12.16.  Is there a need for metering power supply inpedance?=20



12.17.  Confidence in power values=20

   Shall we rename "confidence in power values" to "method for=20
   determining power values"?=20

12.18.  Terminology for reporting on other entitites=20

   In Section 7 we need some additional terms here to streamline the=20
   text (and ultimately our thinking).  Nominations include:=20
   o  "powered entity" (which may be "self-reporting")=20
   o  "reporting entity" (can be "self" or "other")=20
   o  "other entity" (a reporting entity reporting not on itself; likely

      a different term would be better for this)=20
   o  "controlled entity", "controlling entity" (section 8.1)=20
   o  "switched entity", "switching entity" (section 8.2)=20

   Also, there are two cases for an "other entity".  One is where the=20
   powered entity cannot report the value in question itself (either=20
   because it can't report anything, or doesn't know the value in=20
   question, e.g. when metering is external).=20

   The second is where the powered entity can report, but the other=20
   entity is doing the reporting for some convenience.  We need to be=20
   aware of both even if the framework does not need to make the=20



Quittek, et al.         Expires January 12, 2012               [Page 28]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   distinction.=20

   There may be multiple other reporting entities, not just a single=20
   one.=20

   Do components of devices ever report, or do only devices do the=20
   reporting?  This seems like an important point.=20


13.  Informative References=20

   [RFC1628]  Case, J., "UPS Management Information Base", RFC 1628,=20
              May 1994.=20

   [RFC3433]  Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor

              Management Information Base", RFC 3433, December 2002.=20

   [RFC3621]  Berger, A. and D. Romascanu, "Power Ethernet MIB",=20
              RFC 3621, December 2003.=20

   [RFC3805]  Bergman, R., Lewis, H., and I. McDonald, "Printer MIB v2",

              RFC 3805, June 2004.=20

   [RFC4133]  Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)",=20
              RFC 4133, August 2005.=20

   [RFC4268]  Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268,

              November 2005.=20

   [I-D.tychon-eman-applicability-statement]=20
              Tychon, E., Silver, L., and M. Chandramouli, "Energy=20
              Management (EMAN) Applicability Statement",=20
              draft-tychon-eman-applicability-statement-02 (work in=20
              progress), June 2011.=20

   [ACPI.R30b]=20
              Hewlett-Packard Corporation, Intel Corporation, Microsoft=20
              Corporation, Phoenix Corporation, and Toshiba Corporation,

              "Advanced Configuration and Power Interface Specification,

              Revision 3.0b", October 2006.=20

   [DMTF.DSP1027]=20
              Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.),=20
              "Power State Management Profile", September 2008.=20

   [IEEE-ISTO]=20
              Printer Working Group, "PWG 5106.4 - PWG Power Management=20
              Model for Imaging Systems 1.0:", February 2011.=20



Quittek, et al.         Expires January 12, 2012               [Page 29]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   [IEC.62053-21]=20
              International Electrotechnical Commission, "Electricity=20
              metering equipment (a.c.) - Particular requirements - Part

              22: Static meters for active energy  (classes 1 and 2)",=20
              2003.=20

   [IEC.62053-22]=20
              International Electrotechnical Commission, "Electricity=20
              metering equipment (a.c.) - Particular requirements - Part

              22: Static meters for active energy  (classes 0,2 S and=20
              0,5 S)", 2003.=20

   [IEC.61850-7-4]=20
              International Electrotechnical Commission, "Communication=20
              networks and systems for power utility automation - Part=20
              7-4: Basic communication structure - Compatible logical=20
              node classes and data object classes", 2010.=20


Appendix A.  Existing Standards=20

   This section analyzes existing standards for energy consumption and=20
   power state monitoring.  It shows that there are already several=20
   standards that cover only some part of the requirements listed above,

   but even all together they do not cover all of the requirements for=20
   energy management.=20

A.1.  Existing IETF Standards=20

   There are already RFCs available that address a subset of the=20
   requirements.=20

A.1.1.  ENTITY MIB=20

   The ENTITY-MIB module defined in [RFC4133] was designed to model=20
   physical and logical entities of a managed system.  A physical entity

   is an identifiable physical component.  A logical entity can use one=20
   or more physical entities.  From an energy monitoring perspective of=20
   a managed system, the ENTITY-MIB modeling framework can be reused and

   whenever RFC 4133 [RFC4133] has been implemented.  The=20
   entPhysicalIndex from entPhysicalTable can be used to identify an=20
   entity/component.  However, there are use cases of energy monitoring,

   where the application of the ENTITY-MIB does not seem readily=20
   apparent and some of those entities could be beyond the original=20
   scope and intent of the ENTITY-MIB.=20

   Consider the case of remote devices attached to the network, and the=20
   network device could collect the energy measurement and report on=20



Quittek, et al.         Expires January 12, 2012               [Page 30]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   behalf of such attached devices.  Some of the remote devices such as=20
   PoE phones attached to a switch port have been considered in the=20
   Power-over-Ethernet MIB module [RFC3621].  However, there are many=20
   other devices such as a computer, which draw power from a wall outlet

   or building HVAC devices which seem to be beyond the original scope=20
   of the ENTITY-MIB.=20

   Yet another example, is smart-PDUs, which can report the energy=20
   consumption of the device attached to the power outlet of the PDU.=20
   In some cases, the device can be attached to multiple to power=20
   outlets.  Thus, the energy measured at multiple outlets need to be=20
   aggregated to determine the consumption of a single device.  From=20
   mapping perspective, between the PDU outlets and the device this is a

   many-to-one mapping.  It is not clear if such a many-to-one mapping=20
   is feasible within the ENTITY-MIB framework.=20

A.1.2.  ENTITY STATE MIB=20

   RFC 4268 [RFC4268] defines the ENTITY STATE MIB module.=20
   Implementations of this module provide information on entities=20
   including the standby status (hotStandby, coldStandby,=20
   providingService), the operational status (disabled, enabled,=20
   testing), the alarm status (underRepair, critical, major, minor,=20
   warning), and the usage status (idle, active, busy).  This=20
   information is already useful as input for policy decisions and for=20
   other network management tasks.  However, the number of states would=20
   cover only a small subset of the requirements for power state=20
   monitoring and it does not provide means for energy consumption=20
   monitoring.  For associating the information conveyed by the ENTITY=20
   STATE MIB to specific components of a device, the ENTITY STATE MIB=20
   module makes use of the means provided by the ENTITY MIB module=20
   [RFC4133].  Particularly, it uses the entPhysicalIndex for=20
   identifying entities.=20

   The standby status provided by the ENTITY STATE MIB module is related

   to power states required for energy management, but the number of=20
   states is too restricted for meeting all energy management=20
   requirements.  For energy management several more power states are=20
   required, such as different sleep and operational states as defined=20
   by the Advanced Configuration and Power Interface (ACPI) [ACPI.R30b]=20
   or the DMTF Power State Management Profile [DMTF.DSP1027].=20

A.1.3.  ENTITY SENSOR MIB=20

   RFC 3433 [RFC3433] defines the ENTITY SENSOR MIB module.=20
   Implementations of this module offer a generic way to provide data=20
   collected by a sensor.  A sensor could be an energy consumption meter

   delivering measured values in Watt.  This could be used for reporting




Quittek, et al.         Expires January 12, 2012               [Page 31]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   current power of an entity and its components.  Furthermore, the=20
   ENTITY SENSOR MIB can be used to retrieve the accuracy of the used=20
   power meter.=20

   Similar to the ENTITY STATE MIB module, the ENTITY SENSOR MIB module=20
   makes use of the means provided by the ENTITY MIB module [RFC4133]=20
   for relating provided information to components of a device.=20

   However, there is no unit available for reporting energy quantities,=20
   such as, for example, watt seconds or kilowatt hours, and the ENTITY=20
   SENSOR MIB module does not support reporting accuracy of measurements

   according to the IEC / ANSI accuracy classes, which are commonly in=20
   use for electric power and energy measurements.  The ENTITY SENSOR=20
   MIB modules only provides a coarse-grained method for indicating=20
   accuracy by stating the number of correct digits of fixed point=20
   values.=20

A.1.4.  UPS MIB=20

   RFC 1628 [RFC1628] defines the UPS MIB module.  Implementations of=20
   this module provide information on the current real power of entities

   attached to an uninterruptible power supply (UPS) device.  This=20
   application would require identifying which entity is attached to=20
   which port of the UPS device.=20

   UPS MIB provides information on the state of the UPS network.  The=20
   MIB module contains several variables that are used to identify the=20
   UPS entity (name, model,..), the battery state, to characterize the=20
   input load to the UPS, to characterize the output from the UPS, to=20
   indicate the various alarm events.  The measurements of power in UPS=20
   MIB are in Volts, Amperes and Watts.  The units of power measurement=20
   are RMS volts, RMS Amperes and are not based on Entity-Sensor MIB=20
   [RFC3433].=20

A.1.5.  POWER ETHERNET MIB=20

   Similar to the UPS MIB, implementations of the POWER ETHERNET MIB=20
   module defined in RFC3621 [RFC3621] provide information on the=20
   current energy consumption of the entities that receive Power over=20
   Ethernet (PoE).  This information can be retrieved at the power=20
   sourcing equipment.  Analogous to the UPS MIB, it is required to=20
   identify which entities are attached to which port of the power=20
   sourcing equipment.=20

   The POWER ETHERNET MIB does not report power and energy consumption=20
   on a per port basis, but can report aggregated values for groups of=20
   ports.  It does not use objects of the ENTITY MIB module for=20
   identifying entities, although this module existed already when the=20



Quittek, et al.         Expires January 12, 2012               [Page 32]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   POWER ETHERNET MIB modules was standardized.=20

A.1.6.  LLDP MED MIB=20

   The Link Layer Discovery Protocol (LLDP) defined in IEEE 802.1ab is a

   data link layer protocol used by network devices for advertising of=20
   their identities, capabilities, and interconnections on a LAN=20
   network.  The Media Endpoint Discovery (MED) (ANSI/TIA-1057) is an=20
   enhancement of LLDP known as LLDP-MED.  The LLDP-MED enhancements=20
   specifically address voice applications.  LLDP-MED covers 6 basic=20
   areas: capabilities discovery, LAN speed and duplex discovery,=20
   network policy discovery, location identification discovery,=20
   inventory discovery, and power discovery.=20

A.2.  Existing standards of other bodies=20

A.2.1.  DMTF=20

   The DMTF has defined a power state management profile [DMTF.DSP1027]=20
   that is targeted at computer systems.  It is based on the DMTF's=20
   Common Information Model (CIM) and rather an entity profile than an=20
   actual energy consumption monitoring standard.=20

   The power state management profile is used to describe and to manage=20
   the power state of computer systems.  This includes e.g. means to=20
   change the power state of an entity (e.g. to shutdown the entity)=20
   which is an aspect of but not sufficient for active energy=20
   management.=20

A.2.2.  OVDA=20

   ODVA is an association consisting of members from industrial=20
   automation companies.  ODVA supports standardization of network=20
   technologies based on the Common Industrial Protocol (CIP).  Within=20
   ODVA, there is a special interest group focused on energy and=20
   standardization and inter-operability of energy aware entities.=20

A.2.3.  IEEE-ISTO Printer WG=20

   The charter of the IEEE-ISTO Printer Working Group is for open=20
   standards that define printer related protocols, that printer=20
   manufacturers and related software vendors shall benefit from the=20
   interoperability provided by conformance to these standards.  One=20
   particular aspect the Printer WG is focused on is power monitoring=20
   and management of network printers and imaging systems PWG Power=20
   Management Model for Imaging Systems [IEEE-ISTO].  Clearly, these=20
   devices are within the scope of energy management since these devices

   consume power and are attached to the network.  In addition, there is




Quittek, et al.         Expires January 12, 2012               [Page 33]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   ample scope of power management since printers and imaging systems=20
   are not used that often.  IEEE-ISTO Printer working group has defined

   MIB modules for monitoring the power consumption and power state=20
   series that can be useful for power management of printers.  The=20
   energy management framework should also take into account the=20
   standards defined in the Printer working group.  In terms of other=20
   standards, IETF Printer MIB RFC3805 [RFC3805] has been standardized,=20
   however, this MIB module does not address power management of=20
   printers.=20


Authors' Addresses=20

   Juergen Quittek (editor)=20
   NEC Europe Ltd.=20
   NEC Laboratories Europe=20
   Network Research Division=20
   Kurfuersten-Anlage 36=20
   Heidelberg  69115=20
   DE=20

   Phone: +49 6221 4342-115=20
   Email: quittek@neclab.eu=20


   Rolf Winter=20
   NEC Europe Ltd.=20
   NEC Laboratories Europe=20
   Network Research Division=20
   Kurfuersten-Anlage 36=20
   Heidelberg  69115=20
   DE=20

   Phone: +49 6221 4342-121=20
   Email: Rolf.Winter@neclab.eu=20


   Thomas Dietz=20
   NEC Europe Ltd.=20
   NEC Laboratories Europe=20
   Network Research Division=20
   Kurfuersten-Anlage 36=20
   Heidelberg  69115=20
   DE=20

   Phone: +49 6221 4342-128=20
   Email: Thomas.Dietz@neclab.eu=20




Quittek, et al.         Expires January 12, 2012               [Page 34]

=20
Internet-Draft     Requirements for Energy Management          July 2011



   Benoit Claise=20
   Cisco Systems, Inc.=20
   De Kleetlaan 6a b1=20
   Degem  1831=20
   BE=20

   Phone: +32 2 704 5622=20
   Email: bclaise@cisco.com=20


   Mouli Chandramouli=20
   Cisco Systems, Inc.=20
   Sarjapur Outer Ring Road=20
   Bangalore,=20
   IN=20

   Phone: +91 80 4426 3947=20
   Email: moulchan@cisco.com=20

































Quittek, et al.         Expires January 12, 2012               [Page 35]

=20

=20


------_=_NextPart_001_01CC4C89.B512C1C1
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















HI Benoit,



 



We have the notion of relationships setup in the =
framework. I
sent a note to Chris on perhaps using this scheme for modeling =
gangs.



 



Jp



 









From: eman-bounces@ietf.org
[mailto:eman-bounces@ietf.org] On Behalf Of Benoit Claise =
(bclaise)

Sent: Monday, July 25, 2011 11:19 PM

To: eman mailing list

Subject: [eman] feedback on the =
eman-ietf-eman-requirements-04









 



Dear all,



Here is my feedback regarding the EMAN requirement, as a =
contributor.

Note that some points might have been made on the mailing list =
already.



A couple of big points

- the outlet gang was mentioned by Chris Verges as a requirement. I =
don't think
I've seen it mentioned.

    Note: this could be solved by a specificEnergy =
Managed
Object Relationships  (Metering, Power Source, Proxy, =
Dependency)

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

- I've been thinking about the following requirement some =
more



7.3.  Reporting quantities accumulated over =
multiple
powered entities 



   For powered entities reporting single values that are =
accumulated 

   over multiple powered entities, the energy management =
standard
must 

   provide means for reporting the list of all powered =
entities from 

   which contributions are included in the accumulated value. =




And I wonder if we're not trying to make EMAN too =
complex by
adding this aggregation function.

Note: I've been involved in aggregation scheme (See RFC 5982, RFC 6183, =
and http://to=
ols.ietf.org/html/draft-trammell-ipfix-a9n-03)
and this is not straight forward to list all powered entities for which =
there
is an aggregation.

My point is that there is some debate whether or not a switch should =
aggregate
all values for children, or if this is a NMS issue.

Feedback?



See inline







Network Working
Group           &n=
bsp;           &nb=
sp;           
J. Quittek, Ed. 

Internet-Draft          =
;            =
            &=
nbsp;           &n=
bsp; 
R. Winter 

Intended status:
Informational          =
            &=
nbsp;          
T. Dietz 

Expires: January 12, =
2012           &nb=
sp;           &nbs=
p;       
NEC Europe Ltd. 

            &=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;            =
; 
B. Claise 

            &=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;       
M. Chandramouli 

            &=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;   
Cisco Systems, Inc. 

            &=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;         
July 11, 2011 





            &=
nbsp;     
Requirements for Energy Management 

            &=
nbsp;      
draft-ietf-eman-requirements-04 



Abstract 



   This document defines requirements for standards =
specifications
for 

   energy management.  Defined requirements concern =
monitoring
functions 

   as well as control functions.  Covered functions =
include 

   identification of powered entities, monitoring of their =
power
state, 

   power inlets, power outlets, actual power, consumed energy, =
and 

   contained batteries.  Further included is control of =
powered 

   entities' power supply and power state.  This document =
does
not 

   specify the features that must be implemented by compliant =


   implementations but rather features that must be supported =
by 

   standards for energy management. 



This misses the power quality, or whatever name we =
want to
call it.

For example "power characteristics)"









Status of this Memo 



   This Internet-Draft is submitted in full conformance with =
the 

   provisions of BCP 78 and BCP 79. 



   Internet-Drafts are working documents of the Internet =
Engineering 

   Task Force (IETF).  Note that other groups may also
distribute 

   working documents as Internet-Drafts.  The list of =
current
Internet- 

   Drafts is at http://datatracker.i=
etf.org/drafts/current/.




   Internet-Drafts are draft documents valid for a maximum of =
six
months 

   and may be updated, replaced, or obsoleted by other =
documents at
any 

   time.  It is inappropriate to use Internet-Drafts as
reference 

   material or to cite them other than as "work in
progress." 



   This Internet-Draft will expire on January 12, 2012. 



Copyright Notice 



   Copyright (c) 2011 IETF Trust and the persons identified as =
the 

   document authors.  All rights reserved. 









Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;   
[Page 1] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   This document is subject to BCP 78 and the IETF Trust's =
Legal 

   Provisions Relating to IETF Documents 

   (http://trustee.ietf.org/lic=
ense-info)
in effect on the date of 

   publication of this document.  Please review these =
documents 

   carefully, as they describe your rights and restrictions =
with
respect 

   to this document.  Code Components extracted from this
document must 

   include Simplified BSD License text as described in Section =
4.e of


   the Trust Legal Provisions and are provided without =
warranty as 

   described in the Simplified BSD License. 





Table of Contents 



   1.  Introduction . . . . . . . . . . . . . . . . . . . =
. . .
. . .  4 

     1.1.   Conventional requirements for =
energy
management . . . . .  4 

     1.2.   Specific requirements for =
energy
management . . . . . . .  5 



   2.  Terminology  . . . . . . . . . . . . . . . . =
. . . .
. . . . .  6 



   3.  General Objectives of Energy Management  . . =
. . . .
. . . . .  8 

     3.1.   Power states  . . . . . . =
. . .
. . . . . . . . . . . . .  8 

     3.2.   Trade-offs  . . . . . . . =
. . .
. . . . . . . . . . . . .  8 

     3.3.   Local and network-wide energy
management  . . . . . . . .  8 

     3.4.   Energy monitoring . . . . . . =
. . . .
. . . . . . . . . .  9 

     3.5.   Overview of energy management
requirements  . . . . . . . 10 



   4.  Identification of Powered Entities . . . . . . . . =
. . .
. . . 10 



   5.  Information on Powered Entities  . . . . . . =
. . . .
. . . . . 11 

     5.1.   General information on powered
entities . . . . . . . . . 11 

     5.2.   Power state . . . . . . . . . =
. . . .
. . . . . . . . . . 12 

     5.3.   Power inlet and power =
outlet  .
. . . . . . . . . . . . . 14 

     5.4.   Power . . . . . . . . . . . . =
. . . .
. . . . . . . . . . 16 

     5.5.   Energy  . . . . . . . . . =
. . .
. . . . . . . . . . . . . 18 

     5.6.   Battery State . . . . . . . . =
. . . .
. . . . . . . . . . 19 



   6.  Control of Powered Entities  . . . . . . . . =
. . . .
. . . . . 21 



   7.  Reporting on Other Powered Entities  . . . . =
. . . .
. . . . . 22 



   8.  Controlling Other Powered Entities . . . . . . . . =
. . .
. . . 23 

     8.1.   Controlling power states of =
other
powered entities  . . . 23 

     8.2.   Controlling power supply of =
other
powered entities  . . . 24 



   9.  Security Considerations  . . . . . . . . . . =
. . . .
. . . . . 25 



   10. IANA Considerations  . . . . . . . . . . . . . . . =
. . .
. . . 26 









Quittek, et al.         Expires =
January
12, =
2012           &nb=
sp;   
[Page 2] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   11. Acknowledgements . . . . . . . . . . . . . . . . . . . =
. . . .
26 



   12. Open issues  . . . . . . . . . . . . . . . . . . . =
. . .
. . . 26 

     12.1.  Revise security =
considerations  . . .
. . . . . . . . . . 26 

     12.2.  High/Low power notifications  =
. . . .
. . . . . . . . . . 26 

     12.3.  Power and energy time series? . . . =
. . .
. . . . . . . . 26 

     12.4.  Inlet/outlet combinations . . . . . =
. . .
. . . . . . . . 26 

     12.5.  Aggregation functions . . . . . . . =
. . .
. . . . . . . . 27 

     12.6.  Add a definition of 'demand'  =
. . . .
. . . . . . . . . . 27 

     12.7.  IEC references  . . . . . . . =
. . . .
. . . . . . . . . . 27 

     12.8.  Standard references for BACNET or
MODBUS  . . . . . . . . 27 

     12.9.  IEEE 1621 and 802.3az =
references  . .
. . . . . . . . . . 27 

     12.10. DC power quality covered by IEC =
standard? . . .
. . . . . 27 

     12.11. Introduce 'disconnected from power' as =
power
state  . . . 27 

     12.12. Need for basic state 'reduced power'? . =
. . . .
. . . . . 27 

     12.13. Local and network-wide energy =
management 
. . . . . . . . 28 

     12.14. Do we need entity types?  . . . . . =
. . .
. . . . . . . . 28 

     12.15. Power availability mode 'minimum' or =
'ready'? .
. . . . . 28 

     12.16. Is there a need for metering power =
supply
inpedance?  . . 28 

     12.17. Confidence in power values  . . . . =
. . .
. . . . . . . . 28 

     12.18. Terminology for reporting on other
entitites  . . . . . . 28 



   13. Informative References . . . . . . . . . . . . . . . . =
. . . .
29 



   Appendix A.  Existing Standards  . . . . . . . . =
. . . .
. . . . . 30 

     A.1.   Existing IETF Standards . . . =
. . . .
. . . . . . . . . . 30 

       A.1.1.  ENTITY MIB . . . . . . =
. . .
. . . . . . . . . . . . . 30 

       A.1.2.  ENTITY STATE MIB . . . =
. . .
. . . . . . . . . . . . . 31 

       A.1.3.  ENTITY SENSOR =
MIB  . . .
. . . . . . . . . . . . . . . 31 

       A.1.4.  UPS MIB  . . . . =
. . . .
. . . . . . . . . . . . . . . 32 

       A.1.5.  POWER ETHERNET MIB . . =
. . .
. . . . . . . . . . . . . 32 

       A.1.6.  LLDP MED MIB . . . . . =
. . .
. . . . . . . . . . . . . 33 

     A.2.   Existing standards of other
bodies  . . . . . . . . . . . 33 

       A.2.1.  DMTF . . . . . . . . . =
. . .
. . . . . . . . . . . . . 33 

       A.2.2.  OVDA . . . . . . . . . =
. . .
. . . . . . . . . . . . . 33 

       A.2.3.  IEEE-ISTO Printer WG . =
. . .
. . . . . . . . . . . . . 33 



   Authors' Addresses . . . . . . . . . . . . . . . . . . . . =
. . . .
34 



























Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;   
[Page 3] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





1.  Introduction 



   With rising energy cost and with an increasing awareness of =
the 

   ecological impact of running IT and networking equipment, =
energy 

   management is becoming an additional basic requirement for =
network


   management systems and frameworks. 



   This document defines requirements for standards =
specifications
for 

   energy management.  Defined requirements concern =
monitoring
functions 

   as well as control functions.  Covered functions =
include 

   identification of powered entities, monitoring of their =
power
state, 

   power inlets, power outlets, actual power, consumed energy, =
and 

   contained batteries.  Further included is control of =
powered 

   entities' power supply and power state.  Note that =
this
document does 

   not specify the features that must be implemented by =
compliant 

   implementations but rather features that must be supported =
by 

   standards for energy management. 



Same remark about power quality









   The main subject of energy management are powered entities =
that 

   consume electric energy.  Powered entities include =
devices
that have 

   an IP address and can be addressed directly, such as hosts,
routers, 

   and middleboxes, as well as devices indirectly connected to =
an IP 

   network, for which a proxy with an IP address provides a
management 

   interface, for example, devices in a building management =


   infrastructure using BACNET or MODBUS protocols. 



   The requirements specified in this document explicitly =
concern the


   standards specification process and not the implementation =
of 

   specified standards.  All requirements in this =
document must
be 

   reflected by standards specifications to be =
developed.  But
which of 

   the features specified by these standards will be =
mandatory, 

   recommended, or optional for compliant implementations is =
to be 

   defined by the concrete standards track document(s) and not =
in
this 

   document. 



   This document first discusses general objectives of energy
management 

   in Section 3.  Requirements for an energy management =
standard
are 

   specified in Sections 4 to 8. 



1.1.  Conventional requirements for energy management =




I don't know what "conventional" is =
supposed to
mean.









   The specification of requirements for an energy management
standard 

   starts with Section 4 addressing the identification of =
powered 

   entities and the granularity of reporting of energy-related =


   information.  



I don't understand why we have that sentence here =
and not in
the identifier in section 4.







A standard must support unique identification of =


   powered entities.  Furthermore, it must support more =
than
just 

   reporting per powered device.  Support is required for =
also
reporting 

   energy-related information on individual components of a =
device or








Quittek, et al.         Expires =
January
12, =
2012           &nb=
sp;   
[Page 4] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   subtended devices.  This is why this draft uses the =
more
general term 

   "powered entity" rather than "powered
device".  A powered entity may 

   be a device or a component of a device. 



   Section 5 specifies requirements related to monitoring of =
powered 

   entities.  This includes general (type, context) =
information
and 

   specific information on power states, power inlets, power =
outlets,


   power, energy, and batteries.  Control power state and =
power
supply 

   of powered entities is covered by requirements specified in =


   Section 6. 



1.2.  Specific requirements for energy management 



   At first glance the rather conventional requirements =
summarized
above 

   seem to be all that would be needed for energy =
management. 
But it 

   turns out that there are some significant differences =
between
energy 

   management and most of the well known conventional network
management 

   functions.  The most significant difference from many =
other 

   management functions is the need for some devices to report =
on
other 

   entities.  There are three major reasons for this. =


   o  For monitoring and controlling a particular powered =
entity
in 

      general it is not sufficient to =
communicate with
the powered 



"sufficient" is not the right =
wording.

In some cases, this is just impossible to communicate with the powered =
entity.

Example: proxy.









      entity only, but in =
many
cases also communication with other 

      powered entities along the power =
distribution
path may be 

      necessary, for example, with power =
switches and
power meters. 

      Indeed, there are situations where a =
power or
energy meter is not 

      located in the powered entity, but in a
different physical 

      location.  For example, a Power
Distribution Unit (PDU), which 

      supplies power for a server connected to =
a PDU
socket, would meter 

      the power supplied, while the server may =
not
have the capability 

      to measure its power consumption.  =




new text: In specific cases, the monitoring and =
controlling
of powered entities must be done by another entity along the power =
distribution
domain. For example. 

And you remove "a second example" below







A second example is a Power 

      over Ethernet port, which provides power =
to the
attached device, 

      and which can meter how much power/energy =
it
delivers to the 

      attached device. 

   o  Energy management often extends its scope beyond =
powered
entities 

      with IP network interfaces, for example =
toward
non-IP building 

      networks, that are accessed via an IP
gateway.  Requirements in 

      this document do not fully cover all =
these
networks, but they 

      cover means for opening IP network =
management
towards them. 

   o  For monitoring of particular powered entities, it =
is
sometimes not 

      a scalable approach to communicate =
directly with
all the powered 

      entities directly from a central energy
management system as the 

      number of powered entities keeps =
increasing. 



   This specific issue of energy management and a set of =
further ones


   are covered by requirements specified in Sections 7 and 8. =












Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;   
[Page 5] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





2.  Terminology 



2.1.  Energy 



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



   The term 'energy consumption' is commonly used for both, =
for 

   referring to the amount of consumed energy and also for =
referring
to 

   the rate of consuming energy.  In the first case it =
addresses


   consumed energy measured by joule, watthour, or another =
energy
unit, 

   in the second one it addresses power, typically an average =
power 

   measured by watt. 



   However, in this document the term "consumed =
energy"
always refers to 

   an energy quantity (measured in joule, watthour, etc.) and =
not to
a 

   power quantity (measured in watt, etc.). 



2.2.  Power 



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



2.3.  Powered entity 



   A powered entity is a consumer of energy that is subject to =
energy


   management.  In general, all managed physical entities =
in a 

   communication network consume electric energy and thus are =
subject
to 

   energy management including particularly energy monitoring =
and
energy 

   control. 



   A powered entity can be a managed device or a component of =
a
managed 

   device, which is monitored or controlled individually. 



2.4.  Power state 



   Power state of a powered entitiy is defined as a specific =
settings
of 

   a powered entitiy that influences its power.  Examples =
of
power 

   states of a powered entitiy are on, off, and sleep. 



2.5.  Power monitor 



   Energy management requires retrieving energy-related =
information
on 

   powered entities.  In many cases this information is =
not
available at 

   the powered entities themselves, but at other powered
entities.  For 

   example measurement of power and energy consumption can be
conducted 

   by power meters at other locations along the power =
distribution
tree 

   for the powered entity. 



   A power monitor is a module that reports energy-related
information 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;   
[Page 6] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   on powered entities.  A power monitor may be =
integrated into
a 

   powered entity or located remotely of the powered =
entity. 
Instances 

   of power monitors may report information on, for example, =
power 

   supply, power, and power state of a powered entity.  =
There
may be 

   multiple power monitors reporting information on the same =
powered 

   entity. 



2.6.  Power inlet 



   Powered entities receive power at their power inlets.  =
Powered


   entities may have multiple inlets, for example, servers =
with 

   redundant power supply.  Examples for power inlets are =
AC
power cords 

   of a powered entity or an Ethernet port at which the =
powered
entity 

   receives DC Power over Ethernet (PoE). 



2.7.  Power outlet 



   Powered entities may have means to supply others with =
electrical 

   power.  Power is delivered to other powered entities =
through
power 

   outlets.  Power sourcing entities often have more than =
one
power 

   outlet.  Examples for power outlets are AC power =
sockets at a
Power 

   Distribution Unit (PDU) and Ethernet ports at a Power over
Ethernet 

   (PoE) Power Sourcing Equipment (PSE), that can supply =
powered 

   entities with DC power using the Ethernet cable. 



2.8.  Energy management 



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



2.9.  Energy management standard 



This doesn't look like a definition. At least, the =
first
paragraph should be removed.









   This document specifies requirements for an energy =
management 

   standard.  This term refers to a collections of =
documents
specifying 

   standards for energy-related monitoring and control.  =
The
energy 

   management standard specifies means for building energy =
management


   systems. 



   Requirements specified in this document concern the means =
that an 

   energy management standard must provide.  It does not =
imply
that all 

   required means must be implemented in all energy standard
scenarios. 

   Which means and features must be implemented by compliant =


   implementations is to be specified by the energy management
standard 

   itself, not by this requirements document. 



   Note that for meeting individual requirements specified in =
this 

   document, new standards are not necessarily required.  =
It is 

   recommended to rather use existing standards than specify =
new
ones. 



















Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;   
[Page 7] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





3.  General Objectives of Energy Management 



Rename to "general considerations related to =
energy
management"









   The basic objective of energy management is operating
communication 

   networks and other equipment with minimal amount of energy, =
while 

   maintaining a certain level of service.  A set of use =
cases
for 

   energy management can be found in 

   [I-D.tychon-eman-applicability-statement]. 



It would read better if the content of section =
about
trade-offs was next in this introduction (without having a specific =
section)

Then 

    3.1. Power States

    3.2 Energy Monitoring versus Energy Savings

    3.3 Local versus network-wide energy management

    3.4. Overview of the energy management =
requirements











3.1.  Power states 



   One approach to achieve this goal is by setting all powered
entities 

   to an operational state that results in lower energy =
consumption,
but 

   still meets the service level performance objectives.  =
The
sufficient 

   performance level may vary over time and can depend on =
several 

   factors.  In principle, there are four basic types of =
power
states 

   for a powered entity or for a whole system: 

   o  full power state 

   o  reduced power states (lower clock rate for =
processor,
lower data 

      rate on a link, etc.) 

   o  sleep state (not functional, but immediately =
available) 

   o  off state (may imply requiring significant time for
becoming 

      operational) 

   In actual implementations the number of power states and =
their 

   properties vary a lot.  Very simple powered entities =
may just
have 

   only the extreme states, full power and off state.  =
Some 

   implementations might use IEEE1621 model of three states =
on, off,
and 

   sleep.  However, more granular power states can be
implemented with 

   many levels of off, sleep, and reduced power states. 



3.2.  Trade-offs 



   While the general objective of energy management is quite =
clear,
the 

   way to attain that goal is often difficult.  In many =
cases
there is 

   no way of reducing power consumption without the =
consequence of a 

   potential performance, service, or capacity =
degradation. 
Then a 

   trade-off needs to be dealt with between service level =
objectives
and 

   energy efficiency.  In other cases a reduction of =
energy
consumption 

   can easily be achieved while still maintaining sufficient =
service 

   level performance, for example, by switching powered =
entities to 

   lower power states when higher performance is not needed. =




3.3.  Local and network-wide energy management 



   Many energy saving functions can be executed locally by a =
powered 

   entitiy.  The basic principle is that a powered =
entitiy
monitors its 

   usage and dynamically adapts its energy consumption =
according to
the 

   required performance.  It may switch to a sleep state =
when it
is not 

   in use at all.  



Well, not only when it's not in use.

It could be based on the time of day, or any other energy saving =
policies.







Potential interactions with an energy management =








Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;   
[Page 8] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   system for such an entity include the observation of the =
entity's 

   power state and the configuration of power saving policies, =
for 

   example, by setting thresholds for power state changes. =




   Energy savings can also be achieved with policies =
implemented by a


   network management system that controls power states of =
managed 

   entities.  In order to make policy decisions properly,
information 

   about the energy consumption of powered entities in =
different
power 

   states is required.  Often this information is =
acquired best
through 

   monitoring. 



   Both methods, network-wide and local energy management, =
have 

   advantages and disadvantages.  Most buildings use both =
of them. 
In 

   some cases for example, significant energy savings can be =
achieved
by 

   simply setting all powered entities in a network to sleep, =
when
the 

   network is not needed.  However, in general it is =
dangerous
to set 

   all powered entities of a group to the same state, because =
there
is a 

   risk that such actions ignore specifics of individual =
powered 

   entities or violate local service level agreements. =




Can you please expand the previous sentence.

I'm not sure that I agree.









3.4.  Energy monitoring 



rename to "energy monitoring versus energy
savings"









   It should be noted that only monitoring energy consumption =
and
power 

   states is obviously not a means to reduce the energy =
consumption
of a 

   powered entitiy.  In fact, it is likely to increase =
the power


   consumption of a powered entitiy slightly because =
monitoring
energy 

   may require instrumentation that consumes energy when in
use.  And 

   also reporting of measured quantities over the network =
consumes 

   energy.  However, the acquired energy consumption and =
power
state 

   information is essential for defining energy saving =
policies and
can 

   be used as input to power state control loops that in total =
can
lead 

   to energy savings. 



   Monitoring operational power states and energy consumption =
can
also 

   be required for other energy management purposes including =
but not


   limited to: 

   o  investigating power saving potential 

   o  evaluating the effectiveness of energy saving =
policies and


      measures 

   o  deriving, implementing, and testing power =
management
strategies 

   o  accounting for the total power consumption of a =
powered
entity, a 

      network, or a service 

   o  predicting a powered entitiy's reliability based on =
power
usage 

   o  choosing time of next maintenance cycle for a =
powered
entitiy 















Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;   
[Page 9] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





3.5.  Overview of energy management requirements 



   From the considerations described above the following basic =


   management functions appear to be required for energy =
management: 

   o  monitoring power states 

   o  monitoring power (energy consumption rate) 

   o  monitoring (accumulated) energy consumption 

   o  setting power states 

   o  setting and enforcing power saving policies =




And again the comment about the power quality









   It should be noted that active power control is =
complementary (but




what does the "active" power control =
mean?







   essential) to other energy savings =
measures
such as low power 

   electronics, energy saving protocols (for example, IEEE =
802.3az), 

   energy-efficient device design (for example, sleep and =
low-power 

   modes for individual components of a device), and =
energy-efficient


   network architectures.  Measurement of energy =
consumption may
also 

   provide useful input for developing these technologies. =






4.  Identification of Powered Entities 



   As already stated Section 1.1, powered entities on which =
energy- 

   related information is provided



add a comma







are identified in a sufficiently 

   unique way.  This holds in particular for powered =
entities
that are 

   components of managed devices and in case that one powered =
entity 

   reports information on another one, see Section 7.  =
For
powered 

   entities that control other powered entities it is =
important to 

   identify the powered entities they control, see Section 8. =




   Also stated already in Section 1.1 is the requirement of =
providing


   means for reporting energy-related information on =
components of a 

   managed device.  An entity in this document may be an =
entire
managed 

   device or just a component of it.  Examples of =
components of
interest 

   are a hard drive, a battery, or a line card.  For =
controlling


   entities it may be required to be able to address =
individual 

   components in order to save energy.  For example, =
server
blades can 

   be switched off when the overall load is low or line cards =
at 

   switches may be powered down at night times. 



   Instrumentation for measuring energy consumption of a =
device is 

   typically more expensive than instrumentation for =
retrieving the 

   devices power state.  It may be a reasonable =
compromise in
many cases 

   to provide power state information for all individually =
switchable


   components of a device separately, while the energy =
consumption is


   only measured for the entire device. 



   Detailed Requirements: 









Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 10] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





4.1.  Identifying powered entities 



   The energy management standard must provide means for =
uniquely and


   persistently identifying powered entities that are =
monitored or 

   controlled by an energy management system.  Uniqueness =
must
be given 

   in a domain that is large enough to avoid collisions of =
identities
at 

   potential receivers of monitored information. =




We want to remove "and persistently" from =
the
sentence, as this is covered in 4.3



We should have a requirement about a UUID for powered entities.

Let's cover that during the WG.









4.2.  Identifying components of powered devices 



   The energy management standard must provide means for =
identifying
not 

   just entire devices as powered entities, but also =
individual 

   components of powered devices. 



4.3.  Persistency of Identifiers 



   The energy management standard must provide means for =
indicating 

   whether identifiers of powered entities are persistent =
across a
re- 

   start of the powered entitiy that provides the identifiers. =






5.  Information on Powered Entities 



   This section describes energy-related information on =
powered
entities 

   for which an energy management standard must provide means =
for 

   retrieving and reporting. 



   Note that the fact that an energy management standard =
provides 

   required means does not imply that all of them must be =
implemented
by 

   every compliant implementation.  The concrete =
specification
of 

   standards based on these requirements may label individual
features 

   as mandatory, recommended, or optional. 



Remove this paragraph above, as this is already =
covered
before, and this is not specific to this section 5.









   Required information on powered entities can be structured =
into
six 

   groups.  Section 5.1 specifies requirements for =
general
information 

   on powered entities, such as type of powered entity or =
context 

   information.  Section 5.2 covers requirements related =
to
entities' 

   power states.  Requirements for information on power =
inlets
and power 

   outlets of powered entities are specified in Section =
5.3. 
Monitoring 

   of power and energy is covered by Sections 5.4 and 5.5,
respectively. 

   Finally, Section 5.6 specified requirements for monitoring
batteries. 



5.1.  General information on powered entities 



   For energy management it may be required to understand the =
role
and 

   context of a powered entitiy.  When monitoring, it may =
be
helpful to 

   group energy consumption per kind of entity.  When
controlling and 

   setting power states it may be helpful to understand the =
kind and 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 11] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   role of a powered entitiy in a network, for example, in =
order to 

   avoid switching off vital network components. 



   Detailed Requirements: 



5.1.1.  Type of powered entity 



   The energy management standard must provide means to =
retrieve and 

   report the type of powered entities according to a =
standrdized 

   classification scheme. 



see the email thread on the mailing list.









5.1.2.  Context information on powered entities 



   The energy management standard must provide means for =
retrieving
and 

   reporting context information on powered entities, for =
example
tags 

   associated with a powered entity that indicate the powered
entitiy's 

   role, or importance. 



5.1.3.  Grouping of powered entities 



   The energy management standard must provide means for =
grouping 

   powered entities, for example, into energy monitoring =
domains,
energy 

   control domains, power supply domains, groups of powered =
entities
of 

   the same type, etc. 



5.2.  Power state 



   Many powered entities have a limited number of discrete =
power
states, 

   such as, for example, full power, low power, sleep, and =
off. 



   Obviously, there is a need to report the actual power state =
of a 

   powered entitiy.  Beyond that, there is also a =
requirement
for 

   standardizing means for retrieving the list of all =
supported power


   states of a powered entitiy. 



   Different standards bodies have already defined their own =
sets of 

   power states for powered entities.  Further =
organizations are
in the 

   process of adding more of these sets.  In order to =
support
multiple 

   management systems possibly using different power state =
sets,
while 

   simultaneously interfacing with a particular powered =
entity, the 

   energy management standard must provide means for =
supporting
multiple 

   power state sets used simultaneously at a powered entity. =




   Power states have parameters that describe its properties =
It is 

   required to have standardized means for reporting some key =


   properties, such as mean power and maximum power of a =
powered
entitiy 

   in a certain state. 









Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 12] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   There also is a need to report statistics on power states =
including


   the time spent an the energy consumed in a power state. =




   For some network management tasks, it may be desirable to =
receive 

   notifications from powered entities, for example, when the
components 

   or the entire entity change their power state. 



   Detailed Requirements: 



5.2.1.  Actual power state 



   The energy management standard must provide means for =
reporting
the 

   actual power state of a powered entitiy. 



5.2.2.  List of supported power states 








   The energy management standard must provide means for =
retrieving
the 

   list of all potential power states of a powered entitiy. =




5.2.3.  Multiple power state sets 



   The energy management standard must provide means for =
supporting 

   multiple power state sets simultaneously at a powered =
entity. 



5.2.4.  List of supported power state sets 



   The energy management standard must provide means for =
retrieving
the 

   list of all power state sets supported by a powered =
entitiy. 



5.2.5.  List of supported power states 






5.2.2 has got the same title.

Proposal for 5.2.5 "List of supported power states within power =
state
set"









   Referring to the "list of supported power state =
sets"
requirement, 

   the energy management standard must provide means for =
retrieving
the 

   list of all potential power states of a powered entitiy =
that
belong 

   to a given power state set. 



new text.

    For the rest of the document, when the Power State =
term is
used, it implicitly refers to a power state within a power state =
set.



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









5.2.6.  Maximum and average power per power state 



   The energy management standard must provide means for =
retrieving
the 

   maximum power and the average power as a typically static =
property


   for each supported power state. 



5.2.7.  Power state statistics 



   The energy management standard must provide means for =
monitoring 

   statistics per power state including at least the total =
time spent
in 

   a power state, the number of times a state was entered and =
the
last 

   time a state was entered.  More power state statistics =
are
addressed 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 13] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   by requirement 5.5.3. 



5.2.8.  Power state changes 



   The energy management standard must provide means for =
generating a


   notification when the actual power state of a powered =
entity
changes. 



5.3.  Power inlet and power outlet 



   Powered entities have power inlets at which they are =
supplied with


   electric power.  Most powered entities just have a =
single
power 

   inlet, while some have multiple ones.  Often different =
power
inlets 

   are connected to separate power distribution trees.  =
For energy


   monitoring, it is important information which power inlets =
a
powered 

   entitiy has, 



what do you mean? the type, the number, or =
something else?







if power is available at an inlet and which of them =
are 

   actually in use. 



   Some powered entities have power outlets for supplying =
other
powered 

   entities with electric power.  A powered entitiy may =
have
multiple 

   power outlets.  Examples are Power Distribution Units =
(PDUs)
and 

   Power over Ethernet (PoE) Power Sourcing Equipment (PSE). =




Remove the previous sentence, as this is already in =
the
terminology section.









   For identifying and potentially controlling the source of =
power 

   received at an inlet, it may be required to identify the =
power
outlet 

   of another powered entity at which the received power is =
provided.


   Analogously, for each outlet it is of interest to identify =
the
power 

   inlets that receive the power provided at a certain outlet. =




   Static properties of each power inlet and each power outlet =
are 

   required information for energy management.  Static
properties 

   include the kind of electric current (Alternating Current =
(AC) or 

   Direct Current (DC)), the nominal voltage, the nominal AC
frequency, 

   and the number of AC phases. 



So "static properties" is what we called
"power quality"?









   Detailed Requirements: 



5.3.1.  List of power inlets and power outlets 



   The energy management standard must provide means for =
monitoring
the 

   list of power inlets and power outlets at a powered =
entitiy. 



5.3.2.  Corresponding power outlet 



   The energy management standard must provide means for =
identifying
the 

   power outlet that provides the power received at a power =
inlet. 













Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 14] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





5.3.3.  Corresponding power inlets 



   The energy management standard must provide means for =
identifying
the 

   list of power inlets that receive the power provided at a =
power 

   outlet. 



5.3.4.  Availability of power 



   The energy management standard must provide means for =
monitoring
the 

   availability of power at each power inlet and each power =
outlet. 

   This information indicates whether at a power providing =
outlet
power 

   supply is switched on or off. 



5.3.5.  Use of power 



   The energy management standard must provide means for =
monitoring
for 

   each power inlet and each power outlet if it is in actual
use.  For 

   the inlet this means that the powered entitiy actually =
receives
power 

   at the inlet.  For the outlet this means that actually =
power
is 

   provided to one or more powered entities at the outlet. =




5.3.6.  Type of current 



   The energy management standard must provide means for =
reporting
the 

   type of current (Alternating Current (AC) or Direct Current =
(DC))
for 

   each power inlet and each power outlet of a powered entity. =




5.3.7.  Nominal voltage 



   The energy management standard must provide means for =
reporting
the 

   nominal voltage for each power inlet and each power outlet =
of a 

   powered entity. 



5.3.8.  Nominal AC frequency 



   The energy management standard must provide means for =
reporting
the 

   nominal AC frequency for each power inlet and each power =
outlet of
a 

   powered entity. 



5.3.9.  number of AC phases 



number -> Number









   The energy management standard must provide means for =
reporting
the 

   number of AC phases for each power inlet and each power =
outlet of
a 

   powered entity. 















Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 15] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





5.4.  Power 



   Power is a quantity measured as instantaneous power or as =
average 

   power over a time interval.  In contrast to power =
state
values, this 

   quantity may change continuously. 



   Obtaining highly accurate values for power and energy may =
be
costly. 

   Often dedicated metering hardware is needed for this =
purpose. 

   Powered entities without the ability to measure their power =
and 

   energy consumption with high accuracy may just report =
estimated 

   values, for example based on load monitoring or even just =
the
entity 

   type. 



   Depending on how power and energy consumption values are =
obtained
the 

   confidence in the reported value and its accuracy may =
vary. 
Powered 

   entities reporting such values should qualify the =
confidence in
the 

   reported values and quantify the accuracy of =
measurements. 
For 

   reporting accuracy, the accuracy classes specified in IEC =
62053-21


   [IEC.62053-21] and IEC 62053-22 [IEC.62053-22] should be
considered. 



   In addition to the plain real power value, also further =
properties
of 

   the supplied power are subject to monitoring.  In case =
of AC
power 

   supply, there are more power values beyond the real power =
to be 

   reported including the apparent power, the reactive power, =
and the


   phase angle of the current or the power factor.  For =
both AC
and DC 

   power the power quality is also subject of monitoring. =




So "power quality" is mentioned.







Power quality 

   parameters include the actual voltage, the actual =
frequency, the 

   Total Harmonic Distortion (THD) of voltage and current, the
impedance 

   of an AC phase or of the DC supply.  Power quality =
monitoring
should 

   be in line with existing standards, such as =
[IEC.61850-7-4]. 



   For some network management tasks, it is required to obtain =
time 

   series of power values (or energy consumption =
values).  In
general 

   these could be obtained in many different ways.  It =
should be
avoided 

   that such time series can only be obtained by regular =
polling by
the 

   energy management system.  Means should be provided to =
either
push 

   such values from the place they are available to the =
management 

   system or to have them stored at the powered entitiy for a =


   sufficiently long period of time such that a management =
system can


   retrieve a stored time series of values. 



   Detailed Requirements: 



5.4.1.  Real power 



   The energy management standard must provide means for =
reporting
the 

   real power for each power inlet and each power outlet of a =
powered


   entity. 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 16] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





5.4.2.  Power measurement interval 



   The energy management standard must provide means for =
reporting
the 

   corresponding time or time interval for which a power value =
is 

   reported.  The power value can be measured at the
corresponding time 

   or averaged over the corresponding time interval. 



5.4.3.  Confidence in power values 



   The energy management standard must provide means for =
reporting
the 

   confidence in reported power values by indicating the way =
these 

   values have been obtained. for example, by power =
measurement, by 

   estimation based on performance values, or hard coding =
average
power 

   values for a powered entity. 



5.4.4.  Accuracy of power and energy values 



   The energy management standard must provide means for =
reporting
the 

   accuracy of reported power values. 



5.4.5.  Complex power 



   The energy management standard must provide means for =
reporting
the 

   complex power for each power inlet and each power outlet of =
a
powered 

   entity.  Besides the real power, at least two out of =
the
following 

   three quantities need to be reported: apparent power, =
reactive
power, 

   phase angle.  The phase angle can be substituted by =
the power
factor. 

   In case of AC power supply, means must be provided for =
reporting
the 

   complex power per phase. 



5.4.6.  Actual voltage and current 



   The energy management standard must provide means for =
reporting
the 

   actual voltage and actual current for each power inlet and =
each
power 

   outlet of a powered entity.  In case of AC power =
supply,
means must 

   be provided for reporting the actual voltage and actual =
current
per 

   phase. 



5.4.7.  Actual AC frequency 



   The energy management standard must provide means for =
reporting
the 

   actual AC frequency for each power inlet and each power =
outlet of
a 

   powered entity. 



5.4.8.  Total harmonic distortion 



   The energy management standard must provide means for =
reporting
the 

   Total Harmonic Distortion (THD) of voltage and current for =
each
power 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 17] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   inlet and each power outlet of a powered entity.  In =
case of
AC power 

   supply, means must be provided for reporting the THD per =
phase. 



5.4.9.  Power supply impedance 



   The energy management standard must provide means for =
reporting
the 

   impedance of power supply for each power inlet and each =
power
outlet 

   of a powered entity.  In case of AC power supply, =
means must
be 

   provided for reporting the impedance per phase. 



5.4.10.  Time series of power values 



   The energy management standard must provide means for =
collecting
time 

   series of real power values for each power inlet and for =
each
power 

   outlet of a powered entitiy without requiring to regularly =
poll
the 

   powered entitiy from an energy management station.  A
solution for 

   this is that the concerned powered entity or another =
powered
entity 

   closely interacting with the concerned powered entity =
collect time


   series of power values and make them available via push or =
pull 

   mechanisms to receivers of the information. 



5.5.  Energy 



   Monitoring of electrical energy consumed (or converted) at =
a
powered 

   entitiy can be done in various ways.  One is =
collecting time
series 

   of power values for the powered entitiy and calculating the
consumed 

   energy from these values.  An alternative is the =
powered
entity 

   itself or another powered entity taking care of energy =
measurement


   and reporting energy consumption values for certain time
intervals. 

   Time intervals of interest are the time from the last =
restart of
the 

   powered entitiy to the reporting time, the time from =
another past 

   event to the reporting time, or the last given amount of =
time
before 

   the reporting time. 



   In order to monitor energy consumption in different power =
states,
it 

   is useful if powered entities record their energy =
consumption per 

   power state and report these quantities. 



   For some network management tasks, it is required to obtain =
time 

   series of energy values.  In general these could be =
obtained
in many 

   different ways.  It should be avoided that such time =
series
can only 

   be obtained by regular polling by the energy management =
system. 

   Means should be provided to either push such values from =
the place


   they are available to the management system or to have them =
stored
at 

   the powered entitiy for a sufficiently long period of time =
such
that 

   a management system can retrieve a stored time series of =
values. 



   Detailed Requirements: 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 18] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





5.5.1.  Energy 



   The energy management standard must provide means for =
reporting
the 

   consumed energy received at a power input or provided at a =
power 

   outlet of a powered entitiy.  Reports must be made for =
a
clearly 

   specified time interval. 



5.5.2.  Time intervals 



   The energy management standard must provide means for =
reporting
the 

   consumed energy of a powered entitiy for certain time =
intervals. 

   o  Reports must be supported for the time interval =
starting
at the 

      last restart of the powered entitiy and =
ending
at a certain point 

      in time, such as the time when a report =
was
delivered. 

   o  Reports must be supported for a sequence of =
consecutive
non- 

      overlapping time intervals of fixed size
(periodic reports). 

   o  Reports must be supported for a sequence of =
consecutive 

      overlapping time intervals of fixed size
(periodic reports). 

   o  Reports must be supported for an interval of given =
length
ending 

      at a certain point in time, such as the =
time
when a report was 

      delivered (sliding window) 



5.5.3.  Energy per power state 



   The energy management standard must provide means for =
reporting
the 

   consumed energy individually for each power state.  =
This
extends the 

   requirement 5.2.7 on power state statistics. 



5.5.4.  Time series of energy values 



   The energy management standard must provide means for =
collecting
time 

   series of energy values for each power inlet and for each =
power 

   outlet of a powered entitiy without requiring to regularly =
poll
the 

   powered entitiy from an energy management station.  A
solution for 

   this is that the concerned powered entity or another =
powered
entity 

   closely interacting with the concerned powered entity =
collect time


   series of energy values and make them available via push or =
pull 

   mechanisms to receivers of the information. 



5.6.  Battery State 



   Today more and more powered entities contain batteries that =
supply


   them with power when disconnected from electrical power
distribution 

   grids.  Common examples are nomadic and mobile =
devices, such
as 

   notebook computers, netbooks, and smart phones.  The =
status
of 

   batteries in such an powered entity, particularly the =
charging
status 

   is typically controlled by automatic functions that act =
locally on


   the powered entitiy and manually by users of the powered
entity.  In 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 19] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   addition to this, there is a need to monitor the battery =
status of


   these entities by network management systems. 



   The management requirements discussed above in Sections 5.1 =
to 5.5


   concern energy-related information on powered =
entities. 
Powered 

   entities may be powered devices or components of powered =
devices. 



I  believe that we mentioned that sentence =
already.







   Devices containing batteries can be =
modeled in
two ways.  The entire 

   device can be modeled as a single powered entity on which =
energy- 

   related information is reported or the battery can be =
modeled as
an 

   individual powered entity for which energy-related =
information is 

   monitored individually according to requirements in =
Sections 5.1
to 

   5.5. 



   In both cases further information on batteries is of =
interest for 

   energy management, such as the current charge of the =
battery, the 

   number of completed charging cycles, the charging state of =
the 

   battery, and further static and dynamic battery =
properties. 
Also 

   desirable is to receive notifications if the charge of a =
battery 

   becomes very low or if a battery needs to be replaced. 



   Detailed Requirements: 



5.6.1.  Battery charge 



   The energy management standard must provide means for =
reporting
the 

   current charge of a battery. 



5.6.2.  Battery charging state 



   The energy management standard must provide means for =
reporting
the 

   charging state (charged, discharged, etc.) of a battery. =




5.6.3.  Battery charging cycles 



   The energy management standard must provide means for =
reporting
the 

   number of completed charging cycles of a battery. 



5.6.4.  Actual battery capacity 



   The energy management standard must provide means for =
reporting
the 

   actual capacity of a battery. 



5.6.5.  Static battery properties 



   The energy management standard must provide means for =
reporting 

   static properties of a battery, including the nominal =
capacity,
the 

   number of cells, the nominal voltage, and the battery =
technology. 









Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 20] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





5.6.6.  Low battery charge notification 



   The energy management standard must provide means for =
generating a


   notification when a the charge of a battery decreases below =
a
given 

   threshold. 



remove "a"









5.6.7.  Battery replacement notification 



   The energy management standard must provide means for =
generating a


   notification when the number of charging cycles of battery =
exceeds
a 

   given threshold. 



5.6.8.  Multiple batteries 



   The energy management standard must provide means for =
meeting 

   requirements 5.6.1 to 5.6.7 for each individual battery =
contained
in 

   a single powered entity. 





6.  Control of Powered Entities 



   Many powered entities control their power state locally by =
self- 

   managed dynamic adaptation to the environment.  But =
other
powered 

   entities without that capability need interfaces for a =
energy 

   management system to control their power states in order to =
save 

   energy.  Even for self-managed powered entities such
interface may be 

   required for overruling local policy decisions by global =
ones from
an 

   energy management system. 



   Power supply is typically not self-managed by powered
entities.  And 

   controlling power supply is typically not conducted as =
interaction


   between energy management system and the powered entity
itself.  It 

   is rather an interaction between the management system and =
an
entity 

   providing power at its power outlets.  Still, =
requirements
for power 

   state control apply accordingly to power supply control. =




   Note that shutting down the power supply abruptly may have =
severe 

   consequences for the powered entity. 



   Detailed Requirements: 



6.1.  Controlling power states 



   The energy management standard must provide means for =
setting
power 

   states of powered entities. 













Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 21] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





6.2.  Controlling power supply 



   The energy management standard must provide means for =
switching
power 

   supply off or turning power supply on at power outlets =
providing 

   power to one or more powered entity. 





7.  Reporting on Other Powered Entities 



   As already discussed in the introduction of Section 5, not =
all 

   energy-related information may be available at the =
concerned
powered 

   entity.  Such information may be provided by other =
powered
entities, 

   such as a Power Distribution Unit (PDU), external power =
meter, or
a 

   Power over Ethernet (PoE) Power Sourcing Equipment =
(PSE). 
Some of 

   these entities (PDU, PSE) can also control the power =
provided to
the 

   other powered entities, while some can just report on the =
remote 

   powered entities (external power meter).  This section =
covers


   reporting of information (monitoring) only.  See =
Section 8
for 

   requirements on controlling other powered entities. 



   There are cases where a power supply unit switches power =
for
several 

   powered entities by turning power on or off at a single =
power
outlet 

   or where a power meter measures the accumulated power of =
several 

   powered entities at a single power line.  =
Consequently, it
should be 

   possible to report that a monitored value does not relate =
to just
a 

   single powered entity, but is an accumulated value for a =
set of 

   powered entities.  All of these powered entities =
belonging to
that 

   set need to be identified. 



   If a powered entity has information about where =
energy-related 

   information on itself can be retrieved, then it would be =
very
useful 

   if it has a way to communicate this information to an =
energy 

   management system.  This applies even if the =
information only


   provides accumulated quantities for several powered =
entities. 



   Detailed Requirements: 



7.1.  Reports on other powered entities 



   The energy management standard must provide means for a =
powered 

   entitiy to report energy-related information on another =
powered 

   entity. 



7.2.  Identity of other powered entities on which is reported 



   The energy management standard must provide means for =
reporting
the 

   identity of another powered entity on which energy-related =


   information is reported. 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 22] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





7.3.  Reporting quantities accumulated over multiple powered =
entities 



   For powered entities reporting single values that are =
accumulated 

   over multiple powered entities, the energy management =
standard
must 

   provide means for reporting the list of all powered =
entities from 

   which contributions are included in the accumulated value. =




See my comments at the beginning of the email









7.4.  List of all powered entities on which is reported 



   The energy management standard must provide means for a =
powered 

   entitiy to report the list of all other powered entities on =
which
it 

   can report energy-related information. 



7.5.  Content of reports on other powered entities 



   The energy management standard must provide means for a =
powered 

   entitiy to indicate for each other powered entity on which =
it can 

   provide energy-related information which energy-related
information 

   can be provided for this powered entity. 



7.6.  Indicating source of remote information 



   The energy management standard must provide means for a =
powered 

   entity to indicate another powered entity at which =
energy-related 

   information on itself can be retrieved. 



7.7.  Indicating source of remote information 



   For a powered entity that has another powered entity at =
which
energy- 

   related information on itself can be retrieved, the energy
management 

   standard must provide means for indicating the information =
that is


   available at other powered entities per other powered =
entity. 





8.  Controlling Other Powered Entities 



   This section specifies requirements for controlling power =
states
and 

   power supply of powered entities by communicating not with =
these 

   powered entities themselves, but with other powered =
entities that 

   have means for controlling power state or power supply of =
others. 



8.1.  Controlling power states of other powered entities 



   Some powered entities may have control of power states of =
other 

   powered entities.  For example a gateway to a building
network may 

   have means to control the power state of powered entities =
in the 

   building that do not have an IP interface.  For this =
and
similar 

   cases means are needed to make this control accessible to =
the
energy 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 23] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   management system. 



   In addition to this, it is required that a powered entitiy =
that
has 

   its state controlled by other powered entities has means to =
report


   the list of these other powered entities. 



   Detailed Requirements: 



8.1.1.  Control of power states of other powered entities 



   The energy management standard must provide means for an =
energy 

   management system to send power state control commands to a
powered 

   entity that concern the power states of other powered =
entities
than 

   the one the command was send to. 



8.1.2.  Identity of other power state controlled entities 



   The energy management standard must provide means for =
reporting
the 

   identity of another powered entity for which the reporting =
powered


   entity has means to control the power state. 



8.1.3.  List of all power state controlled entities 



   The energy management standard must provide means for a =
powered 

   entitiy to report the list of all powered entities for =
which it
can 

   control the power state. 



8.1.4.  List of all power state controllers 



   The energy management standard must provide means for a =
powered 

   entitiy that receives commands controlling its power state =
from
other 

   powered entities to report the list of all those entities. =




8.2.  Controlling power supply of other powered entities 



   Some powered entities may have control of the power supply =
of
other 

   powered entities, for example, because the other powered =
entity is


   supplied via a power outlet of the powered entitiy.  =
For this
and 

   similar cases means are needed to make this control =
accessible to
the 

   energy management system. 



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



very required -> required







   has its =
supply
controlled by other powered entities has means to 

   report the list of these other powered entities. 



   Detailed Requirements: 











Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 24] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





8.2.1.  Control of power supply of other powered entities 



   The energy management standard must provide means for an =
energy 

   management system to send power supply control commands to =
a
powered 

   entity that concern the power supply of other powered =
entities
than 

   the one the command was send to. 



8.2.2.  Identity of other power supply controlled powered entities =




   The energy management standard must provide means for =
reporting
the 

   identity of another powered entity for which the reporting =
powered


   entity has means to control the power supply. 



8.2.3.  List of all power supply controlled powered entities 



   The energy management standard must provide means for a =
powered 

   entitiy to report the list of all other powered entities =
for which
it 

   can control the power supply. 



8.2.4.  List of all power supply controllers 



   The energy management standard must provide means for a =
powered 

   entitiy that has other powered entities controlling its =
power
supply 

   to report the list of all those powered entities. 





9.  Security Considerations 



   The typical security threats for the management protocol =
for
energy 

   monitoring are similar to the ones specified in the SNMP =
security 

   framework.  In other words, from an energy monitoring =
point
of view, 

   no additional security requirements have been imposed. 



   Link layer discovery mechanisms need to ensure that only =
the
trusted 

   powered entities shall be discovered during discovery and =
detect/ 

   discard powered entities without a trusted relationship to =
be 

   included among the powered entities for energy monitoring. =




   In terms of monitoring, considering that there can be some =
network


   entities which shall be entitled to collect the measured =
data on 

   behalf of other powered entities, then it is important to =


   authenticate and/or authorize such powered entities.  =
In
addition, in 

   the case of control of other powered entities, it would be =
highly 

   desirable to have some form of an authentication mechanism =
to
ensure 

   that only the designated powered entities shall control the
powered 

   entities within its control domain.  It should be =
possible to
prevent 

   a powered entity which does not have the appropriate =
authorization


   and authority to control or configure powered entities in =
its
control 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 25] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   domain/purview.  Secondly, it should be possible to =
prevent
malicious 

   powered entities from exercising control over entities. =






10.  IANA Considerations 



   This document has no actions for IANA. 





11.  Acknowledgements 



   The authors would like to thank Ralf Wolter for his first =
essay on


   this draft.  Many thanks to William Mielke, John =
Parello,
Bruce 

   Nordman, JinHyeock Choi, Georgios Karagiannis, and Michael =
Suchoff


   for helpful comments on the draft. 



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



Regards, Benoit.









12.  Open issues 



12.1.  Revise security considerations 



   A discussion of the sensitivity of the content of the =
monitoring
data 

   is missing. 



12.2.  High/Low power notifications 



   For some network management tasks it may be desirable to =
receive 

   notifications from entities when the power of an powered =
entity 

   exceeds or falls below certain thresholds.  Do we want =
to
make this a 

   requirement? 



   Proposal: added "for example" so that we don't =
restrict
the framework 

   to only this notification 



12.3.  Power and energy time series? 



   We have requirements for reporting of time series of power =
and
energy 

   values.  Do we need both or just one of them?  If =
just
one, then 

   which one? 



12.4.  Inlet/outlet combinations 



   How to model the case that an inlet or outlet changes =
during 

   operation from one kind to the other.  An example is a
battery that 

   receives power at a socket at one time.  Then the =
socket is
an inlet. 

   At another time the battery provides power at the same =
socket. 
Then 

   it's an outlet.  The same holds for entities with =
integrated
power 

   generators. 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 26] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   One solution would be to introduce a new kind of hybrid
in/outlets. 

   Another one would be to model the same socket as inlet as =
well as
as 

   outlet.  It would appear twice in the list of all =
inlets and
outlets. 

   Then received power/energy would be reported under the =
inlet entry


   and provided power/energy would be reported under the =
outlet
entry. 



   These would be two solutions.  What would be the =
concrete
requirement 

   behind them? 



12.5.  Aggregation functions 



   Aggregation functions are not covered (yet).  Are =
there
requirements 

   on aggregation?  Which are they? 



12.6.  Add a definition of 'demand' 



12.7.  IEC references 



   References to mentioned IEC standards are missing.  =
Also
these 

   references should be double checked. 



12.8.  Standard references for BACNET or MODBUS 



   Section 1 mentions BACNET or MODBUS as examples for =
building
network 

   protocols.  We need references to the standards
specifications for 

   these protocols. 



12.9.  IEEE 1621 and 802.3az references 



   A reference to the IEEE 1621 standard is missing in section =
3.1
and a 

   reference to IEEE 802.3az is missing in section 3.4.  =
The
references 

   should be double checked if they are well applicable in the =


   respective section. 



12.10.  DC power quality covered by IEC standard? 



   Is there an IEC standard on DC power quality? 



12.11.  Introduce 'disconnected from power' as power state 



   We need to introduce the concept of a device being
"disconnected" 

   from power.  This is a subset of the Off state.  =
Shall
we do it here 

   or rather in the framework draft? 



12.12.  Need for basic state 'reduced power'? 



   Are "full power" and "reduced power" =
really
different basic types of 

   power states?  Both may be forms of the on =
state. 
Identifying "full" 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 27] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   separately is arbitrary.  (For something like a =
computer,
"idle" is 

   the most common state so would be the one to call out =
separately 

   rather than "full".) 



12.13.  Local and network-wide energy management 



   All but first sentence of the third paragraph in section =
3.3 seem
to 

   be true not needed here.  Proposal: remove them. 



12.14.  Do we need entity types? 



   Or shall we remove Section 5.1.1? 



12.15.  Power availability mode 'minimum' or 'ready'? 



   Do we need an additional mode for power availability called
"minimum" 

   or "ready" for power availability in xref =
target=3D"availability"/>?


   This would reflect a PoE state at which the PSE is ready to =
serve
the 

   PD. 



12.16.  Is there a need for metering power supply inpedance? 







12.17.  Confidence in power values 



   Shall we rename "confidence in power values" to =
"method
for 

   determining power values"? 



12.18.  Terminology for reporting on other entitites 



   In Section 7 we need some additional terms here to =
streamline the 

   text (and ultimately our thinking).  Nominations =
include: 

   o  "powered entity" (which may be
"self-reporting") 

   o  "reporting entity" (can be =
"self" or
"other") 

   o  "other entity" (a reporting entity =
reporting not
on itself; likely 

      a different term would be better for =
this) 

   o  "controlled entity", "controlling
entity" (section 8.1) 

   o  "switched entity", "switching =
entity"
(section 8.2) 



   Also, there are two cases for an "other =
entity". 
One is where the 

   powered entity cannot report the value in question itself =
(either 

   because it can't report anything, or doesn't know the value =
in 

   question, e.g. when metering is external). 



   The second is where the powered entity can report, but the =
other 

   entity is doing the reporting for some convenience.  =
We need
to be 

   aware of both even if the framework does not need to make =
the 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 28] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   distinction. 



   There may be multiple other reporting entities, not just a =
single 

   one. 



   Do components of devices ever report, or do only devices do =
the 

   reporting?  This seems like an important point. 





13.  Informative References 



   [RFC1628]  Case, J., "UPS Management Information
Base", RFC 1628, 

            &=
nbsp;
May 1994. 



   [RFC3433]  Bierman, A., Romascanu, D., and K. Norseth,
"Entity Sensor 

            &=
nbsp;
Management Information Base", RFC 3433, December 2002. 



   [RFC3621]  Berger, A. and D. Romascanu, "Power =
Ethernet
MIB", 

            &=
nbsp;
RFC 3621, December 2003. 



   [RFC3805]  Bergman, R., Lewis, H., and I. McDonald,
"Printer MIB v2", 

            &=
nbsp;
RFC 3805, June 2004. 



   [RFC4133]  Bierman, A. and K. McCloghrie, "Entity =
MIB
(Version 3)", 

            &=
nbsp;
RFC 4133, August 2005. 



   [RFC4268]  Chisholm, S. and D. Perkins, "Entity =
State
MIB", RFC 4268, 

            &=
nbsp;
November 2005. 



   [I-D.tychon-eman-applicability-statement] 

            &=
nbsp;
Tychon, E., Silver, L., and M. Chandramouli, "Energy 

            &=
nbsp;
Management (EMAN) Applicability Statement", 

            &=
nbsp;
draft-tychon-eman-applicability-statement-02 (work in 

            &=
nbsp;
progress), June 2011. 



   [ACPI.R30b] 

            &=
nbsp;
Hewlett-Packard Corporation, Intel Corporation, Microsoft 

            &=
nbsp;
Corporation, Phoenix Corporation, and Toshiba Corporation, 

            &=
nbsp;
"Advanced Configuration and Power Interface Specification, 

            &=
nbsp;
Revision 3.0b", October 2006. 



   [DMTF.DSP1027] 

            &=
nbsp;
Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.), 

            &=
nbsp;
"Power State Management Profile", September 2008. 



   [IEEE-ISTO] 

            &=
nbsp;
Printer Working Group, "PWG 5106.4 - PWG Power Management 

            &=
nbsp;
Model for Imaging Systems 1.0:", February 2011. 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 29] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   [IEC.62053-21] 

            &=
nbsp;
International Electrotechnical Commission, "Electricity 

            &=
nbsp;
metering equipment (a.c.) - Particular requirements - Part 

            &=
nbsp;
22: Static meters for active energy  (classes 1 and 2)", 

            &=
nbsp;
2003. 



   [IEC.62053-22] 

            &=
nbsp;
International Electrotechnical Commission, "Electricity 

            &=
nbsp;
metering equipment (a.c.) - Particular requirements - Part 

            &=
nbsp;
22: Static meters for active energy  (classes 0,2 S and 

            &=
nbsp;
0,5 S)", 2003. 



   [IEC.61850-7-4] 

            &=
nbsp;
International Electrotechnical Commission, "Communication 

            &=
nbsp;
networks and systems for power utility automation - Part 

            &=
nbsp;
7-4: Basic communication structure - Compatible logical 

            &=
nbsp;
node classes and data object classes", 2010. 





Appendix A.  Existing Standards 



   This section analyzes existing standards for energy =
consumption
and 

   power state monitoring.  It shows that there are =
already
several 

   standards that cover only some part of the requirements =
listed
above, 

   but even all together they do not cover all of the =
requirements
for 

   energy management. 



A.1.  Existing IETF Standards 



   There are already RFCs available that address a subset of =
the 

   requirements. 



A.1.1.  ENTITY MIB 



   The ENTITY-MIB module defined in [RFC4133] was designed to =
model 

   physical and logical entities of a managed system.  A
physical entity 

   is an identifiable physical component.  A logical =
entity can
use one 

   or more physical entities.  From an energy monitoring
perspective of 

   a managed system, the ENTITY-MIB modeling framework can be =
reused
and 

   whenever RFC 4133 [RFC4133] has been implemented.  The =


   entPhysicalIndex from entPhysicalTable can be used to =
identify an 

   entity/component.  However, there are use cases of =
energy
monitoring, 

   where the application of the ENTITY-MIB does not seem =
readily 

   apparent and some of those entities could be beyond the =
original 

   scope and intent of the ENTITY-MIB. 



   Consider the case of remote devices attached to the =
network, and
the 

   network device could collect the energy measurement and =
report on 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 30] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   behalf of such attached devices.  Some of the remote =
devices
such as 

   PoE phones attached to a switch port have been considered =
in the 

   Power-over-Ethernet MIB module [RFC3621].  However, =
there are
many 

   other devices such as a computer, which draw power from a =
wall
outlet 

   or building HVAC devices which seem to be beyond the =
original
scope 

   of the ENTITY-MIB. 



   Yet another example, is smart-PDUs, which can report the =
energy 

   consumption of the device attached to the power outlet of =
the PDU.


   In some cases, the device can be attached to multiple to =
power 

   outlets.  Thus, the energy measured at multiple =
outlets need
to be 

   aggregated to determine the consumption of a single =
device. 
>From 

   mapping perspective, between the PDU outlets and the device =
this
is a 

   many-to-one mapping.  It is not clear if such a =
many-to-one
mapping 

   is feasible within the ENTITY-MIB framework. 



A.1.2.  ENTITY STATE MIB 



   RFC 4268 [RFC4268] defines the ENTITY STATE MIB module. =


   Implementations of this module provide information on =
entities 

   including the standby status (hotStandby, coldStandby, 

   providingService), the operational status (disabled, =
enabled, 

   testing), the alarm status (underRepair, critical, major, =
minor, 

   warning), and the usage status (idle, active, busy).  =
This 

   information is already useful as input for policy decisions =
and
for 

   other network management tasks.  However, the number =
of
states would 

   cover only a small subset of the requirements for power =
state 

   monitoring and it does not provide means for energy =
consumption 

   monitoring.  For associating the information conveyed =
by the
ENTITY 

   STATE MIB to specific components of a device, the ENTITY =
STATE MIB


   module makes use of the means provided by the ENTITY MIB =
module 

   [RFC4133].  Particularly, it uses the entPhysicalIndex =
for 

   identifying entities. 



   The standby status provided by the ENTITY STATE MIB module =
is
related 

   to power states required for energy management, but the =
number of 

   states is too restricted for meeting all energy management =


   requirements.  For energy management several more =
power
states are 

   required, such as different sleep and operational states as
defined 

   by the Advanced Configuration and Power Interface (ACPI)
[ACPI.R30b] 

   or the DMTF Power State Management Profile [DMTF.DSP1027]. =




A.1.3.  ENTITY SENSOR MIB 



   RFC 3433 [RFC3433] defines the ENTITY SENSOR MIB module. =


   Implementations of this module offer a generic way to =
provide data


   collected by a sensor.  A sensor could be an energy
consumption meter 

   delivering measured values in Watt.  This could be =
used for
reporting 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 31] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   current power of an entity and its components.  =
Furthermore,
the 

   ENTITY SENSOR MIB can be used to retrieve the accuracy of =
the used


   power meter. 



   Similar to the ENTITY STATE MIB module, the ENTITY SENSOR =
MIB
module 

   makes use of the means provided by the ENTITY MIB module =
[RFC4133]


   for relating provided information to components of a =
device. 



   However, there is no unit available for reporting energy
quantities, 

   such as, for example, watt seconds or kilowatt hours, and =
the
ENTITY 

   SENSOR MIB module does not support reporting accuracy of
measurements 

   according to the IEC / ANSI accuracy classes, which are =
commonly
in 

   use for electric power and energy measurements.  The =
ENTITY
SENSOR 

   MIB modules only provides a coarse-grained method for =
indicating 

   accuracy by stating the number of correct digits of fixed =
point 

   values. 



A.1.4.  UPS MIB 



   RFC 1628 [RFC1628] defines the UPS MIB module. 
Implementations of 

   this module provide information on the current real power =
of
entities 

   attached to an uninterruptible power supply (UPS) =
device. 
This 

   application would require identifying which entity is =
attached to 

   which port of the UPS device. 



   UPS MIB provides information on the state of the UPS
network.  The 

   MIB module contains several variables that are used to =
identify
the 

   UPS entity (name, model,..), the battery state, to =
characterize
the 

   input load to the UPS, to characterize the output from the =
UPS, to


   indicate the various alarm events.  The measurements =
of power
in UPS 

   MIB are in Volts, Amperes and Watts.  The units of =
power
measurement 

   are RMS volts, RMS Amperes and are not based on =
Entity-Sensor MIB 

   [RFC3433]. 



A.1.5.  POWER ETHERNET MIB 



   Similar to the UPS MIB, implementations of the POWER =
ETHERNET MIB 

   module defined in RFC3621 [RFC3621] provide information on =
the 

   current energy consumption of the entities that receive =
Power over


   Ethernet (PoE).  This information can be retrieved at =
the
power 

   sourcing equipment.  Analogous to the UPS MIB, it is =
required
to 

   identify which entities are attached to which port of the =
power 

   sourcing equipment. 



   The POWER ETHERNET MIB does not report power and energy
consumption 

   on a per port basis, but can report aggregated values for =
groups
of 

   ports.  It does not use objects of the ENTITY MIB =
module for 

   identifying entities, although this module existed already =
when
the 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 32] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   POWER ETHERNET MIB modules was standardized. 



A.1.6.  LLDP MED MIB 



   The Link Layer Discovery Protocol (LLDP) defined in IEEE =
802.1ab
is a 

   data link layer protocol used by network devices for =
advertising
of 

   their identities, capabilities, and interconnections on a =
LAN 

   network.  The Media Endpoint Discovery (MED) =
(ANSI/TIA-1057)
is an 

   enhancement of LLDP known as LLDP-MED.  The LLDP-MED
enhancements 

   specifically address voice applications.  LLDP-MED =
covers 6
basic 

   areas: capabilities discovery, LAN speed and duplex =
discovery, 

   network policy discovery, location identification =
discovery, 

   inventory discovery, and power discovery. 



A.2.  Existing standards of other bodies 



A.2.1.  DMTF 



   The DMTF has defined a power state management profile
[DMTF.DSP1027] 

   that is targeted at computer systems.  It is based on =
the
DMTF's 

   Common Information Model (CIM) and rather an entity profile =
than
an 

   actual energy consumption monitoring standard. 



   The power state management profile is used to describe and =
to
manage 

   the power state of computer systems.  This includes =
e.g.
means to 

   change the power state of an entity (e.g. to shutdown the =
entity) 

   which is an aspect of but not sufficient for active energy =


   management. 



A.2.2.  OVDA 



   ODVA is an association consisting of members from =
industrial 

   automation companies.  ODVA supports standardization =
of
network 

   technologies based on the Common Industrial Protocol =
(CIP). 
Within 

   ODVA, there is a special interest group focused on energy =
and 

   standardization and inter-operability of energy aware =
entities. 



A.2.3.  IEEE-ISTO Printer WG 



   The charter of the IEEE-ISTO Printer Working Group is for =
open 

   standards that define printer related protocols, that =
printer 

   manufacturers and related software vendors shall benefit =
from the 

   interoperability provided by conformance to these =
standards. 
One 

   particular aspect the Printer WG is focused on is power =
monitoring


   and management of network printers and imaging systems PWG =
Power 

   Management Model for Imaging Systems [IEEE-ISTO].  =
Clearly,
these 

   devices are within the scope of energy management since =
these
devices 

   consume power and are attached to the network.  In =
addition,
there is 







Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 33] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   ample scope of power management since printers and imaging =
systems


   are not used that often.  IEEE-ISTO Printer working =
group has
defined 

   MIB modules for monitoring the power consumption and power =
state 

   series that can be useful for power management of =
printers. 
The 

   energy management framework should also take into account =
the 

   standards defined in the Printer working group.  In =
terms of
other 

   standards, IETF Printer MIB RFC3805 [RFC3805] has been
standardized, 

   however, this MIB module does not address power management =
of 

   printers. 





Authors' Addresses 



   Juergen Quittek (editor) 

   NEC Europe Ltd. 

   NEC Laboratories Europe 

   Network Research Division 

   Kurfuersten-Anlage 36 

   Heidelberg  69115 

   DE 



   Phone: +49 6221 4342-115 

   Email: quittek@neclab.eu 





   Rolf Winter 

   NEC Europe Ltd. 

   NEC Laboratories Europe 

   Network Research Division 

   Kurfuersten-Anlage 36 

   Heidelberg  69115 

   DE 



   Phone: +49 6221 4342-121 

   Email: Rolf.Winter@neclab.eu






   Thomas Dietz 

   NEC Europe Ltd. 

   NEC Laboratories Europe 

   Network Research Division 

   Kurfuersten-Anlage 36 

   Heidelberg  69115 

   DE 



   Phone: +49 6221 4342-128 

   Email: Thomas.Dietz@neclab.eu










Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 34] 

 

Internet-Draft     Requirements for Energy
Management          July =
2011 





   Benoit Claise 

   Cisco Systems, Inc. 

   De Kleetlaan 6a b1 

   Degem  1831 

   BE 



   Phone: +32 2 704 5622 

   Email: bclaise@cisco.com 





   Mouli Chandramouli 

   Cisco Systems, Inc. 

   Sarjapur Outer Ring Road 

   Bangalore, 

   IN 



   Phone: +91 80 4426 3947 

   Email: moulchan@cisco.com 



































































Quittek, et al.         Expires =
January
12,
2012           &nb=
sp;  
[Page 35] 

 



 









------_=_NextPart_001_01CC4C89.B512C1C1--

From jparello@cisco.com  Wed Jul 27 11:20:05 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0A421F8BF4 for ; Wed, 27 Jul 2011 11:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.965
X-Spam-Level: 
X-Spam-Status: No, score=-2.965 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdzjDmaGVpNo for ; Wed, 27 Jul 2011 11:20:04 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 73E7721F8C18 for ; Wed, 27 Jul 2011 11:20:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=10497; q=dns/txt; s=iport; t=1311790803; x=1313000403; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=u/hq/cqr14o7bDF+6zmGljunhmlyijrIKA1QpioigE4=; b=BTWGqi72/2ENgNSnFr3wiHcXrl51fC5GOuwH6KEGwp23kPCKobBijFvC Lyb6Xr3zfFetv5FsbxSe6zoInAz38odp6x87XnKutqoot4es7/T7LepPc xHSDi2KKdoQ1eSRxSrQD75mdebqv/Ch1vyWZSTwsWTWDd+l0yzbzPJlH/ A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuAAAKxWME6rRDoG/2dsb2JhbAA1AQEBAQIBAQEBEQEhCjoXAwICAQkQAQQBAQEKBgYIARQBBgETDAwjDggCBQEWDBuXW49Id4h8BKNenmsCgyETB4IkXwSHV5Aui3I
X-IronPort-AV: E=Sophos;i="4.67,277,1309737600";  d="scan'208";a="7094408"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-7.cisco.com with ESMTP; 27 Jul 2011 18:20:02 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6RIK18m001318; Wed, 27 Jul 2011 18:20:01 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 27 Jul 2011 11:20:01 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Jul 2011 11:19:22 -0700
Message-ID: 
In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D925@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] Two NMS configuring the Power Monitor with two different Power State Series
Thread-Index: AQHMCXFiSCfqP4ogWEKUmuBzMsYh5ZR6tKGAgIIeIYCAAAuRgIAAWfxQgACfKjCAAEh4gIAC4Haw
References: <4DBFC56E.2020908@cisco.com><20110503092855.GA3772@elstar.local><0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D5C0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com><4E2CFB1B.3030403@cisco.com><75581E268A48F849916117B977D76D372CCD502D@Polydeuces.office.hd> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D925@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
From: "John Parello (jparello)" 
To: "Mielke, William F (Bill)" , "eman mailing list" 
X-OriginalArrivalTime: 27 Jul 2011 18:20:01.0486 (UTC) FILETIME=[CCAA86E0:01CC4C89]
Subject: Re: [eman] Two NMS configuring the Power Monitor with two different Power State Series
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 18:20:05 -0000

That's exactly my understanding.

Jp

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Mielke, William F (Bill)
Sent: Monday, July 25, 2011 3:32 PM
To: eman mailing list
Subject: Re: [eman] Two NMS configuring the Power Monitor with two
different Power State Series

OK, I think I understand now.  I have no problem with a given device
being able to support multiple power series simultaneously if it chooses
to do so.

So let me articulate the operational scenario and you tell me if I have
the proper understanding.

1. Assume some device X supports multiple power series.

2. NMS 1 queries to determine which power series device X supports.

3. NMS 1 selects one power series from the available set and uses that
to interact with X.

4. NMS 2 queries to determine which power series device X supports.

5. NMS 2 selects a potentially different power series from the available
set and uses that to interact with X.

6. NMS 1 and 2 both continue to interact with X using their respective
choices and these interactions can be interleaved without difficulty.

If a device decides to only support one power series then when queried
it only reports that one.

Is this generally the correct idea?

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

=20

> -----Original Message-----
> From: John Parello (jparello) [mailto:jparello@cisco.com]=20
> Sent: Monday, July 25, 2011 2:06 PM
> To: Thomas Dietz; Benoit Claise (bclaise); Mielke, William F (Bill)
> Cc: eman mailing list
> Subject: RE: [eman] Two NMS configuring the Power Monitor=20
> with two different Power State Series
>=20
> Hi Thomas,
>=20
> I agree with you. Having multiple series supported at the same time is
> not an overhead. If a device cannot then it should advertise only the
> one.
>=20
> I don't see why a device would advertise more than one series then
> restrict to one.
>=20
> if a devices can do multiple series then advertise as such if not
> advertise only one.
>=20
> I have implementations that multiple series right now so it's not
> difficult and makes the NMS discovery much more straight forward and
> more importantly universal.
>=20
> +1
>=20
>=20
> Jp
>=20
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20
> Behalf Of
> Thomas Dietz
> Sent: Monday, July 25, 2011 1:39 AM
> To: Benoit Claise (bclaise); Mielke, William F (Bill)
> Cc: eman mailing list
> Subject: Re: [eman] Two NMS configuring the Power Monitor with two
> different Power State Series
>=20
> Dear Bill,
>=20
> The way set forward in the recent draft that was pointed out by Benoit
> gives the different NMS the freedom to choose which power=20
> series to take
> if the managed object supports more than one. And I don't think it is
> much of an overhead for the managed object to match one power=20
> series to
> another.
>=20
> Best Regards,
>=20
> Thomas
>=20
> --
> Thomas Dietz
> NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115
> Heidelberg, Germany
>=20
> NEC Europe Limited, Registered in England 2832014 Registered=20
> Office: NEC
> House, 1 Victoria Road, London W3 6BL
>=20
>=20
> > -----Original Message-----
> > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org]=20
> On Behalf=20
> > Of Benoit Claise
> > Sent: Montag, 25. Juli 2011 07:12
> > To: Mielke, William F (Bill)
> > Cc: eman mailing list
> > Subject: Re: [eman] Two NMS configuring the Power Monitor with two=20
> > different Power State Series
> >=20
> > Hi Bill,
> > > I apologize for having gone silent for so long but I am here in=20
> > > Quebec
> > and am working through old emails to come back up to speed.  I also=20
> > apologize for perhaps covering old ground in some cases.  I plan to=20
> > comment as I go chronologically through the list archive.  If I=20
> > comment on something which was later resolved please bear=20
> with me as I
>=20
> > will eventually find the resolution along the way.  Either=20
> way it is=20
> > probably better that I record my comments in the event that=20
> I identify
>=20
> > something that has not been considered fully.
> > >
> > > Regarding the issue of 2 NMS's interacting with a single Managed=20
> > > Object
> > using different power state series, my thinking all along=20
> was that the
>=20
> > managed object would choose (align with) the power series that made=20
> > sense for it and that the NMS's would have to adapt to=20
> talking to the=20
> > managed object in its preferred  (supported) series.  So in=20
> this case=20
> > there is no confusion, the series selected by the managed object is=20
> > always the one that will be used by any NMS.  This approach is
> consistent with Juergen S.
> > point that traditionally the NMS was assumed to be better=20
> able to deal
>=20
> > with these types of variations rather then the managed object=20
> > implementation.
> > >
> > > How was this point ultimately resolved, assuming it was?
> > By having an extra index in the tables. First the power=20
> state series,=20
> > then the power state.
> > From=20
> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09:
> >=20
> >         pmPowerTable OBJECT-TYPE
> >              SYNTAX          SEQUENCE OF PmPowerEntry
> >              MAX-ACCESS      not-accessible
> >              STATUS          current
> >              DESCRIPTION
> >                 "This table lists Power Monitors."
> >              ::=3D { powerMonitorMIBObjects 1 }
> >=20
> >          pmPowerEntry OBJECT-TYPE
> >              SYNTAX          PmPowerEntry
> >              MAX-ACCESS      not-accessible
> >              STATUS          current
> >              DESCRIPTION
> >                 "An entry describes the power usage of a Power
> Monitor."
> >              INDEX           { pmPowerIndex, pmPowerStateSetIndex}
> >=20
> >=20
> >=20
> > >
> > > William F. Mielke
> > > Alcatel-Lucent
> > > Distinguished Member of Technical Staff 6200 East Broad Street
> > > Room: 4B01-1V
> > > Columbus, OH  43213-1530
> > > Email: Bill.Mielke@alcatel-lucent.com
> > > Phone: 614 367 5628
> > > Fax: 614 367 5965
> > >
> > > "Live like you're going to die tomorrow.
> > >   Learn like you're going to live forever."
> > >
> > >      - Albert Einstein
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20
> > >> Behalf Of Juergen Schoenwaelder
> > >> Sent: Tuesday, May 03, 2011 5:29 AM
> > >> To: Benoit Claise
> > >> Cc: eman mailing list
> > >> Subject: Re: [eman] Two NMS configuring the Power=20
> Monitor with two=20
> > >> different Power State Series
> > >>
> > >> On Tue, May 03, 2011 at 11:05:50AM +0200, Benoit Claise wrote:
> > >>
> > >>> Let's discuss the following situation: what if we have=20
> 2 NMS', and
>=20
> > >>> they speak different Power State Series for a specific Power=20
> > >>> Monitor? Should this be allowed by the [EMAN-REQ]?
> > >> Traditionally, it was always assumed that an SNMP=20
> management system
>=20
> > >> can more easily adapt to devices than the other way round.
> > >>
> > >>> Actually this requirement has got some implications in terms of=20
> > >>> the MIB design (taking
> > >>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07
> > >>> into account)
> > >>>
> > >>> - If the answer is yes, then we need to have an extra=20
> index in the
>=20
> > >>> power pmPowerTable. This index must abe a new TC, which is only=20
> > >>> for the Power State Series.  Note: the table needs to=20
> redesigned=20
> > >>> because the common variable (caliber, nameplate, etc...) are=20
> > >>> common per Power State Series. Then we can have a new=20
> table, for=20
> > >>> discovery, that will only contain  two indices:=20
> > >>> pmPowerMonitorIndex and the new TC-defined pmPowerStateSeries.
> > >>> - If the answer is no, then there is the risk that NMS1=20
> will set=20
> > >>> the
> > >>> DMTF:1 for example, and then NMS2 set it EMAN:3=20
> (assuming that the
>=20
> > >>> Power Monitor supports both the DMTF and the EMAN Power State=20
> > >>> Series), and there is a ping-pong game between two NMS's that=20
> > >>> don't synchronize between the two.
> > >> If two management systems make changes without coordination, you=20
> > >> always have a chance for ping-pong effects, even within a Power=20
> > >> State Series. That said, it might be possible to provide=20
> guidelines
>=20
> > >> such as if a device is reporting a value of a given Power State=20
> > >> Series (e.g. DMTF:3), a management application should=20
> adapt and use
>=20
> > >> DMTF power states.
> > >>
> > >>> The alternative is that the first NMS would say: I will=20
> speak to=20
> > >>> the Power Monitor with the DMTF Power State Series, and=20
> then all=20
> > >>> the other NMS's will have to speak the same language=20
> (i.e. DMTF).
> > >> I think that is a reasonably assumption to make if the number of=20
> > >> different Power State Series is kept limited (that is we prevent=20
> > >> that every vendor/organization comes up with its own creative=20
> > >> series of power states). A large number of different Power State=20
> > >> Series will be hindering interoperability, with or without
> ping-pong effects.
> > >>
> > >> /js
> > >>
> > >> --
> > >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > >> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen,
> Germany
> > >> Fax:   +49 421 200 3103
> > >> _______________________________________________
> > >> eman mailing list
> > >> eman@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/eman
> > >>
> >=20
> > _______________________________________________
> > eman mailing list
> > eman@ietf.org
> > https://www.ietf.org/mailman/listinfo/eman
>=20
_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman

From jparello@cisco.com  Wed Jul 27 11:31:38 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2588D11E8099 for ; Wed, 27 Jul 2011 11:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.643
X-Spam-Level: 
X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_00=-2.599, J_CHICKENPOX_64=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+uGwRB1TWjv for ; Wed, 27 Jul 2011 11:31:37 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 20BFD11E8123 for ; Wed, 27 Jul 2011 11:31:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=4825; q=dns/txt; s=iport; t=1311791497; x=1313001097; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=FziLhvoyGT+I0KPsfd/0wc37e9nyKO6yQ7CSSCpVjvo=; b=GlP30t0O3lg1fvnWM8Icf+mlM0Rkg2pDLIopoMC+gLlFEvHNOdCKYIeR fo8bngYq8kVK8f83sw/NWBl5lDnoF3DogAy0YwSmI/f9Cdkp22fCjoMPQ 4Os91ITSDxwMtfL4WxKlJYsSrUaADJF719nYUSS6tYazrGCmzQrvfNkKW Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuAAAF5YME6rRDoI/2dsb2JhbAA1AQEBAQMBAQERASEKNAYXAwICAQkRBAEBCwYGCRQBBgETDAwjDggBAQUBFgwbl1uPSHeJAKM0nmsCgyEagiRfBIdXkC6Lcg
X-IronPort-AV: E=Sophos;i="4.67,277,1309737600";  d="scan'208";a="7092158"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-2.cisco.com with ESMTP; 27 Jul 2011 18:31:36 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6RIVIRL023555; Wed, 27 Jul 2011 18:31:36 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 27 Jul 2011 11:31:35 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Jul 2011 11:30:57 -0700
Message-ID: 
In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D86D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] New draft on eman requirements - issue 1 - Device type
Thread-Index: Acw9P31+zxauYAdDQHCQA9ZAWZ0oLQNvpy8gAGLwb8A=
References: <1127B34B-6899-4F1D-966E-ED841E25E554@quittek.at><4E142A61.3010103@cisco.com><20248561-E87E-4CD0-9E57-E031B00E479A@quittek.at> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250985D86D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
From: "John Parello (jparello)" 
To: "Mielke, William F (Bill)" , "eman mailing list" 
X-OriginalArrivalTime: 27 Jul 2011 18:31:35.0221 (UTC) FILETIME=[6A2A1650:01CC4C8B]
Subject: Re: [eman] New draft on eman requirements - issue 1 - Device type
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 18:31:38 -0000

Hi Bill

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

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

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

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

Example:

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

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

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

Jp

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

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

Grouping for what purpose?

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

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

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com 

Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein=20

=20


________________________________

	From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On
Behalf Of Bruce Nordman
	Sent: Friday, July 08, 2011 3:17 AM
	To: eman mailing list
	Subject: Re: [eman] New draft on eman requirements - issue 1 -
Device type
=09
=09


	On Wed, Jul 6, 2011 at 4:59 AM, Juergen Quittek
 wrote:
=09

		On 06.07.2011  11:26, Benoit Claise wrote:
		....


			Coming back to this requirement
		=09
		=09

				5.1.1. Type of powered entity
			=09
				The energy management standard must
provide means to retrieve and
				report the type of powered entities.

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

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

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


	I have to disagree completely on this point.
	A major barrier to understanding energy use in
	buildings and in doing things to reduce it is
	lack of information about what devices are=20
	present in a building and how much each
	one is using.  We are going into great detail
	about the quantities of energy, but seem to
	want to avoid saying anything about what
	the device actually is.
=09
	Accomplishing this and meeting the needs of
	energy efficiency need not be burdensome.
	Just a few variables can point to a standard
	index of device types (or "product types" in
	my line of work) and short brand/model
	information.
=09
	Thanks,
=09
	--Bruce
	=20
=09





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

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

From jparello@cisco.com  Wed Jul 27 11:41:52 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABD121F8B73 for ; Wed, 27 Jul 2011 11:41:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.304
X-Spam-Level: 
X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_75=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1kGyxsPJbKO for ; Wed, 27 Jul 2011 11:41:49 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 775FE11E80AD for ; Wed, 27 Jul 2011 11:41:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=28174; q=dns/txt; s=iport; t=1311792108; x=1313001708; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=2ZcvOkXpHKwvg4kd1/bdwDEZThWPWJPtMy+xqIMNoDg=; b=P0NfNYq2Hf0kR1hcmDIDHWFGVGLgOW3xBUDSworeCLVmoBm6ZUqWxPkj wJOOYRqMoFJRaCabnULuQmGxEBUcLHtXf6/j8oYv7YfCXEKCh2LEAaNHA flDsue4xAVfGM/nUmbtAthtJnGDIggv+6bAJPrfED5LugkgZ4bO5EW1EL I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicBAMNaME6rRDoI/2dsb2JhbAAVIAEBAQEDFAEMDAYDSBgCAQkRBAEBCwYGFgEGAQYBEzsOCAIFARYMFAeCNpUlj0h3nDSQCZ5rgyOCPl8Eh1eLSIRmi3I
X-IronPort-AV: E=Sophos;i="4.67,277,1309737600"; d="scan'208,217";a="7095720"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-2.cisco.com with ESMTP; 27 Jul 2011 18:41:47 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6RIflU9001039; Wed, 27 Jul 2011 18:41:47 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 27 Jul 2011 11:41:46 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4C8C.D674180A"
Date: Wed, 27 Jul 2011 11:41:06 -0700
Message-ID: 
In-Reply-To: <7B9BC0FC24CECF4A840DB64B5C5B77850975CCD93B@QHEXMBOX2.hosting.inetserver.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Feedback on Framework Draft
Thread-Index: AcxH+LKmWKbSec3VQ6OixI9JpyOlRQAcVf/wAAmyXPAAAqqMEAAFNQxgAAA/HzAA9oaswA==
References: <7B9BC0FC24CECF4A840DB64B5C5B77850975CCD8A3@QHEXMBOX2.hosting.inetserver.de>  <7B9BC0FC24CECF4A840DB64B5C5B77850975CCD934@QHEXMBOX2.hosting.inetserver.de>  <7B9BC0FC24CECF4A840DB64B5C5B77850975CCD93B@QHEXMBOX2.hosting.inetserver.de>
From: "John Parello (jparello)" 
To: "David Prantl" , 
X-OriginalArrivalTime: 27 Jul 2011 18:41:46.0867 (UTC) FILETIME=[D6BBDC30:01CC4C8C]
Subject: Re: [eman] Feedback on Framework Draft
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 18:41:52 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4C8C.D674180A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

HI David,

=20

Thanks glad we have things in the draft that are useful. Hopefully we
can figure out how to meet you other needs.

=20

Please see inline...=20

=20

From: David Prantl [mailto:david.prantl@joulex.net]=20
Sent: Friday, July 22, 2011 1:54 PM
To: eman@ietf.org
Subject: Feedback on Framework Draft

=20

Hello All,

=20

my name is David Prantl, working for JouleX as a Solution Architect. I
am summarizing

comments from myself and my colleagues Martin Paatz and Rene Seeber. We
have an

Enterprise Energy Management Product and would like to comment on the
latest

draft of the Energy Management Framework Draft - which we think is a
great foundation

for a standardized approach to Energy Management.

Comments as bullet points below:

=20

Energy Monitoring

*         We are Glad that Energy Quality and Demand are available as
optional Values as this permits
us - if available from Energy Managed Objects - to deliver high accuracy
Readings (based on=20
demand/total Energy delivered and not point measurements)

*         The Integration of Battery Information is crucial for shaving
off energy during peak demand periods-
it is good to know this is already integrated, peak-demand handling is
crucial in e.g. Japan.

=20

[jp] thanks!

=20

Energy Managed Object Identification and Context

Today there are specifications for role/keyword/importance/category

*         The Keyword Concept for Grouping is extremely useful and has
been integrated into our=20
Software for arbitrary Objects.

*         The Context Role (5.2.5) must specify more examples or rules
on how the roles-tring should be populated,

e.g. contain standard definitions, otherwise they are only one more
keyword.

However, we appreciate this additional Information field, and would in
fact encourage more of these - but
with clearly defined recommendations in regards to content, see below.

[jp] Thanks we'll add guidance in the framework

=20

*         There should be additional identification fields for at least
vendor and product, e.g.=20
Cisco, WS-C2960G-48TC-L or Lenovo, W500
Otherwise there is no way to uniquely identify Energy Managed Objects
(in respect to what kind of device
is behind it) - this becomes important when additional Information must
be retrieved or presented.
E.g. when an outside mgmt-station maps Manufacturer Power States based
on pre-known states for a=20
certain device-type

=20

[jp] There's a discussion in the requirements for this. I proposed some
vendor,type,species information. What would work for you?

=20

Energy Managed Object Relationships

*         energy topology information - the draft supports the concept
of parent<->child mappings, but does not allow
for more complex energy topologies,=20

e.g. 2 circuits <-> 4 outlets <-> 4 Power Supplies <->=20
blade-chassis(info about chassis-draw, ps-draw)<->8 blades(info about
blade/cpu-draw)
It is also not possible to "populate" the domain with information about
these mappings, e.g. I cannot tell

the domain that server1 is powered by pdu1, plugA and pud2, plugB.

=20

[jp] We added the notion of relationships between devices. We have
metered, powered,proxy,aggregation. For population we'll have to call
that our but the intent was to make the uuid's the link. We have to
settle on the use of a universal identifier first or what you want may
not be convenient or possible. I'll present a topology and let's see of
that suffices for you modeling purposes.

=20

Energy Control

*         non-discrete power-states are not supported -> Section 5.5.
specifies the possibility of mapping=20
"Manufacturer" Power States to the 12 Eman Power states, where there can
be more than 12 Manufacturer
Power States. However, in the context of power-capping of Servers we
have a "non-discrete" floating cap corresponding
to the Manufacturer Power State.
The Problem is that different Servers will have completely different
ranges of supported cap-values, e.g. Server 1 has a dynamic range of
300-500Watt, Server2 has a range of 70-270Watts. Now let's assume
Powerstate 9=3D400 Watts for Server1, but would be 170Watts for Server2.
Which would mean I have to specify a Mapping for each Server-Model.
It would be far more practical if it would be possible to supply a
key-value-pair with a certain power-state in Case the=20
State needs context such as a power-cap, I would then specify a state of
e.g. 7 and supply the desired Cap in the kvp-field.

=20

[jp] This one is interesting. We don't have a model for this so perhaps
some help on proposing one=20

=20

General Stuff.

*         (Page 6) 3. Terminology

Energy Management System is introduced as EnMS later EMS is used (e.g.
Page 7).

=20

[jp] Thanks I'll try and clear that up. EnMS is a term from ISO500001
and EMS is an overloaded term meaning a computerized energy management
system and/or element management system.

=20

*         Generally

parent child relationship can lead to a delayed measurement, especially
with multiple generations

e.g.  1. child measures every 5 minutes -> parent every 4 minutes, this
will lead to different offsets in the readings

=20

[jp] Very true.  Would timestamps help here or is this something
inherent in the problem.

=20

Thanks again!

Jp

=20


------_=_NextPart_001_01CC4C8C.D674180A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















HI =
David,



 



Thanks glad we have =
things in
the draft that are useful. Hopefully we can figure out how to meet you =
other
needs.



 



Please see =
inline… 



 









From:=
 David =
Prantl
[mailto:david.prantl@joulex.net] 

Sent: Friday, July 22, 2011 1:54 PM

To: eman@ietf.org

Subject: Feedback on Framework Draft









 



Hello All,



 



my name is David Prantl, working for JouleX as a =
Solution
Architect. I am summarizing



comments from myself and my colleagues Martin Paatz =
and Rene
Seeber. We have an



Enterprise Energy Management Product and would like =
to
comment on the latest



draft of the Energy Management Framework Draft =
– which
we think is a great foundation



for a standardized approach to Energy =
Management.



Comments as bullet points below:



 



Energy Monitoring



·        
We are Glad that Energy Quality and =
Demand are
available as optional Values as this permits

us – if available from Energy Managed Objects – to deliver =
high
accuracy Readings (based on 

demand/total Energy delivered and not point measurements)



·        
The Integration of Battery Information is
crucial for shaving off energy during peak demand periods-

it is good to know this is already integrated, peak-demand handling is =
crucial
in e.g. Japan.



 



[jp] =
thanks!



 



Energy Managed Object Identification and =
Context



Today there are specifications for
role/keyword/importance/category



·        
The Keyword Concept for Grouping is =
extremely
useful and has been integrated into our 

Software for arbitrary Objects.



·        
The Context Role (5.2.5) must specify =
more
examples or rules on how the roles-tring should be =
populated,



e.g. contain standard definitions, otherwise =
they are
only one more keyword.



However, we appreciate this additional =
Information
field, and would in fact encourage more of these – but

with clearly defined recommendations in regards to content, see =
below.



[jp]
Thanks we’ll add guidance in the framework



 



·        
There should be additional identification =
fields
for at least vendor and product, e.g. 

Cisco, WS-C2960G-48TC-L or Lenovo, W500

Otherwise there is no way to uniquely identify Energy Managed Objects =
(in
respect to what kind of device

is behind it) – this becomes important when additional Information =
must
be retrieved or presented.

E.g. when an outside mgmt-station maps Manufacturer Power States based =
on
pre-known states for a 

certain device-type



 



[jp] There’s a =
discussion
in the requirements for this. I proposed some vendor,type,species =
information.
What would work for you?



 



Energy Managed Object Relationships



·        
energy topology information – the =
draft
supports the concept of parent<->child mappings, but does not =
allow

for more complex energy topologies, 



e.g. 2 circuits <-> 4 outlets =
<-> 4 Power
Supplies <-> 

blade-chassis(info about chassis-draw, ps-draw)<->8 blades(info =
about
blade/cpu-draw)

It is also not possible to “populate” the domain with =
information
about these mappings, e.g. I cannot tell



the domain that server1 is powered by pdu1, =
plugA and
pud2, plugB.



 



[jp] We added the =
notion of relationships
between devices. We have metered, powered,proxy,aggregation. For =
population we’ll
have to call that our but the intent was to make the uuid’s the =
link. We
have to settle on the use of a universal identifier first or what you =
want may
not be convenient or possible. I’ll present a topology and =
let’s
see of that suffices for you modeling purposes.



 



Energy Control



·        
non-discrete power-states are not =
supported
-> Section 5.5. specifies the possibility of mapping 

“Manufacturer” Power States to the 12 Eman Power states, =
where
there can be more than 12 Manufacturer

Power States. However, in the context of power-capping of Servers we =
have a
“non-discrete” floating cap corresponding

to the Manufacturer Power State.

The Problem is that different Servers will have completely different =
ranges of
supported cap-values, e.g. Server 1 has a dynamic range of 300-500Watt, =
Server2
has a range of 70-270Watts. Now let’s assume Powerstate 9=3D400 =
Watts for
Server1, but would be 170Watts for Server2. Which would mean I have to =
specify
a Mapping for each Server-Model.

It would be far more practical if it would be possible to supply a
key-value-pair with a certain power-state in Case the 

State needs context such as a power-cap, I would then specify a state of =
e.g. 7
and supply the desired Cap in the kvp-field.



 



[jp] This one is =
interesting. We
don’t have a model for this so perhaps some help on proposing one =




 



General Stuff.



·        
(Page 6) 3. Terminology



Energy Management =
System is introduced
as EnMS later EMS is used (e.g. Page 7).



 



[jp] Thanks =
I’ll try and
clear that up. EnMS is a term from ISO500001 and EMS is an overloaded =
term meaning
a computerized energy management system and/or element management =
system.



 



·        
Generally



parent child =
relationship can
lead to a delayed measurement, especially with multiple =
generations



e.g.  1. child =
measures
every 5 minutes -> parent every 4 minutes, this will lead to =
different offsets
in the readings



 



[jp] Very true. =
 Would timestamps
help here or is this something inherent in the =
problem.



 



Thanks =
again!



Jp



 









------_=_NextPart_001_01CC4C8C.D674180A--

From jparello@cisco.com  Wed Jul 27 12:00:50 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0116C11E812F for ; Wed, 27 Jul 2011 12:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.854
X-Spam-Level: 
X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UeCHC-NdEQR for ; Wed, 27 Jul 2011 12:00:46 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3369211E814B for ; Wed, 27 Jul 2011 12:00:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=848; q=dns/txt; s=iport; t=1311793245; x=1313002845; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=aSxWBQYShHtykIFgC/60ugGpp+Jag2VXdB+6vd+GtIk=; b=WQQvPwhnQgjpCxlhNMNU1HtMbo6X5Q475w0uDGndi15FJmkpICAUo4z8 Bde740GuIk4sJzO0jLDs0jqugbrCuV2SiEMFRZipfDIzmrL8rxZLN+K/q +zMVlnBuFjg8MjWzpCd4KOPF/040wQ5kgggZCyP1HlJh7WHpc7Bhr+mcs c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqQFAKVfME6rRDoH/2dsb2JhbAA3AQEDFAEhClgBKwYGHgcTUgEFIxuYII8Ed6sGgSOebIMjgj5fBIdXkC6Lcg
X-IronPort-AV: E=Sophos;i="4.67,278,1309737600";  d="scan'208";a="7103600"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-8.cisco.com with ESMTP; 27 Jul 2011 19:00:44 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6RJ0RdX020597 for ; Wed, 27 Jul 2011 19:00:44 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 27 Jul 2011 12:00:34 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Jul 2011 11:59:55 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] terminology Energy Managed Object versus Powered Device
Thread-Index: AcxMj19mnUNaeKxRSHWmTnf8KDx9VA==
From: "John Parello (jparello)" 
To: 
X-OriginalArrivalTime: 27 Jul 2011 19:00:34.0900 (UTC) FILETIME=[77180940:01CC4C8F]
Subject: [eman]  terminology Energy Managed Object versus Powered Device
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 19:00:51 -0000

Hi,

I saw a few threads where we discussed this and I want to pull it to its
own thread.

In the framework I referred to an Energy Managed Object. I got some
feedback and in the alternate ref draft Theresa notion of powered
device.

I like the concept of having a device and power interface similar to the
communication notion of device and interface.

When managing these element however we typically use the term managed
object. That boils down to something you give a unique identifier to and
then manage. This can be interfaces, virtual interfaces, devices,
motherboards etc.

I'd like to use that same notion here with an generic Energy Managed
Object. That was we can model and uniquely identify logical objects
(outlets, inlets, interfaces, etc) as well as physical.

So I think EMO is a better term.

Thoughts?
Jp

From bnordman@lbl.gov  Wed Jul 27 12:53:33 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E33511E8120 for ; Wed, 27 Jul 2011 12:53:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.806
X-Spam-Level: 
X-Spam-Status: No, score=-5.806 tagged_above=-999 required=5 tests=[AWL=0.170,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WERFumHa5a68 for ; Wed, 27 Jul 2011 12:53:32 -0700 (PDT)
Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA7411E8114 for ; Wed, 27 Jul 2011 12:53:32 -0700 (PDT)
X-Ironport-SBRS: 5.2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkEBAMVrME7RVdo0mGdsb2JhbAA1AQEBAQIBAQEBEQJkCwUMDAsjCRsUEwUOAQUBJAcXDBuCNpxSAYgTCBQBAQEBAQgJDQcUJYh8BKQ+Cp0tgyMagwMEknWMSjyDeA
X-IronPort-AV: E=Sophos;i="4.67,278,1309762800"; d="scan'208";a="47049848"
Received: from mail-yi0-f52.google.com ([209.85.218.52]) by ironport4.lbl.gov with ESMTP; 27 Jul 2011 12:53:31 -0700
Received: by mail-yi0-f52.google.com with SMTP id 19so2003241yie.39 for ; Wed, 27 Jul 2011 12:53:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.116.5 with SMTP id o5mr187759anc.60.1311796411267; Wed, 27 Jul 2011 12:53:31 -0700 (PDT)
Received: by 10.100.241.8 with HTTP; Wed, 27 Jul 2011 12:53:31 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 27 Jul 2011 15:53:31 -0400
Message-ID: 
From: Bruce Nordman 
To: "John Parello (jparello)" 
Content-Type: multipart/alternative; boundary=0016e644d62a1c797604a9126712
Cc: eman@ietf.org
Subject: Re: [eman] terminology Energy Managed Object versus Powered Device
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 19:53:33 -0000

--0016e644d62a1c797604a9126712
Content-Type: text/plain; charset=ISO-8859-1

The current definition of an EMO begins:

An Energy Managed Object (EMO) is a device that is part of or
        attached to a communications network...

So, I took that to mean an integral device, like a computer, switch, router,
etc. that
has a power cord and network interfaces.  I use "device" to refer to this
concept.
I know that EMAN Is to report on either entire devices, or components of
devices,
and "entity" can be used to reference the combination of devices and
components
in line with the Entity MIB name.  A Power Interface is also a type of
entity, since
it is a component and there is measurement and control for that just as with
any
other component.

*So, regardless of what terms are used, we need terms that are synonyms for
powered device, component, entity, and power interface.*
An assumption I am making is that an entire device has some characteristics
(important ones reflected in the MIB structure) different from a component.

I think it is very easy for people to accidentally misinterpret what EMO is
referring to - a device, a component, an entity, or even a software object.
I also prefer shorter terms.

A cross-cutting question would seem to be whether things are named based
on what they are, or by what is being done to them.  Dictionary.com
indicates
that management is about control.  Many EMAN entities will support control
and others will not.  Are the ones that don't do control being managed?
Not using the 'manage' term avoids that question.


On Wed, Jul 27, 2011 at 2:59 PM, John Parello (jparello)  wrote:

> Hi,
>
> I saw a few threads where we discussed this and I want to pull it to its
> own thread.
>
> In the framework I referred to an Energy Managed Object. I got some
> feedback and in the alternate ref draft Theresa notion of powered
> device.
>
> I like the concept of having a device and power interface similar to the
> communication notion of device and interface.
>
> When managing these element however we typically use the term managed
> object. That boils down to something you give a unique identifier to and
> then manage. This can be interfaces, virtual interfaces, devices,
> motherboards etc.
>
> I'd like to use that same notion here with an generic Energy Managed
> Object. That was we can model and uniquely identify logical objects
> (outlets, inlets, interfaces, etc) as well as physical.
>
> So I think EMO is a better term.
>
> Thoughts?
> Jp
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>



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

--0016e644d62a1c797604a9126712
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The current definition of an EMO begins:
An Energy Managed Object (=
EMO) is a device that is part of or=20
        attached to a communications network...
So, I took that to mea=
n an integral device, like a computer, switch, router, etc. that
has a p=
ower cord and network interfaces.=A0 I use "device" to refer to t=
his concept.

I know that EMAN Is to report on either entire devices, or components of de=
vices,
and "entity" can be used to reference the combination o=
f devices and components
in line with the Entity MIB name.=A0 A Power In=
terface is also a type of entity, since

it is a component and there is measurement and control for that just as wit=
h any
other component.

So, regardless of what terms are used, =
we need terms that are synonyms for
powered device, componen=
t, entity, and power interface.

An assumption I am making is that an entire device has some characteristics=

(important ones reflected in the MIB structure) different from a compon=
ent.

I think it is very easy for people to accidentally misinterpret=
 what EMO is

referring to - a device, a component, an entity, or even a software object.=

I also prefer shorter terms.

A cross-cutting question would seem=
 to be whether things are named based
on what they are, or by what is be=
ing done to them.=A0 Dictionary.com indicates

that management is about control.=A0 Many EMAN entities will support contro=
l
and others will not.=A0 Are the ones that don't do control being m=
anaged?
Not using the 'manage' term avoids that question.


On Wed, Jul 27, 2011 at 2:59 PM, John Parell=
o (jparello) <jp=
arello@cisco.com> wrote:

Hi,



I saw a few threads where we discussed this and I want to pull it to its
own thread.



In the framework I referred to an Energy Managed Object. I got some

feedback and in the alternate ref draft Theresa notion of powered

device.



I like the concept of having a device and power interface similar to the
communication notion of device and interface.



When managing these element however we typically use the term managed

object. That boils down to something you give a unique identifier to and
then manage. This can be interfaces, virtual interfaces, devices,

motherboards etc.



I'd like to use that same notion here with an generic Energy Managed
Object. That was we can model and uniquely identify logical objects

(outlets, inlets, interfaces, etc) as well as physical.



So I think EMO is a better term.



Thoughts?

Jp

_______________________________________________

eman mailing list

eman@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/eman





-- 
Bru=
ce Nordman
Lawrence Berk=
eley National Laboratory
eetd.lbl.gov/ea/nordman

BNordman@LBL.gov
510-486-7089
m: 510-501-7943



--0016e644d62a1c797604a9126712--

From bill.mielke@alcatel-lucent.com  Wed Jul 27 13:07:55 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45E321F8AE4 for ; Wed, 27 Jul 2011 13:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSRlWxnVBGyt for ; Wed, 27 Jul 2011 13:07:54 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id AA43821F8ADE for ; Wed, 27 Jul 2011 13:07:54 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p6RK7rmn029176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Jul 2011 15:07:53 -0500 (CDT)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6RK7raH030764 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 27 Jul 2011 15:07:53 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 27 Jul 2011 15:07:53 -0500
From: "Mielke, William F (Bill)" 
To: eman mailing list 
Date: Wed, 27 Jul 2011 15:07:51 -0500
Thread-Topic: Comments on draft-ietf-eman-requirements-04
Thread-Index: AcxMmN1Qzgf/R9SMQN2U+6sYEpngBQ==
Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DB80@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
Subject: [eman] Comments on draft-ietf-eman-requirements-04
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 20:07:55 -0000

Provided below.  I will forward a copy of my annotated PDF file to the auth=
ors.  The PDF version also includes some minor corrections/suggestions whic=
h are not reproduced below.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

----------------------------------------------------------------
Comments on draft-ietf-eman-requirements-04
----------------------------------------------------------------

General Comments:

1. In general I think that both the requirements and the framework document=
s are looking much better.  Still room for improvement most likely but they=
 definitely seem to be much improved, IMHO.


Deatiled Comments:

> The basic objective of energy management is operating communication
> networks and other equipment with minimal amount of energy, while
> maintaining a certain level of service. (Page 8)

The focus of energy management is not specifically communications networks,=
 that is only one possible use of these standards.  Consider a less communi=
cations oriented point of view.  The main point is energy management, not e=
nergy management of communications networks.

> 5.2.5. List of supported power states (Page 13)

Are we envisioning having powered entities that support only a subset of th=
e declared power state sets?  How does this come about?  Is this an implica=
tion of supporting multiple power state sets concurrently and therefore the=
 need to map between them?=20

> 5.4.1. Real power (Page 16)

What is "real power"?

> Besides the real power, at least two out of the following
> three quantities need to be reported: apparent power, reactive power,
> phase angle. (Page 17)

What are "apparent power" and "reactive power"?

> 5.4.7. Actual AC frequency (Page 17)

For these parameters like "actual frequency" should we be reporting statist=
ical quantities such as max, min, average, std deviation, etc?

> 5.5.2. Time intervals (Page 19)

Should we include some examples for where the different reporting categorie=
s may apply?

> 5.6.2. Battery charging state (Page 20)

>From the title I would expect: "charged, discharged" -> "charging, discharg=
ing"

> 5.6.4. Actual battery capacity (Page 20)

I know that this has bounced back and forth between "actual" and "current" =
but actual seems like it might get confused with "nominal".  Perhaps consid=
er "available" or "remaining" instead?

> Even for self-managed powered entities such interface may be
> required for overruling local policy decisions by global ones from an
> energy management system. (Page 21)

Actually I believe that these interfaces would be useful for configuring lo=
cal policy parameters (especially for "headless" and "lights out" equipment=
 in networking data centers and central offices), in addition to allowing o=
verrides of the policies based on EnMS level decisions.

Consider:

Even for self-managed powered entities such interfaces may be
required for configuring local policy parameters and for overruling local p=
olicy decisions by global ones from an energy management system.

> Still, requirements for power state control apply accordingly to power su=
pply control. (Page 21)

I am not clear on what this sentence is trying to convey.  Please clarify i=
t.

> 7.7. Indicating source of remote information (Page 23)

Needs a different title.  This is a duplicate from 7.6 but it is talking ab=
out different information.

> 8.2. Controlling power supply of other powered entities (Page 24)

While I am following the meaning here clearly enough I recognize that I am =
already part of the choir so to speak and so I may follow it better than so=
meone who is not already familiar with the concepts.  All of these referenc=
es to "powered entity" get confusing because in each case there is a nuance=
 that is obvious to us but which is not being conveyed to the reader.

I wonder if the document might not benefit from making these nuances explic=
it by defining the concept of a "role" that powered entities can take on de=
pending on their context.  So, for example, we are talking about powered en=
tities that can control the power sources of other powered entities.  Might=
 we not refer to a powered entity which is playing this role as being a "Po=
werController"?  Other roles might be things like "PowerMonitor" or "PowerS=
ensor", "PowerGateway" for the case of proxies as they are being discussed =
here, and so forth.

> 8.2.1. Control of power supply of other powered entities (Page 25)

It seems that we should discuss here a bit the implications of turning a po=
wer outlet on and off when it is connected to multiple powered entities.  I=
n some cases it may not be possible to individually power on or off an indi=
vidual powered entity without affecting others.  This probably applies to o=
ther sections as well.

From jparello@cisco.com  Wed Jul 27 14:10:17 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CF921F884C for ; Wed, 27 Jul 2011 14:10:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.841
X-Spam-Level: 
X-Spam-Status: No, score=-2.841 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl7v566L7KRp for ; Wed, 27 Jul 2011 14:10:15 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EF2FB21F87FA for ; Wed, 27 Jul 2011 14:10:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=9968; q=dns/txt; s=iport; t=1311801012; x=1313010612; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=bCw8EORMcOLSp3YgSZnNMjAkHY+HZEHu3z2Xd/37syQ=; b=N7PKJwzGUC5P3D592cpRUDCFNpEwjO+e7CYNu2zJPMznJFMfQEZXhK3j r1AtJH+zoaUbfA8Zo9jNhW9fDcjeFtRZZL0nuruU3jwJGa8ka+xlaM9zz 6vK7iZjtLrbdgdCcAP20EDH/mS/PznHOKJQ5Q5yUWK4hVBKbjO2UkWhIm E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuAAAG99ME6rRDoH/2dsb2JhbAA0AQEBAQIBAQEBEQEhCjoEDAcDAgIBCREEAQELBg4BFAEGARMMDCMOCAEBBQEWDBuXXI9Id4h8BKMfnlwCgzQHgiRfBIdXkC6Lcg
X-IronPort-AV: E=Sophos;i="4.67,278,1309737600";  d="scan'208";a="7144561"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-9.cisco.com with ESMTP; 27 Jul 2011 21:10:04 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6RL9vSV025059; Wed, 27 Jul 2011 21:10:03 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 27 Jul 2011 14:09:58 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Jul 2011 14:09:17 -0700
Message-ID: 
In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7D8CA@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] Comments on draft-ietf-eman-framework-02
Thread-Index: AcxMG96vtMXWJqcnRJqCzFNHY9fx7wAdN/Dw
References: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7D8CA@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
From: "John Parello (jparello)" 
To: "Mielke, William F (Bill)" , "eman mailing list" 
X-OriginalArrivalTime: 27 Jul 2011 21:09:58.0528 (UTC) FILETIME=[8A93A800:01CC4CA1]
Subject: Re: [eman] Comments on draft-ietf-eman-framework-02
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 21:10:17 -0000

Hi Bill,

Thanks so much. I'll try to address the issues as much as possible in
the session. Please see in line


-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Mielke, William F (Bill)
Sent: Tuesday, July 26, 2011 10:13 PM
To: eman mailing list
Subject: [eman] Comments on draft-ietf-eman-framework-02

Provided below.  I will forward a copy of my annotated PDF file to the
authors.  The PDF version also includes some minor
corrections/suggestions which are not reproduced below.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

----------------------------------------------------------------
Comments on draft-ietf-eman-framework-02
----------------------------------------------------------------

General Comments:

1. Some portions of this document call out communications networks as a
subset of the larger energy management problem space.  It is not clear
to me why we are doing so.  Perhaps we should be writing from a less
communications network developer frame of mind?

[jp] yes I'll reword

2. What is the intended relationship between this document and the
Reference Model that Juergen and Bruce have been developing?  Does
their's replace this?  Augment it somehow?  What?  They seem to be
covering similar ground unless there is a nuance I am missing.

[jp] I'm confused by that myself. I try to make sure the framework can
cover all kinds of topologies so the one in the ref draft is clearly one
to cover.

Deatiled Comments:

> - IPFIX or not? (Page 3)

I am OK with IPFIX being identified as an appropriate choice for PUSH
mode time series data.  I would prefer not to preclude other options for
that as well, but I have none to offer at this time.  I feel that the
standard cannot mandate that compliant implementations include the use
of IPFIX so any mention of it must be considered optional, IMHO.  It's
use in diagrams as an example it likewise fine as long as this is made
clear.

[jp] agree we'll clarify=20

> EDITOR'S NOTE: [EMAN-MON-MIB] and [EMAN-AS] are not EMAN working
> group documents. Hence, these references will be changed in the
> future. (Page 5)

I am confused by this statement.  What are the implications here?  Will
these eventually become WG documents even though they are not officially
so now, or does it mean that their contents will be merged into
something else that IS a WG document?

[jp] They are not official wg documents yet but are the only ones
proposed so far as per the charter.

> For an Energy Management framework to be useful, it should also
> apply to these types of separate networks as they connect and
> interact with a communications network. (Page 6)

I understand the point being made here but I believe the presentation
can be simplified by simply declaring that there are two separate
networks: the power distribution network which is responsible for the
supply of electrical energy to various devices and their components, and
the control network which is used to to monitor and control the flow of
energy throughout the power distribution network.

In network management systems we frequently talk about there being a
"Data Plane" and a "Control Plan".  This is a similar concept to what we
have as well.

[jp] very good point I'll reword along these lines

> 3. Terminology (Page 6)

There seems to be an effort underway to standardize on some of this
terminology.  I assume that this section will be updated to be
consistent with the outcome of that effort.

> An Energy Managed Object (EMO) is a device that is part of or
> attached to a communications network that is monitored,
> controlled, or aids in the management of another device for
> Energy Management. (Page 8)

We seem to be focusing on the communications connectivity here rather
than the fact that and EMO is a powered device (i.e. connected to a
Power Distribution Network) whose energy consumption can be monitored
and controlled via a communications network (Control Network).

[jp]  yes also note though there can be multiple control networks.
Ethernet/ip and then serial/bacnet for example.

> Energy Managed Object Parent (Page 10)

As they are currently defined EMO Parent and EMO Child represent a type
of proxy relationship.  What is the difference between being a proxy for
an EMO and being an EMO Parent?  This distinction needs to be clarified
somehow.=20

[jp] OK I see your point I'll add clarification

> An Energy Managed Object Parent is an Energy Managed Object that
> provides one or more of the Energy Managed Object Relationships
> capabilities.  (Page 11)

I find this notion of "providing a capability" confusing.  What does it
mean for one EMO to "provide" a "capability" to (for?) another EMO.  I
don't understand the intended meaning here.

[jp] I meant to say is participating in a relationship. I'll present
that to clarify=20

> The framework addresses Energy Management but excludes Energy
> Procurement and the environmental impact of energy use. As such
> the framework does not include: (Page 14)

The energy management systems can be reasonably be envisioned to become
the central point for corporate reporting for both cost and
environmental impact especially where compliance to regulations is
concerned. We should have a plan for how these dimensions will be
accommodated.  At a minimum the EMO should optionally allow for the
setting and retention of an applicable set of attributes which can then
be read by other EnMS applications.

[jp] Ok do you want an arbitrary set of information or some formatted
ones? What types of data do you envision.


> An Energy Managed Object Child may inherit the domain value from an
Energy
> Managed Object Parent (Page 15)

I think that sub-domains need to be better thought out or clarified
here.  If an EMO is part of a subdomain it is not also part of the
encompassing domain as well?  This means that each EMO may actually be
part of multiple Energy Domains.  This seems to assume that the EMO is
only part of a single domain which will be determined by its closest
meter in the power distribution tree.  It is not yet clear to me that
this is the only and/or the correct way to look at it.

[jp] True it is simpler to map to one metered domain which is what I
implemented already. I've had people ask for multiple domains but when I
explain the complexity we've have no one push further. So the domain is
like a l2 broadcast domain on size and restriction not communication.

> Energy Managed Objects establish a parent and child relationship
> when one Energy Managed Object provides capabilities for another
> Energy Managed Object. (Page 18)

The notion of "capability" here seems ill defined, or at least not
intuitively obvious to me.  The relationships (capabilities?) mentioned
thus far are: Aggregation, Metering, Power Source, Proxy and Dependency.
I do not think of Aggregation, Proxy, or Dependency as being
"capabilities" which are provided.  I think we need to find a better way
of describing what it intended.

[jp] Yes relationship is better.

> Energy Managed Objects may have Manufacturer Power States Sets
> and can map these to the EMAN Power State Sets. (Page 26)

Given the introduction of IANA registered power state series I think
that this manufacturer power state sets discussion can be removed as it
appears to be no longer necessary or applicable.  Agreed?

[jp] I thought to leave it in to show how someone could use the existing
registered sets and not have to define a new one. I thought to remove it
as well but I thought someone might think they need to create a set for
every device and manufacturer.=20

> powerMonitorId | UUID (Page 29)

Needs to be adjusted given the changes in terminology section(s) ...
e.g. we have done away with the term Power Monitor.

[jp] yes thanks I'll remove.

> | manufacturerLevels[0..n]: State |
> | emanLevels[0..11] : State | (Page 33)

These require some adjustment given the adoption of power state series.

> When an Energy Managed Object requires a mapping with the
> Manufacturer Power State, the Energy Managed Object
> configuration is done via the Power State settings, and not
> directly via the Manufacturer Power States, which are read-only.
> Taking into account Figure 7, where the LowMinus Power State
> corresponds to three different Manufacturer Power States (11 for
> 1%, 12 for 2%, and 13 for 3%), the implication is that this
> framework will not set the Manufacturer Power State to one
> percent granularity without communicating over or configuring
> the proprietary protocol for this Energy Managed Object. (Page 34)

I think that this section can be removed given the introduction of the
IANA registered Power State Series.  I believe that this is no longer
relevant.

[jp] ok

> Note that the Wake-up-on-Lan (WoL)
> mechanism allows to transition a device out of the Off Power
> State. (Page 34)

Seems out of place somehow.  It seem logically unconnected with the rest
of the paragraph.

[jp] Yes I'll move. IIRC we were trying to call out WoL type protocols
since they inevitably come up when we discuss states.=20

> 8. Fault Management (Page 34)

I am not clear on what this section is trying to convey.  Additional
clarification is required.

[jp] I'll remove we have things addresses now in the requirements so
this was left over before we had that draft.
_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman

From ietf@quittek.at  Wed Jul 27 14:42:21 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8255D11E8161 for ; Wed, 27 Jul 2011 14:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.156
X-Spam-Level: 
X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.093,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-dukW2tpvFW for ; Wed, 27 Jul 2011 14:42:20 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8A111E8156 for ; Wed, 27 Jul 2011 14:42:20 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lo5FM-1RJ4q10qS0-00gCYs; Wed, 27 Jul 2011 23:42:18 +0200
References: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DB80@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DB80@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <86E69423-FF59-449A-BD7F-E8C44732BC5D@quittek.at>
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Wed, 27 Jul 2011 17:42:15 -0400
To: "Mielke, William F (Bill)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:/zNXIF5MX3ZLoMyc05b/SWkJGwxTD6BhRzzZPFRFjul XheYJvGQppsGhTtrllbEdR/d7rSSumbVSI1VKKHQnZLMgk3ujd 3/D6eRzl44fSjmZqSiB1KY/5h1eU9mhjPE2MIEq7XQWvW0femg 9S2YwlpBrE/TVo/3vELnVuf02f7B6u8yPD7A39kAAyO7tU5nsw byV1/KK5MhxxFjpwdeGQeW2p2wu+5qp6ujld6IPiPg=
Cc: eman mailing list 
Subject: Re: [eman] Comments on draft-ietf-eman-requirements-04
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 21:42:21 -0000

Hi Bill,

Thank you for all your comments.
Please find replies inline.

Am 27.07.2011 um 16:07 schrieb Mielke, William F (Bill):

> Provided below.  I will forward a copy of my annotated PDF file to the =
authors.  The PDF version also includes some minor =
corrections/suggestions which are not reproduced below.
>=20
> William F. Mielke
> Alcatel-Lucent
> Distinguished Member of Technical Staff
> 6200 East Broad Street
> Room: 4B01-1V
> Columbus, OH  43213-1530
> Email: Bill.Mielke@alcatel-lucent.com
> Phone: 614 367 5628
> Fax: 614 367 5965
>=20
> "Live like you're going to die tomorrow.
> Learn like you're going to live forever."
>=20
>    - Albert Einstein
>=20
> ----------------------------------------------------------------
> Comments on draft-ietf-eman-requirements-04
> ----------------------------------------------------------------
>=20
> General Comments:
>=20
> 1. In general I think that both the requirements and the framework =
documents are looking much better.  Still room for improvement most =
likely but they definitely seem to be much improved, IMHO.
>=20
>=20
> Deatiled Comments:
>=20
>> The basic objective of energy management is operating communication
>> networks and other equipment with minimal amount of energy, while
>> maintaining a certain level of service. (Page 8)
>=20
> The focus of energy management is not specifically communications =
networks, that is only one possible use of these standards.  Consider a =
less communications oriented point of view.  The main point is energy =
management, not energy management of communications networks.

Right. This needs to be changed.

>> 5.2.5. List of supported power states (Page 13)
>=20
> Are we envisioning having powered entities that support only a subset =
of the declared power state sets?  How does this come about?  Is this an =
implication of supporting multiple power state sets concurrently and =
therefore the need to map between them?=20

This is a good question. A device that does only have a number of, say, =
five different power states may want to support the DMTF set of power =
states. What should it do?=20

Should it pretend to support all DMTF power states?
Should it list only the five states that it really supports?
What if a management station tries to set the device to a state that is =
not supported?

>=20
>> 5.4.1. Real power (Page 16)
>=20
> What is "real power"?

When using AC the power is in general described by a complex number.
It has a real component called real power or active power.
It has an imaginary component called reactive power.
The combination of both is the complex power.
The apparent power is the absolute value of the complex power.

You get to complex power when the sinusoidal voltage and current are not =
in synch.
The deviation between their cycles is indicated by a phase angle of the =
current compared to the voltage.
Finally, there is the power factor which is the ration between real and =
apparent power.
For most devices in telecommunications the power factor is close to 1.
Note that the power factor does not necessarily indicate efficiency of a =
device.=20
=20
>> Besides the real power, at least two out of the following
>> three quantities need to be reported: apparent power, reactive power,
>> phase angle. (Page 17)
>=20
> What are "apparent power" and "reactive power"?
>=20
>> 5.4.7. Actual AC frequency (Page 17)
>=20
> For these parameters like "actual frequency" should we be reporting =
statistical quantities such as max, min, average, std deviation, etc?

Maybe. I am not an expert for power quality.
Is there someone on the list who has experience with this?

>> 5.5.2. Time intervals (Page 19)
>=20
> Should we include some examples for where the different reporting =
categories may apply?

Good idea.
I would be grateful if anybody provides text.

>> 5.6.2. Battery charging state (Page 20)
>=20
> =46rom the title I would expect: "charged, discharged" -> "charging, =
discharging"

Right. This needs to be fixed.

>> 5.6.4. Actual battery capacity (Page 20)
>=20
> I know that this has bounced back and forth between "actual" and =
"current" but actual seems like it might get confused with "nominal".  =
Perhaps consider "available" or "remaining" instead?

We got more comments suggesting to call it remaining,=20
Let's switch to remaining as long as nobody objects.

>> Even for self-managed powered entities such interface may be
>> required for overruling local policy decisions by global ones from an
>> energy management system. (Page 21)
>=20
> Actually I believe that these interfaces would be useful for =
configuring local policy parameters (especially for "headless" and =
"lights out" equipment in networking data centers and central offices), =
in addition to allowing overrides of the policies based on EnMS level =
decisions.
>=20
> Consider:
>=20
> Even for self-managed powered entities such interfaces may be
> required for configuring local policy parameters and for overruling =
local policy decisions by global ones from an energy management system.

Sounds good. Let's make this change if nobody objects.

>> Still, requirements for power state control apply accordingly to =
power supply control. (Page 21)
>=20
> I am not clear on what this sentence is trying to convey.  Please =
clarify it.

Right. This sentence needs to be changed or removed.

>> 7.7. Indicating source of remote information (Page 23)
>=20
> Needs a different title.  This is a duplicate from 7.6 but it is =
talking about different information.

I think what we need here is "source" --> "content"

>> 8.2. Controlling power supply of other powered entities (Page 24)
>=20
> While I am following the meaning here clearly enough I recognize that =
I am already part of the choir so to speak and so I may follow it better =
than someone who is not already familiar with the concepts.  All of =
these references to "powered entity" get confusing because in each case =
there is a nuance that is obvious to us but which is not being conveyed =
to the reader.
>=20
> I wonder if the document might not benefit from making these nuances =
explicit by defining the concept of a "role" that powered entities can =
take on depending on their context.  So, for example, we are talking =
about powered entities that can control the power sources of other =
powered entities.  Might we not refer to a powered entity which is =
playing this role as being a "PowerController"?  Other roles might be =
things like "PowerMonitor" or "PowerSensor", "PowerGateway" for the case =
of proxies as they are being discussed here, and so forth.

This would make things clearer here. But it would need to introduce all =
of this terminology.
Let's see if we find an easy way for making things easier.

>> 8.2.1. Control of power supply of other powered entities (Page 25)
>=20
> It seems that we should discuss here a bit the implications of turning =
a power outlet on and off when it is connected to multiple powered =
entities.  In some cases it may not be possible to individually power on =
or off an individual powered entity without affecting others.  This =
probably applies to other sections as well.

Right. In which sections do you think we should mention this?=20
Or do you think that we should list the other sections?

Thanks,

    Juergen

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


From bclaise@cisco.com  Wed Jul 27 20:22:52 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2693911E817E for ; Wed, 27 Jul 2011 20:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.484
X-Spam-Level: 
X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fy+42j9-9Gl for ; Wed, 27 Jul 2011 20:22:51 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9B511E80B0 for ; Wed, 27 Jul 2011 20:22:51 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6S3Mn7n028379 for ; Thu, 28 Jul 2011 05:22:49 +0200 (CEST)
Received: from [10.86.251.97] (bxb-vpn3-865.cisco.com [10.86.251.97]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6S3MjhU026118 for ; Thu, 28 Jul 2011 05:22:46 +0200 (CEST)
Message-ID: <4E30D605.6000400@cisco.com>
Date: Wed, 27 Jul 2011 23:22:45 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: eman mailing list 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [eman] [EMAN-BATTERY]: power state set
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 03:22:52 -0000

Dear all,

A quick review of the battery-mib leads me to this observation

    batteryChargingState OBJECT-TYPE
        SYNTAX      INTEGER {
                        unknown(1),
                        charging(2),
                        maintainingCharge(3),
                        noCharging(4),
                        discharging(5)
                    }

This is power state set, right? Ok, battery specific, but a power state 
set anyway, right?
Since we will have three power state sets in IANA (IEEE1621, DMTF, and 
EMAN), why not register this one in IANA? Maybe in the future, we might 
need an extra battery state.

Next question: is this power state set comparable to the existing power 
state set?
I mean, should a powered device (in the case a battery) advertise that 
it support the battery charging state power state set?
This would have the advantage that a NMS would discover powered devices, 
components, and batteries exactly the same way.

Regards, Benoit.


From jparello@cisco.com  Wed Jul 27 20:33:18 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F321221F8880 for ; Wed, 27 Jul 2011 20:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.829
X-Spam-Level: 
X-Spam-Status: No, score=-2.829 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOGEDHKugRby for ; Wed, 27 Jul 2011 20:33:17 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3885421F88A5 for ; Wed, 27 Jul 2011 20:33:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=1684; q=dns/txt; s=iport; t=1311823997; x=1313033597; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=yIG75sMd8ZTs5wtZrQ1LsvA/app+7s5YeuZ6dFIUIOo=; b=TDVMqxhx8sV/opu6/VR+o6Ne11VRIXdgGCD0shj7lvKbjwE6nxzoSxE+ YxlSVnJzIWZtEQ4A7x5lsjxJuRcDC7RhdZrrf39QrkzXJ/Tfkkx72ZVEA Ww92QuRBjydgRFDzbPIVZZmFeXt4+etVZsPQv9WZHJhmKU33iWj5srdOz E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0AAE3YME6rRDoH/2dsb2JhbAA0AQEBAQMBAQERASEKOhcFAgEJEQQBAQsGIwEGARMYIw4IAQEFARYMG5dfj0l3iQCkO55QhWFfBIdXkC6Lcg
X-IronPort-AV: E=Sophos;i="4.67,279,1309737600";  d="scan'208";a="7235856"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jul 2011 03:33:16 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6S3XGTo015630 for ; Thu, 28 Jul 2011 03:33:16 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 27 Jul 2011 20:33:16 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Jul 2011 20:32:31 -0700
Message-ID: 
In-Reply-To: <4E30D605.6000400@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] [EMAN-BATTERY]: power state set
Thread-Index: AcxM1aVDGkJ+Z4xkQnW+my8Esv9/ZQAARqnQ
References: <4E30D605.6000400@cisco.com>
From: "John Parello (jparello)" 
To: "Benoit Claise (bclaise)" , "eman mailing list" 
X-OriginalArrivalTime: 28 Jul 2011 03:33:16.0129 (UTC) FILETIME=[16371510:01CC4CD7]
Subject: Re: [eman] [EMAN-BATTERY]: power state set
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 03:33:18 -0000

That would be good. That solves and issue we discussed in Prague about a
device that has a battery but does not want to expose it as a component
or part. Like a tablet with non removable battery.

The device could simply support the power state series at the same time.

Nice

+1




-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Benoit Claise (bclaise)
Sent: Wednesday, July 27, 2011 8:23 PM
To: eman mailing list
Subject: [eman] [EMAN-BATTERY]: power state set

Dear all,

A quick review of the battery-mib leads me to this observation

    batteryChargingState OBJECT-TYPE
        SYNTAX      INTEGER {
                        unknown(1),
                        charging(2),
                        maintainingCharge(3),
                        noCharging(4),
                        discharging(5)
                    }

This is power state set, right? Ok, battery specific, but a power state=20
set anyway, right?
Since we will have three power state sets in IANA (IEEE1621, DMTF, and=20
EMAN), why not register this one in IANA? Maybe in the future, we might=20
need an extra battery state.

Next question: is this power state set comparable to the existing power=20
state set?
I mean, should a powered device (in the case a battery) advertise that=20
it support the battery charging state power state set?
This would have the advantage that a NMS would discover powered devices,

components, and batteries exactly the same way.

Regards, Benoit.

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

From bclaise@cisco.com  Wed Jul 27 20:41:14 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4943D21F8B3A for ; Wed, 27 Jul 2011 20:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level: 
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NV7YNN0EYkNT for ; Wed, 27 Jul 2011 20:41:13 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7B38D21F8B39 for ; Wed, 27 Jul 2011 20:41:13 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6S3bRbs000132 for ; Thu, 28 Jul 2011 05:37:27 +0200 (CEST)
Received: from [10.86.251.97] (bxb-vpn3-865.cisco.com [10.86.251.97]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6S3bHkG003072; Thu, 28 Jul 2011 05:37:18 +0200 (CEST)
Message-ID: <4E30D96D.5060907@cisco.com>
Date: Wed, 27 Jul 2011 23:37:17 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "John Parello (jparello)" 
References: <4E30D605.6000400@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: eman mailing list 
Subject: Re: [eman] [EMAN-BATTERY]: power state set
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 03:41:14 -0000

Yes, and the UUID is the only thing that is important.
So an UUID whatever the powered device (or whatever the right term is): 
a device, a port, a component, a battery, or something.

Regards, Benoit (as a contributor)
> That would be good. That solves and issue we discussed in Prague about a
> device that has a battery but does not want to expose it as a component
> or part. Like a tablet with non removable battery.
>
> The device could simply support the power state series at the same time.
>
> Nice
>
> +1
>
>
>
>
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> Benoit Claise (bclaise)
> Sent: Wednesday, July 27, 2011 8:23 PM
> To: eman mailing list
> Subject: [eman] [EMAN-BATTERY]: power state set
>
> Dear all,
>
> A quick review of the battery-mib leads me to this observation
>
>      batteryChargingState OBJECT-TYPE
>          SYNTAX      INTEGER {
>                          unknown(1),
>                          charging(2),
>                          maintainingCharge(3),
>                          noCharging(4),
>                          discharging(5)
>                      }
>
> This is power state set, right? Ok, battery specific, but a power state
> set anyway, right?
> Since we will have three power state sets in IANA (IEEE1621, DMTF, and
> EMAN), why not register this one in IANA? Maybe in the future, we might
> need an extra battery state.
>
> Next question: is this power state set comparable to the existing power
> state set?
> I mean, should a powered device (in the case a battery) advertise that
> it support the battery charging state power state set?
> This would have the advantage that a NMS would discover powered devices,
>
> components, and batteries exactly the same way.
>
> Regards, Benoit.
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From bclaise@cisco.com  Wed Jul 27 21:46:49 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C90721F8AFD for ; Wed, 27 Jul 2011 21:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.488
X-Spam-Level: 
X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.110,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acTYo0lKIuam for ; Wed, 27 Jul 2011 21:46:48 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C8DFF21F8AF9 for ; Wed, 27 Jul 2011 21:46:47 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6S4dEd5007381; Thu, 28 Jul 2011 06:39:14 +0200 (CEST)
Received: from [10.86.251.97] (bxb-vpn3-865.cisco.com [10.86.251.97]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6S4dCj9003286; Thu, 28 Jul 2011 06:39:13 +0200 (CEST)
Message-ID: <4E30E7F0.8040907@cisco.com>
Date: Thu, 28 Jul 2011 00:39:12 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Juergen Quittek 
References: <20110304190215.GA5072@cslinux-build01.cyberswitching.local>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090409060406040503000603"
Cc: chrisv@cyberswitching.com, eman@ietf.org
Subject: Re: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 04:46:49 -0000

This is a multi-part message in MIME format.
--------------090409060406040503000603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 27/07/2011 14:13, Juergen Quittek wrote:
> Dear all,
>
> Would we have a requirement for output gangs to be added to the requirements draft?
Actually, I thought we had this already but, after checking, it's not in 
the latest version...
After some investigation, I found it back in the version 01, 
http://tools.ietf.org/html/draft-ietf-eman-requirements-01

2.9  .  Scenario 9: Ganged outlets on a smart power strip  . . . .9    

But this scenario moved to the 
http://tools.ietf.org/html/draft-tychon-eman-applicability-statement-02#section-2.8

To make a long story short, I believe we should clearly mention it in 
[EMAN-REQ], covering the request from PDU vendors on the list.

Regards, Benoit.
>
> Thanks,
>
>      Juergen
>
>
> Am 27.07.2011 um 14:08 schrieb John Parello (jparello):
>
>> Hi Chris, and list...
>>
>> Following up on this wrt to the new framework draft and recent activity
>> on the list. We've added a set of relationships like metering, powered
>> by.
>>
>> Do you think it would be good to add a relationship like 'ganged' to map
>> managed elements to the same gang?
>>
>> The relationship methphor is quite simple and if we cal this out it
>> could model what you have in mind.
>>
>> Jp
>>
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
>> chrisv@cyberswitching.com
>> Sent: Friday, March 04, 2011 11:02 AM
>> To: eman@ietf.org
>> Subject: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00
>>
>> Hi Juergen,
>>
>> I wrote an additon to the various scenarios described in
>> draft-ietf-eman-requirements-00 to address the "Outlet Gang" scenario
>> found on Smart PDUs.  Please let me know if you have any questions while
>> integrating it.
>>
>> $ diff draft-ietf-eman-requirements-00.txt
>> draft-ietf-eman-requirements-01.txt
>> 416a417,449
>>> 2.9.  Scenario 9: Ganged outlets on a Smart Power Strip
>>>
>>>    Some PDUs allow physical entities like outlets to be "ganged"
>> together as a
>>>    logical entity for simplified management purposes.  This is
>> particularly
>>>    useful for servers with multiple power supplies, where each power
>> supply is
>>>    connected to a different physical outlet.  Other implementations
>> allow
>>>    "gangs" to be created based on common ownership of outlets, such as
>>>    business units or load shed priority or other non-physical
>> relationships.
>>>    Current implementations allow for an "M-to-N" mapping between
>> outlet
>>>    "gangs" and physical outlets.  An example of this mapping includes
>> the
>>>    following:
>>>
>>>       Outlet 1             (physical entity)
>>>       Outlet 2             (physical entity)
>>>       Outlet 3             (physical entity)
>>>       Outlet 4             (physical entity)
>>>       Outlet Gang A        (virtual entity)
>>>       Outlet Gang B        (virtual entity)
>>>
>>>       Gang A ->  Outlets 1, 2 and 3
>>>       Gang B ->  Outlets 3 and 4
>>>
>>>    Note the allowed overlap on Outlet 3, where Outlet 3 belongs to
>> both
>>>    "gangs."
>>>
>>>    Each "Outlet Gang" entity reports the aggregated data from the
>> individual
>>>    outlet entities that comprise it and enables a single point of
>> control for
>>>    all the individual outlet entities.  For example, turning "Outlet
>> Gang A"
>>>    to the "off" state would turn outlets 1, 2, and 3 "off" in some
>>>    implementations.  (The impact of this action on "Outlet Gang B" is
>> to be
>>>    defined by the equipment manufacturer.)
>>>
>> Thanks,
>> Chris
>> _______________________________________________
>> 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


--------------090409060406040503000603
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 27/07/2011 14:13, Juergen Quittek wrote:
    

      
Dear all,

Would we have a requirement for output gangs to be added to the requirements draft?

    

    Actually, I thought we had this already but, after checking, it's
    not in the latest version...

    After some investigation, I found it back in the version 01,
    http://tools.ietf.org/html/draft-ietf-eman-requirements-01

    
2.9.  Scenario 9: Ganged outlets on a smart power strip  . . . .  9 

    But this scenario moved to the
http://tools.ietf.org/html/draft-tychon-eman-applicability-statement-02#section-2.8

    

    To make a long story short, I believe we should clearly mention it
    in [EMAN-REQ], covering the request from PDU vendors on the list.

    

    Regards, Benoit.

    

      

Thanks,

    Juergen


Am 27.07.2011 um 14:08 schrieb John Parello (jparello):



      

        
Hi Chris, and list...

Following up on this wrt to the new framework draft and recent activity
on the list. We've added a set of relationships like metering, powered
by.

Do you think it would be good to add a relationship like 'ganged' to map
managed elements to the same gang?

The relationship methphor is quite simple and if we cal this out it
could model what you have in mind.

Jp

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
chrisv@cyberswitching.com
Sent: Friday, March 04, 2011 11:02 AM
To: eman@ietf.org
Subject: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00

Hi Juergen,

I wrote an additon to the various scenarios described in
draft-ietf-eman-requirements-00 to address the "Outlet Gang" scenario
found on Smart PDUs.  Please let me know if you have any questions while
integrating it.

$ diff draft-ietf-eman-requirements-00.txt
draft-ietf-eman-requirements-01.txt
416a417,449


        

          
2.9.  Scenario 9: Ganged outlets on a Smart Power Strip

  Some PDUs allow physical entities like outlets to be "ganged"


        

        
together as a


        

          
  logical entity for simplified management purposes.  This is


        

        
particularly


        

          
  useful for servers with multiple power supplies, where each power


        

        
supply is


        

          
  connected to a different physical outlet.  Other implementations


        

        
allow


        

          
  "gangs" to be created based on common ownership of outlets, such as
  business units or load shed priority or other non-physical


        

        
relationships.


        

          
  Current implementations allow for an "M-to-N" mapping between


        

        
outlet


        

          
  "gangs" and physical outlets.  An example of this mapping includes


        

        
the


        

          
  following:

     Outlet 1             (physical entity)
     Outlet 2             (physical entity)
     Outlet 3             (physical entity)
     Outlet 4             (physical entity)
     Outlet Gang A        (virtual entity)
     Outlet Gang B        (virtual entity)

     Gang A -> Outlets 1, 2 and 3
     Gang B -> Outlets 3 and 4

  Note the allowed overlap on Outlet 3, where Outlet 3 belongs to


        

        
both


        

          
  "gangs."

  Each "Outlet Gang" entity reports the aggregated data from the


        

        
individual


        

          
  outlet entities that comprise it and enables a single point of


        

        
control for


        

          
  all the individual outlet entities.  For example, turning "Outlet


        

        
Gang A"


        

          
  to the "off" state would turn outlets 1, 2, and 3 "off" in some
  implementations.  (The impact of this action on "Outlet Gang B" is


        

        
to be


        

          
  defined by the equipment manufacturer.)



        

        
Thanks,
Chris
_______________________________________________
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


    

    

  


--------------090409060406040503000603--

From bnordman@lbl.gov  Wed Jul 27 21:56:17 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A297E21F8B42 for ; Wed, 27 Jul 2011 21:56:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.819
X-Spam-Level: 
X-Spam-Status: No, score=-5.819 tagged_above=-999 required=5 tests=[AWL=0.157,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M57b2IGs3QeJ for ; Wed, 27 Jul 2011 21:56:17 -0700 (PDT)
Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDC121F8B3F for ; Wed, 27 Jul 2011 21:56:16 -0700 (PDT)
X-Ironport-SBRS: 4.4
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0BAJXrME7RVaG0kGdsb2JhbAA0AQEBAQIBFAJhDhEMBAcDKRsUExMBBQEkBxcMG4I2nFoBiBQIFAEBAQEJCQ0HFAQhiHyldQqdHIM9gwQEknmMTDyDeA
X-IronPort-AV: E=Sophos;i="4.67,280,1309762800"; d="scan'208";a="47092377"
Received: from mail-gx0-f180.google.com ([209.85.161.180]) by ironport4.lbl.gov with ESMTP; 27 Jul 2011 21:56:16 -0700
Received: by gxk10 with SMTP id 10so2332386gxk.39 for ; Wed, 27 Jul 2011 21:56:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.159.4 with SMTP id l4mr425386ano.148.1311828975781; Wed, 27 Jul 2011 21:56:15 -0700 (PDT)
Received: by 10.100.241.8 with HTTP; Wed, 27 Jul 2011 21:56:15 -0700 (PDT)
In-Reply-To: <86E69423-FF59-449A-BD7F-E8C44732BC5D@quittek.at>
References: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DB80@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <86E69423-FF59-449A-BD7F-E8C44732BC5D@quittek.at>
Date: Thu, 28 Jul 2011 00:56:15 -0400
Message-ID: 
From: Bruce Nordman 
To: Juergen Quittek 
Content-Type: multipart/alternative; boundary=001636eefcac1b86bd04a919fc9a
Cc: eman mailing list 
Subject: Re: [eman] Comments on draft-ietf-eman-requirements-04
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 04:56:17 -0000

--001636eefcac1b86bd04a919fc9a
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jul 27, 2011 at 5:42 PM, Juergen Quittek  wrote:

> ...
>
> >> 5.2.5. List of supported power states (Page 13)
> >
> > Are we envisioning having powered entities that support only a subset of
> the declared power state sets?  How does this come about?  Is this an
> implication of supporting multiple power state sets concurrently and
> therefore the need to map between them?
>
> This is a good question. A device that does only have a number of, say,
> five different power states may want to support the DMTF set of power
> states. What should it do?
>
> Should it pretend to support all DMTF power states?
> Should it list only the five states that it really supports?
> What if a management station tries to set the device to a state that is not
> supported?
>

This is already true today.  While ACPI defines S1 and S2, I am not aware
that
any products actually implement them.  So, supporting fewer power states
than are defined is the norm, not the exception.


> ...
> >> 5.4.7. Actual AC frequency (Page 17)
> >
> > For these parameters like "actual frequency" should we be reporting
> statistical quantities such as max, min, average, std deviation, etc?
>
>
> Maybe. I am not an expert for power quality.
> Is there someone on the list who has experience with this?
>

Does anyone have a use case for this?  Wouldn't the AC frequency be
shared by the whole building?  I am willing to believe there is a use case,
but I expect it is rare.

--Bruce



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

--001636eefcac1b86bd04a919fc9a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Wed, Jul 27, 2011 at 5:42 PM, Juergen=
 Quittek <ietf@quit=
tek.at> wrote:

...




>> 5.2.5. List of supported power states (Page 13)

>

> Are we envisioning having powered entities that support only a subset =
of the declared power state sets? =A0How does this come about? =A0Is this a=
n implication of supporting multiple power state sets concurrently and ther=
efore the need to map between them?





This is a good question. A device that does only have a number of, sa=
y, five different power states may want to support the DMTF set of power st=
ates. What should it do?



Should it pretend to support all DMTF power states?

Should it list only the five states that it really supports?

What if a management station tries to set the device to a state that is not=
 supported?

This is already true today.=A0 While A=
CPI defines S1 and S2, I am not aware that
any products actually impleme=
nt them.=A0 So, supporting fewer power states

than are defined is the norm, not the exception.
=A0
...

>> 5.4.7. Actual AC frequency (Page 17)

>

> For these parameters like "actual frequency" should we be re=
porting statistical quantities such as max, min, average, std deviation, et=
c?





Maybe. I am not an expert for power quality.

Is there someone on the list who has experience with this?
=

=A0
Does anyone have a use case for this?=A0 Wouldn't th=
e AC frequency be
shared by the whole building?=A0 I am willing to belie=
ve there is a use case,

but I expect it is rare.=A0 

--Bruce 

=


-- 
Bruce NordmanLawrence Berkeley National Laborator=
y

eetd.lbl.gov/e=
a/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943


--001636eefcac1b86bd04a919fc9a--

From ietf@quittek.at  Thu Jul 28 05:42:58 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D910621F8B7F for ; Thu, 28 Jul 2011 05:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.161
X-Spam-Level: 
X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.088,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbWVDsVNr19X for ; Thu, 28 Jul 2011 05:42:58 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id F0EFE21F8B02 for ; Thu, 28 Jul 2011 05:42:57 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0May0k-1R6gry0lAY-00KQAz; Thu, 28 Jul 2011 14:42:56 +0200
References: <4E30D605.6000400@cisco.com>
In-Reply-To: <4E30D605.6000400@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: 
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Thu, 28 Jul 2011 08:42:54 -0400
To: Benoit Claise 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:+oLXfZa/b9sMc0W8Ci/B11Z5VI/PwhcrEVfO0IBNSAN I3xMVmEWU/MABYl8iuV8S2UpyDsKeNRQ9TgFuJrfZiKyKfjPSU 4Prfe1Zj72dxZ3EeDtgHVDe6YQ5QzkDiSw3QjK6vK++GAmxod1 REAeJLSzZFKJC/4iOmKWjXWbgCOurp8K8jbv5BouCkYHGPqj9V qDWx2a75yjLR21EYq6iKVWsVkoNJXLuiZ33TF5VcUI=
Cc: eman mailing list 
Subject: Re: [eman] [EMAN-BATTERY]: power state set
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 12:42:59 -0000

Hi Benoit,

I like the idea.=20

However, before fully committing to it I would like to think more about =
the following:

pro: It IS a power state because it describes the power-relevant =
behavior/state of the battery.

con: It is NOT a power state, because it dies not yet cover something =
like an "off" state.
Maybe we can solve this by adding non-operational states to the current =
list of battery states.
Also we may have to rename it. Because then it is not just a charging =
state anymore.

Thanks,

    Juergen

Am 27.07.2011 um 23:22 schrieb Benoit Claise:

> Dear all,
>=20
> A quick review of the battery-mib leads me to this observation
>=20
>   batteryChargingState OBJECT-TYPE
>       SYNTAX      INTEGER {
>                       unknown(1),
>                       charging(2),
>                       maintainingCharge(3),
>                       noCharging(4),
>                       discharging(5)
>                   }
>=20
> This is power state set, right? Ok, battery specific, but a power =
state set anyway, right?
> Since we will have three power state sets in IANA (IEEE1621, DMTF, and =
EMAN), why not register this one in IANA? Maybe in the future, we might =
need an extra battery state.
>=20
> Next question: is this power state set comparable to the existing =
power state set?
> I mean, should a powered device (in the case a battery) advertise that =
it support the battery charging state power state set?
> This would have the advantage that a NMS would discover powered =
devices, components, and batteries exactly the same way.
>=20
> Regards, Benoit.
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From ietf@quittek.at  Thu Jul 28 05:46:20 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF95D21F8BD6 for ; Thu, 28 Jul 2011 05:46:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Level: 
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.083,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hP78ldyJQxR9 for ; Thu, 28 Jul 2011 05:46:20 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 38B8B21F86AC for ; Thu, 28 Jul 2011 05:46:20 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LmgXX-1RM1mN2X4N-00aFaV; Thu, 28 Jul 2011 14:46:17 +0200
References: <4E30D605.6000400@cisco.com> 
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <8F79AC58-23C4-4D5C-BB61-CADBAD084612@quittek.at>
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Thu, 28 Jul 2011 08:46:15 -0400
To: "John Parello (jparello)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:nqQRay/TOYSQT2bsQd8OB+VjEPZNbYZ9fBXTuH6U9Pg ejXcIhi1jlRfigU92QWrfsXBHin3bpq1hS1yW0Cn+P3fYKqaJh 39mTtMAuhz7NkIffjtH6oBlvGNTwgrkexPwvgsXqcDnNaFvk92 4q3sBB6DaHkzWjrT0Ss6sCJf38GxggG+6RNjVTNsbpaOFaYLaz U6b0cUoZM/JXV9/uvZRm+YV0inX1vKiy3ejLGvPBVg=
Cc: eman mailing list 
Subject: Re: [eman] [EMAN-BATTERY]: power state set
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 12:46:21 -0000

Hi John,

Am 27.07.2011 um 23:32 schrieb John Parello (jparello):

> That would be good. That solves and issue we discussed in Prague about =
a
> device that has a battery but does not want to expose it as a =
component
> or part. Like a tablet with non removable battery.
>=20
> The device could simply support the power state series at the same =
time.

I disagree.

I don't think that this is in line with the idea of supporting multiple =
power states.

If a device supports multiple power state series, they must carry the =
same=20
of at least equivalent semantics. Otherwise you would have to read all =
series
in order to understand the device's state.

Thanks,

    Juergen

>=20
> Nice
>=20
> +1
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of
> Benoit Claise (bclaise)
> Sent: Wednesday, July 27, 2011 8:23 PM
> To: eman mailing list
> Subject: [eman] [EMAN-BATTERY]: power state set
>=20
> Dear all,
>=20
> A quick review of the battery-mib leads me to this observation
>=20
>    batteryChargingState OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        unknown(1),
>                        charging(2),
>                        maintainingCharge(3),
>                        noCharging(4),
>                        discharging(5)
>                    }
>=20
> This is power state set, right? Ok, battery specific, but a power =
state=20
> set anyway, right?
> Since we will have three power state sets in IANA (IEEE1621, DMTF, and=20=

> EMAN), why not register this one in IANA? Maybe in the future, we =
might=20
> need an extra battery state.
>=20
> Next question: is this power state set comparable to the existing =
power=20
> state set?
> I mean, should a powered device (in the case a battery) advertise that=20=

> it support the battery charging state power state set?
> This would have the advantage that a NMS would discover powered =
devices,
>=20
> components, and batteries exactly the same way.
>=20
> Regards, Benoit.
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From ietf@quittek.at  Thu Jul 28 05:47:30 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEB021F8C2D for ; Thu, 28 Jul 2011 05:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.17
X-Spam-Level: 
X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 W4-ATui4zUPp for ; Thu, 28 Jul 2011 05:47:29 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1073321F8C2C for ; Thu, 28 Jul 2011 05:47:29 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MOVaj-1Qipcl0Q6v-005tNC; Thu, 28 Jul 2011 14:47:23 +0200
References: <20110304190215.GA5072@cslinux-build01.cyberswitching.local>   <4E30E7F0.8040907@cisco.com>
In-Reply-To: <4E30E7F0.8040907@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-6-690074821
Message-Id: <5F08E40E-38C4-4DE2-932B-B5C3DC4DFC2F@quittek.at>
From: Juergen Quittek 
Date: Thu, 28 Jul 2011 08:47:20 -0400
To: Benoit Claise 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:Dbvu3k4hrzNpex3EQgAUX3a6uojSHrFmGstQ8NshNYI TA3d8888iWw6bv6vkS5uaKS/9rF/6yvtsIl5RAJk+1w5xsTooA sTxLfeO+R7tEEEP/3yhf1WNycG3I5JTkSB649+/EzVzCBA+R9a g3eSdh1zAVt4Hdjjczx5RKSTtCoUIvCzCYYqznOxRP1nBMJ/RQ irhQk5vt6sHqskWZL4eiJ1bPXS5K7lR6x23Ko72598=
Cc: chrisv@cyberswitching.com, eman@ietf.org
Subject: Re: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 12:47:30 -0000

--Apple-Mail-6-690074821
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I agree.

Can please somebody who was involved in the discussion about outlet =
gangs come up with a text proposal for this missing requirement?

Thanks,

    Juergen

Am 28.07.2011 um 00:39 schrieb Benoit Claise:

> On 27/07/2011 14:13, Juergen Quittek wrote:
>>=20
>> Dear all,
>>=20
>> Would we have a requirement for output gangs to be added to the =
requirements draft?
> Actually, I thought we had this already but, after checking, it's not =
in the latest version...
> After some investigation, I found it back in the version 01, =
http://tools.ietf.org/html/draft-ietf-eman-requirements-01
> 2.9.  Scenario 9: Ganged outlets on a smart power strip  . . . .  9=20
> But this scenario moved to the =
http://tools.ietf.org/html/draft-tychon-eman-applicability-statement-02#se=
ction-2.8
>=20
> To make a long story short, I believe we should clearly mention it in =
[EMAN-REQ], covering the request from PDU vendors on the list.
>=20
> Regards, Benoit.
>>=20
>> Thanks,
>>=20
>>     Juergen
>>=20
>>=20
>> Am 27.07.2011 um 14:08 schrieb John Parello (jparello):
>>=20
>>> Hi Chris, and list...
>>>=20
>>> Following up on this wrt to the new framework draft and recent =
activity
>>> on the list. We've added a set of relationships like metering, =
powered
>>> by.
>>>=20
>>> Do you think it would be good to add a relationship like 'ganged' to =
map
>>> managed elements to the same gang?
>>>=20
>>> The relationship methphor is quite simple and if we cal this out it
>>> could model what you have in mind.
>>>=20
>>> Jp
>>>=20
>>> -----Original Message-----
>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of
>>> chrisv@cyberswitching.com
>>> Sent: Friday, March 04, 2011 11:02 AM
>>> To: eman@ietf.org
>>> Subject: [eman] Outlet Gang addition to =
draft-ietf-eman-requirements-00
>>>=20
>>> Hi Juergen,
>>>=20
>>> I wrote an additon to the various scenarios described in
>>> draft-ietf-eman-requirements-00 to address the "Outlet Gang" =
scenario
>>> found on Smart PDUs.  Please let me know if you have any questions =
while
>>> integrating it.
>>>=20
>>> $ diff draft-ietf-eman-requirements-00.txt
>>> draft-ietf-eman-requirements-01.txt
>>> 416a417,449
>>>> 2.9.  Scenario 9: Ganged outlets on a Smart Power Strip
>>>>=20
>>>>   Some PDUs allow physical entities like outlets to be "ganged"
>>> together as a
>>>>   logical entity for simplified management purposes.  This is
>>> particularly
>>>>   useful for servers with multiple power supplies, where each power
>>> supply is
>>>>   connected to a different physical outlet.  Other implementations
>>> allow
>>>>   "gangs" to be created based on common ownership of outlets, such =
as
>>>>   business units or load shed priority or other non-physical
>>> relationships.
>>>>   Current implementations allow for an "M-to-N" mapping between
>>> outlet
>>>>   "gangs" and physical outlets.  An example of this mapping =
includes
>>> the
>>>>   following:
>>>>=20
>>>>      Outlet 1             (physical entity)
>>>>      Outlet 2             (physical entity)
>>>>      Outlet 3             (physical entity)
>>>>      Outlet 4             (physical entity)
>>>>      Outlet Gang A        (virtual entity)
>>>>      Outlet Gang B        (virtual entity)
>>>>=20
>>>>      Gang A -> Outlets 1, 2 and 3
>>>>      Gang B -> Outlets 3 and 4
>>>>=20
>>>>   Note the allowed overlap on Outlet 3, where Outlet 3 belongs to
>>> both
>>>>   "gangs."
>>>>=20
>>>>   Each "Outlet Gang" entity reports the aggregated data from the
>>> individual
>>>>   outlet entities that comprise it and enables a single point of
>>> control for
>>>>   all the individual outlet entities.  For example, turning "Outlet
>>> Gang A"
>>>>   to the "off" state would turn outlets 1, 2, and 3 "off" in some
>>>>   implementations.  (The impact of this action on "Outlet Gang B" =
is
>>> to be
>>>>   defined by the equipment manufacturer.)
>>>>=20
>>> Thanks,
>>> Chris
>>> _______________________________________________
>>> 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


--Apple-Mail-6-690074821
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

I agree.

Can please somebody who was involved in the discussion about outlet gangs come up with a text proposal for this missing requirement?

Thanks,

    Juergen

Am 28.07.2011 um 00:39 schrieb Benoit Claise:


  
    
  
  

    On 27/07/2011 14:13, Juergen Quittek wrote:
    

      
Dear all,

Would we have a requirement for output gangs to be added to the requirements draft?

    

    Actually, I thought we had this already but, after checking, it's
    not in the latest version...

    After some investigation, I found it back in the version 01,
    http://tools.ietf.org/html/draft-ietf-eman-requirements-01

    
2.9.  Scenario 9: Ganged outlets on a smart power strip  . . . .  9 

    But this scenario moved to the
http://tools.ietf.org/html/draft-tychon-eman-applicability-statement-02#section-2.8

    

    To make a long story short, I believe we should clearly mention it
    in [EMAN-REQ], covering the request from PDU vendors on the list.

    

    Regards, Benoit.

    

      
Thanks,

    Juergen


Am 27.07.2011 um 14:08 schrieb John Parello (jparello):



      

        
Hi Chris, and list...

Following up on this wrt to the new framework draft and recent activity
on the list. We've added a set of relationships like metering, powered
by.

Do you think it would be good to add a relationship like 'ganged' to map
managed elements to the same gang?

The relationship methphor is quite simple and if we cal this out it
could model what you have in mind.

Jp

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
chrisv@cyberswitching.com
Sent: Friday, March 04, 2011 11:02 AM
To: eman@ietf.org
Subject: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00

Hi Juergen,

I wrote an additon to the various scenarios described in
draft-ietf-eman-requirements-00 to address the "Outlet Gang" scenario
found on Smart PDUs.  Please let me know if you have any questions while
integrating it.

$ diff draft-ietf-eman-requirements-00.txt
draft-ietf-eman-requirements-01.txt
416a417,449


        

          
2.9.  Scenario 9: Ganged outlets on a Smart Power Strip

  Some PDUs allow physical entities like outlets to be "ganged"


        

        
together as a


        

          
  logical entity for simplified management purposes.  This is


        

        
particularly


        

          
  useful for servers with multiple power supplies, where each power


        

        
supply is


        

          
  connected to a different physical outlet.  Other implementations


        

        
allow


        

          
  "gangs" to be created based on common ownership of outlets, such as
  business units or load shed priority or other non-physical


        

        
relationships.


        

          
  Current implementations allow for an "M-to-N" mapping between


        

        
outlet


        

          
  "gangs" and physical outlets.  An example of this mapping includes


        

        
the


        

          
  following:

     Outlet 1             (physical entity)
     Outlet 2             (physical entity)
     Outlet 3             (physical entity)
     Outlet 4             (physical entity)
     Outlet Gang A        (virtual entity)
     Outlet Gang B        (virtual entity)

     Gang A -> Outlets 1, 2 and 3
     Gang B -> Outlets 3 and 4

  Note the allowed overlap on Outlet 3, where Outlet 3 belongs to


        

        
both


        

          
  "gangs."

  Each "Outlet Gang" entity reports the aggregated data from the


        

        
individual


        

          
  outlet entities that comprise it and enables a single point of


        

        
control for


        

          
  all the individual outlet entities.  For example, turning "Outlet


        

        
Gang A"


        

          
  to the "off" state would turn outlets 1, 2, and 3 "off" in some
  implementations.  (The impact of this action on "Outlet Gang B" is


        

        
to be


        

          
  defined by the equipment manufacturer.)



        

        
Thanks,
Chris
_______________________________________________
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


    

    

  





--Apple-Mail-6-690074821--

From Rolf.Winter@neclab.eu  Thu Jul 28 06:07:53 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3D221F8ADC for ; Thu, 28 Jul 2011 06:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.356
X-Spam-Level: 
X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 v-K2udpb8uQ0 for ; Thu, 28 Jul 2011 06:07:53 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1549F21F8A62 for ; Thu, 28 Jul 2011 06:07:52 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 78AC32800032C; Thu, 28 Jul 2011 15:07:51 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yzzoels+PjPC; Thu, 28 Jul 2011 15:07:51 +0200 (CEST)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 56BE028000198; Thu, 28 Jul 2011 15:07:36 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.20]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Thu, 28 Jul 2011 15:07:36 +0200
From: Rolf Winter 
To: Juergen Quittek , "John Parello (jparello)" 
Thread-Topic: [eman] [EMAN-BATTERY]: power state set
Thread-Index: AQHMTNWwFwOnHp6xr02PkBOjIvpuVZUA8sSAgACatoCAACZVAA==
Date: Thu, 28 Jul 2011 13:07:35 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D1D031EA5@DAPHNIS.office.hd>
References: <4E30D605.6000400@cisco.com>  <8F79AC58-23C4-4D5C-BB61-CADBAD084612@quittek.at>
In-Reply-To: <8F79AC58-23C4-4D5C-BB61-CADBAD084612@quittek.at>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.7.0.202]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: eman mailing list 
Subject: Re: [eman] [EMAN-BATTERY]: power state set
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 13:07:54 -0000

+1=20

The problem is that the power states of a "regular" device conflate operati=
onal state information and energy related state information. The battery ch=
arging state does not I in the same way. So the tablet can be on/sleeping a=
nd off but charging in all these states. So that will be a little inconsist=
ent. I think calling this a power state for a battery is in principle OK, b=
ut I's like to think about it a little longer.

Best,


Rolf


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London =
W3 6BL | Registered in England 2832014=20


> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> Juergen Quittek
> Sent: Donnerstag, 28. Juli 2011 14:46
> To: John Parello (jparello)
> Cc: eman mailing list
> Subject: Re: [eman] [EMAN-BATTERY]: power state set
>=20
> Hi John,
>=20
> Am 27.07.2011 um 23:32 schrieb John Parello (jparello):
>=20
> > That would be good. That solves and issue we discussed in Prague
> about a
> > device that has a battery but does not want to expose it as a
> component
> > or part. Like a tablet with non removable battery.
> >
> > The device could simply support the power state series at the same
> time.
>=20
> I disagree.
>=20
> I don't think that this is in line with the idea of supporting multiple
> power states.
>=20
> If a device supports multiple power state series, they must carry the
> same
> of at least equivalent semantics. Otherwise you would have to read all
> series
> in order to understand the device's state.
>=20
> Thanks,
>=20
>     Juergen
>=20
> >
> > Nice
> >
> > +1
> >
> >
> >
> >
> > -----Original Message-----
> > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
> Of
> > Benoit Claise (bclaise)
> > Sent: Wednesday, July 27, 2011 8:23 PM
> > To: eman mailing list
> > Subject: [eman] [EMAN-BATTERY]: power state set
> >
> > Dear all,
> >
> > A quick review of the battery-mib leads me to this observation
> >
> >    batteryChargingState OBJECT-TYPE
> >        SYNTAX      INTEGER {
> >                        unknown(1),
> >                        charging(2),
> >                        maintainingCharge(3),
> >                        noCharging(4),
> >                        discharging(5)
> >                    }
> >
> > This is power state set, right? Ok, battery specific, but a power
> state
> > set anyway, right?
> > Since we will have three power state sets in IANA (IEEE1621, DMTF,
> and
> > EMAN), why not register this one in IANA? Maybe in the future, we
> might
> > need an extra battery state.
> >
> > Next question: is this power state set comparable to the existing
> power
> > state set?
> > I mean, should a powered device (in the case a battery) advertise
> that
> > it support the battery charging state power state set?
> > This would have the advantage that a NMS would discover powered
> devices,
> >
> > components, and batteries exactly the same way.
> >
> > Regards, Benoit.
> >
> > _______________________________________________
> > eman mailing list
> > eman@ietf.org
> > https://www.ietf.org/mailman/listinfo/eman
> > _______________________________________________
> > eman mailing list
> > eman@ietf.org
> > https://www.ietf.org/mailman/listinfo/eman
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman

From bclaise@cisco.com  Thu Jul 28 08:34:49 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE33C21F8C1E for ; Thu, 28 Jul 2011 08:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level: 
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyN8+VstsmPg for ; Thu, 28 Jul 2011 08:34:49 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id DBEDB21F8C01 for ; Thu, 28 Jul 2011 08:34:48 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6SFYk0E009422; Thu, 28 Jul 2011 17:34:46 +0200 (CEST)
Received: from [10.86.241.199] (che-vpn-cluster-1-454.cisco.com [10.86.241.199]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6SFYi3E013740; Thu, 28 Jul 2011 17:34:45 +0200 (CEST)
Message-ID: <4E318194.1060506@cisco.com>
Date: Thu, 28 Jul 2011 11:34:44 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Rolf Winter 
References: <4E30D605.6000400@cisco.com>  <8F79AC58-23C4-4D5C-BB61-CADBAD084612@quittek.at> <791AD3077F94194BB2BDD13565B6295D1D031EA5@DAPHNIS.office.hd>
In-Reply-To: <791AD3077F94194BB2BDD13565B6295D1D031EA5@DAPHNIS.office.hd>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: eman mailing list 
Subject: Re: [eman] [EMAN-BATTERY]: power state set
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 15:34:49 -0000

Rolf,
> +1
>
> The problem is that the power states of a "regular" device conflate operational state information and energy related state information. The battery charging state does not I in the same way.
This is actually my question.
Is the battery power state set orthogonal to the other 3 power state sets?

Regards, Benoit.


> So the tablet can be on/sleeping and off but charging in all these states. So that will be a little inconsistent. I think calling this a power state for a battery is in principle OK, but I's like to think about it a little longer.
>
> Best,
>
>
> Rolf
>
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
>
>
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
>> Juergen Quittek
>> Sent: Donnerstag, 28. Juli 2011 14:46
>> To: John Parello (jparello)
>> Cc: eman mailing list
>> Subject: Re: [eman] [EMAN-BATTERY]: power state set
>>
>> Hi John,
>>
>> Am 27.07.2011 um 23:32 schrieb John Parello (jparello):
>>
>>> That would be good. That solves and issue we discussed in Prague
>> about a
>>> device that has a battery but does not want to expose it as a
>> component
>>> or part. Like a tablet with non removable battery.
>>>
>>> The device could simply support the power state series at the same
>> time.
>>
>> I disagree.
>>
>> I don't think that this is in line with the idea of supporting multiple
>> power states.
>>
>> If a device supports multiple power state series, they must carry the
>> same
>> of at least equivalent semantics. Otherwise you would have to read all
>> series
>> in order to understand the device's state.
>>
>> Thanks,
>>
>>      Juergen
>>
>>> Nice
>>>
>>> +1
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
>> Of
>>> Benoit Claise (bclaise)
>>> Sent: Wednesday, July 27, 2011 8:23 PM
>>> To: eman mailing list
>>> Subject: [eman] [EMAN-BATTERY]: power state set
>>>
>>> Dear all,
>>>
>>> A quick review of the battery-mib leads me to this observation
>>>
>>>     batteryChargingState OBJECT-TYPE
>>>         SYNTAX      INTEGER {
>>>                         unknown(1),
>>>                         charging(2),
>>>                         maintainingCharge(3),
>>>                         noCharging(4),
>>>                         discharging(5)
>>>                     }
>>>
>>> This is power state set, right? Ok, battery specific, but a power
>> state
>>> set anyway, right?
>>> Since we will have three power state sets in IANA (IEEE1621, DMTF,
>> and
>>> EMAN), why not register this one in IANA? Maybe in the future, we
>> might
>>> need an extra battery state.
>>>
>>> Next question: is this power state set comparable to the existing
>> power
>>> state set?
>>> I mean, should a powered device (in the case a battery) advertise
>> that
>>> it support the battery charging state power state set?
>>> This would have the advantage that a NMS would discover powered
>> devices,
>>> components, and batteries exactly the same way.
>>>
>>> Regards, Benoit.
>>>
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From bclaise@cisco.com  Thu Jul 28 08:46:37 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F7921F8CC1 for ; Thu, 28 Jul 2011 08:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.496
X-Spam-Level: 
X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.102,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQt7nPAYJLSp for ; Thu, 28 Jul 2011 08:46:37 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D63E721F8C7B for ; Thu, 28 Jul 2011 08:46:36 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6SFgpae010510; Thu, 28 Jul 2011 17:42:51 +0200 (CEST)
Received: from [10.86.241.199] (che-vpn-cluster-1-454.cisco.com [10.86.241.199]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6SFgoRq019962; Thu, 28 Jul 2011 17:42:50 +0200 (CEST)
Message-ID: <4E318379.3000403@cisco.com>
Date: Thu, 28 Jul 2011 11:42:49 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Juergen Quittek 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030906080403020203030505"
Cc: eman mailing list 
Subject: Re: [eman] Terminology: energy control
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 15:46:37 -0000

This is a multi-part message in MIME format.
--------------030906080403020203030505
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 26/07/2011 19:46, Juergen Quittek wrote:
> Hi John,
>
> In draft-parello-eman-definitions-00 you define 'energy control' as:
>
>>      Energy Control
>>
>>        Energy Control is a part of Energy Management that deals with
>>        modifying or setting the state of an Energy Managed Object in
>>        order to optimize or ensure its efficiency.
>
> I disagree. Energy Control is not limited to optimization of 
> efficiency. "in order to optimize or ensure its efficiency" should be 
> removed. A function that increases energy consumption needs also to be 
> covered by the term energy control.
>
> What woud be the difference between "modifying" and "setting" a state?
>
> What about the following?:
>
>     Energy Control is a part of Energy Management that deals 
> wit influencing the
>     consumption of energy in a network of energy consuming devices.
That works, but I believe we should replace "energy consuming device" by 
the correct term, i.e. the one used in EMAN. Is this "powered device" or 
"energy managed device", whatever we agree.

Regards, Benoit (as a contributor)
>
> Thanks,
>
>     Juergen
>
>
>
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


--------------030906080403020203030505
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 26/07/2011 19:46, Juergen Quittek wrote:
    

      
Hi John,
        


        

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

      

      


      

      

        

          
   
               Energy Control 

          


            

          
     
               Energy Control is a part of Energy Management that deals
              with 

          
     
               modifying or setting the state of an Energy Managed
              Object in 

          
     
               order to optimize or ensure its efficiency. 

        

      

      

        


        

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

        


        

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

      

      


      

      
What about the following?:

      


      

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

      
    consumption of energy in a network of energy consuming
        devices.

    

    That works, but I believe we should replace "energy consuming
    device" by the correct term, i.e. the one used in EMAN. Is this
    "powered device" or "energy managed device", whatever we agree.

    

    Regards, Benoit (as a contributor)

    

      


      

      
Thanks,

      


      

      
    Juergen

      


      

      


      

      

      

      

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


    

    

  


--------------030906080403020203030505--

From ietf@quittek.at  Thu Jul 28 09:11:31 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600C321F8B13 for ; Thu, 28 Jul 2011 09:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.174
X-Spam-Level: 
X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.074,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 euTJ9HrH+mUg for ; Thu, 28 Jul 2011 09:11:30 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEBA21F8B33 for ; Thu, 28 Jul 2011 09:11:29 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LxYj9-1RSW2a3KJf-017Gq4; Thu, 28 Jul 2011 18:11:25 +0200
References:  <4E318379.3000403@cisco.com>
In-Reply-To: <4E318379.3000403@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-7-702317123
Message-Id: 
From: Juergen Quittek 
Date: Thu, 28 Jul 2011 12:11:22 -0400
To: Benoit Claise 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:XkYbDvsbAhA9gFJwr+fZAWtnelyMZuys3WJ73TSMNAZ cCcLPrfANsEdARH6+UE4UXXHAfZ0qV8uZtMkqTxqDjZzBfEzKR vpvt4D0fNVH+YQ7Ovg+Uoy2vkNKQUoF12Nr+UWWYlElrqqaw8t pZFhPfFBmmMdPcyjKPDMUoUAuXDRgp0Q4Y/uDV+NZH8Ka1jt87 5OV7KX40DV6IWyE5kLh/mwHGfOWpYn0RX9vmkBrGoY=
Cc: eman mailing list 
Subject: Re: [eman] Terminology: energy control
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 16:11:31 -0000

--Apple-Mail-7-702317123
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Am 28.07.2011 um 11:42 schrieb Benoit Claise:

> On 26/07/2011 19:46, Juergen Quittek wrote:
>>=20
>> Hi John,
>>=20
>> In draft-parello-eman-definitions-00 you define 'energy control' as:
>>=20
>>>      Energy Control=20
>>>=20
>>>        Energy Control is a part of Energy Management that deals with=20=

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

>>>        order to optimize or ensure its efficiency.=20
>>=20
>>=20
>> I disagree. Energy Control is not limited to optimization of =
efficiency. "in order to optimize or ensure its efficiency" should be =
removed. A function that increases energy consumption needs also to be =
covered by the term energy control.
>>=20
>> What woud be the difference between "modifying" and "setting" a =
state?
>>=20
>> What about the following?:
>>=20
>>     Energy Control is a part of Energy Management that deals wit =
influencing the
>>     consumption of energy in a network of energy consuming devices.
> That works, but I believe we should replace "energy consuming device" =
by the correct term, i.e. the one used in EMAN. Is this "powered device" =
or "energy managed device", whatever we agree.

Yes. We can make the replacement after agreeing on final terms.

    Juergen

>=20
> Regards, Benoit (as a contributor)
>>=20
>> Thanks,
>>=20
>>     Juergen
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>=20


--Apple-Mail-7-702317123
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


Am 28.07.2011 um 11:42 schrieb Benoit Claise:


  
    
  
  

    On 26/07/2011 19:46, Juergen Quittek wrote:
    

      
Hi John,
        


        

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

      

      


      

      

        

          
   
               Energy Control 

          


            

          
     
               Energy Control is a part of Energy Management that deals
              with 

          
     
               modifying or setting the state of an Energy Managed
              Object in 

          
     
               order to optimize or ensure its efficiency. 

        

      

      

        


        

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

        


        

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

      

      


      

      
What about the following?:

      


      

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

      
    consumption of energy in a network of energy consuming
        devices.

    

    That works, but I believe we should replace "energy consuming
    device" by the correct term, i.e. the one used in EMAN. Is this
    "powered device" or "energy managed device", whatever we agree.

Yes. We can make the replacement after agreeing on final terms.

    Juergen


    

    Regards, Benoit (as a contributor)

    

      


      

      
Thanks,

      


      

      
    Juergen

      


      

      


      

      

      

      

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


    

    

  





--Apple-Mail-7-702317123--

From bclaise@cisco.com  Thu Jul 28 09:12:39 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4EC21F8B11 for ; Thu, 28 Jul 2011 09:12:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.497
X-Spam-Level: 
X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.101,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ne-yX-OL-ftv for ; Thu, 28 Jul 2011 09:12:36 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id DFFBF21F8AF4 for ; Thu, 28 Jul 2011 09:12:35 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6SGCW3p014508; Thu, 28 Jul 2011 18:12:32 +0200 (CEST)
Received: from [10.86.241.199] (che-vpn-cluster-1-454.cisco.com [10.86.241.199]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6SGCUUQ014002; Thu, 28 Jul 2011 18:12:31 +0200 (CEST)
Message-ID: <4E318A6E.104@cisco.com>
Date: Thu, 28 Jul 2011 12:12:30 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Bruce Nordman 
References:  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060201000908070001040203"
Cc: eman@ietf.org
Subject: Re: [eman] terminology Energy Managed Object versus Powered Device
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, 28 Jul 2011 16:12:39 -0000

This is a multi-part message in MIME format.
--------------060201000908070001040203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

If I have to compare "powered device" versus "energy managed object", I 
tend to prefer the latter, as:
1. managed object is a well known term. It's "just" that we deal with 
power/energy. So we have to be more specific.
2. energy managed object is more generic. For example, we will model a 
meter. Is this a "powered device"? It's more a "energy managed device" 
that meter something for someone.
> The current definition of an EMO begins:
> An Energy Managed Object (EMO) is a device that is part of or
>          attached to a communications network...
> So, I took that to mean an integral device, like a computer, switch, 
> router, etc. that
> has a power cord and network interfaces.  I use "device" to refer to 
> this concept.
> I know that EMAN Is to report on either entire devices, or components 
> of devices,
> and "entity" can be used to reference the combination of devices and 
> components
> in line with the Entity MIB name.  A Power Interface is also a type of 
> entity, since
> it is a component and there is measurement and control for that just 
> as with any
> other component.
>
> *So, regardless of what terms are used, we need terms that are 
> synonyms for
> powered device, component, entity, and power interface.*
So your point is that we need a generic term, right?
I believe we should have a generic term, and if you want to know if this 
is box, a line card, a port, a battery, etc... then you refer to the 
ENTITY-MIB
> An assumption I am making is that an entire device has some 
> characteristics
> (important ones reflected in the MIB structure) different from a 
> component.
Yes.

Regards, Benoit.
>
> I think it is very easy for people to accidentally misinterpret what 
> EMO is
> referring to - a device, a component, an entity, or even a software 
> object.
> I also prefer shorter terms.
>
> A cross-cutting question would seem to be whether things are named based
> on what they are, or by what is being done to them.  Dictionary.com 
> indicates
> that management is about control.  Many EMAN entities will support control
> and others will not.  Are the ones that don't do control being managed?
> Not using the 'manage' term avoids that question.
>
>
> On Wed, Jul 27, 2011 at 2:59 PM, John Parello (jparello) 
> > wrote:
>
>     Hi,
>
>     I saw a few threads where we discussed this and I want to pull it
>     to its
>     own thread.
>
>     In the framework I referred to an Energy Managed Object. I got some
>     feedback and in the alternate ref draft Theresa notion of powered
>     device.
>
>     I like the concept of having a device and power interface similar
>     to the
>     communication notion of device and interface.
>
>     When managing these element however we typically use the term managed
>     object. That boils down to something you give a unique identifier
>     to and
>     then manage. This can be interfaces, virtual interfaces, devices,
>     motherboards etc.
>
>     I'd like to use that same notion here with an generic Energy Managed
>     Object. That was we can model and uniquely identify logical objects
>     (outlets, inlets, interfaces, etc) as well as physical.
>
>     So I think EMO is a better term.
>
>     Thoughts?
>     Jp
>     _______________________________________________
>     eman mailing list
>     eman@ietf.org 
>     https://www.ietf.org/mailman/listinfo/eman
>
>
>
>
> -- 
> *Bruce Nordman*
> Lawrence Berkeley National Laboratory
> eetd.lbl.gov/ea/nordman 
> BNordman@LBL.gov
> 510-486-7089
> m: 510-501-7943
>
>
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


--------------060201000908070001040203
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Dear all,

    

    If I have to compare "powered device" versus "energy managed
    object", I tend to prefer the latter, as:

    1. managed object is a well known term. It's "just" that we deal
    with power/energy. So we have to be more specific.

    2. energy managed object is more generic. For example, we will model
    a meter. Is this a "powered device"? It's more a "energy managed
    device" that meter something for someone.

    
The current definition of an EMO begins:

      
An Energy Managed Object (EMO) is a device that is part of or 
        attached to a communications network...

      So, I took that to mean an integral device, like a computer,
      switch, router, etc. that

      has a power cord and network interfaces.  I use "device" to refer
      to this concept.

      I know that EMAN Is to report on either entire devices, or
      components of devices,

      and "entity" can be used to reference the combination of devices
      and components

      in line with the Entity MIB name.  A Power Interface is also a
      type of entity, since

      it is a component and there is measurement and control for that
      just as with any

      other component.

      

      So, regardless of what terms are used, we need terms that are
        synonyms for

        powered device, component, entity, and power interface.

    

    So your point is that we need a generic term, right?

    I believe we should have a generic term, and if you want to know if
    this is box, a line card, a port, a battery, etc... then you refer
    to the ENTITY-MIB

    

      An assumption I am making is that an entire device has some
      characteristics

      (important ones reflected in the MIB structure) different from a
      component.

    

    Yes. 

    

    Regards, Benoit.

    


      I think it is very easy for people to accidentally misinterpret
      what EMO is

      referring to - a device, a component, an entity, or even a
      software object.

      I also prefer shorter terms.

      

      A cross-cutting question would seem to be whether things are named
      based

      on what they are, or by what is being done to them. 
      Dictionary.com indicates

      that management is about control.  Many EMAN entities will support
      control

      and others will not.  Are the ones that don't do control being
      managed?

      Not using the 'manage' term avoids that question.

      

      

      
On Wed, Jul 27, 2011 at 2:59 PM, John
        Parello (jparello) <jparello@cisco.com>
        wrote:

        

          Hi,

          

          I saw a few threads where we discussed this and I want to pull
          it to its

          own thread.

          

          In the framework I referred to an Energy Managed Object. I got
          some

          feedback and in the alternate ref draft Theresa notion of
          powered

          device.

          

          I like the concept of having a device and power interface
          similar to the

          communication notion of device and interface.

          

          When managing these element however we typically use the term
          managed

          object. That boils down to something you give a unique
          identifier to and

          then manage. This can be interfaces, virtual interfaces,
          devices,

          motherboards etc.

          

          I'd like to use that same notion here with an generic Energy
          Managed

          Object. That was we can model and uniquely identify logical
          objects

          (outlets, inlets, interfaces, etc) as well as physical.

          

          So I think EMO is a better term.

          

          Thoughts?

          Jp

          _______________________________________________

          eman mailing list

          eman@ietf.org

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

        

      

      

      

      

      -- 

      Bruce Nordman

      Lawrence Berkeley National
        Laboratory

      eetd.lbl.gov/ea/nordman

      BNordman@LBL.gov

      510-486-7089

      m: 510-501-7943

      

      

      

      

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


    

    

  


--------------060201000908070001040203--

From bnordman@lbl.gov  Thu Jul 28 09:12:50 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCBF21F8B38 for ; Thu, 28 Jul 2011 09:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.83
X-Spam-Level: 
X-Spam-Status: No, score=-5.83 tagged_above=-999 required=5 tests=[AWL=0.146,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0wNrK2KPNFO for ; Thu, 28 Jul 2011 09:12:49 -0700 (PDT)
Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 84BBA21F8B11 for ; Thu, 28 Jul 2011 09:12:49 -0700 (PDT)
X-Ironport-SBRS: 5.2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AosBAHWJMU7RVdo0mGdsb2JhbAA0AQEBAQIBFAJvBQwMBAcDKRsUExMBBQEkBxcngjacZQGIFQgUAQEBAQEICQ0HFCWIfKVPCp0ggz2DBASSeYxMPIN4
X-IronPort-AV: E=Sophos;i="4.67,283,1309762800"; d="scan'208";a="47691402"
Received: from mail-yi0-f52.google.com ([209.85.218.52]) by ironport3.lbl.gov with ESMTP; 28 Jul 2011 09:12:48 -0700
Received: by mail-yi0-f52.google.com with SMTP id 19so2917366yie.39 for ; Thu, 28 Jul 2011 09:12:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.159.4 with SMTP id l4mr141429ano.148.1311869568430; Thu, 28 Jul 2011 09:12:48 -0700 (PDT)
Received: by 10.100.241.8 with HTTP; Thu, 28 Jul 2011 09:12:48 -0700 (PDT)
In-Reply-To: <4E318194.1060506@cisco.com>
References: <4E30D605.6000400@cisco.com>  <8F79AC58-23C4-4D5C-BB61-CADBAD084612@quittek.at> <791AD3077F94194BB2BDD13565B6295D1D031EA5@DAPHNIS.office.hd> <4E318194.1060506@cisco.com>
Date: Thu, 28 Jul 2011 12:12:48 -0400
Message-ID: 
From: Bruce Nordman 
To: Benoit Claise 
Content-Type: multipart/alternative; boundary=001636eefcac9e345304a9236f05
Cc: eman mailing list 
Subject: Re: [eman] [EMAN-BATTERY]: power state set
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 16:12:50 -0000

--001636eefcac9e345304a9236f05
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jul 28, 2011 at 11:34 AM, Benoit Claise  wrote:

> Rolf,
>
>  +1
>>
>> The problem is that the power states of a "regular" device conflate
>> operational state information and energy related state information. The
>> battery charging state does not I in the same way.
>>
> This is actually my question.
> Is the battery power state set orthogonal to the other 3 power state sets?
>

A power state is (in principle) something independent of the device (or
component) type.
It is universal.

The battery state is specific to a single type of component

I can imagine setting a power state for a battery to "off": to electrically
disconnect it to prevent charging or discharging (this might be done
prior to removal for example).  In this case, a battery would want both
a power state and a charging state (the power state variable would be
in the other MIB so not added to the Battery MIB).

If new battery states might be needed, how about simply having a registry
of the current states so that individual states could be added, rather than
entire new series as we have with power states.  This would give flexibility
to add in future with minimal complexity, and not conflate with power
states.

--Bruce

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

--001636eefcac9e345304a9236f05
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Thu, Jul 28, 2011 at 11:34 AM, Benoit=
 Claise <bclaise@=
cisco.com> wrote:

Rolf,




+1



The problem is that the power states of a "regular" device confla=
te operational state information and energy related state information. The =
battery charging state does not I in the same way.



This is actually my question.

Is the battery power state set orthogonal to the other 3 power state sets?<=
br>

A power state is (in principle) something independ=
ent of the device (or component) type.
It is universal.

The batte=
ry state is specific to a single type of component 


I can imagine setting a power state for a battery to "off": t=
o electrically
disconnect it to prevent charging or discharging (this mi=
ght be done
prior to removal for example).=A0 In this case, a battery wo=
uld want both

a power state and a charging state (the power state variable would be
in=
 the other MIB so not added to the Battery MIB).

If new battery stat=
es might be needed, how about simply having a registry
of the current st=
ates so that individual states could be added, rather than

entire new series as we have with power states.=A0 This would give flexibil=
ity
to add in future with minimal complexity, and not conflate with powe=
r states.

--Bruce




Regards, Benoit.

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


--001636eefcac9e345304a9236f05--

From jparello@cisco.com  Thu Jul 28 09:30:47 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0DF21F8B44 for ; Thu, 28 Jul 2011 09:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.817
X-Spam-Level: 
X-Spam-Status: No, score=-2.817 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zmk0u2ae4r-6 for ; Thu, 28 Jul 2011 09:30:47 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 10F3421F8B3E for ; Thu, 28 Jul 2011 09:30:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=5230; q=dns/txt; s=iport; t=1311870647; x=1313080247; h=mime-version:subject:date:message-id:references:from:to: cc; bh=UOlz9FygS061+hfy5TTEICcsWEocAjwkQJRN0fqhAyQ=; b=BNXmEVziPUAPT/gU2OJMI6t2efZZ9VXzqWTjb/NIYII0RLAOWIrg25pY 4WiBcBtg3dCksTMph86XL4uLtuOz/TE8RLzqQJcy/AwuvbH1ahpIBCrNk 5YC70QLBAkcO68lwLxIQ4UtdvCpY1dbOdkBUZXFvdigdcUYnoUHBKFJ01 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAOqNMU6rRDoH/2dsb2JhbAA0AQEBAQIBFAEMEgNECwUHBQIBCQQKAwQBAQsGDxUGARNJCAEBBQEWDBunOXeIfKQOnlmDPYIlXwSHKi+QMIt0
X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208,217";a="7443457"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jul 2011 16:30:46 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6SGUk4J026914; Thu, 28 Jul 2011 16:30:46 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 28 Jul 2011 09:30:45 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4D43.B32F2834"
Date: Thu, 28 Jul 2011 09:28:47 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] [EMAN-BATTERY]: power state set
Thread-Index: AcxNQTe4m9DJAEb/SN6Q0V1xAT7NMAAAjV/C
References: <4E30D605.6000400@cisco.com><8F79AC58-23C4-4D5C-BB61-CADBAD084612@quittek.at><791AD3077F94194BB2BDD13565B6295D1D031EA5@DAPHNIS.office.hd><4E318194.1060506@cisco.com> 
From: "John Parello (jparello)" 
To: "Bruce Nordman" , "Benoit Claise (bclaise)" 
X-OriginalArrivalTime: 28 Jul 2011 16:30:45.0743 (UTC) FILETIME=[B38D47F0:01CC4D43]
Cc: eman mailing list 
Subject: Re: [eman] [EMAN-BATTERY]: power state set
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 16:30:48 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4D43.B32F2834
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


OK but thinking about it. I'm not sure the battery state is independent =
of the device in all cases.

Tablet example. We refer to them as on, off, charging, etc. We don't say =
the device is on and the battery is off. It's merged.

So while I agree they can be separate we have to allow for the case when =
they are combined as well.

Jp



-----Original Message-----
From: eman-bounces@ietf.org on behalf of Bruce Nordman
Sent: Thu 7/28/2011 9:12 AM
To: Benoit Claise (bclaise)
Cc: eman mailing list
Subject: Re: [eman] [EMAN-BATTERY]: power state set
=20
On Thu, Jul 28, 2011 at 11:34 AM, Benoit Claise  =
wrote:

> Rolf,
>
>  +1
>>
>> The problem is that the power states of a "regular" device conflate
>> operational state information and energy related state information. =
The
>> battery charging state does not I in the same way.
>>
> This is actually my question.
> Is the battery power state set orthogonal to the other 3 power state =
sets?
>

A power state is (in principle) something independent of the device (or
component) type.
It is universal.

The battery state is specific to a single type of component

I can imagine setting a power state for a battery to "off": to =
electrically
disconnect it to prevent charging or discharging (this might be done
prior to removal for example).  In this case, a battery would want both
a power state and a charging state (the power state variable would be
in the other MIB so not added to the Battery MIB).

If new battery states might be needed, how about simply having a =
registry
of the current states so that individual states could be added, rather =
than
entire new series as we have with power states.  This would give =
flexibility
to add in future with minimal complexity, and not conflate with power
states.

--Bruce

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


------_=_NextPart_001_01CC4D43.B32F2834
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [eman] [EMAN-BATTERY]: power state set







OK but thinking about it. I'm not sure the battery =
state is independent of the device in all cases.



Tablet example. We refer to them as on, off, charging, etc. We don't say =
the device is on and the battery is off. It's merged.



So while I agree they can be separate we have to allow for the case when =
they are combined as well.



Jp







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

From: eman-bounces@ietf.org on behalf of Bruce Nordman

Sent: Thu 7/28/2011 9:12 AM

To: Benoit Claise (bclaise)

Cc: eman mailing list

Subject: Re: [eman] [EMAN-BATTERY]: power state set



On Thu, Jul 28, 2011 at 11:34 AM, Benoit Claise =
<bclaise@cisco.com> wrote:



> Rolf,

>

>  +1

>>

>> The problem is that the power states of a "regular" =
device conflate

>> operational state information and energy related state =
information. The

>> battery charging state does not I in the same way.

>>

> This is actually my question.

> Is the battery power state set orthogonal to the other 3 power =
state sets?

>



A power state is (in principle) something independent of the device =
(or

component) type.

It is universal.



The battery state is specific to a single type of component



I can imagine setting a power state for a battery to "off": to =
electrically

disconnect it to prevent charging or discharging (this might be done

prior to removal for example).  In this case, a battery would want =
both

a power state and a charging state (the power state variable would =
be

in the other MIB so not added to the Battery MIB).



If new battery states might be needed, how about simply having a =
registry

of the current states so that individual states could be added, rather =
than

entire new series as we have with power states.  This would give =
flexibility

to add in future with minimal complexity, and not conflate with =
power

states.



--Bruce



>

> Regards, Benoit.

>

> ...

>

--

*Bruce Nordman*

Lawrence Berkeley National Laboratory

eetd.lbl.gov/ea/nordman

BNordman@LBL.gov

510-486-7089

m: 510-501-7943









------_=_NextPart_001_01CC4D43.B32F2834--

From bclaise@cisco.com  Thu Jul 28 09:39:20 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB08521F8C7B for ; Thu, 28 Jul 2011 09:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO5ZQiaxol+5 for ; Thu, 28 Jul 2011 09:39:20 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1338F21F8C7A for ; Thu, 28 Jul 2011 09:39:19 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6SGdIV4017992 for ; Thu, 28 Jul 2011 18:39:18 +0200 (CEST)
Received: from [10.86.241.199] (che-vpn-cluster-1-454.cisco.com [10.86.241.199]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6SGdHjb008480 for ; Thu, 28 Jul 2011 18:39:17 +0200 (CEST)
Message-ID: <4E3190B5.70005@cisco.com>
Date: Thu, 28 Jul 2011 12:39:17 -0400
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: eman mailing list 
References: <4E2CC5F4.2040800@internet2.edu>
In-Reply-To: <4E2CC5F4.2040800@internet2.edu>
X-Forwarded-Message-Id: <4E2CC5F4.2040800@internet2.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [eman] Remote Participation Details for EMAN at IETF 81
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, 28 Jul 2011 16:39:20 -0000

Dear all,

If you plan to join remotely, we start at THURSDAY, July 28, 2011 at 1740-1940 Quebec time.
If you're local, we're in room 204 B.

Assuming the Audio stream is working, please join it:


Audio will be archived at


All the latest versions of the slides received will be posted here by meeting time:


Jabber info:
, we'll be in eman@jabber.ietf.org
(We will monitor jabber; however, do not expect that the session will
be completely scribed there!)

IETF remote participation page:


Regards, Bruce&  Benoit.


From j.schoenwaelder@jacobs-university.de  Thu Jul 28 09:45:08 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EBF21F8CBF for ; Thu, 28 Jul 2011 09:45:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.032
X-Spam-Level: 
X-Spam-Status: No, score=-103.032 tagged_above=-999 required=5 tests=[AWL=0.217, 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 8jLiS5IEVMuH for ; Thu, 28 Jul 2011 09:45:08 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9C221F8CBD for ; Thu, 28 Jul 2011 09:45:07 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0656120C57 for ; Thu, 28 Jul 2011 18:45:07 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VyOJ7uL0gp1D; Thu, 28 Jul 2011 18:45:05 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 13F5120C60; Thu, 28 Jul 2011 18:45:05 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id F183A1A1CF50; Thu, 28 Jul 2011 18:45:03 +0200 (CEST)
Date: Thu, 28 Jul 2011 18:45:03 +0200
From: Juergen Schoenwaelder 
To: eman@ietf.org
Message-ID: <20110728164503.GA30392@elstar.local>
Mail-Followup-To: eman@ietf.org
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="AqsLC8rIMeq19msA"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 16:45:09 -0000

--AqsLC8rIMeq19msA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

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

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

--AqsLC8rIMeq19msA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=IANA-POWER-STATE-MIB

IANA-POWER-STATE-MIB DEFINITIONS ::= BEGIN 

IMPORTS
    MODULE-IDENTITY, mib-2           FROM SNMPv2-SMI
    TEXTUAL-CONVENTION               FROM SNMPv2-TC;

ianaRtProtoMIB  MODULE-IDENTITY
    LAST-UPDATED "201107280000Z" -- July 28, 2011
    ORGANIZATION "IANA"
    CONTACT-INFO
            " Internet Assigned Numbers Authority
              Internet Corporation for Assigned Names and Numbers
              4676 Admiralty Way, Suite 330
              Marina del Rey, CA 90292-6601

              Phone: +1 310 823 9358
              EMail: iana&iana.org"
    DESCRIPTION
            "TBD"

    REVISION     "201107280000Z"  --  July 28, 2011
    DESCRIPTION  "Original version, published in coordination
                 with RFC XXXX."

    ::= { mib-2 XXXX }

IANAPowerStateSet ::= TEXTUAL-CONVENTION 
    STATUS	current 
    DESCRIPTION 

       "IANAPowerState is a textual convention that describes Power
        State Sets and Power State Set Values a Power Monitor
        supports. IANA has created a registry of Power State supported
        by a Power Monitor entity and IANA shall administer the list
        of Power State Sets and Power States.

	The textual convention assumes that power states in a power
	state set are limited to 255 distinct values. For a Power
	State Set S, the named number with the value S * 256 is
	allocated to indicate the power state set. For a Power State X
	in the Power State S, the named number with the value S * 256
	+ X + 1 is allocated to represent the power state."
                
    REFERENCE 
       "http://www.iana.org/assignments/eman 
        RFC EDITOR NOTE: please change the previous URL if this is 
	not the correct one after IANA assigned it." 
              
    SYNTAX      INTEGER {
    			unknown(0),		-- unknown power state
			other(255),		-- indicates other set

			ieee1621On(256),
			ieee1621Off(257),
			ieee1621Sleep(258),
    			ieee1621(511),		-- indicates IEEE1621 set
			
			dmtfOn(512),
			dmtfSleepLight(513),
			dmtfSleepDeep(514),
			dmtfOffHard(515),
			dmtfOffSoft(516),
			dmtfHibernate(517),
			dmtfPowerOffSoft(518),
			dmtfPowerOffHard(519),
			dmtfMasterBusReset(520),
			dmtfDiagnosticInterrapt(521),
			dmtfOffSoftGraceful(522),
			dmtfOffHardGraceful(523),
			dmtfMasterBusResetGraceful(524),
			dmtfPowerCycleOffSoftGraceful(525),
			dmtfPowerCycleHardGraceful(526),
			dmtf(767),		-- indicates DMTF set
			
			emanTBD(1024),
			eman(1023)		-- indicates EMAN set
		}

END

         

--AqsLC8rIMeq19msA--

From bill.mielke@alcatel-lucent.com  Thu Jul 28 09:45:34 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E72F21F8AD6 for ; Thu, 28 Jul 2011 09:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfQNvT1de79d for ; Thu, 28 Jul 2011 09:45:34 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id F38E521F8AC9 for ; Thu, 28 Jul 2011 09:45:33 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p6SGjURJ007554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Jul 2011 11:45:31 -0500 (CDT)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6SGjUf7009107 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 28 Jul 2011 11:45:30 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 28 Jul 2011 11:45:30 -0500
From: "Mielke, William F (Bill)" 
To: eman mailing list 
Date: Thu, 28 Jul 2011 11:45:16 -0500
Thread-Topic: Comments on draft-ietf-eman-battery-mib-02
Thread-Index: AcxNRbrVKfOWwDrTR1+ULn8i42RuxQ==
Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DDD0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: [eman] Comments on draft-ietf-eman-battery-mib-02
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, 28 Jul 2011 16:45:34 -0000

Provided below.  I will forward a copy of my annotated PDF file to the auth=
ors.  The PDF version also includes some minor corrections/suggestions whic=
h are not reproduced below.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

----------------------------------------------------------------
Comments on draft-ietf-eman-battery-mib-02
----------------------------------------------------------------

General Comments:

1. I believe that the definitions for the following terms should be adjuste=
d to clarify their intent.  I was confused after reading the current defini=
tions in the document but after some thought I believe that the intended us=
e of these is as follows:

batteryNominalCapacity:

This represents the manufacturer's static design capacity for the battery. =
 It is the rated or nameplate value advertised by the manufacturer.  It is =
a static number.

batteryActualCapacity:

This represents the same value as batteryNominalCapacity only it has been a=
djusted to account for the age and historical usage of the battery both of =
which degrade its capacity below its nominal rating.  It is a dynamic estim=
ate.

batteryCurrentCharge:

This represents the amount of energy which is estimated to be remaining in =
the battery at any given point in time.  It is a dynamic estimate.

Are these the correct interpretations?

2. In general I think that this is in pretty good shape.

Deatiled Comments:

> The Battery MIB module serves for monitoring the battery status. It
> does not implement a Power Monitor as defined in the framework for
> energy management [I-D.ietf-eman-framework]. (Page 3)

Adjust to match the replacement terminology for "Power Monitor".

> batteryTemperature OBJECT-TYPE
> SYNTAX Integer32
> UNITS "degrees Celsius" (Page 16)

I don't know the level of precision required here, but I suspect some level=
 of fractional degrees would be appropriate.  Should we consider deci-degre=
es, centi-degrees, or even milli-degrees?  I would expect deci- or centi- w=
ould be appropriate but I have no expertise to back that up.  I will inquir=
e about this with our SMEs and get back to you.

> batteryReplacementAlarmCycles OBJECT-TYPE
> SYNTAX Unsigned32
> UNITS "milliampere hours" (Page 18)

This is simply a count, no?  So no units at all.  :)

> batteryHighAlarmTemperature OBJECT-TYPE
> SYNTAX Integer32
> UNITS "degrees Celsius" (Page 18)

Same comment as above regarding the precision.

> 8.1. Writable Notification thresholds (Page 23)

I favor allowing the thresholds to be settable by the EnMS.=

From Rolf.Winter@neclab.eu  Thu Jul 28 09:50:35 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C608D11E80B2 for ; Thu, 28 Jul 2011 09:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.379
X-Spam-Level: 
X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 H9bn8D981-ns for ; Thu, 28 Jul 2011 09:50:35 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id DB14711E8096 for ; Thu, 28 Jul 2011 09:50:34 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 11B3C2800032F; Thu, 28 Jul 2011 18:50:34 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEyWVW5e+731; Thu, 28 Jul 2011 18:50:33 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id E5C4B280001AA; Thu, 28 Jul 2011 18:50:13 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.20]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Thu, 28 Jul 2011 18:50:14 +0200
From: Rolf Winter 
To: "John Parello (jparello)" , Bruce Nordman , "Benoit Claise (bclaise)" 
Thread-Topic: [eman] [EMAN-BATTERY]: power state set
Thread-Index: AcxNQTe4FwOnHp6xr02PkBOjIvpuVQAAjV/CAABZH7A=
Date: Thu, 28 Jul 2011 16:50:13 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D1D033326@DAPHNIS.office.hd>
References: <4E30D605.6000400@cisco.com><8F79AC58-23C4-4D5C-BB61-CADBAD084612@quittek.at><791AD3077F94194BB2BDD13565B6295D1D031EA5@DAPHNIS.office.hd><4E318194.1060506@cisco.com>  
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.7.0.197]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: eman mailing list 
Subject: Re: [eman] [EMAN-BATTERY]: power state set
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 16:50:35 -0000

I think these states are completely independent. Take the three power state=
s on, sleep, off and the charging states charging, discharging, maintaining=
 charge. Which ones are dependent on each other? I think any of these combi=
nations work. Answering Benoit's question, I believe these are orthogonal.

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London =
W3 6BL | Registered in England 2832014=20


> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> John Parello (jparello)
> Sent: Donnerstag, 28. Juli 2011 18:29
> To: Bruce Nordman; Benoit Claise (bclaise)
> Cc: eman mailing list
> Subject: Re: [eman] [EMAN-BATTERY]: power state set
>=20
>=20
> OK but thinking about it. I'm not sure the battery state is independent
> of the device in all cases.
>=20
> Tablet example. We refer to them as on, off, charging, etc. We don't
> say the device is on and the battery is off. It's merged.
>=20
> So while I agree they can be separate we have to allow for the case
> when they are combined as well.
>=20
> Jp
>=20
>=20
>=20
> -----Original Message-----
> From: eman-bounces@ietf.org on behalf of Bruce Nordman
> Sent: Thu 7/28/2011 9:12 AM
> To: Benoit Claise (bclaise)
> Cc: eman mailing list
> Subject: Re: [eman] [EMAN-BATTERY]: power state set
>=20
> On Thu, Jul 28, 2011 at 11:34 AM, Benoit Claise 
> wrote:
>=20
> > Rolf,
> >
> >  +1
> >>
> >> The problem is that the power states of a "regular" device conflate
> >> operational state information and energy related state information.
> >> The battery charging state does not I in the same way.
> >>
> > This is actually my question.
> > Is the battery power state set orthogonal to the other 3 power state
> sets?
> >
>=20
> A power state is (in principle) something independent of the device (or
> component) type.
> It is universal.
>=20
> The battery state is specific to a single type of component
>=20
> I can imagine setting a power state for a battery to "off": to
> electrically disconnect it to prevent charging or discharging (this
> might be done prior to removal for example).  In this case, a battery
> would want both a power state and a charging state (the power state
> variable would be in the other MIB so not added to the Battery MIB).
>=20
> If new battery states might be needed, how about simply having a
> registry of the current states so that individual states could be added,
> rather than entire new series as we have with power states.  This would
> give flexibility to add in future with minimal complexity, and not
> conflate with power states.
>=20
> --Bruce
>=20
> >
> > Regards, Benoit.
> >
> > ...
> >
> --
> *Bruce Nordman*
> Lawrence Berkeley National Laboratory
> eetd.lbl.gov/ea/nordman
> BNordman@LBL.gov
> 510-486-7089
> m: 510-501-7943
>=20
>=20


From bnordman@lbl.gov  Thu Jul 28 10:01:21 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C28B11E80B2 for ; Thu, 28 Jul 2011 10:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.84
X-Spam-Level: 
X-Spam-Status: No, score=-5.84 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7t4yQ0Lg+Hfp for ; Thu, 28 Jul 2011 10:01:20 -0700 (PDT)
Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 709E221F8B88 for ; Thu, 28 Jul 2011 10:01:20 -0700 (PDT)
X-Ironport-SBRS: 4.4
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApkBAGiVMU7RVdW0kGdsb2JhbAA0AQEBAQIBAQEBEQJkEAoCDAQHAwInGxQMBwUOAQUBJAcBFieCNpxmiBYIFAEBAQEJCQ0HFAQhiHwEpSIKnRsCgzuDBASSeYxMPIN4
X-IronPort-AV: E=Sophos;i="4.67,283,1309762800"; d="scan'208";a="47137179"
Received: from mail-yx0-f180.google.com ([209.85.213.180]) by ironport4.lbl.gov with ESMTP; 28 Jul 2011 10:01:19 -0700
Received: by mail-yx0-f180.google.com with SMTP id 30so2522054yxk.39 for ; Thu, 28 Jul 2011 10:01:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.116.5 with SMTP id o5mr215371anc.60.1311872479172; Thu, 28 Jul 2011 10:01:19 -0700 (PDT)
Received: by 10.100.241.8 with HTTP; Thu, 28 Jul 2011 10:01:19 -0700 (PDT)
In-Reply-To: <20110728164503.GA30392@elstar.local>
References: <20110728164503.GA30392@elstar.local>
Date: Thu, 28 Jul 2011 13:01:19 -0400
Message-ID: 
From: Bruce Nordman 
To: Juergen Schoenwaelder , eman@ietf.org
Content-Type: multipart/alternative; boundary=0016e644d62a1c97f004a9241d16
Subject: Re: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 17:01:21 -0000

--0016e644d62a1c97f004a9241d16
Content-Type: text/plain; charset=ISO-8859-1

I'm not a MIB person, but assuming this is the desired
structure, sets for ACPI and the Printer group should
be added, and EMAN dropped.

For 1621, it also defines "Unplugged" (today I would have
instead called it "Disconnected") to refer to a subset of
Off when not mains-connected (a battery powered device
could be On or in Sleep when unplugged).  This probably
worth adding.
Also, 1621 is specifically scoped to electronic devices,
and for non-electronic ones, "Ready" is a common power
state. It would be convenient to include Ready as an
expansion of 1621.  It is not defined, but is mentioned
in the text as a form of On, along with Active.


Thanks,

--Bruce



On Thu, Jul 28, 2011 at 12:45 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Hi,
>
> here is a proposal for an IANA maintained power state textual
> convention. There are of course other ways of doing this but I thought
> a concrete proposal might help the discussion.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>
>


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

--0016e644d62a1c97f004a9241d16
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'm not a MIB person, but assuming this is the desired
structure, se=
ts for ACPI and the Printer group should
be added, and EMAN dropped.
=

For 1621, it also defines "Unplugged" (today I would have

instead called it "Disconnected") to refer to a subset of
Off =
when not mains-connected (a battery powered device
could be On or in Sle=
ep when unplugged).=A0 This probably
worth adding.
Also, 1621 is spec=
ifically scoped to electronic devices,

and for non-electronic ones, "Ready" is a common power
state. =
It would be convenient to include Ready as an
expansion of 1621.=A0 It i=
s not defined, but is mentioned
in the text as a form of On, along with =
Active.



Thanks,

--Bruce



On=
 Thu, Jul 28, 2011 at 12:45 PM, Juergen Schoenwaelder <=
;j.schoenwaelder@ja=
cobs-university.de> wrote:


Hi,



here is a proposal for an IANA maintained power state textual

convention. There are of course other ways of doing this but I thought

a concrete proposal might help the discussion.



/js



--

Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH
Phone: +49=
 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany

Fax: =A0 +=
49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>


_______________________________________________

eman mailing list

eman@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/eman





-- 
Bruce Nordman
Lawrence =
Berkeley National Laboratory
eetd.lbl.gov/ea/nordman

BNordman@LBL.gov
510-486-7089
m: 510-501-7943



--0016e644d62a1c97f004a9241d16--

From bill.mielke@alcatel-lucent.com  Thu Jul 28 10:03:30 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF6511E80B2 for ; Thu, 28 Jul 2011 10:03:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIMry1RLdKqr for ; Thu, 28 Jul 2011 10:03:29 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF8321F8B9A for ; Thu, 28 Jul 2011 10:03:29 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p6SH3ROh023617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2011 12:03:27 -0500 (CDT)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6SH3Qrn017023 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Jul 2011 12:03:26 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 28 Jul 2011 12:03:26 -0500
From: "Mielke, William F (Bill)" 
To: Benoit Claise , Bruce Nordman 
Date: Thu, 28 Jul 2011 12:03:15 -0500
Thread-Topic: [eman] terminology Energy Managed Object versus Powered Device
Thread-Index: AcxNQS2PUViBHpajQ0Oxs6qPoKSFGwABwmog
Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DDEA@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References:   <4E318A6E.104@cisco.com>
In-Reply-To: <4E318A6E.104@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DDEAUSNAVSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Cc: "eman@ietf.org" 
Subject: Re: [eman] terminology Energy Managed Object versus Powered Device
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, 28 Jul 2011 17:03:31 -0000

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

+1 for what Bruce said.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein



________________________________
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Ben=
oit Claise
Sent: Thursday, July 28, 2011 12:13 PM
To: Bruce Nordman
Cc: eman@ietf.org
Subject: Re: [eman] terminology Energy Managed Object versus Powered Device

Dear all,

If I have to compare "powered device" versus "energy managed object", I ten=
d to prefer the latter, as:
1. managed object is a well known term. It's "just" that we deal with power=
/energy. So we have to be more specific.
2. energy managed object is more generic. For example, we will model a mete=
r. Is this a "powered device"? It's more a "energy managed device" that met=
er something for someone.
The current definition of an EMO begins:

An Energy Managed Object (EMO) is a device that is part of or
        attached to a communications network...

So, I took that to mean an integral device, like a computer, switch, router=
, etc. that
has a power cord and network interfaces.  I use "device" to refer to this c=
oncept.
I know that EMAN Is to report on either entire devices, or components of de=
vices,
and "entity" can be used to reference the combination of devices and compon=
ents
in line with the Entity MIB name.  A Power Interface is also a type of enti=
ty, since
it is a component and there is measurement and control for that just as wit=
h any
other component.

So, regardless of what terms are used, we need terms that are synonyms for
powered device, component, entity, and power interface.
So your point is that we need a generic term, right?
I believe we should have a generic term, and if you want to know if this is=
 box, a line card, a port, a battery, etc... then you refer to the ENTITY-M=
IB
An assumption I am making is that an entire device has some characteristics
(important ones reflected in the MIB structure) different from a component.
Yes.

Regards, Benoit.

I think it is very easy for people to accidentally misinterpret what EMO is
referring to - a device, a component, an entity, or even a software object.
I also prefer shorter terms.

A cross-cutting question would seem to be whether things are named based
on what they are, or by what is being done to them.  Dictionary.com indicat=
es
that management is about control.  Many EMAN entities will support control
and others will not.  Are the ones that don't do control being managed?
Not using the 'manage' term avoids that question.


On Wed, Jul 27, 2011 at 2:59 PM, John Parello (jparello) > wrote:
Hi,

I saw a few threads where we discussed this and I want to pull it to its
own thread.

In the framework I referred to an Energy Managed Object. I got some
feedback and in the alternate ref draft Theresa notion of powered
device.

I like the concept of having a device and power interface similar to the
communication notion of device and interface.

When managing these element however we typically use the term managed
object. That boils down to something you give a unique identifier to and
then manage. This can be interfaces, virtual interfaces, devices,
motherboards etc.

I'd like to use that same notion here with an generic Energy Managed
Object. That was we can model and uniquely identify logical objects
(outlets, inlets, interfaces, etc) as well as physical.

So I think EMO is a better term.

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



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




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



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







+1 for what Bruce said.


William F.=20
Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200=
 East=20
Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email:=20
Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628Fax: 614=20
367 5965

"Live like you're going to die tomorrow.
 Learn lik=
e=20
you're going to live forever."

    - Albert=20
Einstein 


 



  

  

  From: eman-bounces@ietf.org=20
  [mailto:eman-bounces@ietf.org] On Behalf Of Benoit=20
  Claise
Sent: Thursday, July 28, 2011 12:13 PM
To: Bru=
ce=20
  Nordman
Cc: eman@ietf.org
Subject: Re: [eman] termino=
logy=20
  Energy Managed Object versus Powered Device


  
Dear all,

If I have to compare "powered device" versus=
=20
  "energy managed object", I tend to prefer the latter, as:
1. managed o=
bject=20
  is a well known term. It's "just" that we deal with power/energy. So we h=
ave=20
  to be more specific.
2. energy managed object is more generic. For exa=
mple,=20
  we will model a meter. Is this a "powered device"? It's more a "energy ma=
naged=20
  device" that meter something for someone.

  The current definition of an EMO begins:
An Energy =
Managed Object (EMO) is a device that is part of or=20
        attached to a communications network...
So, I took that to mea=
n=20
    an integral device, like a computer, switch, router, etc. that
has a=
=20
    power cord and network interfaces.  I use "device" to refer to thi=
s=20
    concept.
I know that EMAN Is to report on either entire devices, or=
=20
    components of devices,
and "entity" can be used to reference the=20
    combination of devices and components
in line with the Entity MIB=20
    name.  A Power Interface is also a type of entity, since
it is =
a=20
    component and there is measurement and control for that just as with=20
    any
other component.

So, regardless of what terms are used=
, we=20
    need terms that are synonyms for
powered device, component, entity, and power interface.
So=20
  your point is that we need a generic term, right?
I believe we should =
have=20
  a generic term, and if you want to know if this is box, a line card, a po=
rt, a=20
  battery, etc... then you refer to the ENTITY-MIB

  An assumption I am making is that an entire device has some=
=20
    characteristics
(important ones reflected in the MIB structure) diff=
erent=20
    from a component.
Yes. 

Regards, Benoit.

  
I think it is very easy for people to accidentally=20
    misinterpret what EMO is
referring to - a device, a component, an en=
tity,=20
    or even a software object.
I also prefer shorter terms.

A=20
    cross-cutting question would seem to be whether things are named based<=
BR>on=20
    what they are, or by what is being done to them.  Dictionary.com=20
    indicates
that management is about control.  Many EMAN entities=
 will=20
    support control
and others will not.  Are the ones that don't d=
o=20
    control being managed?
Not using the 'manage' term avoids that=20
    question.



    
On Wed, Jul 27, 2011 at 2:59 PM, John Parello=
=20
    (jparello) <jparello@cisco.com> wrote:

    Hi,

I saw a few threads where we discussed t=
his=20
      and I want to pull it to its
own thread.

In the framework I=
=20
      referred to an Energy Managed Object. I got some
feedback and in t=
he=20
      alternate ref draft Theresa notion of powered
device.

I lik=
e the=20
      concept of having a device and power interface similar to=20
      the
communication notion of device and interface.

When mana=
ging=20
      these element however we typically use the term managed
object. Th=
at=20
      boils down to something you give a unique identifier to and
then=20
      manage. This can be interfaces, virtual interfaces,=20
      devices,
motherboards etc.

I'd like to use that same notion=
 here=20
      with an generic Energy Managed
Object. That was we can model and=20
      uniquely identify logical objects
(outlets, inlets, interfaces, et=
c) as=20
      well as physical.

So I think EMO is a better=20
      term.

Thoughts?
Jp
_____________________________________=
__________
eman=20
      mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman


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



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




--_000_0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DDEAUSNAVSXCHMBSA_--

From bill.mielke@alcatel-lucent.com  Thu Jul 28 10:04:56 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA7021F8BA4 for ; Thu, 28 Jul 2011 10:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UujYKGeJ0osG for ; Thu, 28 Jul 2011 10:04:55 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2074821F8B9F for ; Thu, 28 Jul 2011 10:04:55 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p6SH4rBI002958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2011 12:04:53 -0500 (CDT)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6SH4q4C017783 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Jul 2011 12:04:52 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 28 Jul 2011 12:04:52 -0500
From: "Mielke, William F (Bill)" 
To: "Mielke, William F (Bill)" , Benoit Claise , Bruce Nordman 
Date: Thu, 28 Jul 2011 12:04:41 -0500
Thread-Topic: [eman] terminology Energy Managed Object versus Powered Device
Thread-Index: AcxNQS2PUViBHpajQ0Oxs6qPoKSFGwABwmogAAANZYA=
Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DDEC@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References:   <4E318A6E.104@cisco.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DDECUSNAVSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Cc: "eman@ietf.org" 
Subject: Re: [eman] terminology Energy Managed Object versus Powered Device
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, 28 Jul 2011 17:04:56 -0000

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

Oops, I mean what Benoit said.  :)

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein



________________________________
From: Mielke, William F (Bill)
Sent: Thursday, July 28, 2011 1:03 PM
To: 'Benoit Claise'; Bruce Nordman
Cc: eman@ietf.org
Subject: RE: [eman] terminology Energy Managed Object versus Powered Device

+1 for what Bruce said.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein



________________________________
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Ben=
oit Claise
Sent: Thursday, July 28, 2011 12:13 PM
To: Bruce Nordman
Cc: eman@ietf.org
Subject: Re: [eman] terminology Energy Managed Object versus Powered Device

Dear all,

If I have to compare "powered device" versus "energy managed object", I ten=
d to prefer the latter, as:
1. managed object is a well known term. It's "just" that we deal with power=
/energy. So we have to be more specific.
2. energy managed object is more generic. For example, we will model a mete=
r. Is this a "powered device"? It's more a "energy managed device" that met=
er something for someone.
The current definition of an EMO begins:

An Energy Managed Object (EMO) is a device that is part of or
        attached to a communications network...

So, I took that to mean an integral device, like a computer, switch, router=
, etc. that
has a power cord and network interfaces.  I use "device" to refer to this c=
oncept.
I know that EMAN Is to report on either entire devices, or components of de=
vices,
and "entity" can be used to reference the combination of devices and compon=
ents
in line with the Entity MIB name.  A Power Interface is also a type of enti=
ty, since
it is a component and there is measurement and control for that just as wit=
h any
other component.

So, regardless of what terms are used, we need terms that are synonyms for
powered device, component, entity, and power interface.
So your point is that we need a generic term, right?
I believe we should have a generic term, and if you want to know if this is=
 box, a line card, a port, a battery, etc... then you refer to the ENTITY-M=
IB
An assumption I am making is that an entire device has some characteristics
(important ones reflected in the MIB structure) different from a component.
Yes.

Regards, Benoit.

I think it is very easy for people to accidentally misinterpret what EMO is
referring to - a device, a component, an entity, or even a software object.
I also prefer shorter terms.

A cross-cutting question would seem to be whether things are named based
on what they are, or by what is being done to them.  Dictionary.com indicat=
es
that management is about control.  Many EMAN entities will support control
and others will not.  Are the ones that don't do control being managed?
Not using the 'manage' term avoids that question.


On Wed, Jul 27, 2011 at 2:59 PM, John Parello (jparello) > wrote:
Hi,

I saw a few threads where we discussed this and I want to pull it to its
own thread.

In the framework I referred to an Energy Managed Object. I got some
feedback and in the alternate ref draft Theresa notion of powered
device.

I like the concept of having a device and power interface similar to the
communication notion of device and interface.

When managing these element however we typically use the term managed
object. That boils down to something you give a unique identifier to and
then manage. This can be interfaces, virtual interfaces, devices,
motherboards etc.

I'd like to use that same notion here with an generic Energy Managed
Object. That was we can model and uniquely identify logical objects
(outlets, inlets, interfaces, etc) as well as physical.

So I think EMO is a better term.

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



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




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



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









Oops, I mean what Benoit said. =20
:)


William F.=20
Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200=
 East=20
Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email:=20
Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628Fax: 614=20
367 5965

"Live like you're going to die tomorrow.
 Learn lik=
e=20
you're going to live forever."

    - Albert=20
Einstein 


 



  

  

  From: Mielke, William F (Bill)=20
  
Sent: Thursday, July 28, 2011 1:03 PM
To: 'Benoit=20
  Claise'; Bruce Nordman
Cc: eman@ietf.org
Subject: RE:=
=20
  [eman] terminology Energy Managed Object versus Powered=20
  Device


  

  
+1 for what Bruce said.

  
William F.=20
  Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
62=
00=20
  East Broad Street
Room: 4B01-1V
Columbus, OH =20
  43213-1530
Email: Bill.Mielke@alcatel-lucent.com=

Phone: 614 367 5628<=
BR>Fax: 614=20
  367 5965

"Live like you're going to die tomorrow.
 Learn l=
ike=20
  you're going to live forever."

    - Albert=20
  Einstein 

  
 


  
    

    

    From: eman-bounces@ietf.org=20
    [mailto:eman-bounces@ietf.org] On Behalf Of Benoit=20
    Claise
Sent: Thursday, July 28, 2011 12:13 PM
To: B=
ruce=20
    Nordman
Cc: eman@ietf.org
Subject: Re: [eman]=20
    terminology Energy Managed Object versus Powered Device

<=
/DIV>
    
Dear all,

If I have to compare "powered device" versu=
s=20
    "energy managed object", I tend to prefer the latter, as:
1. managed=
=20
    object is a well known term. It's "just" that we deal with power/energy=
. So=20
    we have to be more specific.
2. energy managed object is more generi=
c.=20
    For example, we will model a meter. Is this a "powered device"? It's mo=
re a=20
    "energy managed device" that meter something for someone.

    The current definition of an EMO begins:
An Energ=
y Managed Object (EMO) is a device that is part of or=20
        attached to a communications network...
So, I took that to=20
      mean an integral device, like a computer, switch, router, etc. thathas=20
      a power cord and network interfaces.  I use "device" to refer to=
 this=20
      concept.
I know that EMAN Is to report on either entire devices, o=
r=20
      components of devices,
and "entity" can be used to reference the=20
      combination of devices and components
in line with the Entity MIB=
=20
      name.  A Power Interface is also a type of entity, since
it i=
s a=20
      component and there is measurement and control for that just as with=
=20
      any
other component.

So, regardless of what terms are us=
ed,=20
      we need terms that are synonyms for
powered device, component, entity, and power interface.
So=20
    your point is that we need a generic term, right?
I believe we shoul=
d=20
    have a generic term, and if you want to know if this is box, a line car=
d, a=20
    port, a battery, etc... then you refer to the ENTITY-MIB

    An assumption I am making is that an entire device has so=
me=20
      characteristics
(important ones reflected in the MIB structure)=20
      different from a component.
Yes. 

Regards,=20
Benoit.

    
I think it is very easy for people to accidentally=20
      misinterpret what EMO is
referring to - a device, a component, an=
=20
      entity, or even a software object.
I also prefer shorter=20
      terms.

A cross-cutting question would seem to be whether thing=
s are=20
      named based
on what they are, or by what is being done to them.&nb=
sp;=20
      Dictionary.com indicates
that management is about control.  M=
any=20
      EMAN entities will support control
and others will not.  Are =
the=20
      ones that don't do control being managed?
Not using the 'manage' t=
erm=20
      avoids that question.



      
On Wed, Jul 27, 2011 at 2:59 PM, John Parell=
o=20
      (jparello) <jparello@cisco.com> wrote:

      Hi,

I saw a few threads where we discussed=
 this=20
        and I want to pull it to its
own thread.

In the framework=
 I=20
        referred to an Energy Managed Object. I got some
feedback and in=
 the=20
        alternate ref draft Theresa notion of powered
device.

I l=
ike=20
        the concept of having a device and power interface similar to=20
        the
communication notion of device and interface.

When=20
        managing these element however we typically use the term=20
        managed
object. That boils down to something you give a unique=20
        identifier to and
then manage. This can be interfaces, virtual=20
        interfaces, devices,
motherboards etc.

I'd like to use th=
at=20
        same notion here with an generic Energy Managed
Object. That was=
 we=20
        can model and uniquely identify logical objects
(outlets, inlets=
,=20
        interfaces, etc) as well as physical.

So I think EMO is a be=
tter=20
        term.

Thoughts?
Jp
___________________________________=
____________
eman=20
        mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman=



-- 
Bruce Nordman
=
Lawrence Berkeley National=20
      Laboratory
eetd.lbl.gov/ea/nordman<=
BR>BNordman@LBL.gov
510-486-7089=

m:=20
      510-501-7943



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




--_000_0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DDECUSNAVSXCHMBSA_--

From bill.mielke@alcatel-lucent.com  Thu Jul 28 10:12:58 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828AD21F8BAE for ; Thu, 28 Jul 2011 10:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfAIT8KvMBR7 for ; Thu, 28 Jul 2011 10:12:57 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8D36721F8865 for ; Thu, 28 Jul 2011 10:12:57 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p6SHCr39000106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Jul 2011 12:12:54 -0500 (CDT)
Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6SHCr2i022848 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 28 Jul 2011 12:12:53 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 28 Jul 2011 12:12:53 -0500
From: "Mielke, William F (Bill)" 
To: eman mailing list 
Date: Thu, 28 Jul 2011 12:12:47 -0500
Thread-Topic: [eman] [EMAN-BATTERY]: power state set
Thread-Index: AcxNQTe4FwOnHp6xr02PkBOjIvpuVQAAjV/CAABZH7AAAQ434A==
Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DDF2@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: <4E30D605.6000400@cisco.com><8F79AC58-23C4-4D5C-BB61-CADBAD084612@quittek.at><791AD3077F94194BB2BDD13565B6295D1D031EA5@DAPHNIS.office.hd><4E318194.1060506@cisco.com>   <791AD3077F94194BB2BDD13565B6295D1D033326@DAPHNIS.office.hd>
In-Reply-To: <791AD3077F94194BB2BDD13565B6295D1D033326@DAPHNIS.office.hd>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
Subject: Re: [eman] [EMAN-BATTERY]: power state set
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 17:12:58 -0000

+1  I believe that the two sets of states are orthogonal.

When people talk about a device charging they are simply being imprecise an=
d conflating the two.  It is an artifact of informal speech.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

=20

> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20
> Behalf Of Rolf Winter
> Sent: Thursday, July 28, 2011 12:50 PM
> To: John Parello (jparello); Bruce Nordman; Benoit Claise (bclaise)
> Cc: eman mailing list
> Subject: Re: [eman] [EMAN-BATTERY]: power state set
>=20
> I think these states are completely independent. Take the=20
> three power states on, sleep, off and the charging states=20
> charging, discharging, maintaining charge. Which ones are=20
> dependent on each other? I think any of these combinations=20
> work. Answering Benoit's question, I believe these are orthogonal.
>=20
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria=20
> Road, London W3 6BL | Registered in England 2832014=20
>=20
>=20
> > -----Original Message-----
> > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org]=20
> On Behalf Of
> > John Parello (jparello)
> > Sent: Donnerstag, 28. Juli 2011 18:29
> > To: Bruce Nordman; Benoit Claise (bclaise)
> > Cc: eman mailing list
> > Subject: Re: [eman] [EMAN-BATTERY]: power state set
> >=20
> >=20
> > OK but thinking about it. I'm not sure the battery state is=20
> independent
> > of the device in all cases.
> >=20
> > Tablet example. We refer to them as on, off, charging, etc. We don't
> > say the device is on and the battery is off. It's merged.
> >=20
> > So while I agree they can be separate we have to allow for the case
> > when they are combined as well.
> >=20
> > Jp
> >=20
> >=20
> >=20
> > -----Original Message-----
> > From: eman-bounces@ietf.org on behalf of Bruce Nordman
> > Sent: Thu 7/28/2011 9:12 AM
> > To: Benoit Claise (bclaise)
> > Cc: eman mailing list
> > Subject: Re: [eman] [EMAN-BATTERY]: power state set
> >=20
> > On Thu, Jul 28, 2011 at 11:34 AM, Benoit Claise 
> > wrote:
> >=20
> > > Rolf,
> > >
> > >  +1
> > >>
> > >> The problem is that the power states of a "regular"=20
> device conflate
> > >> operational state information and energy related state=20
> information.
> > >> The battery charging state does not I in the same way.
> > >>
> > > This is actually my question.
> > > Is the battery power state set orthogonal to the other 3=20
> power state
> > sets?
> > >
> >=20
> > A power state is (in principle) something independent of=20
> the device (or
> > component) type.
> > It is universal.
> >=20
> > The battery state is specific to a single type of component
> >=20
> > I can imagine setting a power state for a battery to "off": to
> > electrically disconnect it to prevent charging or discharging (this
> > might be done prior to removal for example).  In this case,=20
> a battery
> > would want both a power state and a charging state (the power state
> > variable would be in the other MIB so not added to the Battery MIB).
> >=20
> > If new battery states might be needed, how about simply having a
> > registry of the current states so that individual states=20
> could be added,
> > rather than entire new series as we have with power states.=20
>  This would
> > give flexibility to add in future with minimal complexity, and not
> > conflate with power states.
> >=20
> > --Bruce
> >=20
> > >
> > > Regards, Benoit.
> > >
> > > ...
> > >
> > --
> > *Bruce Nordman*
> > Lawrence Berkeley National Laboratory
> > eetd.lbl.gov/ea/nordman
> > BNordman@LBL.gov
> > 510-486-7089
> > m: 510-501-7943
> >=20
> >=20
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
> =

From bill.mielke@alcatel-lucent.com  Thu Jul 28 10:26:57 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E5E11E80FE for ; Thu, 28 Jul 2011 10:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS7ii6W809Lu for ; Thu, 28 Jul 2011 10:26:56 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 846B911E80E5 for ; Thu, 28 Jul 2011 10:26:56 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p6SHQtWe012913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Jul 2011 12:26:56 -0500 (CDT)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6SHQtSp031598 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 28 Jul 2011 12:26:55 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 28 Jul 2011 12:26:55 -0500
From: "Mielke, William F (Bill)" 
To: eman mailing list 
Date: Thu, 28 Jul 2011 12:26:46 -0500
Thread-Topic: Comments on draft-ietf-eman-battery-mib-02
Thread-Index: AcxNRbrVKfOWwDrTR1+ULn8i42RuxQABVBnQ
Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DE05@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DDD0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DDD0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
Subject: Re: [eman] Comments on draft-ietf-eman-battery-mib-02
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, 28 Jul 2011 17:26:57 -0000

Based on the feedback I have received it seems that setting the level of pr=
ecision for temperature measurements at deci-degrees would be appropriate b=
ased on experience with existing systems.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

=20

> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20
> Behalf Of Mielke, William F (Bill)
> Sent: Thursday, July 28, 2011 12:45 PM
> To: eman mailing list
> Subject: [eman] Comments on draft-ietf-eman-battery-mib-02
>=20
> Provided below.  I will forward a copy of my annotated PDF=20
> file to the authors.  The PDF version also includes some=20
> minor corrections/suggestions which are not reproduced below.
>=20
> William F. Mielke
> Alcatel-Lucent
> Distinguished Member of Technical Staff
> 6200 East Broad Street
> Room: 4B01-1V
> Columbus, OH  43213-1530
> Email: Bill.Mielke@alcatel-lucent.com
> Phone: 614 367 5628
> Fax: 614 367 5965
>=20
> "Live like you're going to die tomorrow.
>  Learn like you're going to live forever."
>=20
>     - Albert Einstein
>=20
> ----------------------------------------------------------------
> Comments on draft-ietf-eman-battery-mib-02
> ----------------------------------------------------------------
>=20
> General Comments:
>=20
> 1. I believe that the definitions for the following terms=20
> should be adjusted to clarify their intent.  I was confused=20
> after reading the current definitions in the document but=20
> after some thought I believe that the intended use of these=20
> is as follows:
>=20
> batteryNominalCapacity:
>=20
> This represents the manufacturer's static design capacity for=20
> the battery.  It is the rated or nameplate value advertised=20
> by the manufacturer.  It is a static number.
>=20
> batteryActualCapacity:
>=20
> This represents the same value as batteryNominalCapacity only=20
> it has been adjusted to account for the age and historical=20
> usage of the battery both of which degrade its capacity below=20
> its nominal rating.  It is a dynamic estimate.
>=20
> batteryCurrentCharge:
>=20
> This represents the amount of energy which is estimated to be=20
> remaining in the battery at any given point in time.  It is a=20
> dynamic estimate.
>=20
> Are these the correct interpretations?
>=20
> 2. In general I think that this is in pretty good shape.
>=20
> Deatiled Comments:
>=20
> > The Battery MIB module serves for monitoring the battery status. It
> > does not implement a Power Monitor as defined in the framework for
> > energy management [I-D.ietf-eman-framework]. (Page 3)
>=20
> Adjust to match the replacement terminology for "Power Monitor".
>=20
> > batteryTemperature OBJECT-TYPE
> > SYNTAX Integer32
> > UNITS "degrees Celsius" (Page 16)
>=20
> I don't know the level of precision required here, but I=20
> suspect some level of fractional degrees would be=20
> appropriate.  Should we consider deci-degrees, centi-degrees,=20
> or even milli-degrees?  I would expect deci- or centi- would=20
> be appropriate but I have no expertise to back that up.  I=20
> will inquire about this with our SMEs and get back to you.
>=20
> > batteryReplacementAlarmCycles OBJECT-TYPE
> > SYNTAX Unsigned32
> > UNITS "milliampere hours" (Page 18)
>=20
> This is simply a count, no?  So no units at all.  :)
>=20
> > batteryHighAlarmTemperature OBJECT-TYPE
> > SYNTAX Integer32
> > UNITS "degrees Celsius" (Page 18)
>=20
> Same comment as above regarding the precision.
>=20
> > 8.1. Writable Notification thresholds (Page 23)
>=20
> I favor allowing the thresholds to be settable by the EnMS.
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
> =

From jparello@cisco.com  Thu Jul 28 10:27:29 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65AB11E80FB for ; Thu, 28 Jul 2011 10:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.807
X-Spam-Level: 
X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5x1TrnnYozi for ; Thu, 28 Jul 2011 10:27:29 -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 2329711E80E5 for ; Thu, 28 Jul 2011 10:27:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=5475; q=dns/txt; s=iport; t=1311874047; x=1313083647; h=mime-version:subject:date:message-id:references:from:to; bh=u3eTxYaI/9zi76hOr8I6oaf3M2B1zb2n00OcmAt7a5Q=; b=IpQOE0eX/CoXb/ab+HL+M0V2y8D8bmjdUonJQXlb0aAC/MVN6ag9VWPG WkrW2tBBR9csDXAS3ShiG1Zz+VymDmZtcDDam3eZOPRLrEBQvtMyOL6Xb 7NWnVkHff5jMKzLr0sEbstPgmtzrTlQg6tkPSWAagqOI7JVjV+QlusEHr A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAOGaMU6rRDoH/2dsb2JhbAA0AQEBAQIBAQEBEQEMEgNEEAcDAgIBCQQKAgEEAQELBg8VBgETDAwxCAEBBQEWDBunOneIfASkFJ5PAoM7giVfBIcqL5Awi3Q
X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208,217";a="7462958"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 28 Jul 2011 17:27:26 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6SHRQkV007576; Thu, 28 Jul 2011 17:27:26 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 28 Jul 2011 10:27:26 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4D4B.9E1BE7B6"
Date: Thu, 28 Jul 2011 10:26:12 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] iana powerstate tc proposal
Thread-Index: AcxNSF9a6XFdaZT2QeiSM2va7f4K6gAAxNeV
References: <20110728164503.GA30392@elstar.local> 
From: "John Parello (jparello)" 
To: "Bruce Nordman" , "Juergen Schoenwaelder" , 
X-OriginalArrivalTime: 28 Jul 2011 17:27:26.0060 (UTC) FILETIME=[9E4C7AC0:01CC4D4B]
Subject: Re: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 17:27:30 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4D4B.9E1BE7B6
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Disconneted, Unplugged is more precisely defined as mechanical-off.

Once you add these and a ready state you get very close to the eman =
states we proposed.

I like keeping to the spirit of ou 1621 as three states and then setting =
up DMTF and EMAN with the full spectrum.

Jp



-----Original Message-----
From: eman-bounces@ietf.org on behalf of Bruce Nordman
Sent: Thu 7/28/2011 10:01 AM
To: Juergen Schoenwaelder; eman@ietf.org
Subject: Re: [eman] iana powerstate tc proposal
=20
I'm not a MIB person, but assuming this is the desired
structure, sets for ACPI and the Printer group should
be added, and EMAN dropped.

For 1621, it also defines "Unplugged" (today I would have
instead called it "Disconnected") to refer to a subset of
Off when not mains-connected (a battery powered device
could be On or in Sleep when unplugged).  This probably
worth adding.
Also, 1621 is specifically scoped to electronic devices,
and for non-electronic ones, "Ready" is a common power
state. It would be convenient to include Ready as an
expansion of 1621.  It is not defined, but is mentioned
in the text as a form of On, along with Active.


Thanks,

--Bruce



On Thu, Jul 28, 2011 at 12:45 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Hi,
>
> here is a proposal for an IANA maintained power state textual
> convention. There are of course other ways of doing this but I thought
> a concrete proposal might help the discussion.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>
>


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


------_=_NextPart_001_01CC4D4B.9E1BE7B6
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [eman] iana powerstate tc proposal







Disconneted, Unplugged is more precisely defined as =
mechanical-off.



Once you add these and a ready state you get very close to the eman =
states we proposed.



I like keeping to the spirit of ou 1621 as three states and then setting =
up DMTF and EMAN with the full spectrum.



Jp







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

From: eman-bounces@ietf.org on behalf of Bruce Nordman

Sent: Thu 7/28/2011 10:01 AM

To: Juergen Schoenwaelder; eman@ietf.org

Subject: Re: [eman] iana powerstate tc proposal



I'm not a MIB person, but assuming this is the desired

structure, sets for ACPI and the Printer group should

be added, and EMAN dropped.



For 1621, it also defines "Unplugged" (today I would have

instead called it "Disconnected") to refer to a subset of

Off when not mains-connected (a battery powered device

could be On or in Sleep when unplugged).  This probably

worth adding.

Also, 1621 is specifically scoped to electronic devices,

and for non-electronic ones, "Ready" is a common power

state. It would be convenient to include Ready as an

expansion of 1621.  It is not defined, but is mentioned

in the text as a form of On, along with Active.





Thanks,



--Bruce







On Thu, Jul 28, 2011 at 12:45 PM, Juergen Schoenwaelder <

j.schoenwaelder@jacobs-university.de> wrote:



> Hi,

>

> here is a proposal for an IANA maintained power state textual

> convention. There are of course other ways of doing this but I =
thought

> a concrete proposal might help the discussion.

>

> /js

>

> --

> Juergen =
Schoenwaelder          =
 Jacobs University Bremen gGmbH

> Phone: +49 421 200 =
3587         Campus Ring 1, =
28759 Bremen, Germany

> Fax:   +49 421 200 =
3103         <http://www.jacobs-university.de=
/>

>

> _______________________________________________

> eman mailing list

> eman@ietf.org

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

>

>





--

*Bruce Nordman*

Lawrence Berkeley National Laboratory

eetd.lbl.gov/ea/nordman

BNordman@LBL.gov

510-486-7089

m: 510-501-7943









------_=_NextPart_001_01CC4D4B.9E1BE7B6--

From jparello@cisco.com  Thu Jul 28 10:31:55 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F402D21F8C17 for ; Thu, 28 Jul 2011 10:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level: 
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIiEYJw-JNfw for ; Thu, 28 Jul 2011 10:31:54 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 26D6321F8C13 for ; Thu, 28 Jul 2011 10:31:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=3208; q=dns/txt; s=iport; t=1311874314; x=1313083914; h=mime-version:subject:date:message-id:references:from:to; bh=wa+3pDXZmIUH/R8t89Bnjb0K+uJdnLIxOSZ9Kwo1PRw=; b=Xz/7x892iSmA8QC8O4PM0YkEviYQiI0kKAEHh9pKY0Jtna+VyXa0DR6Y B6iqOA2PiSIDCObRjOyTbjJrmcHt1gm8wmiH3z9rQqkssc5+1tSBZTfOb mgUEc5pvwxEudCsvyQka/gQYnepahMcvNhcuBGxF52UdgnBKis8cRpEOr E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAFCcMU6rRDoJ/2dsb2JhbAA0AQEBAQMUAQwSA1sDAgIBCQQKAgEEAQELBg8VBgETDD0IAQEFARYMG6c6d60Nnk8CgzuCJV8EhyovkDCLdA
X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208,217";a="7465138"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-3.cisco.com with ESMTP; 28 Jul 2011 17:31:53 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6SHVrxT004052 for ; Thu, 28 Jul 2011 17:31:53 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 28 Jul 2011 10:31:53 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4D4C.3D1D5EA1"
Date: Thu, 28 Jul 2011 10:28:57 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] iana powerstate tc proposal
Thread-Index: AcxNRbm99hOCkEX1Q3G73tKJFo3zNwABhsR3
References: <20110728164503.GA30392@elstar.local>
From: "John Parello (jparello)" 
To: "Juergen Schoenwaelder" , 
X-OriginalArrivalTime: 28 Jul 2011 17:31:53.0012 (UTC) FILETIME=[3D6A1F40:01CC4D4C]
Subject: Re: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 17:31:55 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4D4C.3D1D5EA1
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


There was a long discussion on having two indecies. One to represent the =
set and then numbering within the set.

I'd like to see a seperate index for the sets  then numbering withing =
the set as opposed to a single numbered array.

This way it's easy to determine the set you implement. I find this type =
of sparse array very arcane and cumbersome.

There was quite a discussion on that an IIRC a single array was not =
desirable.
Jp

-----Original Message-----
From: eman-bounces@ietf.org on behalf of Juergen Schoenwaelder
Sent: Thu 7/28/2011 9:45 AM
To: eman@ietf.org
Subject: [eman] iana powerstate tc proposal
=20
Hi,

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

/js

--=20
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         


------_=_NextPart_001_01CC4D4C.3D1D5EA1
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [eman] iana powerstate tc proposal







There was a long discussion on having two indecies. =
One to represent the set and then numbering within the set.



I'd like to see a seperate index for the sets  then numbering =
withing the set as opposed to a single numbered array.



This way it's easy to determine the set you implement. I find this type =
of sparse array very arcane and cumbersome.



There was quite a discussion on that an IIRC a single array was not =
desirable.

Jp



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

From: eman-bounces@ietf.org on behalf of Juergen Schoenwaelder

Sent: Thu 7/28/2011 9:45 AM

To: eman@ietf.org

Subject: [eman] iana powerstate tc proposal



Hi,



here is a proposal for an IANA maintained power state textual

convention. There are of course other ways of doing this but I =
thought

a concrete proposal might help the discussion.



/js



--

Juergen =
Schoenwaelder          =
 Jacobs University Bremen gGmbH

Phone: +49 421 200 3587         =
Campus Ring 1, 28759 Bremen, Germany

Fax:   +49 421 200 =
3103         <http://www.jacobs-university.de=
/>









------_=_NextPart_001_01CC4D4C.3D1D5EA1--

From karagian@cs.utwente.nl  Thu Jul 28 10:50:11 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34665E8014 for ; Thu, 28 Jul 2011 10:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level: 
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[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 g8+mXY3oqBpW for ; Thu, 28 Jul 2011 10:50:11 -0700 (PDT)
Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 234FB5E800D for ; Thu, 28 Jul 2011 10:50:10 -0700 (PDT)
Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p6SHm7um025553;  Thu, 28 Jul 2011 19:48:07 +0200 (MEST)
Received: from 130.129.37.54 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 28 Jul 2011 17:50:17 +0000
To: "eman mailing list" 
Date: Thu, 28 Jul 2011 17:50:17 +0000
X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl)
Message-ID: 
From: "Georgios Karagiannis" 
Bounce-To: "Georgios Karagiannis" 
Errors-To: "Georgios Karagiannis" 
MIME-Version: 1.0 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 28 Jul 2011 19:48:16 +0200 (MEST)
Subject: [eman] terminology and monitoring devices that generate energy
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 17:50:11 -0000

Hi all,

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

http://www.ietf.org/id/draft-ietf-eman-framework-02.txt


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

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

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

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

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

  Energy Management Domain

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

Into something like:


  Energy Management Domain

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


Best regards,
Georgios

From jparello@cisco.com  Thu Jul 28 10:55:41 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1F921F8A62 for ; Thu, 28 Jul 2011 10:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.79
X-Spam-Level: 
X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[AWL=-0.192,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGIk8l4t4+wC for ; Thu, 28 Jul 2011 10:55:40 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAD521F8AEC for ; Thu, 28 Jul 2011 10:55:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=6132; q=dns/txt; s=iport; t=1311875738; x=1313085338; h=mime-version:subject:date:message-id:references:from:to; bh=G5pd1OSUUxGdfMigoalY0DU24bIrIvv+4jqO9MgKGDs=; b=DpBTs1IDzful15PM+xg+UGTXnomKkTGugNneisfVqSvB1WlWZ++o06qk Z2Q9TIkpnXlMSPRbgDfVLhaebmNLWjvLGBKw0pQGMrbw/101TTMowTT9V IAiqijmrNKwx2incO4IPGGddkI8fQgM/uK/wnbMy1WFXwYXrRZLXbDv28 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAOihMU6rRDoJ/2dsb2JhbAA0AQEBAQMBAQERAQwSA0QXBQIBCQ4DBAEBCwYkBgETGDEIAQEFARYMARqnOneJAKROnk2FYl8EhyovkDCLdA
X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208,217";a="7474128"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jul 2011 17:55:37 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6SHtUGX027478; Thu, 28 Jul 2011 17:55:36 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 28 Jul 2011 10:55:34 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4D4F.8B3C6B52"
Date: Thu, 28 Jul 2011 10:53:33 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] terminology and monitoring devices that generate energy
Thread-Index: AcxNTs/cyrRL19JoTxagwmTdACzU1QAAHSma
References: 
From: "John Parello (jparello)" 
To: "Georgios Karagiannis" , "eman mailing list" 
X-OriginalArrivalTime: 28 Jul 2011 17:55:34.0651 (UTC) FILETIME=[8CC704B0:01CC4D4F]
Subject: Re: [eman] terminology and monitoring devices that generate energy
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 17:55:41 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4D4F.8B3C6B52
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Thanks!

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

Are you ok with the term Energy Managed Object?

Jp

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

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

http://www.ietf.org/id/draft-ietf-eman-framework-02.txt


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

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

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

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

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

  Energy Management Domain

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

Into something like:


  Energy Management Domain

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


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


------_=_NextPart_001_01CC4D4F.8B3C6B52
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [eman] terminology and monitoring devices that generate =
energy







Thanks!



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



Are you ok with the term Energy Managed Object?



Jp



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

From: eman-bounces@ietf.org on behalf of Georgios Karagiannis

Sent: Thu 7/28/2011 10:50 AM

To: eman mailing list

Subject: [eman] terminology and monitoring devices that generate =
energy



Hi all,



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

generic comment:



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





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

monitoring the energy consumption.



In my opinion it is also needed to also emphasize that energy =
monitoring

& control is accomplished for energy consumption and/or energy

generation.



This addition will be needed in most of the provided terms, for =
example,

this terminology modification is needed in the following terms:



"Energy Management System (EnMS)", "Energy =
Management", "Energy

Control", "Energy Managed Object", "Energy Aware =
Object", "Energy

Management Domain".



For example the modification on the definition of the "Energy =
Management

Domain" could change from:



  Energy Management Domain



        An Energy Management Domain =
is a name or name space that

        logically groups Energy =
Managed Objects into a zone of Energy

        Management.  Typically, =
this zone will have as members all

        Energy Managed Objects that =
are powered from the same electrical

        panel(s) for which there is a =
meter or sub meter.



Into something like:





  Energy Management Domain



        An Energy Management Domain =
is a name or name space that

        logically groups Energy =
Managed Objects into a zone of Energy

        Management.  Typically, =
this zone will have as members all

        Energy Managed Objects that =
are powered from the same electrical

        panel(s) and/or are supplying =
power to the same electrical

panel(s)

        for which there is a meter or =
sub meter.





Best regards,

Georgios

_______________________________________________

eman mailing list

eman@ietf.org

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









------_=_NextPart_001_01CC4D4F.8B3C6B52--

From jparello@cisco.com  Thu Jul 28 11:08:33 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E66411E811F for ; Thu, 28 Jul 2011 11:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level: 
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuuNRmTPpb-H for ; Thu, 28 Jul 2011 11:08:32 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1C55511E807B for ; Thu, 28 Jul 2011 11:08:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=11640; q=dns/txt; s=iport; t=1311876512; x=1313086112; h=mime-version:subject:date:message-id:references:from:to: cc; bh=yDOFoVY/zO7+rPjYHifhgqnRg7YqoULHU/ytbJkUcgs=; b=PSVnZ9TSiVfFMR8s9YFjgl7fMl6M+tg+wXLFB0RYl+cF6fshyrEARlQk XkWauIDaQkztkI5bEW/giC4ebNKx6vqkl3luq6AXFwQwxzcqe838zf0f+ bz7YgiMNkHCizWwEVSIbmwlDitq1ZSN7U6di6CVW7J3zfLWMYIt57Y5nO 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuQAAIekMU6rRDoH/2dsb2JhbAA0AQEBAQMUAQwSA0QLDAUCAQkRBAEBCwYjAQYBEzsOCAIFARYMG5drj093rU+eRYViXwSHKi+QMIt0
X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208,217";a="7478085"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-1.cisco.com with ESMTP; 28 Jul 2011 18:08:28 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6SI8Omt015835; Thu, 28 Jul 2011 18:08:24 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 28 Jul 2011 11:08:24 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4D51.56795F7C"
Date: Thu, 28 Jul 2011 11:05:45 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - open issue 12.3:time series of energy/power values
Thread-Index: AQHMTGdebe5iwHf9hECy9RtMmcgg7pUCCSPV
References: 
From: "John Parello (jparello)" 
To: "Juergen Quittek" , "Juergen Quittek" 
X-OriginalArrivalTime: 28 Jul 2011 18:08:24.0664 (UTC) FILETIME=[57BDAD80:01CC4D51]
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:time series of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 18:08:33 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4D51.56795F7C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


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

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

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

Jp


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

my Question was=20

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


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

Thanks,

    Juergen


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

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



------_=_NextPart_001_01CC4D51.56795F7C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






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







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



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



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



Jp





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

From: Juergen Quittek [mailto:Quittek@neclab.eu]

Sent: Wed 7/27/2011 7:13 AM

To: John Parello (jparello); Juergen Quittek

Cc: eman mailing list

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



Hi John,



my Question was



"Do I understand right that you would support a requirement for =
specifying

a standard for time series of power but not for time series of =
energy?"





I take you answer as a no. This would mean we keep both requirements =
(time

series of power and time series of energy). Is this correct?



Thanks,



    Juergen





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



>

>Hi Jeurgen,

>

>We need to express power, energy as a measurement (scalar).

>

>For time series (vector) IMO having the capability of providing =
power

>over time series (which is demand) or energy over time is valuable =
and

>should not be excluded.  Even though for energy an odometer can =
suffice I

>see no need to prevent this for devices that have this =
capability.

>

>

>Please take a look at the draft-claise-energy-monitoring-mib.  =
I think

>they did a good job of providing time series modeling that covers =
this.

>

>thanks

>Jp

>

>

>

>

>

>

>

>

>-----Original Message-----

>From: Juergen Quittek [mailto:ietf@quittek.at]

>Sent: Tue 7/26/2011 12:39 PM

>To: John Parello (jparello)

>Cc: Mouli Chandramouli (moulchan); eman mailing list

>Subject: Re: [eman] new revision of eman requirements - open =
issue

>12.3:time series of energy/power values

>

>Hi John,

>

>We are currently not discussing optional or mandatory =
implementation.

>

>The question is whether or not we have a requirement for specifying =
a

>standard for reporting both, energy time series and power time =
series, or

>just one of them. What compliant devices must implement is an issue =
to be

>discussed later.

>

>Do I understand right that you would support a requirement for =
specifying

>a standard for time series of power but not for time series of =
energy?

>

>Thanks,

>

>    Juergen

>

>Am 26.07.2011 um 13:08 schrieb John Parello (jparello):

>

>> Hi Jeurgen,

>>

>> I tend to agree, for simple devices an energy odometer(s) as =
describe

>> from the comments and what I presented from the ODVA =
suffices.

>>

>> For time series of data like historical demand devices such as =
PDUs very

>> typically store this. Some our as long as a year's worth of =
data on the

>> device. For the very reason that Bill pointed out.

>>

>> So it would seem that a power value and an energy odometer =
could be a

>> required minimum and then time series of power or demand can =
be

>> optional.

>>

>> We specified a power value as required in the monitoring mib =
with time

>> series of power and demand as optional.

>>

>> Jp

>>

>> -----Original Message-----

>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] =
On Behalf Of

>> Juergen Quittek

>> Sent: Wednesday, July 13, 2011 5:53 AM

>> To: Mouli Chandramouli (moulchan)

>> Cc: eman mailing list

>> Subject: Re: [eman] new revision of eman requirements - open =
issue

>> 12.3:time series of energy/power values

>>

>> Dear Mouli,

>>

>> Thank you for commenting on this issue. I would like to have a =
look at

>> the following point of view:

>>

>> So far, storing time series of measurements on managed nodes is =
rarely

>> standardized and rarely available as implementation.

>>

>> Typically, it is the job of a network management system to =
collect time

>> series and store them.

>>

>> Take for example byte and packet counters at line cards. You =
see many

>> curves showing time series of traffic rate/volume in the =
Internet, but

>> almost all of them were collected at management stations or =
data

>> collector modules, but not within MIB modules. (Please correct =
me if I'm

>> wrong.)

>>

>> Now the question is: Is energy management so much different =
from other

>> network management tasks, that we need the rarely used =
mechanism of

>> storing time series in MIB modules?

>>

>> If not, it would be sufficient to just report the number of =
total energy

>> consumed since the last re-start as you do it with packet and =
byte

>> counters.

>> This would be just a single managed object to be specified =
and

>> implemented.

>>

>> Thanks,

>>

>>    Juergen

>>











------_=_NextPart_001_01CC4D51.56795F7C--

From Michael.Suchoff@raritan.com  Thu Jul 28 11:25:18 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8A711E8118 for ; Thu, 28 Jul 2011 11:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.048
X-Spam-Level: 
X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=0.950,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54ik493fHL+f for ; Thu, 28 Jul 2011 11:25:15 -0700 (PDT)
Received: from fig.raritan.com (fig.raritan.com [12.144.63.197]) by ietfa.amsl.com (Postfix) with ESMTP id 3109F11E8078 for ; Thu, 28 Jul 2011 11:25:15 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4D53.AB5A3834"
Date: Thu, 28 Jul 2011 14:25:01 -0400
Message-ID: <9C329342B62B87498B92834DEC9FF51E0D6187D8@fig.raritan.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values
Thread-Index: AQHMTGdebe5iwHf9hECy9RtMmcgg7pUCCSPVgAABTtA=
References:  
From: "Michael Suchoff" 
To: "John Parello \(jparello\)" , "Juergen Quittek" , "Juergen Quittek" 
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values
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, 28 Jul 2011 18:25:18 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4D53.AB5A3834
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

=20

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

=20

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

=20

________________________________

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

=20

=20

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

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

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

Jp


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

Hi John,

my Question was

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


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

Thanks,

    Juergen


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

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




------_=_NextPart_001_01CC4D53.AB5A3834
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







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










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



 



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



 



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



 















From:
eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of John Parello (jparello)

Sent: Thursday, July 28, =
2011 2:06
PM

To: Juergen Quittek; =
Juergen
Quittek

Cc: eman mailing list

Subject: Re: [eman] new =
revision
of eman requirements - open issue 12.3:timeseries of energy/power =
values






 



 



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



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



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



Jp





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

From: Juergen Quittek [mailto:Quittek@neclab.eu]

Sent: Wed 7/27/2011 7:13 AM

To: John Parello (jparello); Juergen Quittek

Cc: eman mailing list

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



Hi John,



my Question was



"Do I understand right that you would support a requirement for =
specifying

a standard for time series of power but not for time series of =
energy?"





I take you answer as a no. This would mean we keep both requirements =
(time

series of power and time series of energy). Is this correct?



Thanks,



    Juergen





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



>

>Hi Jeurgen,

>

>We need to express power, energy as a measurement (scalar).

>

>For time series (vector) IMO having the capability of providing =
power

>over time series (which is demand) or energy over time is valuable =
and

>should not be excluded.  Even though for energy an odometer can
suffice I

>see no need to prevent this for devices that have this =
capability.

>

>

>Please take a look at the draft-claise-energy-monitoring-mib.  =
I think

>they did a good job of providing time series modeling that covers =
this.

>

>thanks

>Jp

>

>

>

>

>

>

>

>

>-----Original Message-----

>From: Juergen Quittek [mailto:ietf@quittek.at]

>Sent: Tue 7/26/2011 12:39 PM

>To: John Parello (jparello)

>Cc: Mouli Chandramouli (moulchan); eman mailing list

>Subject: Re: [eman] new revision of eman requirements - open =
issue

>12.3:time series of energy/power values

>

>Hi John,

>

>We are currently not discussing optional or mandatory =
implementation.

>

>The question is whether or not we have a requirement for specifying =
a

>standard for reporting both, energy time series and power time =
series, or

>just one of them. What compliant devices must implement is an issue =
to be

>discussed later.

>

>Do I understand right that you would support a requirement for =
specifying

>a standard for time series of power but not for time series of =
energy?

>

>Thanks,

>

>    Juergen

>

>Am 26.07.2011 um 13:08 schrieb John Parello (jparello):

>

>> Hi Jeurgen,

>>

>> I tend to agree, for simple devices an energy odometer(s) as =
describe

>> from the comments and what I presented from the ODVA =
suffices.

>>

>> For time series of data like historical demand devices such as =
PDUs
very

>> typically store this. Some our as long as a year's worth of =
data on
the

>> device. For the very reason that Bill pointed out.

>>

>> So it would seem that a power value and an energy odometer =
could be a

>> required minimum and then time series of power or demand can =
be

>> optional.

>>

>> We specified a power value as required in the monitoring mib =
with time

>> series of power and demand as optional.

>>

>> Jp

>>

>> -----Original Message-----

>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org]
On Behalf Of

>> Juergen Quittek

>> Sent: Wednesday, July 13, 2011 5:53 AM

>> To: Mouli Chandramouli (moulchan)

>> Cc: eman mailing list

>> Subject: Re: [eman] new revision of eman requirements - open =
issue

>> 12.3:time series of energy/power values

>>

>> Dear Mouli,

>>

>> Thank you for commenting on this issue. I would like to have a =
look at

>> the following point of view:

>>

>> So far, storing time series of measurements on managed nodes is =
rarely

>> standardized and rarely available as implementation.

>>

>> Typically, it is the job of a network management system to =
collect
time

>> series and store them.

>>

>> Take for example byte and packet counters at line cards. You =
see many

>> curves showing time series of traffic rate/volume in the =
Internet, but

>> almost all of them were collected at management stations or =
data

>> collector modules, but not within MIB modules. (Please correct =
me if
I'm

>> wrong.)

>>

>> Now the question is: Is energy management so much different =
from other

>> network management tasks, that we need the rarely used =
mechanism of

>> storing time series in MIB modules?

>>

>> If not, it would be sufficient to just report the number of =
total
energy

>> consumed since the last re-start as you do it with packet and =
byte

>> counters.

>> This would be just a single managed object to be specified =
and

>> implemented.

>>

>> Thanks,

>>

>>    Juergen

>>













------_=_NextPart_001_01CC4D53.AB5A3834--

From moulchan@cisco.com  Thu Jul 28 11:31:18 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B7B11E8077 for ; Thu, 28 Jul 2011 11:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.189
X-Spam-Level: 
X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xSRE+r4QMwp for ; Thu, 28 Jul 2011 11:31:17 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BD4FA11E8078 for ; Thu, 28 Jul 2011 11:31:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=9921; q=dns/txt; s=iport; t=1311877877; x=1313087477; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=Lqs2y9djjn7SsBpbOTUvoCqReunIAhNxRy5J6aJchuY=; b=g9xeXdpXOBrFKNWjj85wGKFM2P2tRA/3KBlbke1TYIyy3orbV95QVtQM 5L3Od8vECMCqP92Xwk5HsCTZ5drIJc5JmyRfZROWhkz78gDAnH0IGnUfO Acc9IHizSaDH06ghCk9IrGzLQoe8O7vYmWfTxyUs6koXlWXiD2sBdZir7 k=;
X-Files: onetc.txt, twotc.txt : 3391, 2334
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuUAAAaqMU6tJXG9/2dsb2JhbAA0AQEBAQMUAQwVRhUDAgIBCQ4CAQQBAQsGDxQBBgEBEgwvDggBAQUBFgwbl2uPT3etbJ4/AoM7giVfBIdZhiSKDIty
X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="txt'?scan'208";a="7485664"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 28 Jul 2011 18:31:16 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6SIVGSj000422;  Thu, 28 Jul 2011 18:31:16 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 28 Jul 2011 13:31:15 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC4D54.895A89EE"
Date: Thu, 28 Jul 2011 13:31:13 -0500
Message-ID: 
In-Reply-To: <20110728164503.GA30392@elstar.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] iana powerstate tc proposal
Thread-Index: AcxNRbkzhxOsoDfKSwGIrnu9tVWDfQADQxsg
References: <20110728164503.GA30392@elstar.local>
From: "Mouli Chandramouli (moulchan)" 
To: "Juergen Schoenwaelder" , 
X-OriginalArrivalTime: 28 Jul 2011 18:31:15.0586 (UTC) FILETIME=[88DFC620:01CC4D54]
Subject: Re: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 18:31:18 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4D54.895A89EE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Juergen S.

Thanks for your proposal.=20

We as authors had debated 3 approaches.=20

1.  One TC for PowerStateSet - which is a 2 byte octet - one byte for
Power State Set and one byte for the Power State within the Set =20

Proposal one has an advantage of a single index which captures both
Power State Set and Power State within the set.=20


2.  One TC for the PowerStateset which is a 1-byte octet and States
within the set is a simple enumeration - (consensus of authors) as it is
this version of the document.=20


3. one  TCs for the PowerStateSet - simple enumeration and one TC for
the Power States with in the Set (another enumeration).=20


We had discussed this extensively and felt design 2 was good. Your
comments welcome.


Thanks
Mouli

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

Hi,

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

/js

--=20
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

------_=_NextPart_001_01CC4D54.895A89EE
Content-Type: text/plain;
	name="onetc.txt"
Content-Transfer-Encoding: base64
Content-Description: onetc.txt
Content-Disposition: attachment;
	filename="onetc.txt"

UG93ZXJTdGF0ZVNldCA6Oj0gVEVYVFVBTC1DT05WRU5USU9ODQogICAgU1RBVFVTICAgICAgICAg
IGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KIlBvd2VyU3RhdGVTZXQgVEMgaXMgdXNlZCB0byBj
YXB0dXJlIGJvdGggdGhlIFBvd2VyIFN0YXRlIFNlcmllcyBhbmQgdGhlIHBvd2VyIHN0YXRlIHdp
dGhpbiB0aGUgc2VyaWVzIHdpdGggYSBzaW5nbGUgMiBieXRlIGluZGV4LiANCg0KVGhlIFBvd2Vy
U3RhdGVTZXQgaXMgY29tcG9zZWQgb2YgdHdvIGJ5dGVzLiAgDQpPbmUgYnl0ZSBpcyB1c2VkIHRv
IHJlcHJlc2VudCB0aGUgcG93ZXIgc3RhdGUgc2VyaWVzLg0KVGhlIHNlY29uZCBieXRlIGNvbnRh
aW5zIHRoZSBzcGVjaWZpYyBwb3dlciBzdGF0ZSB3aXRoaW4gdGhlIHBvd2VyIHN0YXRlIHNlcmll
cy4gDQoNCg0KICAgICAgIGZpZWxkICBvY3RldHMgIGNvbnRlbnRzICAgICAgICAgICAgIHJhbmdl
DQogICAgICAgLS0tLS0gIC0tLS0tLSAgLS0tLS0tLS0gICAgICAgICAgICAgLS0tLS0NCiAgICAg
ICAgMSAgICAgICAxICAgICBwb3dlciBzdGF0ZSBzZXQgICAgICAwLi4yNTUNCiAgICAgICAgMiAg
ICAgICAyICAgICBwb3dlciBzdGF0ZSAgICAgICAgICAxLi4yNTUNCiAgICAgICAgICAgICANCiAg
Tm90ZXM6DQogICAgdGhlIHZhbHVlIG9mIHBvd2VyIHN0YXRlIHNlcmllcyBpbiBuZXR3b3JrIGJ5
dGUgb3JkZXIgDQogICAgdGhlIHZhbHVlIG9mIHBvd2VyIHN0YXRlIGluIG5ldHdvcmsgYnl0ZSBv
cmRlciANCg0KMCBpbiB0aGUgZmlyc3QgYnl0ZSB0byBpbmRpY2F0ZSBCYXNpYyBwb3dlciBzdGF0
ZSBzZXJpZXMgDQoxIGluIHRoZSBmaXJzdCBieXRlIHRvIGluZGljYXRlIERNVEYgcG93ZXIgc3Rh
dGUgc2VyaWVzIA0KMiBpbiB0aGUgZmlyc3QgYnl0ZSB0byBpbmRpY2F0ZSBFTUFOIHBvd2VyIHN0
YXRlIHNlcmllcyANCg0KRm9yIHRoZSBCYXNpYyBwb3dlciBzdGF0ZSBzZXJpZXMNCg0KSWYgdGhl
IGZpcnN0IGJ5dGUgaGFzIDAgYW5kIHRoZSBzZWNvbmQgYnl0ZSBjb250YWlucyANCjEgaW4gdGhl
IHNlY29uZCBieXRlIHRvIHJlcHJlc2VudCBCYXNpYyBwb3dlciBzdGF0ZSBzZXJpZXMgc3RhdGUg
T04uDQoyIGluIHRoZSBzZWNvbmQgYnl0ZSBjYW4gYmUgdXNlZCB0byByZXByZXNlbnQgQmFzaWMg
cG93ZXIgc2VyaWVzIHN0YXRlIFNsZWVwIA0KMyBpbiB0aGUgc2Vjb25kIGJ5dGUgY2FuIGJlIHVz
ZWQgdG8gcmVwcmVzZW50IEJhc2ljIHBvd2VyIHN0YXRlIHNlcmllcyBzdGF0ZSBPRkYuDQoNCkZv
ciB0aGUgRE1URiBwb3dlciBzdGF0ZSBzZXJpZXMNCg0KaWYgdGhlIGZpc3QgYnl0ZSBoYXMgMSBh
bmQgdGhlIHNlY29uZCBieXRlIGNhbiBiZSB1c2VkIHRvIHJlcHJlc2VudCB0aGUgcG93ZXIgc3Rh
dGVzIG9mIERNVEYuIA0KCQ0KMSBpbiB0aGUgc2Vjb25kIGJ5dGUgdG8gcmVwcmVzZW50IERNVEYg
cG93ZXIgc3RhdGUgb24NCjIgaW4gdGhlIHNlY29uZCBieXRlIHRvIHJlcHJlc2VudCBETVRGIHBv
d2VyIHN0YXRlIFNsZWVwLUxpZ2h0DQozIGluIHRoZSBzZWNvbmQgYnl0ZSB0byByZXByZXNlbnQg
RE1URiBwb3dlciBzdGF0ZSAgU2xlZXAtRGVlcA0KNCBpbiB0aGUgc2Vjb25kIGJ5dGUgdG8gcmVw
cmVzZW50IERNVEYgcG93ZXIgc3RhdGUgIFBvd2VyIEN5Y2xlIChPZmYtU29mdCkNCjUgaW4gdGhl
IHNlY29uZCBieXRlIHRvIHJlcHJlc2VudCBETVRGIHBvd2VyIHN0YXRlIE9mZiAtIEhhcmQNCjYg
aW4gdGhlIHNlY29uZCBieXRlIHRvIHJlcHJlc2VudCBETVRGIHBvd2VyIHN0YXRlICBIaWJlcm5h
dGUgKE9mZi1Tb2Z0KQ0KNyBpbiB0aGUgc2Vjb25kIGJ5dGUgdG8gcmVwcmVzZW50IERNVEYgcG93
ZXIgc3RhdGUgT2ZmIJYgU29mdA0KOCBpbiB0aGUgc2Vjb25kIGJ5dGUgdG8gcmVwcmVzZW50IERN
VEYgcG93ZXIgc3RhdGUgIFBvd2VyIEN5Y2xlIChPZmYtSGFyZCkNCjkgaW4gdGhlIHNlY29uZCBi
eXRlIHRvIHJlcHJlc2VudCBETVRGIHBvd2VyIHN0YXRlICBNYXN0ZXIgQnVzIFJlc2V0DQoxMCBp
biB0aGUgc2Vjb25kIGJ5dGUgdG8gcmVwcmVzZW50IERNVEYgcG93ZXIgc3RhdGUgIERpYWdub3N0
aWMgSW50ZXJydXB0IChOTUkpIA0KMTEgaW4gdGhlIHNlY29uZCBieXRlIHRvIHJlcHJlc2VudCBE
TVRGIHBvd2VyIHN0YXRlIE9mZiAtIFNvZnQgR3JhY2VmdWwgDQoxMiBpbiB0aGUgc2Vjb25kIGJ5
dGUgdG8gcmVwcmVzZW50IERNVEYgcG93ZXIgc3RhdGUgT2ZmIC0gSGFyZCBHcmFjZWZ1bA0KMTMg
aW4gdGhlIHNlY29uZCBieXRlIHRvIHJlcHJlc2VudCBETVRGIHBvd2VyIHN0YXRlICBNYXN0ZXIg
QnVzIFJlc2V0IEdyYWNlZnVsIA0KMTQgaW4gdGhlIHNlY29uZCBieXRlIHRvIHJlcHJlc2VudCBE
TVRGIHBvd2VyIHN0YXRlICBQb3dlciBDeWNsZSAoT2ZmIC0gU29mdCBHcmFjZWZ1bCkgDQoxNSBp
biB0aGUgc2Vjb25kIGJ5dGUgdG8gcmVwcmVzZW50IERNVEYgcG93ZXIgc3RhdGUgIFBvd2VyIEN5
Y2xlIChPZmYgLSBIYXJkIEdyYWNlZnVsKQ0KDQpGb3IgdGhlIEVNQU4gcG93ZXIgc3RhdGUgc2Vy
aWVzDQoNCmlmIHRoZSBmaXN0IGJ5dGUgaGFzIDIgYW5kIHRoZSBzZWNvbmQgYnl0ZSBjYW4gYmUg
dXNlZCB0byByZXByZXNlbnQgdGhlIHBvd2VyIHN0YXRlcyBvZiBFTUFOLiANCgkNCjEgaW4gdGhl
IHNlY29uZCBieXRlIHRvIHJlcHJlc2VudCBFTUFOIHBvd2VyIHN0YXRlIG1lY2hvZmYNCjIgaW4g
dGhlIHNlY29uZCBieXRlIHRvIHJlcHJlc2VudCBFTUFOIHBvd2VyIHN0YXRlIHNvZnRvZmYNCjMg
aW4gdGhlIHNlY29uZCBieXRlIHRvIHJlcHJlc2VudCBFTUFOIHBvd2VyIHN0YXRlICBoaWJlcm5h
dGUNCjQgaW4gdGhlIHNlY29uZCBieXRlIHRvIHJlcHJlc2VudCBFTUFOIHBvd2VyIHN0YXRlIHNs
ZWVwDQo1IGluIHRoZSBzZWNvbmQgYnl0ZSB0byByZXByZXNlbnQgRU1BTiBwb3dlciBzdGF0ZSBz
dGFuZGJ5IA0KNiBpbiB0aGUgc2Vjb25kIGJ5dGUgdG8gcmVwcmVzZW50IEVNQU4gcG93ZXIgc3Rh
dGUgIHJlYWR5IA0KNyBpbiB0aGUgc2Vjb25kIGJ5dGUgdG8gcmVwcmVzZW50IEVNQU4gcG93ZXIg
c3RhdGUgIGxvd01pbnVzDQo4IGluIHRoZSBzZWNvbmQgYnl0ZSB0byByZXByZXNlbnQgRU1BTiBw
b3dlciBzdGF0ZSBsb3cgDQo5IGluIHRoZSBzZWNvbmQgYnl0ZSB0byByZXByZXNlbnQgRU1BTiBw
b3dlciBzdGF0ZSAgbWVkaXVtTWludXMNCjEwIGluIHRoZSBzZWNvbmQgYnl0ZSB0byByZXByZXNl
bnQgRU1BTiBwb3dlciBzdGF0ZSBtZWRpdW0gDQoxMSBpbiB0aGUgc2Vjb25kIGJ5dGUgdG8gcmVw
cmVzZW50IEVNQU4gcG93ZXIgc3RhdGUgIGhpZ2hNaW51cw0KMTIgaW4gdGhlIHNlY29uZCBieXRl
IHRvIHJlcHJlc2VudCBFTUFOIHBvd2VyIHN0YXRlICBoaWdoIg0KDQogICAgICAgU1lOVEFYICAg
ICBPQ1RFVCBTVFJJTkcgKFNJWkUgKDIpKSANCg==

------_=_NextPart_001_01CC4D54.895A89EE
Content-Type: text/plain;
	name="twotc.txt"
Content-Transfer-Encoding: base64
Content-Description: twotc.txt
Content-Disposition: attachment;
	filename="twotc.txt"

DQoNCiAgUG93ZXJTdGF0ZXNldCA6Oj0gVEVYVFVBTC1DT05WRU5USU9ODQogICAgICAgU1RBVFVT
IGN1cnJlbnQNCiAgICAgICBERVNDUklQVElPTg0KICAgICAgICJUaGUgcG93ZXIgc3RhdGUgb2Yg
dGhpcyBjb21wb25lbnQgLiINCiAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAiVGFibGUgb2YgUG93
ZXIgUHJvZmlsZS4iDQogICAgICAgIFNZTlRBWCBJTlRFR0VSICB7DQogICAgICAgICAgIElFRUUx
NjIxICAgICAgKDEpLCANCiAgICAgICAgICAgRE1URiAgICAgICAgICAoMiksDQogICAgICAgICAg
IEVNQU4gICAgICAgICAgKDMpLA0KICAgICAgICAgICANCiAgICAgICAgICB9DQoNCg0KICAgUG93
ZXJTdGF0IDo6PSBURVhUVUFMLUNPTlZFTlRJT04NCiAgICAgICBTVEFUVVMgY3VycmVudA0KICAg
ICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoZSBwb3dlciBzdGF0ZSBvZiB0aGlzIGNvbXBvbmVu
dCAuIg0KICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICJUYWJsZSBvZiBQb3dlciBTdGF0IFNlcmll
cy4iDQogICAgICAgIFNZTlRBWCBJTlRFR0VSICB7DQogICAgICAgICAgICAgICAgICAgSUVFRTE2
MjEtT24gICAgICAgICAgICAgICAgICAoMTAwMSksDQogICAgICAgICAgICAgICAgICAgSUVFRTE2
MjEtU2xlZXAgICAgICAgICAgICAgICAoMTAwMiksDQogICAgICAgICAgICAgICAgICAgSUVFRTE2
MjEtT2ZmICAgICAgICAgICAgICAgICAoMTAwMyksDQogICAgICAgICAgICAgICAgICAgRE1URi1P
biAgICAgICAgICAgICAgICAgICAgICAoMjAwMiksDQogICAgICAgICAgICAgICAgICAgRE1URi1z
bGVlcGxpZ2h0ICAgICAgICAgICAgICAoMjAwMyksICAgICAgICAgICAgIA0KICAgICAgICAgICAg
ICAgICAgIERNVEYtc2xlZXBkZWVwICAgICAgICAgICAgICAgKDIwMDQpLA0KICAgICAgICAgICAg
ICAgICAgIERNVEYtcG93ZXJjeWNsZXNvZnQgICAgICAgICAgKDIwMDUpLA0KICAgICAgICAgICAg
ICAgICAgIERNVEYtb2ZmaGFyZCAgICAgICAgICAgICAgICAgKDIwMDYpLA0KICAgICAgICAgICAg
ICAgICAgIERNVEYtaGliZXJuYXRlICAgICAgICAgICAgICAgKDIwMDcpLA0KICAgICAgICAgICAg
ICAgICAgIERNVEYtb2Zmc29mdCAgICAgICAgICAgICAgICAgKDIwMDgpLA0KICAgICAgICAgICAg
ICAgICAgIERNVEYtcG93ZXJjeWNsZWhhcmQgICAgICAgICAgKDIwMDkpLA0KICAgICAgICAgICAg
ICAgICAgIERNVEYtbWFzdGVyYnVzcmVzZXQgICAgICAgICAgKDIwMTApLA0KICAgICAgICAgICAg
ICAgICAgIERNVEYtZGlhZ2ludGVycnVwdCAgICAgICAgICAgKDIwMTEpLA0KICAgICAgICAgICAg
ICAgICAgIERNVEYtb2Zmc29mdGdyYWNlZnVsICAgICAgICAgKDIwMTIpLA0KICAgICAgICAgICAg
ICAgICAgIERNVEYtb2ZmaGFyZGdyYWNlZnVsICAgICAgICAgKDIwMTMpLA0KICAgICAgICAgICAg
ICAgICAgIERNVEYtbWFzdGVyYnVzcmVzZXRncmFjZWZ1bCAgKDIwMTQpLA0KICAgICAgICAgICAg
ICAgICAgIERNVEYtcG93ZXJjeWNsZXNvZnRncmFjZWZ1bCAgKDIwMTUpLA0KICAgICAgICAgICAg
ICAgICAgIERNVEYtcG93ZXJjeWNsZWhhcmRncmFjZWZ1bCAgKDIwMTYpLA0KICAgICAgICAgICAg
ICAgICAgIEVNQU4tTWVjaG9mZiAgICAgICAgICAgICAgICAgKDMwMDEpLA0KICAgICAgICAgICAg
ICAgICAgIEVNQU4tU29mdG9mZiAgICAgICAgICAgICAgICAgKDMwMDIpLA0KICAgICAgICAgICAg
ICAgICAgIEVNQU4tSGliZXJuYXRlICAgICAgICAgICAgICAgKDMwMDMpLA0KICAgICAgICAgICAg
ICAgICAgIEVNQU4tU2xlZXAgICAgICAgICAgICAgICAgICAgKDMwMDQpLA0KICAgICAgICAgICAg
ICAgICAgIEVNQU4tU3RhbmRieSAgICAgICAgICAgICAgICAgKDMwMDUpLA0KICAgICAgICAgICAg
ICAgICAgIEVNQU4tUmVhZHkgICAgICAgICAgICAgICAgICAgKDMwMDYpLA0KICAgICAgICAgICAg
ICAgICAgIEVNQU4tTG93TWludXMgICAgICAgICAgICAgICAgKDMwMDcpLA0KICAgICAgICAgICAg
ICAgICAgIEVNQU4tTG93ICAgICAgICAgICAgICAgICAgICAgKDMwMDgpLA0KICAgICAgICAgICAg
ICAgICAgIEVNQU4tTWVkaXVtTWludXMgICAgICAgICAgICAgKDMwMDkpLA0KICAgICAgICAgICAg
ICAgICAgIEVNQU4tTWVkaXVtICAgICAgICAgICAgICAgICAgKDMwMTApLA0KICAgICAgICAgICAg
ICAgICAgIEVNQU4tSGlnaE1pbnVzICAgICAgICAgICAgICAgKDMwMTEpLA0KICAgICAgICAgICAg
ICAgICAgIEVNQU4tSGlnaCAgICAgICAgICAgICAgICAgICAgKDMwMTIpLA0KICAgICAgICAgICAg
ICAgICAgIHVua25vd24gICAgICAgICAgICAgICAgICAgICAgKDApDQogICAgICAgICAgfQ0K

------_=_NextPart_001_01CC4D54.895A89EE--

From j.schoenwaelder@jacobs-university.de  Thu Jul 28 11:42:38 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4948721F8865 for ; Thu, 28 Jul 2011 11:42:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.036
X-Spam-Level: 
X-Spam-Status: No, score=-103.036 tagged_above=-999 required=5 tests=[AWL=0.213, 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 FQIYjhyP5u48 for ; Thu, 28 Jul 2011 11:42:37 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7D65E8017 for ; Thu, 28 Jul 2011 11:42:37 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE50820C46; Thu, 28 Jul 2011 20:42:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pmgm9K2JEOpI; Thu, 28 Jul 2011 20:42:35 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7740A20C43; Thu, 28 Jul 2011 20:42:35 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 6F7E21A1D3E7; Thu, 28 Jul 2011 20:42:35 +0200 (CEST)
Date: Thu, 28 Jul 2011 20:42:35 +0200
From: Juergen Schoenwaelder 
To: "John Parello (jparello)" 
Message-ID: <20110728184235.GD30565@elstar.local>
Mail-Followup-To: "John Parello (jparello)" , "eman@ietf.org" 
References: <20110728164503.GA30392@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "eman@ietf.org" 
Subject: Re: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 18:42:38 -0000

On Thu, Jul 28, 2011 at 07:28:57PM +0200, John Parello (jparello) wrote:
> 
> There was a long discussion on having two indecies. One to represent the set and then numbering within the set.
> 
> I'd like to see a seperate index for the sets  then numbering withing the set as opposed to a single numbered array.
> 
> This way it's easy to determine the set you implement. I find this type of sparse array very arcane and cumbersome.

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

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

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

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

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

So here are three technical arguments. Looking forward to the
technical arguments against this.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From jparello@cisco.com  Thu Jul 28 13:47:45 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9428021F8ABD for ; Thu, 28 Jul 2011 13:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.764
X-Spam-Level: 
X-Spam-Status: No, score=-2.764 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+Qe2XVxb+zm for ; Thu, 28 Jul 2011 13:47:44 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 799B321F8AAC for ; Thu, 28 Jul 2011 13:47:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=5690; q=dns/txt; s=iport; t=1311886064; x=1313095664; h=mime-version:subject:date:message-id:references:from:to: cc; bh=uk33s/epXSEkuogbjI0/aBMALMpN7JXve+4v2YnU2pE=; b=jpF5zN6H2ELLsDaD66EoFVVkOwSRyEuM5ejY5hZwiC9AE0ZFJfQT3ft/ +YT55jwvK4zHNzk3hGmB/W6P5sOOoaYl2zu8GDlqEhcWAegg6O+cKS9XW a5vSOjMyjAkMiEH2TsduK1sWrxmtYJJ7hKu1XPLOTFD+CNsqWgObzg/Yq w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EACLKMU6rRDoG/2dsb2JhbAA0AQEBAQMUAQwSA08MBQIBCQQKAgEEAQEBCgYjAQYBEzsOCAEBBRcMG6c6d64UnjuFYl8EhyovkDCLdA
X-IronPort-AV: E=Sophos;i="4.67,284,1309737600"; d="scan'208,217";a="7536796"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jul 2011 20:47:43 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6SKlbWE011098 for ; Thu, 28 Jul 2011 20:47:43 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 28 Jul 2011 13:47:41 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4D67.979FFDE5"
Date: Thu, 28 Jul 2011 13:47:40 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] iana powerstate tc proposal
Thread-Index: AcxNViL6dNA55PqoTiq1cvFlVXYVlwAEDbjm
References: <20110728164503.GA30392@elstar.local>  <20110728184235.GD30565@elstar.local>
From: "John Parello (jparello)" 
To: "Juergen Schoenwaelder" 
X-OriginalArrivalTime: 28 Jul 2011 20:47:41.0021 (UTC) FILETIME=[97C608D0:01CC4D67]
Cc: eman@ietf.org
Subject: Re: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 20:47:45 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4D67.979FFDE5
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi JS,


Thanks for throwing out a strawman for it BTW but I think you need to =
review the discussions to see what the consensus was.=20

See inline...


-----Original Message-----
From: Juergen Schoenwaelder =
[mailto:j.schoenwaelder@jacobs-university.de]
Sent: Thu 7/28/2011 11:42 AM
To: John Parello (jparello)
Cc: eman@ietf.org
Subject: Re: [eman] iana powerstate tc proposal
=20
On Thu, Jul 28, 2011 at 07:28:57PM +0200, John Parello (jparello) wrote:
>=20
> There was a long discussion on having two indecies. One to represent =
the set and then numbering within the set.
>=20
> I'd like to see a seperate index for the sets  then numbering withing =
the set as opposed to a single numbered array.
>=20
> This way it's easy to determine the set you implement. I find this =
type of sparse array very arcane and cumbersome.

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

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

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

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

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

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

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

[jp] Having an index to the series first is still machine readable. Also =
BTW you are limiting power states to 256. There was lengthy discussions =
on not limiting it. I can see a series with 1000 as percentage =
increments.

Again all this was discussed. I think Mouli sent a summary.

Jp

------_=_NextPart_001_01CC4D67.979FFDE5
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [eman] iana powerstate tc proposal





Hi JS,





Thanks for throwing out a strawman for it BTW but I think you need to =
review the discussions to see what the consensus was.



See inline...





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

From: Juergen Schoenwaelder [mailto:j.schoenwaeld=
er@jacobs-university.de]

Sent: Thu 7/28/2011 11:42 AM

To: John Parello (jparello)

Cc: eman@ietf.org

Subject: Re: [eman] iana powerstate tc proposal



On Thu, Jul 28, 2011 at 07:28:57PM +0200, John Parello (jparello) =
wrote:

>

> There was a long discussion on having two indecies. One to =
represent the set and then numbering within the set.

>

> I'd like to see a seperate index for the sets  then numbering =
withing the set as opposed to a single numbered array.

>

> This way it's easy to determine the set you implement. I find this =
type of sparse array very arcane and cumbersome.



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

the following:



- I always have to poll two OIDs to retrieve the power state. This

  adds runtime verbosity and overhead.



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



- I need to implement and enforce atomic sets with two varbinds in

  order to change from a value in one power state set to a value in =
a

  different power state set.



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



Compared to this, doing (value & 0xff) or (value >> 8) is =
rather

cheap. And in addition, with this this appraoch,



- I have _all_ IANA maintained power states defined in a machine

  readable format, something that can drive tools and =
automation.



[jp] Having an index to the series first is still machine readable. Also =
BTW you are limiting power states to 256. There was lengthy discussions =
on not limiting it. I can see a series with 1000 as percentage =
increments.



Again all this was discussed. I think Mouli sent a summary.



Jp







------_=_NextPart_001_01CC4D67.979FFDE5--

From j.schoenwaelder@jacobs-university.de  Thu Jul 28 14:20:21 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF5E11E8133 for ; Thu, 28 Jul 2011 14:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.04
X-Spam-Level: 
X-Spam-Status: No, score=-103.04 tagged_above=-999 required=5 tests=[AWL=0.209, 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 x4LqDlBH2nGO for ; Thu, 28 Jul 2011 14:20:20 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AD37E11E8099 for ; Thu, 28 Jul 2011 14:20:19 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 16AC820C65; Thu, 28 Jul 2011 23:20:19 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ezINC1QZmxRU; Thu, 28 Jul 2011 23:20:17 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2BB2120C64; Thu, 28 Jul 2011 23:20:17 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id B00421A1D971; Thu, 28 Jul 2011 23:20:16 +0200 (CEST)
Date: Thu, 28 Jul 2011 23:20:16 +0200
From: Juergen Schoenwaelder 
To: "John Parello (jparello)" 
Message-ID: <20110728212016.GA31474@elstar.local>
Mail-Followup-To: "John Parello (jparello)" , "eman@ietf.org" 
References: <20110728164503.GA30392@elstar.local>  <20110728184235.GD30565@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "eman@ietf.org" 
Subject: Re: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 21:20:21 -0000

On Thu, Jul 28, 2011 at 10:47:40PM +0200, John Parello (jparello) wrote:

> The code (value & 0xff) is not that complex. What I find complex is
> the following:
> 
> - I always have to poll two OIDs to retrieve the power state. This
>   adds runtime verbosity and overhead.
> 
> [jp] If you define a numeric value to each set then this is an index to a state series subtree so you don't have to poll twice It would be in a the tree. If you keep it the way you have it you have to poll the base number first remember the series and then know to avoid or use that range to find out what is supported. With a seperate power state set number it's implicit in the data.  You just traverse or get the entire table.

But that particular table design I think you are refering to is
awkward in the first place since it indexes and thus duplicates
objects that are really not specific to the set. That said, once
stored, a single integer is simply self-contained (and you even get a
meaningful descriptor with typical generic SNMP tools).
 
> - I need to implement and enforce atomic sets with two varbinds in
>   order to change from a value in one power state set to a value in a
>   different power state set.
> 
> [jp] If you have an index for the set first you get the same ability

Well, not completely true. If you have dmtf off and you want to change
to eman on, how does set look like? I know that you assume magic
implementation specific translations between the power state sets,
which I find ugly. Too much magic if our goal is interoperability.

> Compared to this, doing (value & 0xff) or (value >> 8) is rather
> cheap. And in addition, with this this appraoch,
> 
> - I have _all_ IANA maintained power states defined in a machine
>   readable format, something that can drive tools and automation.
> 
> [jp] Having an index to the series first is still machine
> readable. 

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

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

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

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From bschoening@noveda.com  Thu Jul 28 15:09:03 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0129F21F8541 for ; Thu, 28 Jul 2011 15:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qi+uQzW24zbH for ; Thu, 28 Jul 2011 15:09:01 -0700 (PDT)
Received: from cal3-mh484-a.smtproutes.com (cal3-mh484-a.smtproutes.com [208.70.89.247]) by ietfa.amsl.com (Postfix) with ESMTP id 1527C21F852E for ; Thu, 28 Jul 2011 15:09:00 -0700 (PDT)
X-Katharion-ID: 1311890879.38643.cal3-mh484
Received: from ex01.noveda.com ([66.198.105.170]) by  cal3-mh484.smtproutes.com [(208.70.89.158)] with ESMTP via TCP; 28 Jul  2011 15:07:59 -0700
Received: from EX01.noveda.com ([::1]) by ex01.noveda.com ([::1]) with mapi; Thu, 28 Jul 2011 18:07:56 -0400
From: Brad Schoening 
To: "John Parello (jparello)" , Bruce Nordman , Juergen Schoenwaelder , "eman@ietf.org" 
Thread-Topic: [eman] iana powerstate tc proposal
Thread-Index: AcxNSF9aYR9DqA881kq9/zpdhjaDOAAAxNeVAAnEvXA=
Date: Thu, 28 Jul 2011 22:07:54 +0000
Message-ID: <22B2909DCC2E62418BE369A1F10488994B79885D@ex01.noveda.com>
References: <20110728164503.GA30392@elstar.local>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_22B2909DCC2E62418BE369A1F10488994B79885Dex01novedacom_"
MIME-Version: 1.0
Subject: Re: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 22:09:03 -0000

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

ECMA has four power states:  Off, Sleep, Idle, Active.  This more adaptable=
 than the three in 1621.



I agree with John that 'mechanically off' is the correct term.




From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Joh=
n Parello (jparello)
Sent: Thursday, July 28, 2011 1:26 PM
To: Bruce Nordman; Juergen Schoenwaelder; eman@ietf.org
Subject: Re: [eman] iana powerstate tc proposal



Disconneted, Unplugged is more precisely defined as mechanical-off.

Once you add these and a ready state you get very close to the eman states =
we proposed.

I like keeping to the spirit of ou 1621 as three states and then setting up=
 DMTF and EMAN with the full spectrum.

Jp



-----Original Message-----
From: eman-bounces@ietf.org on behalf of Bruce Nordman
Sent: Thu 7/28/2011 10:01 AM
To: Juergen Schoenwaelder; eman@ietf.org
Subject: Re: [eman] iana powerstate tc proposal

I'm not a MIB person, but assuming this is the desired
structure, sets for ACPI and the Printer group should
be added, and EMAN dropped.

For 1621, it also defines "Unplugged" (today I would have
instead called it "Disconnected") to refer to a subset of
Off when not mains-connected (a battery powered device
could be On or in Sleep when unplugged).  This probably
worth adding.
Also, 1621 is specifically scoped to electronic devices,
and for non-electronic ones, "Ready" is a common power
state. It would be convenient to include Ready as an
expansion of 1621.  It is not defined, but is mentioned
in the text as a form of On, along with Active.


Thanks,

--Bruce



On Thu, Jul 28, 2011 at 12:45 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Hi,
>
> here is a proposal for an IANA maintained power state textual
> convention. There are of course other ways of doing this but I thought
> a concrete proposal might help the discussion.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>
>


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

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

RE: [eman] ia=
na powerstate tc proposal
ECMA has four power states:  Off, Sleep, Idle, Active.&nbs=
p; This more adaptable than the three in 1621.   
 
I agree with John that ‘me=
chanically off’ is the correct term.
 
 
 
From: eman-bounc=
es@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of John Parello=
 (jparello)
Sent: Thursday, July 28, 2011 1:26 PM
To: B=
ruce Nordman; Juergen Schoenwaelder; eman@ietf.org
Subject: Re: [=
eman] iana powerstate tc proposal
 
 
Disconn=
eted, Unplugged is more precisely defined as mechanical-off.

Once yo=
u add these and a ready state you get very close to the eman states we prop=
osed.

I like keeping to the spirit of ou 1621 as three states and th=
en setting up DMTF and EMAN with the full spectrum.

Jp


-----Original Message-----
From: eman-bounces@ietf.org on behalf of Br=
uce Nordman
Sent: Thu 7/28/2011 10:01 AM
To: Juergen Schoenwaelder; e=
man@ietf.org
Subject: Re: [eman] iana powerstate tc proposal

I'm =
not a MIB person, but assuming this is the desired
structure, sets for A=
CPI and the Printer group should
be added, and EMAN dropped.

For =
1621, it also defines "Unplugged" (today I would have
instead =
called it "Disconnected") to refer to a subset of
Off when not=
 mains-connected (a battery powered device
could be On or in Sleep when =
unplugged).  This probably
worth adding.
Also, 1621 is specifica=
lly scoped to electronic devices,
and for non-electronic ones, "Rea=
dy" is a common power
state. It would be convenient to include Read=
y as an
expansion of 1621.  It is not defined, but is mentioned
=
in the text as a form of On, along with Active.


Thanks,

-=
-Bruce



On Thu, Jul 28, 2011 at 12:45 PM, Juergen Schoenwaeld=
er <
j.schoenwaelder@jacobs-university.de> wrote:

> Hi,<=
br>>
> here is a proposal for an IANA maintained power state textu=
al
> convention. There are of course other ways of doing this but I t=
hought
> a concrete proposal might help the discussion.
>
&g=
t; /js
>
> --
> Juergen Schoenwaelder   &n=
bsp;       Jacobs University Bremen gGmbH
=
> Phone: +49 421 200 3587        =
; Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200=
 3103         <http://www.jacobs-university.de/>
>=
;
> _______________________________________________
> eman mail=
ing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>>


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

--_000_22B2909DCC2E62418BE369A1F10488994B79885Dex01novedacom_--


From bschoening@noveda.com  Thu Jul 28 15:13:24 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B8E21F8799 for ; Thu, 28 Jul 2011 15:13:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wj7ixzOutn+0 for ; Thu, 28 Jul 2011 15:13:21 -0700 (PDT)
Received: from cal3-mh481-a.smtproutes.com (cal3-mh481-a.smtproutes.com [208.70.89.235]) by ietfa.amsl.com (Postfix) with ESMTP id BB38821F854E for ; Thu, 28 Jul 2011 15:13:21 -0700 (PDT)
X-Katharion-ID: 1311891179.71869.cal3-mh481
Received: from ex01.noveda.com ([66.198.105.170]) by  cal3-mh481.smtproutes.com [(208.70.89.155)] with ESMTP via TCP; 28 Jul  2011 15:12:59 -0700
Received: from EX01.noveda.com ([::1]) by ex01.noveda.com ([::1]) with mapi; Thu, 28 Jul 2011 18:12:45 -0400
From: Brad Schoening 
To: Michael Suchoff , "John Parello (jparello)" , Juergen Quittek , Juergen Quittek 
Thread-Topic: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values
Thread-Index: AQHMTGdebe5iwHf9hECy9RtMmcgg7pUCCSPVgAABTtCAAELfkA==
Date: Thu, 28 Jul 2011 22:12:43 +0000
Message-ID: <22B2909DCC2E62418BE369A1F10488994B79886F@ex01.noveda.com>
References:   <9C329342B62B87498B92834DEC9FF51E0D6187D8@fig.raritan.com>
In-Reply-To: <9C329342B62B87498B92834DEC9FF51E0D6187D8@fig.raritan.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_22B2909DCC2E62418BE369A1F10488994B79886Fex01novedacom_"
MIME-Version: 1.0
Cc: eman mailing list 
Subject: Re: [eman] new revision of eman requirements - open issue	12.3:timeseries of energy/power values
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 22:13:24 -0000

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

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

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

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

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

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

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



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

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

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

Jp


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

Hi John,

my Question was

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


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

Thanks,

    Juergen


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

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

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

RE: [eman] new revision of eman requirements - o=
pen issue 12.3:time series of energy/power values
An energy t=
ime series is can be reported as an odometer reading.  I think youR=
17;ll need to be adaptable to allow either an absolute value like instantan=
eous kW, kWh over a sample period or odometer sampling for kWh.<=
/span>
 
From: eman-bounces@ietf.org [mailto:eman-bounces@ie=
tf.org] On Behalf Of Michael Suchoff
Sent: Thursday, July =
28, 2011 2:25 PM
To: John Parello (jparello); Juergen Quittek; Ju=
ergen Quittek
Cc: eman mailing list
Subject: Re: [eman]=
 new revision of eman requirements - open issue 12.3:timeseries of energy/p=
ower values
&nbs=
p;
I would add current to the series as wel=
l.  Most AC devices presently don’t have circuitry to report pow=
er or energy, they simply report AC current.  Also, for capacity plann=
ing, current is very useful (it is current that limits how many devices can=
 be placed on an electrical branch circuit or PDU – not power).<=
/o:p>
 
Ideally, the time series would be structured as a table with=
 the columns being measurements (i.e. column 1 =3D time stamp, 2 =3D power,=
 3 =3D energy, 4 =3D current, 5 =3D voltage, etc).  The columns could =
be partitioned into SNMP augmented tables (tables sharing same index). &nbs=
p;This would allow easy addition of new columns for products that offer mor=
e information.
 
I don’t see reason for demand as a=
 special table.  Demand (watts) is easily computed from the energy rea=
dings.  For example, if kWh =3D 1000 at 1PM and kWh =3D 2000 at 1:15PM=
, then average power over the 15 minute interval is (2000kWh – 1000kW=
h) * 60minutes/15minutes =3D 4kW.  Doesn’t it seem a lot simpler=
 for management program to compute demand based on polled energy readings (=
i.e. a simple SQL query) – rather than having to write a procedure to=
 configure the power agent to perform demand computations?
 
From: eman-bounces@ietf.org [m=
ailto:eman-bounces@ietf.org] On Behalf Of John Parello (jparello)Sent: Thursday, July 28, 2011 2:06 PM
To: Juergen Quittek=
; Juergen Quittek
Cc: eman mailing list
Subject: Re: [e=
man] new revision of eman requirements - open issue 12.3:timeseries of ener=
gy/power values
 =

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

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

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

Jp


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

Hi John,

my Question was

"=
Do I understand right that you would support a requirement for specifyinga standard for time series of power but not for time series of energy?&qu=
ot;


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

Thanks,

    Juergen


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

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

--_000_22B2909DCC2E62418BE369A1F10488994B79886Fex01novedacom_--


From ietf@quittek.at  Thu Jul 28 15:24:35 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E584E5E800B for ; Thu, 28 Jul 2011 15:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.178
X-Spam-Level: 
X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.071,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRF6BZ8Efptd for ; Thu, 28 Jul 2011 15:24:35 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 134125E8007 for ; Thu, 28 Jul 2011 15:24:35 -0700 (PDT)
Received: from dhcp-11e9.meeting.ietf.org (dhcp-11e9.meeting.ietf.org [130.129.17.233]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0Lo2Ke-1RJRuJ26y8-00gQrr; Fri, 29 Jul 2011 00:24:32 +0200
References: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DDD0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922509A7DDD0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: 
Content-Transfer-Encoding: quoted-printable
From: Juergen Quittek 
Date: Thu, 28 Jul 2011 18:24:30 -0400
To: "Mielke, William F (Bill)" 
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:zd6OnDFh7q+0tWFKX8LK1p4CmWp8/hNx1a0HDHPSJdO 2GHOn0G0LHLmstzPSUQ9ZpP6EXxXmwFre6OjE+k3ArWfFbD62t uJo60dSUxKjoe0w65RlgSOmwl2ooMMzlco/6LABMusTmW4BY8z pa1sk6E2qME0O+4/eZeBkU0DScgy2e0/k/tMumlTG88gdW1fGp y5NdpDuixSbNB1wkuxpw+c9P+mPXacOGSuJSjGrv4c=
Cc: eman mailing list 
Subject: Re: [eman] Comments on draft-ietf-eman-battery-mib-02
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, 28 Jul 2011 22:24:36 -0000

Hi Bill,

Thank you very much for this review.
Please find replies inline.

Am 28.07.2011 um 12:45 schrieb Mielke, William F (Bill):

> Provided below.  I will forward a copy of my annotated PDF file to the =
authors.  The PDF version also includes some minor =
corrections/suggestions which are not reproduced below.
>=20
> William F. Mielke
> Alcatel-Lucent
> Distinguished Member of Technical Staff
> 6200 East Broad Street
> Room: 4B01-1V
> Columbus, OH  43213-1530
> Email: Bill.Mielke@alcatel-lucent.com
> Phone: 614 367 5628
> Fax: 614 367 5965
>=20
> "Live like you're going to die tomorrow.
> Learn like you're going to live forever."
>=20
>    - Albert Einstein
>=20
> ----------------------------------------------------------------
> Comments on draft-ietf-eman-battery-mib-02
> ----------------------------------------------------------------
>=20
> General Comments:
>=20
> 1. I believe that the definitions for the following terms should be =
adjusted to clarify their intent.  I was confused after reading the =
current definitions in the document but after some thought I believe =
that the intended use of these is as follows:
>=20
> batteryNominalCapacity:
>=20
> This represents the manufacturer's static design capacity for the =
battery.  It is the rated or nameplate value advertised by the =
manufacturer.  It is a static number.
>=20
> batteryActualCapacity:
>=20
> This represents the same value as batteryNominalCapacity only it has =
been adjusted to account for the age and historical usage of the battery =
both of which degrade its capacity below its nominal rating.  It is a =
dynamic estimate.
>=20
> batteryCurrentCharge:
>=20
> This represents the amount of energy which is estimated to be =
remaining in the battery at any given point in time.  It is a dynamic =
estimate.
>=20
> Are these the correct interpretations?

Yes, these are all correct.
Proposals for improved naming and explanations are very welcome.
We received proposals to rename batteryActualCapacity to =
batteryRemainingCapacity
BTW. This remaining capacity is often measured by the device.

> 2. In general I think that this is in pretty good shape.
>=20
> Deatiled Comments:
>=20
>> The Battery MIB module serves for monitoring the battery status. It
>> does not implement a Power Monitor as defined in the framework for
>> energy management [I-D.ietf-eman-framework]. (Page 3)
>=20
> Adjust to match the replacement terminology for "Power Monitor".

Yes. We have to as soon as we have agreed on terms.

>> batteryTemperature OBJECT-TYPE
>> SYNTAX Integer32
>> UNITS "degrees Celsius" (Page 16)
>=20
> I don't know the level of precision required here, but I suspect some =
level of fractional degrees would be appropriate.  Should we consider =
deci-degrees, centi-degrees, or even milli-degrees?  I would expect =
deci- or centi- would be appropriate but I have no expertise to back =
that up.  I will inquire about this with our SMEs and get back to you.

We are about to send the draft to external reviewers for review.
We will asked them for input on this issue.

>> batteryReplacementAlarmCycles OBJECT-TYPE
>> SYNTAX Unsigned32
>> UNITS "milliampere hours" (Page 18)
>=20
> This is simply a count, no?  So no units at all.  :)

Yes. Good catch. Thanks for pointing this out.

>> batteryHighAlarmTemperature OBJECT-TYPE
>> SYNTAX Integer32
>> UNITS "degrees Celsius" (Page 18)
>=20
> Same comment as above regarding the precision.

Yes.

>> 8.1. Writable Notification thresholds (Page 23)
>=20
> I favor allowing the thresholds to be settable by the EnMS.

Thanks,

    Juergen

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


From blueroofmusic@gmail.com  Thu Jul 28 16:16:54 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD4921F8B75 for ; Thu, 28 Jul 2011 16:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.265
X-Spam-Level: 
X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.333,  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 zyfDzUeRlayR for ; Thu, 28 Jul 2011 16:16:53 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5773921F8B3E for ; Thu, 28 Jul 2011 16:16:53 -0700 (PDT)
Received: by fxe6 with SMTP id 6so1926709fxe.31 for ; Thu, 28 Jul 2011 16:16:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u9eARxNHJYOWn5YLEDXo+9bStcxfMeHFFVJtW20mlVk=; b=UsohgHqeFA7JbE1gZ32kxJBSzRI8l6WeUhgnSDd4nojX6Qk+J+CYgDQkAcroQEJkT0 uBU6XYlkOK6fyR1fu3yAYL09aNzRpGXDjPagn+mwiCk8VzjPQ9jIDNS28MoDV2zplLnt d6NEZfaAsqsUUb41bxABEZ+nEEcDsOoLNAeD8=
MIME-Version: 1.0
Received: by 10.223.1.201 with SMTP id 9mr747173fag.91.1311895010424; Thu, 28 Jul 2011 16:16:50 -0700 (PDT)
Received: by 10.223.124.12 with HTTP; Thu, 28 Jul 2011 16:16:50 -0700 (PDT)
In-Reply-To: <22B2909DCC2E62418BE369A1F10488994B79885D@ex01.noveda.com>
References: <20110728164503.GA30392@elstar.local>   <22B2909DCC2E62418BE369A1F10488994B79885D@ex01.noveda.com>
Date: Thu, 28 Jul 2011 19:16:50 -0400
Message-ID: 
From: Ira McDonald 
To: Brad Schoening , Ira McDonald 
Content-Type: multipart/alternative; boundary=20cf3054a46114389e04a9295cf1
Cc: "eman@ietf.org" 
Subject: Re: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 23:16:54 -0000

--20cf3054a46114389e04a9295cf1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,

I find Juergen Schoenwalder's single enumeration arguments
compelling.  And we do have 32 bits, so 16-bits for particular
state seems quite sufficient.

Also, I suggest that power state should *not* be an index
in any table, if possible - though I did this in two tables in the
IEEE-ISTO PWG Imaging System Power MIB (for printers
and MFDs), but we didn't have to support multiple power
state series.

Even a table that describes the nominal power consumption
and capabilities (can accept work, can process work, etc.)
for each power state can have a simple integer index - an
NMS only needs to read this table once.

BTW - powSupportTable in the PWG Power MIB, has a much
richer set of the capabilities for each supported power state:

PowSupportEntry ::=3D SEQUENCE {
        powSupportPowerState            PowPowerStateTC,
        powSupportPowerInactiveWatts    Integer32,
        powSupportPowerActiveWatts      Integer32,
        powSupportCanAcceptJobs         TruthValue,
        powSupportCanProcessJobs        TruthValue,
        powSupportCanRequestPowerState  TruthValue,
        powSupportCanUseInterfaces      DisplayString,
        powSupportPowerPeakWatts        Integer32
    }

In the printer industry, the terms active and inactive are
qualifiers of the *same* operational or power state and
are *not* separate states.

Cheers,
- Ira (Editor of IEEE-ISTO PWG Imaging System Power MIB)


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

On Thu, Jul 28, 2011 at 6:07 PM, Brad Schoening wrot=
e:

> ECMA has four power states:  Off, Sleep, Idle, Active.  This more adaptab=
le than the three in 1621.   ****
>
> ** **
>
> I agree with John that =91mechanically off=92 is the correct term.****
>
>

--20cf3054a46114389e04a9295cf1
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,

I find Juergen Schoenwalder's single enumeration argumentscompelling.=A0 And we do have 32 bits, so 16-bits for particular
state=
 seems quite sufficient.

Also, I suggest that power state should *no=
t* be an index

in any table, if possible - though I did this in two tables in the 
IEEE=
-ISTO PWG Imaging System Power MIB (for printers 
and MFDs), but we didn=
't have to support multiple power
state series.

Even a table =
that describes the nominal power consumption 

and capabilities (can accept work, can process work, etc.)
for each powe=
r state can have a simple integer index - an
NMS only needs to read this=
 table once.

BTW - powSupportTable in the PWG Power MIB, has a much =


richer set of the capabilities for each supported power state:

PowSupportEntry ::=3D SEQUEN=
CE {
=A0=A0=A0=A0=A0=A0=A0 powSupportPower=
State=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PowPowerStateTC,

=A0=A0=A0=A0=A0=A0=A0 p=
owSupportPowerInactiveWatts=A0=A0=A0 Integer32,
=A0=A0=A0=A0=A0=A0=A0 powSupportPowerActiveWatts=A0=A0=A0=A0=A0 Integ=
er32,

=A0=A0=A0=A0=A0=A0=A0 p=
owSupportCanAcceptJobs=A0=A0=A0=A0=A0=A0=A0=A0 TruthValue,
=A0=A0=A0=A0=A0=A0=A0 powSupportCanProcessJobs=A0=A0=A0=
=A0=A0=A0=A0 TruthValue,

=A0=A0=A0=A0=A0=A0=A0 p=
owSupportCanRequestPowerState=A0 TruthValue,
=A0=A0=A0=A0=A0=A0=A0 powSupportCanUseInterfaces=A0=A0=A0=A0=A0 DisplayS=
tring,

=A0=A0=A0=A0=A0=A0=A0 p=
owSupportPowerPeakWatts=A0=A0=A0=A0=A0=A0=A0 Integer32
=A0=A0=A0 }


In the printer industry, the terms active and inactive are
qualifiers of=
 the *same* operational or power state and
are *not* separate states.
Cheers,
- Ira (Editor of IEEE-ISTO PWG Imaging System Power MIB)



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

On Thu, Jul 28, 2011 at 6:07 PM, Brad Schoening <bschoening@noveda.com>=
 wrote:


ECMA has four power states:=A0 Off, Sleep, Idle, Active.=A0 This more adaptable tha=
n the three in 1621.=A0=A0 


=A0
I agree with John that =91mechanically off=92 is the correct term.<=
/u>




--20cf3054a46114389e04a9295cf1--

From kerlyn2001@gmail.com  Thu Jul 28 15:51:41 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2E111E80A1 for ; Thu, 28 Jul 2011 15:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.952
X-Spam-Level: 
X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=1.648,  BAYES_00=-2.599, 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 jVN3B4CTI342 for ; Thu, 28 Jul 2011 15:51:41 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 037DA11E809A for ; Thu, 28 Jul 2011 15:51:40 -0700 (PDT)
Received: by qwc23 with SMTP id 23so2094350qwc.31 for ; Thu, 28 Jul 2011 15:51:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer; bh=GEWMM/zkKr2/5NQhw2LJd52Ri6Ased512xWuasR+SEo=; b=tT/x0RzuKg0FS6UnkQclaQSXHQGQbCQ4E06VMgYlfN6CraxUBQVylcAQrztlIu1oev +f20NVgxjGqhT93cm5CEKDRJaK14pWQcOzpRXnCKufqB58zJHxGSyLWkhPYF0ehsuR+s 2xo2te7hIwZsLdlIXHBrty8PWJhn9RWrXnpjQ=
Received: by 10.224.182.212 with SMTP id cd20mr476000qab.263.1311893500534; Thu, 28 Jul 2011 15:51:40 -0700 (PDT)
Received: from ?IPv6:2001:df8::16:a1aa:5d9c:5ea:f5c5? ([2001:df8:0:16:a1aa:5d9c:5ea:f5c5]) by mx.google.com with ESMTPS id u12sm1006724qct.39.2011.07.28.15.51.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 15:51:40 -0700 (PDT)
From: Kerry Lynn 
Content-Type: text/plain; charset=us-ascii
Message-Id: 
Date: Thu, 28 Jul 2011 18:51:39 -0400
To: "eman@ietf.org" 
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (iPhone Mail 8K2)
X-Mailer: iPhone Mail (8K2)
X-Mailman-Approved-At: Thu, 28 Jul 2011 21:18:35 -0700
Subject: [eman] ASHRAE 201P home page
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, 28 Jul 2011 22:51:41 -0000

This the effort I mentioned in the WG meeting. I don't see
any docs here yet, but you can see their charter and judge
whether their work might be applicable to your problem. 

I'll try to post their milestone dates along with any draft docs
if possible. 

-K-

Sent from my iPhone

From jparello@cisco.com  Fri Jul 29 09:38:03 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF4621F87ED for ; Fri, 29 Jul 2011 09:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.758
X-Spam-Level: 
X-Spam-Status: No, score=-2.758 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXZdeasJXnIx for ; Fri, 29 Jul 2011 09:38:02 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDD421F8582 for ; Fri, 29 Jul 2011 09:38:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=4255; q=dns/txt; s=iport; t=1311957482; x=1313167082; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=dbm5eCTZQhz4tgIM00m7m9WVRRn3q3fvF0RkYDhPuJw=; b=ffS+0P+0DbsY4wcEEgYkky3F3ShYr4fu32ui8aZeVmLdnBAmwvNEzxxe mkq+Nq4sJ6cFZKs1J3zmiz9TwuRxHYZOZ1XYzt84MchxFRgQ4tUXQcQcl JQanbpvV+TyQpSteZzqas0XoJm0SrKpOE5bjACKvHvk4oAPHIjXo7sHbH U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Au4AAKDhMk6rRDoI/2dsb2JhbAA0AQEBAQIBFAEhCkAFBQcDAgIBCQ4CAQQBAQsGDxQBBgETDC8OCAEBBRcMG5dtj1h3iHyhE54pAoM7giVfBIdakC+LdA
X-IronPort-AV: E=Sophos;i="4.67,288,1309737600";  d="scan'208";a="7845543"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-4.cisco.com with ESMTP; 29 Jul 2011 16:38:02 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6TGc1AZ003752; Fri, 29 Jul 2011 16:38:01 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 29 Jul 2011 09:38:01 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 29 Jul 2011 09:37:11 -0700
Message-ID: 
In-Reply-To: <20110728212016.GA31474@elstar.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] iana powerstate tc proposal
Thread-Index: AcxNbFK8yeio5cOJSmej02FQFby+qAAn/LwQ
References: <20110728164503.GA30392@elstar.local>  <20110728184235.GD30565@elstar.local>  <20110728212016.GA31474@elstar.local>
From: "John Parello (jparello)" 
To: "Juergen Schoenwaelder" 
X-OriginalArrivalTime: 29 Jul 2011 16:38:01.0559 (UTC) FILETIME=[E1BB4670:01CC4E0D]
Cc: eman@ietf.org
Subject: Re: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2011 16:38:03 -0000

Hi Jeurgen,

Either design is reasonable.=20

So I have some specific questions/use cases in your design that I am
concerned about:

1) How would a mgt station determine which power state sets are
supported?
This would be for a discovery stage inquiry. I want to determine the
power state sets supported by a device. I don't want to set any, just
determine which is supported

2) Can you ensure that if a device supports a particular power state set
it is valid to get or set a state in the series?
I don't mean valid from the point of the device ack or nack the set but
I mean not an error in syntax.

By that I mean with the two byte values you propose I can imagine
someone choosing to do DMTF(3) and DMTF(5) and then say IEEE(2)?  What
I'd like to have is a clear way of having these sets be like and
interface that an device supports. That's natural to the mgt stations
when presenting controls.

So I'm not concerned with the encoding but more about how to announce
and discover the power state sets a device supports.

I'd like one get with values of the power state sets supported. Then
assurance that if I try to decode to a specific set in that series is a
valid request (other than operational ack or nack)

Can your design cover that?

Jp

PS go for the 64K states right now versus the 255 so we don't have to
come back to this point in our lifetimes ;)





-----Original Message-----
From: Juergen Schoenwaelder
[mailto:j.schoenwaelder@jacobs-university.de]=20
Sent: Thursday, July 28, 2011 2:20 PM
To: John Parello (jparello)
Cc: eman@ietf.org
Subject: Re: [eman] iana powerstate tc proposal

On Thu, Jul 28, 2011 at 10:47:40PM +0200, John Parello (jparello) wrote:

> The code (value & 0xff) is not that complex. What I find complex is
> the following:
>=20
> - I always have to poll two OIDs to retrieve the power state. This
>   adds runtime verbosity and overhead.
>=20
> [jp] If you define a numeric value to each set then this is an index
to a state series subtree so you don't have to poll twice It would be in
a the tree. If you keep it the way you have it you have to poll the base
number first remember the series and then know to avoid or use that
range to find out what is supported. With a seperate power state set
number it's implicit in the data.  You just traverse or get the entire
table.

But that particular table design I think you are refering to is
awkward in the first place since it indexes and thus duplicates
objects that are really not specific to the set. That said, once
stored, a single integer is simply self-contained (and you even get a
meaningful descriptor with typical generic SNMP tools).
=20
> - I need to implement and enforce atomic sets with two varbinds in
>   order to change from a value in one power state set to a value in a
>   different power state set.
>=20
> [jp] If you have an index for the set first you get the same ability

Well, not completely true. If you have dmtf off and you want to change
to eman on, how does set look like? I know that you assume magic
implementation specific translations between the power state sets,
which I find ugly. Too much magic if our goal is interoperability.

> Compared to this, doing (value & 0xff) or (value >> 8) is rather
> cheap. And in addition, with this this appraoch,
>=20
> - I have _all_ IANA maintained power states defined in a machine
>   readable format, something that can drive tools and automation.
>=20
> [jp] Having an index to the series first is still machine
> readable.=20

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

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

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

/js

--=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 Jul 29 10:02:15 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3117B21F8AAC for ; Fri, 29 Jul 2011 10:02:15 -0700 (PDT)
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.185, 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 AnK0aP4f8Jwi for ; Fri, 29 Jul 2011 10:02:14 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2D96E21F8A80 for ; Fri, 29 Jul 2011 10:02:14 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 73A5320BFF; Fri, 29 Jul 2011 19:02:12 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id amp98zZp-jSS; Fri, 29 Jul 2011 19:02:10 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57BE720C13; Fri, 29 Jul 2011 19:02:10 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id B9B191A1EFBE; Fri, 29 Jul 2011 19:02:09 +0200 (CEST)
Date: Fri, 29 Jul 2011 19:02:09 +0200
From: Juergen Schoenwaelder 
To: "John Parello (jparello)" 
Message-ID: <20110729170207.GC34377@elstar.local>
Mail-Followup-To: "John Parello (jparello)" , eman@ietf.org
References: <20110728164503.GA30392@elstar.local>  <20110728184235.GD30565@elstar.local>  <20110728212016.GA31474@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: eman@ietf.org
Subject: Re: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2011 17:02:15 -0000

On Fri, Jul 29, 2011 at 09:37:11AM -0700, John Parello (jparello) wrote:
 
> So I have some specific questions/use cases in your design that I am
> concerned about:
> 
> 1) How would a mgt station determine which power state sets are
> supported?
> This would be for a discovery stage inquiry. I want to determine the
> power state sets supported by a device. I don't want to set any, just
> determine which is supported

I can imagine different ways of doing this but this also depends how
the tables in general look like for devices that claim to support
multiple power state sets. Is a device always in exactly one state or
can a device be in multiple states of different sets simultaneously?
If the later, what is the mapping and what happens if there is not
suitable mapping?
 
> 2) Can you ensure that if a device supports a particular power state set
> it is valid to get or set a state in the series?
> I don't mean valid from the point of the device ack or nack the set but
> I mean not an error in syntax.
> 
> By that I mean with the two byte values you propose I can imagine
> someone choosing to do DMTF(3) and DMTF(5) and then say IEEE(2)?  What
> I'd like to have is a clear way of having these sets be like and
> interface that an device supports. That's natural to the mgt stations
> when presenting controls.

I am not sure I understand your question. You set the state to
dmtfSleepDeep or dmtfOffSoft or ieee1621Sleep. The device will either
do as requested or return an error. If your NMS wants to present
things in a different way (because you believe DMTF(3) is more user
friendly than dmtfSleep), this can be easily be done. The encoding on
the wire is not the user interface.

> So I'm not concerned with the encoding but more about how to announce
> and discover the power state sets a device supports.
> 
> I'd like one get with values of the power state sets supported. Then
> assurance that if I try to decode to a specific set in that series is a
> valid request (other than operational ack or nack)

If the device is correct and the power state set did not get augmented
(seems to have happened in the past), you can make this assumption. In
the real world, you know that a set succeeds when it got carried out.
(But this is generally independent of the encoding.) The main point
here is that power state sets do not seem to be static and with
additions over time and implementations improving over time, you
simply will never be fully sure. This is a versioning issues and
independent of the encoding on the wire - you will always face this.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From kerlyn2001@gmail.com  Fri Jul 29 10:23:59 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A8121F8AF7 for ; Fri, 29 Jul 2011 10:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=1.098, 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 dnkpc7NfWMOn for ; Fri, 29 Jul 2011 10:23:58 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3566A21F8AD3 for ; Fri, 29 Jul 2011 10:23:58 -0700 (PDT)
Received: by iye7 with SMTP id 7so5112422iye.31 for ; Fri, 29 Jul 2011 10:23:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=L94FZ8Mdw3ytMeqeAbFJw2rglqM9g2gZ96/1/GW6u54=; b=fZa0wGuLD7O0ygFdwnqwlZ3ZV+aIjXKElk383qk1kgbWivShOfna8pH1dTYx1r6nLi tqulQ9/YPK/ZbTJmQwbpW+vHFuMvK5dAz5pwllKVZC8Ppy5ZN6g5fLE5/Chm+lxBhFim 9ui4Wat0fZ+P+xBBIAbLO0R+shPelLv/6Bnqs=
MIME-Version: 1.0
Received: by 10.42.170.130 with SMTP id f2mr358813icz.283.1311960236324; Fri, 29 Jul 2011 10:23:56 -0700 (PDT)
Received: by 10.42.174.66 with HTTP; Fri, 29 Jul 2011 10:23:56 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 29 Jul 2011 13:23:56 -0400
Message-ID: 
From: Kerry Lynn 
To: "eman@ietf.org" 
Content-Type: multipart/alternative; boundary=90e6ba6e883cd878e104a9388be5
Subject: Re: [eman] ASHRAE 201P home page
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, 29 Jul 2011 17:23:59 -0000

--90e6ba6e883cd878e104a9388be5
Content-Type: text/plain; charset=ISO-8859-1

Somehow the URI didn't make it into the message:
http://spc201.ashraepcs.org/

I believe the standard produced by ASHRAE SPC 201 will
be the main deliverable of SGIP PAP 17:
http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP17FacilitySmartGridInformationStandard

I believe those who wish to see the current draft FSGIMs
(Facility Smart Grid Information Models) must join the
ASHRAE 201P committee.  I'll provide additional information
if that changes.

Regards, -K-


On Thu, Jul 28, 2011 at 6:51 PM, Kerry Lynn  wrote:

> This the effort I mentioned in the WG meeting. I don't see
> any docs here yet, but you can see their charter and judge
> whether their work might be applicable to your problem.
>
> I'll try to post their milestone dates along with any draft docs
> if possible.
>
> -K-
>
> Sent from my iPhone
>

--90e6ba6e883cd878e104a9388be5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Somehow the URI didn't make it into the message:

I believe the standard produced by ASHRAE SPC 201 will
be t=
he main deliverable of SGIP PAP 17:


http://collaborate.nist.gov/twi=
ki-sggrid/bin/view/SmartGrid/PAP17FacilitySmartGridInformationStandard<=
/div>


I believe those who wish to see the current draft FSGIM=
s
(Facility Smart Grid Information Models) must join the
ASHRAE 201P committee. =A0I'll provide additional information


if that changes.

Regards, -K-

<=
br>
On Thu, Jul 28, 2011 at 6:51 PM, Kerry Lynn <=
span dir=3D"ltr"><kerlyn2001@gma=
il.com> wrote:


This the effort I mentioned in the WG meeti=
ng. I don't see

any docs here yet, but you can see their charter and judge

whether their work might be applicable to your problem.



I'll try to post their milestone dates along with any draft docs

if possible.



-K-



Sent from my iPhone





--90e6ba6e883cd878e104a9388be5--

From jparello@cisco.com  Fri Jul 29 10:27:26 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05C65E8003 for ; Fri, 29 Jul 2011 10:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.752
X-Spam-Level: 
X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVOb3lfCKdUB for ; Fri, 29 Jul 2011 10:27:25 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E4E0321F8B3F for ; Fri, 29 Jul 2011 10:27:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=3693; q=dns/txt; s=iport; t=1311960440; x=1313170040; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=IUyy1fbC/ceh/FhAC3TYegFJab7v9QbBVcmZV/Asn3c=; b=Qe5HpxGki+yTnTD6obkglpJQ3m5N+7sBJV9UiKaB1BLPNawtnWiFTfMW 77sxvvGyQsJXwNpW1EwOTFVL1Mm+QiN3WXzKLoILEMDif2cHA10KCDfkD rXO/sSSSvyWny+5gBhS+aOG+3jv6XdvQmyofLhdRaP5MFUtwT1coJXhaM E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtgAAC/sMk6rRDoI/2dsb2JhbAA0AQEBAQIBFAEhCjMNBQUHAwICAQkOAgEEAQELBg8UAQYBEwwvDggBAQUXDBuXbY9Yd4h8oGueKQKDO4IlXwSHWpAvi3Q
X-IronPort-AV: E=Sophos;i="4.67,288,1309737600";  d="scan'208";a="7859672"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-2.cisco.com with ESMTP; 29 Jul 2011 17:27:19 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6THRIWB013135; Fri, 29 Jul 2011 17:27:19 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 29 Jul 2011 10:27:18 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 29 Jul 2011 10:26:28 -0700
Message-ID: 
In-Reply-To: <20110729170207.GC34377@elstar.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] iana powerstate tc proposal
Thread-Index: AcxOEUgISXNOwBtoS3SVf2f+SoVdPAAAs48w
References: <20110728164503.GA30392@elstar.local>  <20110728184235.GD30565@elstar.local>  <20110728212016.GA31474@elstar.local>  <20110729170207.GC34377@elstar.local>
From: "John Parello (jparello)" 
To: "Juergen Schoenwaelder" 
X-OriginalArrivalTime: 29 Jul 2011 17:27:18.0637 (UTC) FILETIME=[C44991D0:01CC4E14]
Cc: eman@ietf.org
Subject: Re: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2011 17:27:26 -0000

Hi Jeurgen,

Ok, I guess maybe my questions are in the mib design then not the IANA
registry.

I want to ask what are the power sets you support. After that I want to
make sure that if I ask  to go to a state in a set that was not
supported - that is a different error than if I ask to set to a state
and the device can/cannot do that right now.

So I'm looking for validity of request versus execution of request.

For your question on multiple states and sets at the same time I think
we converged (see Bills email) on two power sets can be supported at the
same time.

Jp

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:j.schoenwaelder@jacobs-university.de]=20
Sent: Friday, July 29, 2011 10:02 AM
To: John Parello (jparello)
Cc: eman@ietf.org
Subject: Re: [eman] iana powerstate tc proposal

On Fri, Jul 29, 2011 at 09:37:11AM -0700, John Parello (jparello) wrote:
=20
> So I have some specific questions/use cases in your design that I am
> concerned about:
>=20
> 1) How would a mgt station determine which power state sets are
> supported?
> This would be for a discovery stage inquiry. I want to determine the
> power state sets supported by a device. I don't want to set any, just
> determine which is supported

I can imagine different ways of doing this but this also depends how
the tables in general look like for devices that claim to support
multiple power state sets. Is a device always in exactly one state or
can a device be in multiple states of different sets simultaneously?
If the later, what is the mapping and what happens if there is not
suitable mapping?
=20
> 2) Can you ensure that if a device supports a particular power state
set
> it is valid to get or set a state in the series?
> I don't mean valid from the point of the device ack or nack the set
but
> I mean not an error in syntax.
>=20
> By that I mean with the two byte values you propose I can imagine
> someone choosing to do DMTF(3) and DMTF(5) and then say IEEE(2)?  What
> I'd like to have is a clear way of having these sets be like and
> interface that an device supports. That's natural to the mgt stations
> when presenting controls.

I am not sure I understand your question. You set the state to
dmtfSleepDeep or dmtfOffSoft or ieee1621Sleep. The device will either
do as requested or return an error. If your NMS wants to present
things in a different way (because you believe DMTF(3) is more user
friendly than dmtfSleep), this can be easily be done. The encoding on
the wire is not the user interface.

> So I'm not concerned with the encoding but more about how to announce
> and discover the power state sets a device supports.
>=20
> I'd like one get with values of the power state sets supported. Then
> assurance that if I try to decode to a specific set in that series is
a
> valid request (other than operational ack or nack)

If the device is correct and the power state set did not get augmented
(seems to have happened in the past), you can make this assumption. In
the real world, you know that a set succeeds when it got carried out.
(But this is generally independent of the encoding.) The main point
here is that power state sets do not seem to be static and with
additions over time and implementations improving over time, you
simply will never be fully sure. This is a versioning issues and
independent of the encoding on the wire - you will always face this.

/js

--=20
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From jparello@cisco.com  Fri Jul 29 10:36:31 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8DD21F8A70 for ; Fri, 29 Jul 2011 10:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.747
X-Spam-Level: 
X-Spam-Status: No, score=-6.747 tagged_above=-999 required=5 tests=[AWL=3.852,  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 OFzuI56Wg7WF for ; Fri, 29 Jul 2011 10:36:29 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 984F121F8A95 for ; Fri, 29 Jul 2011 10:36:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=37; q=dns/txt; s=iport; t=1311960989; x=1313170589; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=LcjWw3FBQdn110muLOyoFSwdpnefjVKaqRW7CH7pGZ0=; b=irXj5yMJf/hf8BOwehShz4tg3CYR4h+/AisCv1sVQE4F26BSx2pt+spc EOk/spB5Qp9aUKiets+cc11yY1BAiWkdhZ3Am8mMYUQB3pW3nb128qme6 E4LkdC/U8IYC5Sg8H/SRCDhRxdYSBp4c58LS4gR3bhEh65q9AVR3cqbaO 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhsHADnvMk6Q/khN/2dsb2JhbAAwBgEBAxQBCRgKWAErBiQHE1IBBSMBGpgxjxR3iHYKnyuBI54qhWJfBIdakC+LdA
X-IronPort-AV: E=Sophos;i="4.67,288,1309737600"; d="scan'208";a="105718985"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2011 17:36:28 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6THa3oa031796 for ; Fri, 29 Jul 2011 17:36:28 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 29 Jul 2011 10:36:24 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 29 Jul 2011 10:35:34 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] FYI... RFC 4122  for UUID
Thread-Index: AcxOFevYO9yRvhlMQHul2t4KymFHDA==
From: "John Parello (jparello)" 
To: 
X-OriginalArrivalTime: 29 Jul 2011 17:36:24.0417 (UTC) FILETIME=[0998FD10:01CC4E16]
Subject: [eman]  FYI... RFC 4122  for UUID
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, 29 Jul 2011 17:36:31 -0000

http://www.ietf.org/rfc/rfc4122.txt

From j.schoenwaelder@jacobs-university.de  Fri Jul 29 12:51:38 2011
Return-Path: 
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0C111E808D for ; Fri, 29 Jul 2011 12:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.067
X-Spam-Level: 
X-Spam-Status: No, score=-103.067 tagged_above=-999 required=5 tests=[AWL=0.182, 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 l8tTKxODvfdQ for ; Fri, 29 Jul 2011 12:51:37 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD6E11E807C for ; Fri, 29 Jul 2011 12:51:29 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB8DF20C3A; Fri, 29 Jul 2011 21:51:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id oMfOTqTLjWJZ; Fri, 29 Jul 2011 21:51:27 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BF7A20C39; Fri, 29 Jul 2011 21:51:27 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0AB521A1F27A; Fri, 29 Jul 2011 21:51:27 +0200 (CEST)
Date: Fri, 29 Jul 2011 21:51:26 +0200
From: Juergen Schoenwaelder 
To: "John Parello (jparello)" 
Message-ID: <20110729195126.GB34681@elstar.local>
Mail-Followup-To: "John Parello (jparello)" , eman@ietf.org
References: <20110728164503.GA30392@elstar.local>  <20110728184235.GD30565@elstar.local>  <20110728212016.GA31474@elstar.local>  <20110729170207.GC34377@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: eman@ietf.org
Subject: Re: [eman] iana powerstate tc proposal
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2011 19:51:38 -0000

On Fri, Jul 29, 2011 at 10:26:28AM -0700, John Parello (jparello) wrote:
 
> I want to ask what are the power sets you support. After that I want to
> make sure that if I ask  to go to a state in a set that was not
> supported - that is a different error than if I ask to set to a state
> and the device can/cannot do that right now.
> 
> So I'm looking for validity of request versus execution of request.

This is an SNMP question since error codes are SNMP specific, not data
model specific. Fortunately, SNMP distinquishes between 'wrongValue',
'inconsistentValue', and 'resourceUnavailable' (see section 4.2.5 of
RFC 3416 for the details).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103