From karagian@cs.utwente.nl Wed Aug 1 11:03:45 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728C011E8399 for ; Wed, 1 Aug 2012 11:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.212 X-Spam-Level: X-Spam-Status: No, score=-0.212 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFlWROCtXqXR for ; Wed, 1 Aug 2012 11:03:43 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC2511E82F8 for ; Wed, 1 Aug 2012 11:03:42 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 1 Aug 2012 20:03:41 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.41]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Wed, 1 Aug 2012 20:03:41 +0200 From: To: , , Thread-Topic: [eman] comments on draft-ietf-eman-applicability-statement-01.txt Thread-Index: AQHNb35I9BjHlVF8ykukn1vjCIzjiZdEB30AgAE2QcA= Date: Wed, 1 Aug 2012 18:03:40 +0000 Message-ID: References: , In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.114.255.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] comments on draft-ietf-eman-applicability-statement-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:03:45 -0000 Hi Brad, The proposed subsection is closest to the Home Energy Gateways use case (Se= ction 2.7). This use case illustrates the aggregation of the energy use in neighborhood= s. In particular, this use case differs from the Home Energy Gateway use ca= se from the point of how the aggregation of energy needs to be managed, how= frequent the energy objects need to be monitored and how they need to be m= anaged. In other words the magement of the power quality and reliability in these t= wo domais (Home and neighborhood) is different, see also draft-nordman-nano= grids-00 and the following paper: Marnay, C., Nordman, B., and J. Lai, "Future Roles of Milli-, Micro-, and = Nano- Grids", presented at the CIGRE International Symposium, Bologna, Ital= y LBNL-4927E, 2011. Best regards, Georgios ________________________________________ Van: Brad Schoening [brads@coraid.com] Verzonden: woensdag 1 augustus 2012 3:21 Aan: Karagiannis, G. (EWI); moulchan@cisco.com; eman@ietf.org Onderwerp: Re: [eman] comments on draft-ietf-eman-applicability-statement-0= 1.txt Georgios, We very much appreciate your input on Neighborhood Energy Gateways, but as mentioned previously, we feel they are covered by our existing use cases. While there are a large number of potential specific use case, we have tried to provide general ones. Could you provide more information regarding why you feel this is not covered by our existing use cases. It would help us if you could identify which use cases are closest to the Neighborhood Energy Gateway, and in which ways you find them not quite adequate. The result may not be a new use case, but perhaps we can improve an existing one so that it covers this one. Best Regards, Brad On 7/31/12 5:44 PM, "karagian@cs.utwente.nl" wrote: >Hi Mouli, Hi all, > >I have two comments on draft-ietf-eman-applicability-statement-01.txt. > >Comment_1: On the 24th of June, see bottom of this email, I have had >provided input for a new subsection that describes the Neighborhood >Energy Gateways use case. Hopefully it is not too late to include this >section in the draft. > >Comment_2: The description of the IEEE 37.118-2005 [IEEE37118] is >missing. This is a monitoring standard based on synchrophasors, like >Phasor Measurement Units (PMUs). >Please note that an ongoing IEC standardization activity was defined that >is focusing on the integration of this type of monitoring into IEC 61850, >see reference [Mar11] below. > >[IEEE37118] IEEE 37.118-2005, "IEEE Standard for Synchrophasors for Power >System", IEEE standard, 2005. > >[Mart11] K. E. Martin, "Synchrophasor Standards Development - IEEE >C37.118 & IEC 61850", Proc. of 44th Hawaii International Conference on >System Sciences (ICSS'2011), pp. 1-8, 2011. > >Best regards, >Georgios > >_______________________________________ >Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens >karagian@cs.utwente.nl [karagian@cs.utwente.nl] >Verzonden: zondag 24 juni 2012 21:39 >Aan: moulchan@cisco.com; eman@ietf.org >Onderwerp: Re: [eman] draft-ietf-eman-applicability-statement-01.txt > >Hi Mouli, Hi all, > >During the IETF eman WG meeting in Paris I had promissed to send a >proposal text for a new section that describes the neighborhood energy >gateways. >This text can be found below: > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >2.x. Neighborhood Energy Gateways > >This use case describes the scenario of energy management of a >neighborhood, where a neighborhood energy gateway operates as a proxy >that interfaces to the home energy gateways. > It is expected that the number of photovoltaic stations (PV) on the >roofs of the houses in towns will increase significantly during the next >years. Moreover, a large scale deployment of some renewable energy >sources, namely wind and solar, imposes system integration challenges >due to their variable and often unpredictable characteristics. >Furthermore, current central systems used for energy management are not >able to efficiently >coordinate distributed renewable energy in higher penetration. >In order to increase the overall energy efficiency including the >producers and consumers, neighborhood energy gateways can be used to >manage the consumption of the locally produced energy as locally as >possible, within the neighborhood and between the individual >buildings/homes. >If the energy produced by an individual building/home cannot be consumed >by the same building/home, then either another building/home in the >neighborhood could be found to consume the energy or means need to be >found to store it. This can be supported using the neighborhood energy >gateways that monitor and manage the home energy gateways. >The EMAN information model can be applied to the protocols under >consideration for energy management of a neighborhood. > > The essential properties of this use case are: > > . Target devices: Neighborhood Energy Gateways and Home energy >gateways > . How powered: Any method. > . Reporting: Neighborhood Energy Gateways can collect power >consumption of a home via the home energy gateway and possibly report the >metering reading to the utility. > >This use case illustrates the aggregation of the energy use in >neighborhoods. In particular, this use case differs from the Home Energy >Gateway use case from the point of how the aggregation of energy needs to >be managed, how frequent the energy objects need to be monitored and how >they need to be managed. > >=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Best regards, >Georgios >________________________________________ >Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens Mouli >Chandramouli (moulchan) [moulchan@cisco.com] >Verzonden: dinsdag 19 juni 2012 8:29 >Aan: eman@ietf.org >Onderwerp: [eman] draft-ietf-eman-applicability-statement-01.txt > >Hello all, > >An updated version of the EMAN Applicability Statement has been >submitted. > >http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-01 > >Most open issues from the previous version of the draft have been closed >at the IETF 83 WG meeting. > >The remaining open issues are: > >1. Relevance of ASHRAE SPC201P to EMAN standards (comment from Dave >Robin @ WG meeting) > > ASHRAE standard has not been released for public review yet and >should be available in a month or so. > Hopefully, the next version of the applicability statement draft >shall have a discussion on this topic. > >2. Scope of Applicability Statement draft > > This was discussed in the last WG meeting and some overlap of among >cases was considered fine. > Secondly, the Applicability Statement draft should describe how the >technology developed in the other drafts can be applied/implemented. > In that sense, Applicability Statement can be completed after >Requirements, Framework, MIB modules are stable. > >Please let us know if you have any comments, suggestions to improve the >draft. > >Thanks >Bruce, Brad and Mouli > > > >-----Original Message----- >From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of >internet-drafts@ietf.org >Sent: Tuesday, June 19, 2012 11:39 AM >To: i-d-announce@ietf.org >Cc: eman@ietf.org >Subject: [eman] I-D Action: >draft-ietf-eman-applicability-statement-01.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Energy Management Working Group of the >IETF. > > Title : Energy Management (EMAN) Applicability >Statement > Author(s) : Brad Schoening > Mouli Chandramouli > Bruce Nordman > Filename : draft-ietf-eman-applicability-statement-01.txt > Pages : 30 > Date : 2012-06-18 > >Abstract: > The objective of Energy Management (EMAN) is to provide an > energy management framework for networked devices. This > document presents the applicability of the EMAN framework for a > variety of scenarios. This document lists use cases and target > devices that can potentially implement the EMAN framework and > associated SNMP MIB modules. These use cases are useful for > identifying requirements for the framework. Further, we > describe the relationship of the EMAN framework to relevant > other energy monitoring standards and architectures. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-01 > >A diff from previous version is available at: >http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-applicability-stateme >nt-01 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman= From brads@coraid.com Wed Aug 1 11:14:19 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F2411E829D for ; Wed, 1 Aug 2012 11:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3Pa+mEabGOc for ; Wed, 1 Aug 2012 11:14:18 -0700 (PDT) Received: from server505.appriver.com (server505k.appriver.com [98.129.35.43]) by ietfa.amsl.com (Postfix) with ESMTP id D776911E825D for ; Wed, 1 Aug 2012 11:14:17 -0700 (PDT) X-Note-AR-ScanTimeLocal: 8/1/2012 1:14:16 PM X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Primary: brads@coraid.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @coraid.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G279 G280 G281 G282 G286 G287 G298 G389 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 22143735; Wed, 01 Aug 2012 13:14:16 -0500 Received: from MBX22.exg5.exghost.com ([169.254.1.186]) by HT08-E5.exg5.exghost.com ([98.129.23.244]) with mapi; Wed, 1 Aug 2012 13:14:14 -0500 From: Brad Schoening To: "karagian@cs.utwente.nl" , "moulchan@cisco.com" , "eman@ietf.org" Date: Wed, 1 Aug 2012 13:14:13 -0500 Thread-Topic: [eman] comments on draft-ietf-eman-applicability-statement-01.txt Thread-Index: Ac1wEXSjyohUz/yQQ5u6hIhqpH+PdA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] comments on draft-ietf-eman-applicability-statement-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:14:19 -0000 Georgios, Great. That's helpful. I'm wondering, does this use case add additional requirements? It seem it may require additional information in the EMAN model to provide support for the storage and routing of excess energy produced. Brad Schoening Engineering | Coraid Tel: +1 917 304 7190 brads@coraid.com | www.coraid.com Coraid: Redefining Storage On 8/1/12 11:03 AM, "karagian@cs.utwente.nl" wrote: >Hi Brad, > >The proposed subsection is closest to the Home Energy Gateways use case >(Section 2.7). > >This use case illustrates the aggregation of the energy use in >neighborhoods. In particular, this use case differs from the Home Energy >Gateway use case from the point of how the aggregation of energy needs to >be managed, how frequent the energy objects need to be monitored and how >they need to be managed. >In other words the magement of the power quality and reliability in these >two domais (Home and neighborhood) is different, see also >draft-nordman-nanogrids-00 and the following paper: > > Marnay, C., Nordman, B., and J. Lai, "Future Roles of Milli-, Micro-, >and Nano- Grids", presented at the CIGRE International Symposium, >Bologna, Italy LBNL-4927E, 2011. > >Best regards, >Georgios > > > > >________________________________________ >Van: Brad Schoening [brads@coraid.com] >Verzonden: woensdag 1 augustus 2012 3:21 >Aan: Karagiannis, G. (EWI); moulchan@cisco.com; eman@ietf.org >Onderwerp: Re: [eman] comments on >draft-ietf-eman-applicability-statement-01.txt > >Georgios, > >We very much appreciate your input on Neighborhood Energy Gateways, but as >mentioned previously, we feel they are covered by our existing use cases. >While there are a large number of potential specific use case, we have >tried to provide general ones. Could you provide more information >regarding why you feel this is not covered by our existing use cases. > >It would help us if you could identify which use cases are closest to the >Neighborhood Energy Gateway, and in which ways you find them not quite >adequate. The result may not be a new use case, but perhaps we can >improve an existing one so that it covers this one. > >Best Regards, > >Brad > > > >On 7/31/12 5:44 PM, "karagian@cs.utwente.nl" >wrote: > >>Hi Mouli, Hi all, >> >>I have two comments on draft-ietf-eman-applicability-statement-01.txt. >> >>Comment_1: On the 24th of June, see bottom of this email, I have had >>provided input for a new subsection that describes the Neighborhood >>Energy Gateways use case. Hopefully it is not too late to include this >>section in the draft. >> >>Comment_2: The description of the IEEE 37.118-2005 [IEEE37118] is >>missing. This is a monitoring standard based on synchrophasors, like >>Phasor Measurement Units (PMUs). >>Please note that an ongoing IEC standardization activity was defined that >>is focusing on the integration of this type of monitoring into IEC 61850, >>see reference [Mar11] below. >> >>[IEEE37118] IEEE 37.118-2005, "IEEE Standard for Synchrophasors for Power >>System", IEEE standard, 2005. >> >>[Mart11] K. E. Martin, "Synchrophasor Standards Development - IEEE >>C37.118 & IEC 61850", Proc. of 44th Hawaii International Conference on >>System Sciences (ICSS'2011), pp. 1-8, 2011. >> >>Best regards, >>Georgios >> >>_______________________________________ >>Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens >>karagian@cs.utwente.nl [karagian@cs.utwente.nl] >>Verzonden: zondag 24 juni 2012 21:39 >>Aan: moulchan@cisco.com; eman@ietf.org >>Onderwerp: Re: [eman] draft-ietf-eman-applicability-statement-01.txt >> >>Hi Mouli, Hi all, >> >>During the IETF eman WG meeting in Paris I had promissed to send a >>proposal text for a new section that describes the neighborhood energy >>gateways. >>This text can be found below: >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>2.x. Neighborhood Energy Gateways >> >>This use case describes the scenario of energy management of a >>neighborhood, where a neighborhood energy gateway operates as a proxy >>that interfaces to the home energy gateways. >> It is expected that the number of photovoltaic stations (PV) on the >>roofs of the houses in towns will increase significantly during the next >>years. Moreover, a large scale deployment of some renewable energy >>sources, namely wind and solar, imposes system integration challenges >>due to their variable and often unpredictable characteristics. >>Furthermore, current central systems used for energy management are not >>able to efficiently >>coordinate distributed renewable energy in higher penetration. >>In order to increase the overall energy efficiency including the >>producers and consumers, neighborhood energy gateways can be used to >>manage the consumption of the locally produced energy as locally as >>possible, within the neighborhood and between the individual >>buildings/homes. >>If the energy produced by an individual building/home cannot be consumed >>by the same building/home, then either another building/home in the >>neighborhood could be found to consume the energy or means need to be >>found to store it. This can be supported using the neighborhood energy >>gateways that monitor and manage the home energy gateways. >>The EMAN information model can be applied to the protocols under >>consideration for energy management of a neighborhood. >> >> The essential properties of this use case are: >> >> . Target devices: Neighborhood Energy Gateways and Home energy >>gateways >> . How powered: Any method. >> . Reporting: Neighborhood Energy Gateways can collect power >>consumption of a home via the home energy gateway and possibly report the >>metering reading to the utility. >> >>This use case illustrates the aggregation of the energy use in >>neighborhoods. In particular, this use case differs from the Home Energy >>Gateway use case from the point of how the aggregation of energy needs to >>be managed, how frequent the energy objects need to be monitored and how >>they need to be managed. >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>Best regards, >>Georgios >>________________________________________ >>Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens Mouli >>Chandramouli (moulchan) [moulchan@cisco.com] >>Verzonden: dinsdag 19 juni 2012 8:29 >>Aan: eman@ietf.org >>Onderwerp: [eman] draft-ietf-eman-applicability-statement-01.txt >> >>Hello all, >> >>An updated version of the EMAN Applicability Statement has been >>submitted. >> >>http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-01 >> >>Most open issues from the previous version of the draft have been closed >>at the IETF 83 WG meeting. >> >>The remaining open issues are: >> >>1. Relevance of ASHRAE SPC201P to EMAN standards (comment from Dave >>Robin @ WG meeting) >> >> ASHRAE standard has not been released for public review yet and >>should be available in a month or so. >> Hopefully, the next version of the applicability statement draft >>shall have a discussion on this topic. >> >>2. Scope of Applicability Statement draft >> >> This was discussed in the last WG meeting and some overlap of among >>cases was considered fine. >> Secondly, the Applicability Statement draft should describe how the >>technology developed in the other drafts can be applied/implemented. >> In that sense, Applicability Statement can be completed after >>Requirements, Framework, MIB modules are stable. >> >>Please let us know if you have any comments, suggestions to improve the >>draft. >> >>Thanks >>Bruce, Brad and Mouli >> >> >> >>-----Original Message----- >>From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of >>internet-drafts@ietf.org >>Sent: Tuesday, June 19, 2012 11:39 AM >>To: i-d-announce@ietf.org >>Cc: eman@ietf.org >>Subject: [eman] I-D Action: >>draft-ietf-eman-applicability-statement-01.txt >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Energy Management Working Group of the >>IETF. >> >> Title : Energy Management (EMAN) Applicability >>Statement >> Author(s) : Brad Schoening >> Mouli Chandramouli >> Bruce Nordman >> Filename : draft-ietf-eman-applicability-statement-01.txt >> Pages : 30 >> Date : 2012-06-18 >> >>Abstract: >> The objective of Energy Management (EMAN) is to provide an >> energy management framework for networked devices. This >> document presents the applicability of the EMAN framework for a >> variety of scenarios. This document lists use cases and target >> devices that can potentially implement the EMAN framework and >> associated SNMP MIB modules. These use cases are useful for >> identifying requirements for the framework. Further, we >> describe the relationship of the EMAN framework to relevant >> other energy monitoring standards and architectures. >> >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-01 >> >>A diff from previous version is available at: >>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-applicability-statem= e >>nt-01 >> >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>eman mailing list >>eman@ietf.org >>https://www.ietf.org/mailman/listinfo/eman >>_______________________________________________ >>eman mailing list >>eman@ietf.org >>https://www.ietf.org/mailman/listinfo/eman >>_______________________________________________ >>eman mailing list >>eman@ietf.org >>https://www.ietf.org/mailman/listinfo/eman >>_______________________________________________ >>eman mailing list >>eman@ietf.org >>https://www.ietf.org/mailman/listinfo/eman From karagian@cs.utwente.nl Wed Aug 1 11:17:51 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A251D11E825D for ; Wed, 1 Aug 2012 11:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.248 X-Spam-Level: X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAM+YpkTZx1u for ; Wed, 1 Aug 2012 11:17:50 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA4811E826D for ; Wed, 1 Aug 2012 11:17:49 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 1 Aug 2012 20:17:48 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.41]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Wed, 1 Aug 2012 20:17:47 +0200 From: To: , , Thread-Topic: [eman] comments on draft-ietf-eman-requirements-08.txt Thread-Index: AQHNb3t8cLxl7ZurrkC784Qyz3NiY5dECFaAgAE7m1A= Date: Wed, 1 Aug 2012 18:17:47 +0000 Message-ID: References: , In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.114.255.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] comments on draft-ietf-eman-requirements-08.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:17:51 -0000 Hi Brad, The IEEE C37.118 standard specifies the monitoring and the communication of= the=20 synchrophasor measurements from Phasor Measurement Units (PMUs) towards the= phasor data concentrators (PDCs). By using the received synchrophasor measurement data and information (via t= he PDCs) the grid operators will be able to have better visibility of power= grid operations and respond to grid disturbances earlier to prevent major = blackouts. >From IEEE C37.118 we could use the specification related to monitoring. Best regards, Georgios ________________________________________ Van: Brad Schoening [brads@coraid.com] Verzonden: woensdag 1 augustus 2012 3:24 Aan: Karagiannis, G. (EWI); Quittek@neclab.eu; eman@ietf.org Onderwerp: Re: [eman] comments on draft-ietf-eman-requirements-08.txt Hi Georgios, The standard you reference, IEEE 37.118, appears to involve a special communications protocol with phasor measurement units (PMUs). Could you provide a little more background on this standard and how it would be applicable in a SNMP management environment? Most importantly, could not synchrophasor data simply roll up and be reported as an aggregate in EMAN? In EMAN, we have tried to provide general use case that cover many different underlying technologies for acquiring the data. By encapsulating the specifics of the underlying protocols, we simplify the reporting and control. Regarding bi-directional power, I believe we cover that by allowing meters to report consumed, exported, and net energy. Best Regards, Brad Schoening On 7/31/12 5:34 PM, "karagian@cs.utwente.nl" wrote: >Hi Juergen, Hi all, > >I have read the last version of the requirements draft and I have two >main comments! > >Comment_1: Section 5.3, page 14, specifies that: >"Power monitoring should be in line with existing standards, such as >[IEC.61850-7-4]." > >What I miss is a reference to IEEE 37.118-2005 [IEEE37118], which is a >monitoring standard based on synchrophasors, like Phasor Measurement >Units (PMUs). >Please note that an ongoing IEC standardization activity was defined that >is focusing on the integration of this type of monitoring into IEC 61850, >see reference [Mar11] below. >Note also that a reference to IEEE37118 is not included in the >Applicability statement draft. I will be happy to provide input on this >standard. > >[IEEE37118] IEEE 37.118-2005, "IEEE Standard for Synchrophasors for Power >System", IEEE standard, 2005. > >[Mart11] K. E. Martin, "Synchrophasor Standards Development - IEEE >C37.118 & IEC 61850", Proc. of 44th Hawaii International Conference on >System Sciences (ICSS'2011), pp. 1-8, 2011. > >Comment_2: The requirements draft is not mentioning bidirectional power >interfaces, which I think is needed. For motivation of this argument, >please see section 4.1.4 of the eman framework draft. > >Best regards, >Georgios > > >________________________________________ >Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens Juergen Quittek >[Quittek@neclab.eu] >Verzonden: maandag 16 juli 2012 15:50 >Aan: eman mailing list >Onderwerp: [eman] FW: New Version Notification for >draft-ietf-eman-requirements-08.txt > >Dear all, > >This update only brings a small change in terminology. >We found that the term "Powered Entity" is not appropriate, >because it is also used for devices providing power to others. > >The solution in this draft is to just use "entity" instead. > >Thanks, > Juergen > >On 16.07.12 15:27, "internet-drafts@ietf.org" >wrote: > >> >>A new version of I-D, draft-ietf-eman-requirements-08.txt >>has been successfully submitted by Juergen Quittek and posted to the >>IETF repository. >> >>Filename: draft-ietf-eman-requirements >>Revision: 08 >>Title: Requirements for Energy Management >>Creation date: 2012-07-16 >>WG ID: eman >>Number of pages: 32 >>URL: >>http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-08.txt >>Status: >>http://datatracker.ietf.org/doc/draft-ietf-eman-requirements >>Htmlized: >>http://tools.ietf.org/html/draft-ietf-eman-requirements-08 >>Diff: >>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-requirements-08 >> >>Abstract: >> This document defines requirements for standards specifications for >> energy management. The requirements defined in this document concern >> monitoring functions as well as control functions. In detail, the >> focus of the requirements is on the following features: >> identification of energy-managed devices and their components, >> monitoring of their Power State, power inlets, power outlets, actual >> power, power properties, received energy, provided energy, and >> contained batteries. Further requirements are included to enable >> control of their power supply and Power State. This document does >> not specify the features that must be implemented by compliant >> implementations but rather features that must be supported by >> standards for energy management. >> >> >> >> >> >>The IETF Secretariat > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman= From brads@coraid.com Wed Aug 1 11:26:02 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8487911E8102 for ; Wed, 1 Aug 2012 11:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MNfCna2hk2h for ; Wed, 1 Aug 2012 11:26:01 -0700 (PDT) Received: from server505.appriver.com (server505k.appriver.com [98.129.35.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6E84111E80E5 for ; Wed, 1 Aug 2012 11:26:00 -0700 (PDT) X-Note-AR-ScanTimeLocal: 8/1/2012 1:26:00 PM X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Primary: brads@coraid.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @coraid.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G279 G280 G281 G282 G286 G287 G298 G389 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 22149273; Wed, 01 Aug 2012 13:26:00 -0500 Received: from MBX22.exg5.exghost.com ([169.254.1.186]) by HT08-E5.exg5.exghost.com ([98.129.23.244]) with mapi; Wed, 1 Aug 2012 13:26:00 -0500 From: Brad Schoening To: "karagian@cs.utwente.nl" , "Quittek@neclab.eu" , "eman@ietf.org" Date: Wed, 1 Aug 2012 13:25:59 -0500 Thread-Topic: [eman] comments on draft-ietf-eman-requirements-08.txt Thread-Index: Ac1wExk4cEll3EFzSGiIzYUQ5kbRVQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] comments on draft-ietf-eman-requirements-08.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:26:02 -0000 Hi Georgios, Phasor Measurement Units seem to be something used in power substations. Is this a correct assumption? I don't believe our requirement currently do or should include grid operations. Regarding the specifications for monitoring, could you articulate which ones you believe are highly relevant to EMAN? Regards, Brad On 8/1/12 11:17 AM, "karagian@cs.utwente.nl" wrote: >Hi Brad, > >The IEEE C37.118 standard specifies the monitoring and the communication >of the=20 >synchrophasor measurements from Phasor Measurement Units (PMUs) towards >the phasor data concentrators (PDCs). > >By using the received synchrophasor measurement data and information (via >the PDCs) the grid operators will be able to have better visibility of >power grid operations and respond to grid disturbances earlier to prevent >major blackouts. > >From IEEE C37.118 we could use the specification related to monitoring. > > >Best regards, >Georgios > > > >________________________________________ >Van: Brad Schoening [brads@coraid.com] >Verzonden: woensdag 1 augustus 2012 3:24 >Aan: Karagiannis, G. (EWI); Quittek@neclab.eu; eman@ietf.org >Onderwerp: Re: [eman] comments on draft-ietf-eman-requirements-08.txt > >Hi Georgios, > >The standard you reference, IEEE 37.118, appears to involve a special >communications protocol with phasor measurement units (PMUs). Could you >provide a little more background on this standard and how it would be >applicable in a SNMP management environment? Most importantly, could not >synchrophasor data simply roll up and be reported as an aggregate in EMAN? > >In EMAN, we have tried to provide general use case that cover many >different underlying technologies for acquiring the data. By >encapsulating the specifics of the underlying protocols, we simplify the >reporting and control. > >Regarding bi-directional power, I believe we cover that by allowing meters >to report consumed, exported, and net energy. > >Best Regards, > >Brad Schoening > > > >On 7/31/12 5:34 PM, "karagian@cs.utwente.nl" >wrote: > >>Hi Juergen, Hi all, >> >>I have read the last version of the requirements draft and I have two >>main comments! >> >>Comment_1: Section 5.3, page 14, specifies that: >>"Power monitoring should be in line with existing standards, such as >>[IEC.61850-7-4]." >> >>What I miss is a reference to IEEE 37.118-2005 [IEEE37118], which is a >>monitoring standard based on synchrophasors, like Phasor Measurement >>Units (PMUs). >>Please note that an ongoing IEC standardization activity was defined that >>is focusing on the integration of this type of monitoring into IEC 61850, >>see reference [Mar11] below. >>Note also that a reference to IEEE37118 is not included in the >>Applicability statement draft. I will be happy to provide input on this >>standard. >> >>[IEEE37118] IEEE 37.118-2005, "IEEE Standard for Synchrophasors for Power >>System", IEEE standard, 2005. >> >>[Mart11] K. E. Martin, "Synchrophasor Standards Development - IEEE >>C37.118 & IEC 61850", Proc. of 44th Hawaii International Conference on >>System Sciences (ICSS'2011), pp. 1-8, 2011. >> >>Comment_2: The requirements draft is not mentioning bidirectional power >>interfaces, which I think is needed. For motivation of this argument, >>please see section 4.1.4 of the eman framework draft. >> >>Best regards, >>Georgios >> >> >>________________________________________ >>Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens Juergen Quittek >>[Quittek@neclab.eu] >>Verzonden: maandag 16 juli 2012 15:50 >>Aan: eman mailing list >>Onderwerp: [eman] FW: New Version Notification for >>draft-ietf-eman-requirements-08.txt >> >>Dear all, >> >>This update only brings a small change in terminology. >>We found that the term "Powered Entity" is not appropriate, >>because it is also used for devices providing power to others. >> >>The solution in this draft is to just use "entity" instead. >> >>Thanks, >> Juergen >> >>On 16.07.12 15:27, "internet-drafts@ietf.org" >>wrote: >> >>> >>>A new version of I-D, draft-ietf-eman-requirements-08.txt >>>has been successfully submitted by Juergen Quittek and posted to the >>>IETF repository. >>> >>>Filename: draft-ietf-eman-requirements >>>Revision: 08 >>>Title: Requirements for Energy Management >>>Creation date: 2012-07-16 >>>WG ID: eman >>>Number of pages: 32 >>>URL: >>>http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-08.txt >>>Status: >>>http://datatracker.ietf.org/doc/draft-ietf-eman-requirements >>>Htmlized: >>>http://tools.ietf.org/html/draft-ietf-eman-requirements-08 >>>Diff: >>>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-requirements-08 >>> >>>Abstract: >>> This document defines requirements for standards specifications for >>> energy management. The requirements defined in this document concern >>> monitoring functions as well as control functions. In detail, the >>> focus of the requirements is on the following features: >>> identification of energy-managed devices and their components, >>> monitoring of their Power State, power inlets, power outlets, actual >>> power, power properties, received energy, provided energy, and >>> contained batteries. Further requirements are included to enable >>> control of their power supply and Power State. This document does >>> not specify the features that must be implemented by compliant >>> implementations but rather features that must be supported by >>> standards for energy management. >>> >>> >>> >>> >>> >>>The IETF Secretariat >> >>_______________________________________________ >>eman mailing list >>eman@ietf.org >>https://www.ietf.org/mailman/listinfo/eman >>_______________________________________________ >>eman mailing list >>eman@ietf.org >>https://www.ietf.org/mailman/listinfo/eman From karagian@cs.utwente.nl Wed Aug 1 11:33:44 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81A811E83E3 for ; Wed, 1 Aug 2012 11:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.277 X-Spam-Level: X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-rdTq4PSj+V for ; Wed, 1 Aug 2012 11:33:44 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 80F8511E8303 for ; Wed, 1 Aug 2012 11:33:42 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 1 Aug 2012 20:33:47 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.41]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Wed, 1 Aug 2012 20:33:41 +0200 From: To: , , Thread-Topic: [eman] comments on draft-ietf-eman-requirements-08.txt Thread-Index: AQHNb3t8cLxl7ZurrkC784Qyz3NiY5dECFaAgAE7m1D//+HCgIAAIgQq Date: Wed, 1 Aug 2012 18:33:40 +0000 Message-ID: References: , In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.114.255.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] comments on draft-ietf-eman-requirements-08.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:33:44 -0000 Hi Brad, PMUs can be used in any parts of the power network as long as the utility p= rovider wants to have better visibility of the dynamical state of the power= network. Note that 61850 was primarily also designed to be used only in power substa= tions. The situation is currently changed. Regarding monitoring, it relates to power quality parameters and their moni= toring frequency! Best regards, Georgios ________________________________________ Van: Brad Schoening [brads@coraid.com] Verzonden: woensdag 1 augustus 2012 20:25 Aan: Karagiannis, G. (EWI); Quittek@neclab.eu; eman@ietf.org Onderwerp: Re: [eman] comments on draft-ietf-eman-requirements-08.txt Hi Georgios, Phasor Measurement Units seem to be something used in power substations. Is this a correct assumption? I don't believe our requirement currently do or should include grid operations. Regarding the specifications for monitoring, could you articulate which ones you believe are highly relevant to EMAN? Regards, Brad On 8/1/12 11:17 AM, "karagian@cs.utwente.nl" wrote: >Hi Brad, > >The IEEE C37.118 standard specifies the monitoring and the communication >of the >synchrophasor measurements from Phasor Measurement Units (PMUs) towards >the phasor data concentrators (PDCs). > >By using the received synchrophasor measurement data and information (via >the PDCs) the grid operators will be able to have better visibility of >power grid operations and respond to grid disturbances earlier to prevent >major blackouts. > >From IEEE C37.118 we could use the specification related to monitoring. > > >Best regards, >Georgios > > > >________________________________________ >Van: Brad Schoening [brads@coraid.com] >Verzonden: woensdag 1 augustus 2012 3:24 >Aan: Karagiannis, G. (EWI); Quittek@neclab.eu; eman@ietf.org >Onderwerp: Re: [eman] comments on draft-ietf-eman-requirements-08.txt > >Hi Georgios, > >The standard you reference, IEEE 37.118, appears to involve a special >communications protocol with phasor measurement units (PMUs). Could you >provide a little more background on this standard and how it would be >applicable in a SNMP management environment? Most importantly, could not >synchrophasor data simply roll up and be reported as an aggregate in EMAN? > >In EMAN, we have tried to provide general use case that cover many >different underlying technologies for acquiring the data. By >encapsulating the specifics of the underlying protocols, we simplify the >reporting and control. > >Regarding bi-directional power, I believe we cover that by allowing meters >to report consumed, exported, and net energy. > >Best Regards, > >Brad Schoening > > > >On 7/31/12 5:34 PM, "karagian@cs.utwente.nl" >wrote: > >>Hi Juergen, Hi all, >> >>I have read the last version of the requirements draft and I have two >>main comments! >> >>Comment_1: Section 5.3, page 14, specifies that: >>"Power monitoring should be in line with existing standards, such as >>[IEC.61850-7-4]." >> >>What I miss is a reference to IEEE 37.118-2005 [IEEE37118], which is a >>monitoring standard based on synchrophasors, like Phasor Measurement >>Units (PMUs). >>Please note that an ongoing IEC standardization activity was defined that >>is focusing on the integration of this type of monitoring into IEC 61850, >>see reference [Mar11] below. >>Note also that a reference to IEEE37118 is not included in the >>Applicability statement draft. I will be happy to provide input on this >>standard. >> >>[IEEE37118] IEEE 37.118-2005, "IEEE Standard for Synchrophasors for Power >>System", IEEE standard, 2005. >> >>[Mart11] K. E. Martin, "Synchrophasor Standards Development - IEEE >>C37.118 & IEC 61850", Proc. of 44th Hawaii International Conference on >>System Sciences (ICSS'2011), pp. 1-8, 2011. >> >>Comment_2: The requirements draft is not mentioning bidirectional power >>interfaces, which I think is needed. For motivation of this argument, >>please see section 4.1.4 of the eman framework draft. >> >>Best regards, >>Georgios >> >> >>________________________________________ >>Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens Juergen Quittek >>[Quittek@neclab.eu] >>Verzonden: maandag 16 juli 2012 15:50 >>Aan: eman mailing list >>Onderwerp: [eman] FW: New Version Notification for >>draft-ietf-eman-requirements-08.txt >> >>Dear all, >> >>This update only brings a small change in terminology. >>We found that the term "Powered Entity" is not appropriate, >>because it is also used for devices providing power to others. >> >>The solution in this draft is to just use "entity" instead. >> >>Thanks, >> Juergen >> >>On 16.07.12 15:27, "internet-drafts@ietf.org" >>wrote: >> >>> >>>A new version of I-D, draft-ietf-eman-requirements-08.txt >>>has been successfully submitted by Juergen Quittek and posted to the >>>IETF repository. >>> >>>Filename: draft-ietf-eman-requirements >>>Revision: 08 >>>Title: Requirements for Energy Management >>>Creation date: 2012-07-16 >>>WG ID: eman >>>Number of pages: 32 >>>URL: >>>http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-08.txt >>>Status: >>>http://datatracker.ietf.org/doc/draft-ietf-eman-requirements >>>Htmlized: >>>http://tools.ietf.org/html/draft-ietf-eman-requirements-08 >>>Diff: >>>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-requirements-08 >>> >>>Abstract: >>> This document defines requirements for standards specifications for >>> energy management. The requirements defined in this document concern >>> monitoring functions as well as control functions. In detail, the >>> focus of the requirements is on the following features: >>> identification of energy-managed devices and their components, >>> monitoring of their Power State, power inlets, power outlets, actual >>> power, power properties, received energy, provided energy, and >>> contained batteries. Further requirements are included to enable >>> control of their power supply and Power State. This document does >>> not specify the features that must be implemented by compliant >>> implementations but rather features that must be supported by >>> standards for energy management. >>> >>> >>> >>> >>> >>>The IETF Secretariat >> >>_______________________________________________ >>eman mailing list >>eman@ietf.org >>https://www.ietf.org/mailman/listinfo/eman >>_______________________________________________ >>eman mailing list >>eman@ietf.org >>https://www.ietf.org/mailman/listinfo/eman= From karagian@cs.utwente.nl Wed Aug 1 11:39:30 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C517A11E8180 for ; Wed, 1 Aug 2012 11:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjJAXD-aJxV5 for ; Wed, 1 Aug 2012 11:39:29 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 397F111E810B for ; Wed, 1 Aug 2012 11:39:29 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 1 Aug 2012 20:39:35 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.41]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Wed, 1 Aug 2012 20:39:28 +0200 From: To: , Thread-Topic: comments on draft-nordman-nanogrids-00.txt Thread-Index: AQHNcBT6eMsjGi9PWE+TtZE6gwPpuw== Date: Wed, 1 Aug 2012 18:39:27 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.114.255.126] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CBE6506EXMBX04adutwent_" MIME-Version: 1.0 Subject: [eman] comments on draft-nordman-nanogrids-00.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:39:30 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CBE6506EXMBX04adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bruce, I have read draft-nordman-nanogrids-00, which describes an interesting idea= . However, I was wondering why it is stressed in the draft, that electricity = sources are not part of the nanogrid. If also energy sources were part of the nanogrid, then the Nanogrid control= ler could probably manage the generation and consumption of power within th= e nanogrid more optimally! Best regards, Georgios ________________________________ Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens Bruce Nordman [bn= ordman@lbl.gov] Verzonden: woensdag 18 juli 2012 22:03 Aan: eman mailing list Onderwerp: [eman] Fwd: New Version Notification for draft-nordman-nanogrids= -00.txt I would like to call your attention to the -00 draft below. If there is time, I will present this in Vancouver, but I am not expecting there will be time. Thus, if the topic interests you, let me know. The draft outlines an alternative approach to distributing power than that of the centralized grid - it takes a network model as the basis. EMAN needs to accommodate both, and for the most part I believe our approach does this. Thanks, --Bruce ---------- Forwarded message ---------- From: > Date: Mon, Jul 9, 2012 at 4:04 PM Subject: New Version Notification for draft-nordman-nanogrids-00.txt To: bnordman@lbl.gov Cc: christen@csee.usf.edu A new version of I-D, draft-nordman-nanogrids-00.txt has been successfully submitted by Bruce Nordman and posted to the IETF repository. Filename: draft-nordman-nanogrids Revision: 00 Title: Nanogrids Creation date: 2012-07-09 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-nordman-nanogrid= s-00.txt Status: http://datatracker.ietf.org/doc/draft-nordman-nanogrids Htmlized: http://tools.ietf.org/html/draft-nordman-nanogrids-00 Abstract: A nanogrid is a very small electricity domain that is distinct from any other grid it is connected to in voltage, reliability, quality, or price. Nanogrids could form the basis of a future electricity system built on a bottom-up, decentralized, and distributed network model rather than the top-down centralized grid we have today in most parts of the world. This document introduces the idea of a nanogrid to the IETF community for two purposes -- to inform the work on energy management presently underway in the EMAN working group, and to describe how future communications within and between grids could be accomplished with protocols that are the product of the IETF. There appears to be no fundamental conflict between the nanogrid concept and the current drafts in the EMAN working group. The IETF Secretariat -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CBE6506EXMBX04adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Bruce,

 =

I have read draft-nordma= n-nanogrids-00, which describes an interesting idea.

 =

However, I was wondering= why it is stressed in the draft, that electricity sources are not part of = the nanogrid.

 =

If also energy sources w= ere part of the nanogrid, then the Nanogrid controller could probably manag= e the generation and consumption of power within the nanogrid more optimally!

 =

Best regards,=

Georgios

Van: eman-bounces@ietf.org [eman-bounces@i= etf.org] namens Bruce Nordman [bnordman@lbl.gov]
Verzonden: woensdag 18 juli 2012 22:03
Aan: eman mailing list
Onderwerp: [eman] Fwd: New Version Notification for draft-nordman-na= nogrids-00.txt

I would like to call your attention to the -00 draft below.
If there is time, I will present this in Vancouver, but I am not
expecting there will be time.  Thus, if the topic interests you,
let me know.

The draft outlines an alternative approach to distributing
power than that of the centralized grid - it takes a network
model as the basis.  EMAN needs to accommodate both,
and for the most part I believe our approach does this.

Thanks,

--Bruce

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Jul 9, 2012 at 4:04 PM
Subject: New Version Notification for draft-nordman-nanogrids-00.txt
To: bnordman@lbl.gov<= /a>
Cc: christen@cse= e.usf.edu



A new version of I-D, draft-nordman-nanogrids-00.txt
has been successfully submitted by Bruce Nordman and posted to the
IETF repository.

Filename:        draft-nordman-nanogrids
Revision:        00
Title:           Nanogrids
Creation date:   2012-07-09
WG ID:           Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-nordman-nanogrids-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-nordman-nanogrids
Htmlized:        http://tools.ietf.org/html/dr= aft-nordman-nanogrids-00


Abstract:
   A nanogrid is a very small electricity domain that is distinct= from
   any other grid it is connected to in voltage, reliability, qua= lity,
   or price.  Nanogrids could form the basis of a future ele= ctricity
   system built on a bottom-up, decentralized, and distributed ne= twork
   model rather than the top-down centralized grid we have today = in most
   parts of the world.  This document introduces the idea of= a nanogrid
   to the IETF community for two purposes -- to inform the work o= n
   energy management presently underway in the EMAN working group= , and
   to describe how future communications within and between grids= could
   be accomplished with protocols that are the product of the IET= F.
   There appears to be no fundamental conflict between the nanogr= id
   concept and the current drafts in the EMAN working group.




The IETF Secretariat



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

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CBE6506EXMBX04adutwent_-- From bnordman@lbl.gov Wed Aug 1 12:15:14 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E13921F874A for ; Wed, 1 Aug 2012 12:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.665 X-Spam-Level: X-Spam-Status: No, score=-5.665 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 576t3U52jyLY for ; Wed, 1 Aug 2012 12:15:12 -0700 (PDT) Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3D27E21F8704 for ; Wed, 1 Aug 2012 12:15:04 -0700 (PDT) X-Ironport-SBRS: 5.5 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUCAAh/GVDRVdy0m2dsb2JhbABCA4JKpV6IEwGITAgiAQEBAQEICQsJFCeCIAEBAQMBEgJaCwULCwsGAQIBAi8iEgEFAQ4GCBkJCw6HZQYLnhsJA58Ii0kbg02DIQOITYx6gRSNHD6EHg X-IronPort-AV: E=Sophos;i="4.77,695,1336374000"; d="scan'208";a="82223970" Received: from mail-vc0-f180.google.com ([209.85.220.180]) by ironport3.lbl.gov with ESMTP; 01 Aug 2012 12:15:03 -0700 Received: by mail-vc0-f180.google.com with SMTP id fw7so10130056vcb.39 for ; Wed, 01 Aug 2012 12:15:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=vQXyyT6lhxCRa/xBmbjCkThhATPngSKESrEnZQp370g=; b=ClwNohGm4FTybphkiCFj74lVUj2vWOPjdkeGpWncdlidmoE8lxuJImT42MUT42RLtn mlBJEky2Fp95p/KoD6bUDL1IjDNwWwJMxG43DCn7RsWfSXc7SUWuNJmnVjdG8fHK5VID SxsgZCGcG+/g198VP/2y9oAIHp0LhOVSebxCrBkZxzOZABE0pNFWY9Eyl0Mh3t1SYtgN vYgy2vDudp4y58TlrNfJqToe7druC2+vl1XWOu5PGKBBMena6oJvwuBoRoDhkxDjZgRi FdzjcJYe9c1+5bCiyRh0L5CoaUPiRYXGPamFk8MYUjPwFXaeiK4AJAxv/lLt1a2IGRg2 IO5w== MIME-Version: 1.0 Received: by 10.220.220.76 with SMTP id hx12mr18016365vcb.9.1343848502805; Wed, 01 Aug 2012 12:15:02 -0700 (PDT) Received: by 10.58.253.69 with HTTP; Wed, 1 Aug 2012 12:15:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 12:15:02 -0700 Message-ID: From: Bruce Nordman To: karagian@cs.utwente.nl Content-Type: multipart/alternative; boundary=14dae9cfcdf0a4467504c6391c75 X-Gm-Message-State: ALoCoQlzoT1UIWvZipTxcoW6SYQK1GDxMIL4S6fqkCtevhystzqZokiQ8cOqARRlO6m862ZguZM8 Cc: eman@ietf.org Subject: Re: [eman] comments on draft-nordman-nanogrids-00.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 19:15:14 -0000 --14dae9cfcdf0a4467504c6391c75 Content-Type: text/plain; charset=ISO-8859-1 The intent is for the nanogrid architecture to be as simple as possible. Microgrids today often manage local generation, so commonly a building would be a microgrid, have local generation, and several or many subsidiary nanogrids. Alternatively, local generation could interface directly to a nanogrid and exchange power without any other entities involved. Also, a nanogrid has a single physical layer of electricity (e.g. 5V, 12 V, 48 V, 115 VAC, etc.) and it is unlikely that an arbitrary local generation unit would share the nanogrid's physical layer. This is what the standard gateways are for. Thanks for your interest. --Bruce On Wed, Aug 1, 2012 at 11:39 AM, wrote: > Hi Bruce, ** **** > > ** ** > > I have read draft-nordman-nanogrids-00, which describes an interesting > idea.**** > > ** ** > > However, I was wondering why it is stressed in the draft, that electricity > sources are not part of the nanogrid. **** > > ** ** > > If also energy sources were part of the nanogrid, then the Nanogrid > controller could probably manage the generation and consumption of power > within the nanogrid more optimally!**** > > ** ** > > Best regards,**** > > Georgios**** > > > > ------------------------------ > *Van:* eman-bounces@ietf.org [eman-bounces@ietf.org] namens Bruce Nordman > [bnordman@lbl.gov] > *Verzonden:* woensdag 18 juli 2012 22:03 > *Aan:* eman mailing list > *Onderwerp:* [eman] Fwd: New Version Notification for > draft-nordman-nanogrids-00.txt > > I would like to call your attention to the -00 draft below. > If there is time, I will present this in Vancouver, but I am not > expecting there will be time. Thus, if the topic interests you, > let me know. > > The draft outlines an alternative approach to distributing > power than that of the centralized grid - it takes a network > model as the basis. EMAN needs to accommodate both, > and for the most part I believe our approach does this. > > Thanks, > > --Bruce > > ---------- Forwarded message ---------- > From: > Date: Mon, Jul 9, 2012 at 4:04 PM > Subject: New Version Notification for draft-nordman-nanogrids-00.txt > To: bnordman@lbl.gov > Cc: christen@csee.usf.edu > > > > A new version of I-D, draft-nordman-nanogrids-00.txt > has been successfully submitted by Bruce Nordman and posted to the > IETF repository. > > Filename: draft-nordman-nanogrids > Revision: 00 > Title: Nanogrids > Creation date: 2012-07-09 > WG ID: Individual Submission > Number of pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-nordman-nanogrids-00.txt > Status: http://datatracker.ietf.org/doc/draft-nordman-nanogrids > Htmlized: http://tools.ietf.org/html/draft-nordman-nanogrids-00 > > > Abstract: > A nanogrid is a very small electricity domain that is distinct from > any other grid it is connected to in voltage, reliability, quality, > or price. Nanogrids could form the basis of a future electricity > system built on a bottom-up, decentralized, and distributed network > model rather than the top-down centralized grid we have today in most > parts of the world. This document introduces the idea of a nanogrid > to the IETF community for two purposes -- to inform the work on > energy management presently underway in the EMAN working group, and > to describe how future communications within and between grids could > be accomplished with protocols that are the product of the IETF. > There appears to be no fundamental conflict between the nanogrid > concept and the current drafts in the EMAN working group. > > > > > The IETF Secretariat > > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > nordman.lbl.gov > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > -- *Bruce Nordman* Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --14dae9cfcdf0a4467504c6391c75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The intent is for the nanogrid architecture to be as simple as possible.Microgrids today often manage local generation, so commonly a building
= would be a microgrid, have local generation, and several or many
subsidi= ary nanogrids.=A0 Alternatively, local generation could interface
directly to a nanogrid and exchange power without any other entities
inv= olved.

Also, a nanogrid has a single physical layer of electricity (= e.g. 5V, 12 V,
48 V, 115 VAC, etc.) and it is unlikely that an arbitrary= local generation
unit would share the nanogrid's physical layer.=A0 This is what the sta= ndard
gateways are for.

Thanks for your interest.

--Bruce<= br>
On Wed, Aug 1, 2012 at 11:39 AM, <= karagian@cs.utwente.nl> wrote:

Hi Bruce,

=A0

I have read draft-nordman-nanogrids-00, which descr= ibes an interesting idea.

=A0

However, I was wondering why it is stressed in the = draft, that electricity sources are not part of the nanogrid.

=A0

If also energy sources were part of the nanogrid, t= hen the Nanogrid controller could probably manage the generation and consum= ption of power within the nanogrid more optimally!

=A0

Best regards,

Georgios

=A0
=A0
=A0
Van= : eman-bounc= es@ietf.org [eman-bounces@ietf.org] namens Bruce Nordman [bnordman@lbl.gov]
Verzonden: woensdag 18 juli 2012 22:03
Aan: eman mailing list
Onderwerp: [eman] Fwd: New Version Notification for draft-nordman-na= nogrids-00.txt

I would like to call your attention to the -00 draft below.
If there is time, I will present this in Vancouver, but I am not
expecting there will be time.=A0 Thus, if the topic interests you,
let me know.

The draft outlines an alternative approach to distributing
power than that of the centralized grid - it takes a network
model as the basis.=A0 EMAN needs to accommodate both,
and for the most part I believe our approach does this.

Thanks,

--Bruce

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Jul 9, 2012 at 4:04 PM
Subject: New Version Notification for draft-nordman-nanogrids-00.txt
To: bnordman@lbl.gov<= /a>
Cc: christen@cse= e.usf.edu



A new version of I-D, draft-nordman-nanogrids-00.txt
has been successfully submitted by Bruce Nordman and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-nordman-nanogrids
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Nanogrids
Creation date: =A0 2012-07-09
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 8
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-nordman-nanogrids-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft= -nordman-nanogrids
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-nordman-= nanogrids-00


Abstract:
=A0 =A0A nanogrid is a very small electricity domain that is distinct from<= br> =A0 =A0any other grid it is connected to in voltage, reliability, quality,<= br> =A0 =A0or price. =A0Nanogrids could form the basis of a future electricity<= br> =A0 =A0system built on a bottom-up, decentralized, and distributed network<= br> =A0 =A0model rather than the top-down centralized grid we have today in mos= t
=A0 =A0parts of the world. =A0This document introduces the idea of a nanogr= id
=A0 =A0to the IETF community for two purposes -- to inform the work on
=A0 =A0energy management presently underway in the EMAN working group, and<= br> =A0 =A0to describe how future communications within and between grids could=
=A0 =A0be accomplished with protocols that are the product of the IETF.
=A0 =A0There appears to be no fundamental conflict between the nanogrid
=A0 =A0concept and the current drafts in the EMAN working group.




The IETF Secretariat



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




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

--14dae9cfcdf0a4467504c6391c75-- From bnordman@lbl.gov Wed Aug 1 12:18:07 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBE311E80AD for ; Wed, 1 Aug 2012 12:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.704 X-Spam-Level: X-Spam-Status: No, score=-5.704 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLi2YfFFXSCU for ; Wed, 1 Aug 2012 12:18:06 -0700 (PDT) Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 51E2721F8838 for ; Wed, 1 Aug 2012 12:18:06 -0700 (PDT) X-Ironport-SBRS: 4.7 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcCABeAGVDRVdQ0k2dsb2JhbABCA4JKpVwBiBQBiEwIIgEBAQEJCQsJFAQjgjkCXi1dEgEFASITCBqHa5tEgmEJA58Hi0kFFoNNgyEDiE2MeoEUjRw+hB4 X-IronPort-AV: E=Sophos;i="4.77,695,1336374000"; d="scan'208";a="82224222" Received: from mail-vb0-f52.google.com ([209.85.212.52]) by ironport3.lbl.gov with ESMTP; 01 Aug 2012 12:18:05 -0700 Received: by mail-vb0-f52.google.com with SMTP id b23so10042752vbz.39 for ; Wed, 01 Aug 2012 12:18:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=CQzfdbqDinn0VD1prz7SX9aCNeUd/KURaj/ShZDQgzg=; b=Gk3cErHhD0JWZYZRPXuHHnpf/e4Rw4pkApAcGXD8V9wIjHo02vUJdFCvqpqffdri/V r7YXY9F5ZvApJvPGkKRTnrJg3cioNU82VztzboMxDQpawmXC+7W9XVdBPyFj0WiiZNcO 9n42zxIGm6rR6arrDoOoVU2t9sNM9ehdwTSobFEopJAe74a3e21KAvAYY7Nw98pup/0e IQz/WvBE2Hgwmjf+T8ibRl+1xq3vyb3l/PpoRdzdHhhvYdyXNvDXMCHisdiPQi6jyuOl yue23LWso1qgkoLK6TzZJf9sjbK+DSX+WcP9afb3xnzmNag07vUiSk9rHFe8GWKnIOpP Fhvw== MIME-Version: 1.0 Received: by 10.52.23.107 with SMTP id l11mr15703976vdf.6.1343848685448; Wed, 01 Aug 2012 12:18:05 -0700 (PDT) Received: by 10.58.253.69 with HTTP; Wed, 1 Aug 2012 12:18:05 -0700 (PDT) Date: Wed, 1 Aug 2012 12:18:05 -0700 Message-ID: From: Bruce Nordman To: eman mailing list Content-Type: multipart/alternative; boundary=20cf307811b6872bde04c63927f9 X-Gm-Message-State: ALoCoQm2lFmuOiB5Qxlza2+acS5/xHOt/Xe/JkP/attMKcCrrSYe9MqkRtkvIPqaZW57eiwuV6th Subject: [eman] Requirements 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, 01 Aug 2012 19:18:07 -0000 --20cf307811b6872bde04c63927f9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Comments on Requirements-08 Bruce Nordman July 31, 2012 Many thanks to the authors for advancing the draft. "Aggregate" or "aggregation" is used to reflect grouping of entities, as well as to summation across such a group. It can also refer to a quantity which is inherently a summed quantity, such as a measurement of power being delivered to a collection of devices. We need a term for each of these concepts and assure that they are used consistently in all drafts. I would propose "Collection" for the process of creating a group of measurements, and "summation" for adding up values across a collection. An entity as defined here is either a device or a component. Interfaces ar= e not mentioned. I think that some of the references should really apply onl= y to devices, others to devices or components, some to all three, and some to either a device or interface. We need to be specific as to whether an interface is included in "entity" (I think it should be) and it may be helpful to have a terms that cover other groupings. An example where this may be important is that reference is made to communication with entities. Can the management system communicate with a component, or only with an entire device? I think a definition of component would also be helpful - something like "an entity that is a subset of a device". In the Introduction, the concept of Power Interface has not yet been define= d so that referring to inlets and outlets seems quite appropriate. However, once we have the interface notion, then inlet and outlet should only be used when interface is not suitable, as they are not different concepts, bu= t only whether the power value is positive or negative. This applies in several places but particularly 5.2. Along these lines, 5.2.2 and 5.2.3 need to be combined, since as an interface can change inlet/outlet state dynamically, the connections are simply to other interfaces. Also, connections can be to multiple other interfaces and commonly are (the language implies only a 1:1 relationship). For 5.2.5, need only say that power is flowing -- there is no need to reference the direction. 3.1. I disagree that "full" and "reduced" are different power states - there is a continuum of levels within the fully on state - there are three basic types of power states in general. 5.1.3,5.1.4. I don't think these are well enough defined to be included an= d would drop both. The definition of Domain should be imported. It should be made clear if a device can be a member of multiple domains or only a single domain. 5.2.6. "=85 as well as for entire Powered Entity". Why include this phras= e? The entity may or may not have a single type, and this is duplicative of information available elsewhere. 5.3.3. With the accuracy data available, it seems unnecessary to include the measurement method. 5.4.6. Maximum and average both seem ill-defined and not necessary to include. (Also, I think "typical" would be a better term than "average" for this type of usage). 5.5.2. "Time Interval" seems to imply a specific implementation and seems to exclude the simple "meter reading" approach (like a vehicle odometer) so "Time Stamp" or similar term would be more generic. That is needed regardless. 5.6. Shouldn't the text refer to modeling the battery as an individual component rather than an entity? 7.5. If we require to indicate what data are available in reports on other devices, shouldn't we require the same mechanism for reporting on oneself? 7.6. This seems problematic - I would remove. How would a device know what other devices know? why should we assume such knowledge is correct? Wouldn't it be better to simply ask the other device what it knows? A.2. This section, on standards of other bodies, is already covered by the applicability statement, which does this more thoroughly. Thus, this section can be removed and the entire appendix be about Existing IETF standards. Minor points: --Does "Power State" need to be capitalized? I can see the sense for Entity and Interface. --3.3., last sentence. Add "functional" before "load" to distinguish this from electrical load. --6.2. "outlets" to "interfaces". --8. "controlling Power State or power supply of others" to "doing that control". --8.1.1. Move "other" after "Powered Entities". --References: Applicability statement has an incorrect author. --=20 *Bruce Nordman* Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --20cf307811b6872bde04c63927f9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Comments on Requirements-08
Bruce Nordman
July 31, 2012

Many t= hanks to the authors for advancing the draft.

=A0"Aggregate&quo= t; or "aggregation" is used to reflect grouping of entities, as w= ell
as to summation across such a group.=A0 It can also refer to a quantity whi= ch
is inherently a summed quantity, such as a measurement of power being=
delivered to a collection of devices.=A0 We need a term for each of the= se
concepts and assure that they are used consistently in all drafts.
I wou= ld propose "Collection" for the process of creating a group ofmeasurements, and "summation" for adding up values across a coll= ection.

An entity as defined here is either a device or a component.=A0 Interfa= ces are
not mentioned.=A0 I think that some of the references should rea= lly apply only
to devices, others to devices or components, some to all = three, and some to
either a device or interface.=A0 We need to be specific as to whether an in= terface
is included in "entity" (I think it should be) and it = may be helpful to have a
terms that cover other groupings.
=A0 An exa= mple where this may be important is that reference is made to
communication with entities.=A0 Can the management system communicate
wi= th a component, or only with an entire device?
=A0 I think a definition = of component would also be helpful - something like
"an entity that= is a subset of a device".

In the Introduction, the concept of Power Interface has not yet been de= fined
so that referring to inlets and outlets seems quite appropriate.= =A0 However,
once we have the interface notion, then inlet and outlet s= hould only be
used when interface is not suitable, as they are not different concepts, bu= t
only whether the power value is positive or negative.=A0 This applies = in several
places but particularly 5.2.=A0 Along these lines, 5.2.2 and = 5.2.3 need to be
combined, since as an interface can change inlet/outlet state dynamically,<= br>the connections are simply to other interfaces.=A0 Also, connections can= be
to multiple other interfaces and commonly are (the language implies = only
a 1:1 relationship).=A0 For 5.2.5, need only say that power is flowing -- t= here
is no need to reference the direction.

3.1. I disagree that= "full" and "reduced" are different power states - ther= e is
a continuum of levels within the fully on state - there are three basic typ= es
of power states in general.

5.1.3,5.1.4.=A0 I don't think = these are well enough defined to be included and
would drop both.
The definition of Domain should be imported.=A0 It should be made clear if<= br>a device can be a member of multiple domains or only a single domain.
5.2.6.=A0 "=85 as well as for entire Powered Entity".=A0 Wh= y include this phrase?
The entity may or may not have a single type, and this is duplicative of information available elsewhere.

5.3.3.=A0 With the accuracy data = available, it seems unnecessary to include
the measurement method.

5.4.6.=A0 Maximum and average both seem ill-defined and not necessaryto include.=A0 (Also, I think "typical" would be a better term = than "average"
for this type of usage).

5.5.2.=A0 "= ;Time Interval" seems to imply a specific implementation and seems
to exclude the simple "meter reading" approach (like a vehicle od= ometer)
so "Time Stamp" or similar term would be more generic.= =A0 That is needed
regardless.

5.6.=A0 Shouldn't the text ref= er to modeling the battery as an individual component
rather than an entity?

7.5.=A0 If we require to indicate what data a= re available in reports on other
devices, shouldn't we require the s= ame mechanism for reporting on oneself?

7.6.=A0 This seems problemat= ic - I would remove.=A0 How would a device know
what other devices know?=A0 why should we assume such knowledge is correct?=
Wouldn't it be better to simply ask the other device what it knows?=

A.2.=A0 This section, on standards of other bodies, is already cove= red by the
applicability statement, which does this more thoroughly.=A0 Thus, this
= section can be removed and the entire appendix be about Existing IETF stand= ards.


Minor points:
--Does "Power State" need to be= capitalized?=A0 I can see the sense for
=A0 Entity and Interface.
--3.3., last sentence.=A0 Add "functional= " before "load" to distinguish this
=A0 from electrical l= oad.
--6.2. "outlets" to "interfaces".
--8. "= ;controlling Power State or power supply of others" to "doing tha= t control".
--8.1.1.=A0 Move "other" after "Powered Entities".
-= -References: Applicability statement has an incorrect author.


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

--20cf307811b6872bde04c63927f9-- From bnordman@lbl.gov Wed Aug 1 12:26:03 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BB011E80E5 for ; Wed, 1 Aug 2012 12:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.734 X-Spam-Level: X-Spam-Status: No, score=-5.734 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTIDmGZaoivk for ; Wed, 1 Aug 2012 12:26:02 -0700 (PDT) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 224B811E810B for ; Wed, 1 Aug 2012 12:26:02 -0700 (PDT) X-Ironport-SBRS: 5.5 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUCAFGCGVDRVdy0m2dsb2JhbABCA4JKpV6IEwGITAgiAQEBAQEICQsJFCeCIAEBAQMBAQEBDwJUBgsFCwsLDS4iBQ0BBQEcGQkSB4dlBgueHAkDnwWLSQUWg02DIQOITYx6gRSNHD6EHg X-IronPort-AV: E=Sophos;i="4.77,695,1336374000"; d="scan'208";a="81707952" Received: from mail-vc0-f180.google.com ([209.85.220.180]) by ironport4.lbl.gov with ESMTP; 01 Aug 2012 12:25:54 -0700 Received: by mail-vc0-f180.google.com with SMTP id fw7so10151519vcb.39 for ; Wed, 01 Aug 2012 12:25:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=bWWMTDu9JBlnNLgVT68XNo6oCxzmTnYJYnDoEcr+j6Q=; b=Gr8bSxwb0ym4/hH/Tn7977iEO6ODd3oPgId0jIHpEZPRaluOE8U1CfvhHJHRDkVpJw WAh+duIRMZXwJ8eQGer/q25t4iEAVmoSvPQZc4o2jaLOPpAgSZaupfiDSUKbkZRXVUyG FEhO5tQBTrywsqTHMFq+0I3i61yTAOZORiogEoAWXCBCXd1+/Y/UyG1kqVAaYPtryGdX sOfitzFnqdWVEgEhMBaCocszcO+hxrW6MZctdVSvaXJbhKtkckYnFFmgrsW8In8aIYfy GNl5h/ZNntq42RBGUGA6OgwuyQIZlEWmtqVaKflf1S2I44UhTYCtniv/zs5ztZJSppBE hCIQ== MIME-Version: 1.0 Received: by 10.58.211.71 with SMTP id na7mr31965vec.39.1343849153910; Wed, 01 Aug 2012 12:25:53 -0700 (PDT) Received: by 10.58.253.69 with HTTP; Wed, 1 Aug 2012 12:25:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 12:25:53 -0700 Message-ID: From: Bruce Nordman To: karagian@cs.utwente.nl Content-Type: multipart/alternative; boundary=047d7bd6bd6c7357cf04c6394329 X-Gm-Message-State: ALoCoQkEVKmFw72ZAmcvtWE3RyHfkjP2pGTPhxjpVfuPRBgdRYk5xngO4HEggKQHxMap9qluIuma Cc: eman@ietf.org Subject: Re: [eman] comments on draft-ietf-eman-requirements-08.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 19:26:04 -0000 --047d7bd6bd6c7357cf04c6394329 Content-Type: text/plain; charset=ISO-8859-1 I confess that I am unfamiliar with exactly what PMUs do, but my guess is that to be useful, there would need to be communication with the grid for this, and as Brad noted, we don't address any communication with the grid in EMAN. If such measurements did ever get to buildings, then I would expect that to happen first at the utility meter, a topic which EMAN also does not address. Thanks, --Bruce On Wed, Aug 1, 2012 at 11:33 AM, wrote: > Hi Brad, > > PMUs can be used in any parts of the power network as long as the utility > provider wants to have better visibility of the dynamical state of the > power network. > Note that 61850 was primarily also designed to be used only in power > substations. The situation is currently changed. > > Regarding monitoring, it relates to power quality parameters and their > monitoring frequency! > > Best regards, > Georgios > > > > ________________________________________ > Van: Brad Schoening [brads@coraid.com] > Verzonden: woensdag 1 augustus 2012 20:25 > Aan: Karagiannis, G. (EWI); Quittek@neclab.eu; eman@ietf.org > Onderwerp: Re: [eman] comments on draft-ietf-eman-requirements-08.txt > > Hi Georgios, > > Phasor Measurement Units seem to be something used in power substations. > Is this a correct assumption? I don't believe our requirement currently > do or should include grid operations. > > Regarding the specifications for monitoring, could you articulate which > ones you believe are highly relevant to EMAN? > > Regards, > > Brad > > > > > On 8/1/12 11:17 AM, "karagian@cs.utwente.nl" > wrote: > > >Hi Brad, > > > >The IEEE C37.118 standard specifies the monitoring and the communication > >of the > >synchrophasor measurements from Phasor Measurement Units (PMUs) towards > >the phasor data concentrators (PDCs). > > > >By using the received synchrophasor measurement data and information (via > >the PDCs) the grid operators will be able to have better visibility of > >power grid operations and respond to grid disturbances earlier to prevent > >major blackouts. > > > >From IEEE C37.118 we could use the specification related to monitoring. > > > > > >Best regards, > >Georgios > > > > > > > >________________________________________ > >Van: Brad Schoening [brads@coraid.com] > >Verzonden: woensdag 1 augustus 2012 3:24 > >Aan: Karagiannis, G. (EWI); Quittek@neclab.eu; eman@ietf.org > >Onderwerp: Re: [eman] comments on draft-ietf-eman-requirements-08.txt > > > >Hi Georgios, > > > >The standard you reference, IEEE 37.118, appears to involve a special > >communications protocol with phasor measurement units (PMUs). Could you > >provide a little more background on this standard and how it would be > >applicable in a SNMP management environment? Most importantly, could not > >synchrophasor data simply roll up and be reported as an aggregate in EMAN? > > > >In EMAN, we have tried to provide general use case that cover many > >different underlying technologies for acquiring the data. By > >encapsulating the specifics of the underlying protocols, we simplify the > >reporting and control. > > > >Regarding bi-directional power, I believe we cover that by allowing meters > >to report consumed, exported, and net energy. > > > >Best Regards, > > > >Brad Schoening > > > > > > > >On 7/31/12 5:34 PM, "karagian@cs.utwente.nl" > >wrote: > > > >>Hi Juergen, Hi all, > >> > >>I have read the last version of the requirements draft and I have two > >>main comments! > >> > >>Comment_1: Section 5.3, page 14, specifies that: > >>"Power monitoring should be in line with existing standards, such as > >>[IEC.61850-7-4]." > >> > >>What I miss is a reference to IEEE 37.118-2005 [IEEE37118], which is a > >>monitoring standard based on synchrophasors, like Phasor Measurement > >>Units (PMUs). > >>Please note that an ongoing IEC standardization activity was defined that > >>is focusing on the integration of this type of monitoring into IEC 61850, > >>see reference [Mar11] below. > >>Note also that a reference to IEEE37118 is not included in the > >>Applicability statement draft. I will be happy to provide input on this > >>standard. > >> > >>[IEEE37118] IEEE 37.118-2005, "IEEE Standard for Synchrophasors for Power > >>System", IEEE standard, 2005. > >> > >>[Mart11] K. E. Martin, "Synchrophasor Standards Development - IEEE > >>C37.118 & IEC 61850", Proc. of 44th Hawaii International Conference on > >>System Sciences (ICSS'2011), pp. 1-8, 2011. > >> > >>Comment_2: The requirements draft is not mentioning bidirectional power > >>interfaces, which I think is needed. For motivation of this argument, > >>please see section 4.1.4 of the eman framework draft. > >> > >>Best regards, > >>Georgios > >> > >> > >>________________________________________ > >>Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens Juergen > Quittek > >>[Quittek@neclab.eu] > >>Verzonden: maandag 16 juli 2012 15:50 > >>Aan: eman mailing list > >>Onderwerp: [eman] FW: New Version Notification for > >>draft-ietf-eman-requirements-08.txt > >> > >>Dear all, > >> > >>This update only brings a small change in terminology. > >>We found that the term "Powered Entity" is not appropriate, > >>because it is also used for devices providing power to others. > >> > >>The solution in this draft is to just use "entity" instead. > >> > >>Thanks, > >> Juergen > >> > >>On 16.07.12 15:27, "internet-drafts@ietf.org" > >>wrote: > >> > >>> > >>>A new version of I-D, draft-ietf-eman-requirements-08.txt > >>>has been successfully submitted by Juergen Quittek and posted to the > >>>IETF repository. > >>> > >>>Filename: draft-ietf-eman-requirements > >>>Revision: 08 > >>>Title: Requirements for Energy Management > >>>Creation date: 2012-07-16 > >>>WG ID: eman > >>>Number of pages: 32 > >>>URL: > >>>http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-08.txt > >>>Status: > >>>http://datatracker.ietf.org/doc/draft-ietf-eman-requirements > >>>Htmlized: > >>>http://tools.ietf.org/html/draft-ietf-eman-requirements-08 > >>>Diff: > >>>http://tools.ietf.org/rfcdiff?url2=draft-ietf-eman-requirements-08 > >>> > >>>Abstract: > >>> This document defines requirements for standards specifications for > >>> energy management. The requirements defined in this document concern > >>> monitoring functions as well as control functions. In detail, the > >>> focus of the requirements is on the following features: > >>> identification of energy-managed devices and their components, > >>> monitoring of their Power State, power inlets, power outlets, actual > >>> power, power properties, received energy, provided energy, and > >>> contained batteries. Further requirements are included to enable > >>> control of their power supply and Power State. This document does > >>> not specify the features that must be implemented by compliant > >>> implementations but rather features that must be supported by > >>> standards for energy management. > >>> > >>> > >>> > >>> > >>> > >>>The IETF Secretariat > >> > >>_______________________________________________ > >>eman mailing list > >>eman@ietf.org > >>https://www.ietf.org/mailman/listinfo/eman > >>_______________________________________________ > >>eman mailing list > >>eman@ietf.org > >>https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > -- *Bruce Nordman* Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --047d7bd6bd6c7357cf04c6394329 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I confess that I am unfamiliar with exactly what PMUs do, but my guess is t= hat
to be useful, there would need to be communication with the grid for=
this, and as Brad noted, we don't address any communication with the grid in EMAN.=A0 If such measurements did ever get to buildings,
the= n I would expect that to happen first at the utility meter, a topic whichEMAN also does not address.
Thanks,
--Bruce

On Wed, Aug 1, 2012 at 11:33 AM, <karagian@cs.utwente.nl> wrote:
Hi Brad,

PMUs can be used in any parts of the power network as long as the utility p= rovider wants to have better visibility of the dynamical state of the power= network.
Note that 61850 was primarily also designed to be used only in power substa= tions. The situation is currently changed.

Regarding monitoring, it relates to power quality parameters and their moni= toring frequency!

Best regards,
Georgios



________________________________________
Van: Brad Schoening [brads@coraid.com]
Verzonden: woensdag 1 augustus 2012 20:25
Aan: Karagiannis, G. (EWI); Quittek@neclab.eu; eman@ietf.org
Onderwerp: Re: [eman] comments on draft-ietf-eman-requirements-08.txt

Hi Georgios,

Phasor Measurement Units seem to be something used in power substations. Is this a correct assumption? =A0I don't believe our requirement curren= tly
do or should include grid operations.

Regarding the specifications for monitoring, could you articulate which
ones you believe are highly relevant to EMAN?

Regards,

Brad




On 8/1/12 11:17 AM, "karagia= n@cs.utwente.nl" <kar= agian@cs.utwente.nl>
wrote:

>Hi Brad,
>
>The IEEE C37.118 standard specifies the monitoring and the communicatio= n
>of the
>synchrophasor measurements from Phasor Measurement Units (PMUs) towards=
>the phasor data concentrators (PDCs).
>
>By using the received synchrophasor measurement data and information (v= ia
>the PDCs) the grid operators will be able to have better visibility of<= br> >power grid operations and respond to grid disturbances earlier to preve= nt
>major blackouts.
>
>From IEEE C37.118 we could use the specification related to monitoring.=
>
>
>Best regards,
>Georgios
>
>
>
>________________________________________
>Van: Brad Schoening [brads@coraid.c= om]
>Verzonden: woensdag 1 augustus 2012 3:24
>Aan: Karagiannis, G. (EWI); Quitte= k@neclab.eu; eman@ietf.org
>Onderwerp: Re: [eman] comments on draft-ietf-eman-requirements-08.txt >
>Hi Georgios,
>
>The standard you reference, IEEE 37.118, appears to involve a special >communications protocol with phasor measurement units (PMUs). =A0Could = you
>provide a little more background on this standard and how it would be >applicable in a SNMP management environment? =A0Most importantly, could= not
>synchrophasor data simply roll up and be reported as an aggregate in EM= AN?
>
>In EMAN, we have tried to provide general use case that cover many
>different underlying technologies for acquiring the data. =A0By
>encapsulating the specifics of the underlying protocols, we simplify th= e
>reporting and control.
>
>Regarding bi-directional power, I believe we cover that by allowing met= ers
>to report consumed, exported, and net energy.
>
>Best Regards,
>
>Brad Schoening
>
>
>
>On 7/31/12 5:34 PM, "kar= agian@cs.utwente.nl" <karagian@cs.utwente.nl>
>wrote:
>
>>Hi Juergen, Hi all,
>>
>>I have read the last version of the requirements draft and I have t= wo
>>main comments!
>>
>>Comment_1: Section 5.3, page 14, specifies that:
>>"Power monitoring should be in line with existing standards, s= uch as
>>[IEC.61850-7-4]."
>>
>>What I miss is a reference to IEEE 37.118-2005 [IEEE37118], which i= s a
>>monitoring standard based on synchrophasors, like Phasor Measuremen= t
>>Units (PMUs).
>>Please note that an ongoing IEC standardization activity was define= d that
>>is focusing on the integration of this type of monitoring into IEC = 61850,
>>see reference [Mar11] below.
>>Note also that a reference to IEEE37118 is not included in the
>>Applicability statement draft. I will be happy to provide input on = this
>>standard.
>>
>>[IEEE37118] IEEE 37.118-2005, "IEEE Standard for Synchrophasor= s for Power
>>System", IEEE standard, 2005.
>>
>>[Mart11] K. E. Martin, "Synchrophasor Standards Development - = IEEE
>>C37.118 & IEC 61850", Proc. of 44th Hawaii International C= onference on
>>System Sciences (ICSS'2011), pp. 1-8, 2011.
>>
>>Comment_2: The requirements draft is not mentioning bidirectional p= ower
>>interfaces, which I think is needed. For motivation of this argumen= t,
>>please see section 4.1.4 of the eman framework draft.
>>
>>Best regards,
>>Georgios
>>
>>
>>________________________________________
>>Van: eman-bounces@ietf.org= [eman-bounces@ietf.org] n= amens Juergen Quittek
>>[Quittek@neclab.eu]
>>Verzonden: maandag 16 juli 2012 15:50
>>Aan: eman mailing list
>>Onderwerp: [eman] FW: New Version Notification for
>>draft-ietf-eman-requirements-08.txt
>>
>>Dear all,
>>
>>This update only brings a small change in terminology.
>>We found that the term "Powered Entity" is not appropriat= e,
>>because it is also used for devices providing power to others.
>>
>>The solution in this draft is to just use "entity" instea= d.
>>
>>Thanks,
>> =A0 =A0Juergen
>>
>>On 16.07.12 15:27, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
>>wrote:
>>
>>>
>>>A new version of I-D, draft-ietf-eman-requirements-08.txt
>>>has been successfully submitted by Juergen Quittek and posted t= o the
>>>IETF repository.
>>>
>>>Filename: =A0 =A0 =A0 draft-ietf-eman-requirements
>>>Revision: =A0 =A0 =A0 08
>>>Title: =A0 =A0 =A0 =A0 =A0Requirements for Energy Management >>>Creation date: =A02012-07-16
>>>WG ID: =A0 =A0 =A0 =A0 =A0eman
>>>Number of pages: 32
>>>URL:
>>>http://www.ietf.org/internet-drafts/= draft-ietf-eman-requirements-08.txt
>>>Status:
>>>http://datatracker.ietf.org/doc/draft-ietf-eman= -requirements
>>>Htmlized:
>>>http://tools.ietf.org/html/draft-ietf-eman-requir= ements-08
>>>Diff:
>>>http://tools.ietf.org/rfcdiff?url2=3Ddr= aft-ietf-eman-requirements-08
>>>
>>>Abstract:
>>> =A0 This document defines requirements for standards specifica= tions for
>>> =A0 energy management. =A0The requirements defined in this doc= ument concern
>>> =A0 monitoring functions as well as control functions. =A0In d= etail, the
>>> =A0 focus of the requirements is on the following features: >>> =A0 identification of energy-managed devices and their compone= nts,
>>> =A0 monitoring of their Power State, power inlets, power outle= ts, actual
>>> =A0 power, power properties, received energy, provided energy,= and
>>> =A0 contained batteries. =A0Further requirements are included = to enable
>>> =A0 control of their power supply and Power State. =A0This doc= ument does
>>> =A0 not specify the features that must be implemented by compl= iant
>>> =A0 implementations but rather features that must be supported= by
>>> =A0 standards for energy management.
>>>
>>>
>>>
>>>
>>>
>>>The IETF Secretariat
>>
>>_______________________________________________
>>eman mailing list
>>eman@ietf.org
>>https://www.ietf.org/mailman/listinfo/eman
>>_______________________________________________
>>eman mailing list
>>eman@ietf.org
>>https://www.ietf.org/mailman/listinfo/eman
_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman



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

--047d7bd6bd6c7357cf04c6394329-- From brads@coraid.com Wed Aug 1 12:30:30 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8196021F88CF for ; Wed, 1 Aug 2012 12:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GyGaWyn9Xs4 for ; Wed, 1 Aug 2012 12:30:29 -0700 (PDT) Received: from server505.appriver.com (server505f.appriver.com [98.129.35.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD5221F88A5 for ; Wed, 1 Aug 2012 12:30:29 -0700 (PDT) X-Note-AR-ScanTimeLocal: 8/1/2012 2:30:29 PM X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Primary: brads@coraid.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @coraid.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: smtp.exg5.exghost.com X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G279 G280 G281 G282 G286 G287 G298 G389 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 307041638; Wed, 01 Aug 2012 14:30:28 -0500 Received: from MBX22.exg5.exghost.com ([169.254.1.186]) by HT07.exg5.exghost.com ([98.129.23.207]) with mapi; Wed, 1 Aug 2012 14:30:26 -0500 From: Brad Schoening To: Bruce Nordman , eman mailing list Date: Wed, 1 Aug 2012 14:30:26 -0500 Thread-Topic: [eman] Requirements comments Thread-Index: Ac1wHBoz6k4567BtR4OKE1T9gv3AaA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC3ECF8955740bradscoraidcom_" MIME-Version: 1.0 Subject: Re: [eman] Requirements 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, 01 Aug 2012 19:30:30 -0000 --_000_CC3ECF8955740bradscoraidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3.1. I disagree that "full" and "reduced" are different power states - ther= e is a continuum of levels within the fully on state - there are three basic typ= es of power states in general. Bruce, as we have discussed at great length, there are many operational sta= tes that are supported by real, deployed systems. EMAN will be less usefu= l if it willfully ignores these. This was the motivation behind the propos= al to add IANA power states. I thought we had reached consensus on this, d= id we not? Windows Mobile (CE) has "Full on" and "Low on" http://msdn.microsoft.com/en-us/library/aa932261.aspx Windows 7 has by default three: "Balanced", "Power saver", "High performanc= e" http://windows.microsoft.com/en-us/windows-vista/Power-plans-frequently-ask= ed-questions Regards, Brad --_000_CC3ECF8955740bradscoraidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3.1. I = disagree that "full" and "reduced" are different power states - there is
a continuum of levels within the fully on state - there are three basic typ= es
of power states in general.

Bruce, as= we have discussed at great length, there are many operational states that = are supported by real, deployed systems.   EMAN will be less useful if= it willfully ignores these.  This was the motivation behind the propo= sal to add IANA power states.  I thought we had reached consensus on t= his, did we not?

Windows Mobile (CE) has "Full on" and "Lo= w on"

Regard= s,

Brad
--_000_CC3ECF8955740bradscoraidcom_-- From bnordman@lbl.gov Wed Aug 1 12:37:43 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AA611E8135 for ; Wed, 1 Aug 2012 12:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.758 X-Spam-Level: X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFJwowik+7Sb for ; Wed, 1 Aug 2012 12:37:43 -0700 (PDT) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 169BA11E80A3 for ; Wed, 1 Aug 2012 12:37:43 -0700 (PDT) X-Ironport-SBRS: 5.5 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukBAIWEGVDRVdy0m2dsb2JhbABCA4JKrXEBiEwIIgEBAQEBCAkLCRQngiABAQEDARICURQQCwQHOyISAQUBDgENBhMih2UGC54kCQOfBYtJG4NNgyEDiE2MeoEUjRw+hB4 X-IronPort-AV: E=Sophos;i="4.77,695,1336374000"; d="scan'208";a="81708960" Received: from mail-vc0-f180.google.com ([209.85.220.180]) by ironport4.lbl.gov with ESMTP; 01 Aug 2012 12:37:36 -0700 Received: by mail-vc0-f180.google.com with SMTP id fw7so10164112vcb.39 for ; Wed, 01 Aug 2012 12:37:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+UO3u4o3jsnHbmbnRHF/G2qtP2xptavLK2ZUcBbhOu0=; b=I3l/9PIlZH78pXawAsgoMCE6DFiGXtff7xNOjwkz/C9n5fdB8lF7K3mjWWw1PLdCWV sK4s70plEPe6NAGMNW1SHcwYUBLyy/FATXMskJRBC0iag7pbK+IkXtdUk+RKO55L1a+N gTcowBaUkqF+ko/ZL4DnfA0c0pezukwHAuIrnD4agMAEFcj6d6i4LkYimPi/VUrQ+cDF 1YzYR0712J0RMXjXNrxi5YXzjFTPODXMjDhYmPTjrTgEnD/WsTg6i40uVUDVLIKCFHF9 2KrzlJL8+ZyxWyM3ZB9MyR0JhDRnZprfmgfbjdpaShzpF5/jSmoxiXeduz2CW7fHmRDj GFvQ== MIME-Version: 1.0 Received: by 10.220.219.7 with SMTP id hs7mr18052178vcb.0.1343849856422; Wed, 01 Aug 2012 12:37:36 -0700 (PDT) Received: by 10.58.253.69 with HTTP; Wed, 1 Aug 2012 12:37:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 12:37:36 -0700 Message-ID: From: Bruce Nordman To: Brad Schoening Content-Type: multipart/alternative; boundary=14dae9cfccd252d4d404c6396dfe X-Gm-Message-State: ALoCoQlsoGAVNpy9ZE8rLge+uQEcXSo2hCUathnRElUiE3Q3XLMeLQnqNRtDDBi+DjNYMIRiLPkW Cc: eman mailing list Subject: Re: [eman] Requirements 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, 01 Aug 2012 19:37:44 -0000 --14dae9cfccd252d4d404c6396dfe Content-Type: text/plain; charset=ISO-8859-1 The section in question in the requirements draft refers to "basic types of power states". I fully agree that many devices have a wide range of sub-states so that a full list of states for a particular device might be one or might be dozens long. However, this is about "basic types" which groups these into a much smaller number. The Windows 7 items below are not power states, but policies implemented by a device to manage how to move among power states and otherwise manage resources. --Bruce On Wed, Aug 1, 2012 at 12:30 PM, Brad Schoening wrote: > > 3.1. I disagree that "full" and "reduced" are different power states - > there is > > a continuum of levels within the fully on state - there are three basic > types > of power states in general. > > Bruce, as we have discussed at great length, there are many operational > states that are supported by real, deployed systems. EMAN will be less > useful if it willfully ignores these. This was the motivation behind the > proposal to add IANA power states. I thought we had reached consensus on > this, did we not? > > > Windows Mobile (CE) has "Full on" and "Low on" > http://msdn.microsoft.com/en-us/library/aa932261.aspx > > Windows 7 has by default three: "Balanced", "Power saver", "High > performance" > > > http://windows.microsoft.com/en-us/windows-vista/Power-plans-frequently-asked-questions > > > Regards, > > Brad > -- *Bruce Nordman* Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --14dae9cfccd252d4d404c6396dfe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The section in question in the requirements draft refers to "basic typ= es of power states".
I fully agree that many devices have a wide ra= nge of sub-states so that a full list of
states for a particular device = might be one or might be dozens long.
However, this is about "basic types" which groups these into a mu= ch smaller number.

The Windows 7 items below are not power states, b= ut policies implemented by
a device to manage how to move among power st= ates and otherwise manage
resources.

--Bruce

On Wed, Aug 1, = 2012 at 12:30 PM, Brad Schoening <brads@coraid.com> wrote:

3.1. I disagree that "full= " and "reduced" are different power states - there is
a continuum of levels within the fully on state - there are three basic typ= es
of power states in general.

Bru= ce, as we have discussed at great length, there are many operational states= that are supported by real, deployed systems. =A0 EMAN will be less useful= if it willfully ignores these. =A0This was the motivation behind the propo= sal to add IANA power states. =A0I thought we had reached consensus on this= , did we not?


Regards,

Brad



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

--14dae9cfccd252d4d404c6396dfe-- From bnordman@lbl.gov Wed Aug 1 14:14:50 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1988211E831A for ; Wed, 1 Aug 2012 14:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.778 X-Spam-Level: X-Spam-Status: No, score=-5.778 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7XNp6C5LTDt for ; Wed, 1 Aug 2012 14:14:47 -0700 (PDT) Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 268F611E830B for ; Wed, 1 Aug 2012 14:14:47 -0700 (PDT) X-Ironport-SBRS: 4.7 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsBALmbGVDRVdQ0k2dsb2JhbABCA4JKrXEBiE0IIgEBAQEJCQsJFAQjgiABAQECAQEBAQEPAloEBwULCwsNLiIFDQEFARwGEyKHZQYLni8JA558i0kbg02DIQOITYx6gRSNHD6EHg X-IronPort-AV: E=Sophos;i="4.77,696,1336374000"; d="scan'208";a="82241845" Received: from mail-vb0-f52.google.com ([209.85.212.52]) by ironport3.lbl.gov with ESMTP; 01 Aug 2012 14:14:22 -0700 Received: by mail-vb0-f52.google.com with SMTP id b23so10188333vbz.39 for ; Wed, 01 Aug 2012 14:14:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=0Fn6tCx6LVR+5x/HlhA05C5/OMHvRTTumaAtqlR/2co=; b=NF6qvAjE1kzWjE2KXXOpyuh22S+ZtYqXU2Mi3BR1RihXHVymEn9vE/yPZbaGnM68Z3 UvWVmV58eUaF/37O4AVFqoW9lrb1Kfvw6yd30dMJtHZvXDLM2g/nWJGL6OP72LuRuRHl ZHQPx6WKnWzAxT8Mdnd/4bIiKmOa8L2tOiQ3wabRBMVozpL71xCmMbGWFP6vvnDQVnny M84CgW5Ra82wRW1zFzu6SGMvHBrDISu5DpTB5pxipFO8CC9P/wuhtgHgZqQRo9qERsDj 71+Zh5yUsK0IqcLLKs2Q4w794OEe/OeTUSLH16wdPbA1ZsX59sOtcOthcvX5dNFcI3rC K3Mg== MIME-Version: 1.0 Received: by 10.220.242.73 with SMTP id lh9mr18274538vcb.4.1343855661919; Wed, 01 Aug 2012 14:14:21 -0700 (PDT) Received: by 10.58.253.69 with HTTP; Wed, 1 Aug 2012 14:14:21 -0700 (PDT) In-Reply-To: References: <9C213D38848B89428F46808B16F6F086020E40@xmb-rcd-x04.cisco.com> Date: Wed, 1 Aug 2012 14:14:21 -0700 Message-ID: From: Bruce Nordman To: Juergen Quittek Content-Type: multipart/alternative; boundary=14dae9cdcaad5badb804c63ac746 X-Gm-Message-State: ALoCoQk4B7YWptQpt5hv8AjjE2gfwpOBONoLweHUZpMnu+GKtM6+8CIaX/Xp482Ydekvt4Egei0U Cc: eman mailing list Subject: Re: [eman] Question to requirements Authors on Framework Example X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 01 Aug 2012 21:14:50 -0000 --14dae9cdcaad5badb804c63ac746 Content-Type: text/plain; charset=ISO-8859-1 (apologies for returning to this thread right before the meeting). This thread raises a question - can one mix the two approaches (device to device vs interface to interface). That is, can one link from a device to an interface or vice versa. Offhand I think this is OK, and would be very practical for all the devices that have only a single power interface. These could have an implicit power interface with the same ID as the entire device. I don't know what this might mean for the MIB construction though. This also raises the issue of how a management system merges data from many devices, some of which report on device relationships, and others on power interface connections. Does such mixed systems create any problems? Not sure. Also, presumably a device could be implemented to report via both mechanisms, and management systems could choose to gather data for both, one, or the other. --Bruce On Wed, Jul 4, 2012 at 3:45 PM, Juergen Quittek wrote: > Hi John, > > For me both examples are absolutely in line with the requirements draft. > > Both show a view on the same physical reality. The model with interfaces > shows more details. But how much detail is needed depends on the needs of > the energy management task you are conducting. > > Thanks, > Juergen > > > On 04.07.12 20:14, "John Parello (jparello)" wrote: > > >HI, > > > >Thanks again to the authors of the requirements. I'm now trying to ensure > >the framework can fulfill and comply to the requirements. Your opinion > >would be greatly appreciated to expedite this. > > > >Please take a look at Example 1 in the presentation from last IETF-83 > >(it's slide 7) > > > >http://tools.ietf.org/agenda/83/slides/slides-83-eman-4.pdf > > > >Please refer to that slide for the questions below: > > > >Would the implementation suggested by the framework and shown in the > >example fulfill the requirements you've defined? > > In the "Interfaces" example: > > Energy Objects Y and W would be Power Entities and Energy > >Object 8 and 1 would be Power Interfaces > > In the "No interfaces" example > > Energy Objects Y and W would be Power Entities and still show > >a connection without the interface objects. > > > >Would both examples in slide 7 and described above hold as valid > >according to the requirements draft you are proposing? > > > >Jp > >_______________________________________________ > >eman mailing list > >eman@ietf.org > >https://www.ietf.org/mailman/listinfo/eman > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > -- *Bruce Nordman* Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --14dae9cdcaad5badb804c63ac746 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (apologies for returning to this thread right before the meeting).

T= his thread raises a question - can one mix the two approaches
(device to= device vs interface to interface).=A0 That is, can one link
from a devi= ce to an interface or vice versa.=A0 Offhand I think this
is OK, and would be very practical for all the devices that have
only a = single power interface.=A0 These could have an implicit
power interface = with the same ID as the entire device.=A0 I don't
know what this mig= ht mean for the MIB construction though.

This also raises the issue of how a management system
merges data fr= om many devices, some of which report on
device relationships, and other= s on power interface connections.
Does such mixed systems create any pro= blems?=A0 Not sure.
Also, presumably a device could be implemented to report
via both mechan= isms, and management systems could choose
to gather data for both, one, = or the other.

--Bruce

On Wed, Jul = 4, 2012 at 3:45 PM, Juergen Quittek <Quittek@neclab.eu> wrot= e:
Hi John,

For me both examples are absolutely in line with the requirements draft.
Both show a view on the same physical reality. =A0The model with interfaces=
shows more details. =A0But how much detail is needed depends on the needs o= f
the energy management task you are conducting.

Thanks,
=A0 =A0 Juergen


On 04.07.12 20:14, "John Parello (jparello)" <jparello@cisco.com> wrote:

>HI,
>
>Thanks again to the authors of the requirements. I'm now trying to = ensure
>the framework can fulfill and comply to the requirements. Your opinion<= br> >would be greatly appreciated to expedite this.
>
>Please take a look at Example 1 in the presentation from last IETF-83 >(it's slide 7)
>
>http://tools.ietf.org/agenda/83/slides/slides-83-eman-4.= pdf
>
>Please refer to that slide for the questions below:
>
>Would the implementation suggested by the framework and shown in the >example fulfill the requirements you've defined?
> =A0 =A0In the "Interfaces" example:
> =A0 =A0 =A0 =A0 =A0 Energy Objects Y and W would be =A0Power Entities = and Energy
>Object 8 and 1 would be Power Interfaces
> =A0 =A0In the "No interfaces" example
> =A0 =A0 =A0 =A0 =A0 Energy Objects Y and W would be Power Entities and= still show
>a connection without the interface objects.
>
>Would both examples in slide 7 and described above =A0hold as valid
>according to the requirements draft you are proposing?
>
>Jp
>_______________________________________________
>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
La= wrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--14dae9cdcaad5badb804c63ac746-- From moulchan@cisco.com Wed Aug 1 14:16:36 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8D911E8295 for ; Wed, 1 Aug 2012 14:16:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOGCmQev3EDQ for ; Wed, 1 Aug 2012 14:16:34 -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 B801711E831E for ; Wed, 1 Aug 2012 14:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=8156; q=dns/txt; s=iport; t=1343855794; x=1345065394; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wBRIToHhKVPZwCtImuKz0Hho/+Q2BCREN2Ksw/Px7Rg=; b=eHis9ZQcgRxfYHFr1ZvzNDbTWbAC8Z5QyKJAlP337gUOR21julTpE6a9 fxlcXa/mD1vdzXE7IBt8sl4YLWLsag8MIsFgk1eGFYPbj4m/b2O3tcbw8 c0KPMrat24+tkfoBGi121YzNz6HPe+eaD6IizEsdSi3wNl6y9/M9gxh2t 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFqbGVCtJXG9/2dsb2JhbABFuRGBB4IgAQEBBAEBAQ8BJy4GBBMEAgEIEQQBAQsUCQcnCxQJCAIEARIIGodrC5x2oEGLSRuGDmADlluNE4Fmgl+BXw X-IronPort-AV: E=Sophos;i="4.77,696,1336348800"; d="scan'208";a="107645654" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 01 Aug 2012 21:16:34 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q71LGYdl017277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 21:16:34 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.122]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 16:16:33 -0500 From: "Mouli Chandramouli (moulchan)" To: "karagian@cs.utwente.nl" , "eman@ietf.org" Thread-Topic: comments on draft-ietf-eman-applicability-statement-01.txt Thread-Index: AQHNb35I9BjHlVF8ykukn1vjCIzjiZdFdHbw Date: Wed, 1 Aug 2012 21:16:32 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA40E65A6B0@xmb-rcd-x08.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.001 x-tm-as-result: No--45.893300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] comments on draft-ietf-eman-applicability-statement-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:16:36 -0000 Hello Georgios, We have included some text you had proposed and added to the Home Energy Ga= teway Section 2.7. While the intent is to provide an exhaustive list of use= cases; we felt it is also important to have unique use cases that drive th= e requirements. Aggregation is covered in some other use cases also.=20 Thanks Mouli -----Original Message----- From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl]=20 Sent: Wednesday, August 01, 2012 6:15 AM To: Mouli Chandramouli (moulchan); eman@ietf.org Subject: comments on draft-ietf-eman-applicability-statement-01.txt Hi Mouli, Hi all, I have two comments on draft-ietf-eman-applicability-statement-01.txt. Comment_1: On the 24th of June, see bottom of this email, I have had provid= ed input for a new subsection that describes the Neighborhood Energy Gatewa= ys use case. Hopefully it is not too late to include this section in the dr= aft. Comment_2: The description of the IEEE 37.118-2005 [IEEE37118] is missing. = This is a monitoring standard based on synchrophasors, like Phasor Measurem= ent Units (PMUs). Please note that an ongoing IEC standardization activity was defined that i= s focusing on the integration of this type of monitoring into IEC 61850, se= e reference [Mar11] below. [IEEE37118] IEEE 37.118-2005, "IEEE Standard for Synchrophasors for Power S= ystem", IEEE standard, 2005. [Mart11] K. E. Martin, "Synchrophasor Standards Development - IEEE C37.118 = & IEC 61850", Proc. of 44th Hawaii International Conference on System Scien= ces (ICSS'2011), pp. 1-8, 2011. Best regards, Georgios _______________________________________ Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens karagian@cs.utwen= te.nl [karagian@cs.utwente.nl] Verzonden: zondag 24 juni 2012 21:39 Aan: moulchan@cisco.com; eman@ietf.org Onderwerp: Re: [eman] draft-ietf-eman-applicability-statement-01.txt Hi Mouli, Hi all, During the IETF eman WG meeting in Paris I had promissed to send a proposal= text for a new section that describes the neighborhood energy gateways. This text can be found below: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2.x. Neighborhood Energy Gateways This use case describes the scenario of energy management of a neighborhood= , where a neighborhood energy gateway operates as a proxy that interfaces t= o the home energy gateways. It is expected that the number of photovoltaic stations (PV) on the roofs = of the houses in towns will increase significantly during the next years. = Moreover, a large scale deployment of some renewable energy sources, namely= wind and solar, imposes system integration challenges due to their variab= le and often unpredictable characteristics. Furthermore, current central s= ystems used for energy management are not able to efficiently coordinate distributed renewable energy in higher penetration. In order to increase the overall energy efficiency including the producers = and consumers, neighborhood energy gateways can be used to manage the consu= mption of the locally produced energy as locally as possible, within the ne= ighborhood and between the individual buildings/homes. If the energy produced by an individual building/home cannot be consumed by= the same building/home, then either another building/home in the neighborh= ood could be found to consume the energy or means need to be found to store= it. This can be supported using the neighborhood energy gateways that moni= tor and manage the home energy gateways. The EMAN information model can be applied to the protocols under considerat= ion for energy management of a neighborhood. The essential properties of this use case are: . Target devices: Neighborhood Energy Gateways and Home energy ga= teways . How powered: Any method. . Reporting: Neighborhood Energy Gateways can collect power consu= mption of a home via the home energy gateway and possibly report the meteri= ng reading to the utility. This use case illustrates the aggregation of the energy use in neighborhood= s. In particular, this use case differs from the Home Energy Gateway use ca= se from the point of how the aggregation of energy needs to be managed, how= frequent the energy objects need to be monitored and how they need to be m= anaged. =3D=3D=3D=3D=3D=3D=3D=3D=3D Best regards, Georgios ________________________________________ Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens Mouli Chandramoul= i (moulchan) [moulchan@cisco.com] Verzonden: dinsdag 19 juni 2012 8:29 Aan: eman@ietf.org Onderwerp: [eman] draft-ietf-eman-applicability-statement-01.txt Hello all, An updated version of the EMAN Applicability Statement has been submitted. http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-01 Most open issues from the previous version of the draft have been closed at the IETF 83 WG meeting. The remaining open issues are: 1. Relevance of ASHRAE SPC201P to EMAN standards (comment from Dave Robin @ WG meeting) ASHRAE standard has not been released for public review yet and should be available in a month or so. Hopefully, the next version of the applicability statement draft shall have a discussion on this topic. 2. Scope of Applicability Statement draft This was discussed in the last WG meeting and some overlap of among cases was considered fine. Secondly, the Applicability Statement draft should describe how the technology developed in the other drafts can be applied/implemented. In that sense, Applicability Statement can be completed after Requirements, Framework, MIB modules are stable. Please let us know if you have any comments, suggestions to improve the draft. Thanks Bruce, Brad and Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, June 19, 2012 11:39 AM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Energy Management Working Group of the IETF. Title : Energy Management (EMAN) Applicability Statement Author(s) : Brad Schoening Mouli Chandramouli Bruce Nordman Filename : draft-ietf-eman-applicability-statement-01.txt Pages : 30 Date : 2012-06-18 Abstract: The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN framework for a variety of scenarios. This document lists use cases and target devices that can potentially implement the EMAN framework and associated SNMP MIB modules. These use cases are useful for identifying requirements for the framework. Further, we describe the relationship of the EMAN framework to relevant other energy monitoring standards and architectures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-applicability-stateme nt-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From moulchan@cisco.com Wed Aug 1 14:34:37 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABC411E817B for ; Wed, 1 Aug 2012 14:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-L7ysjceR1F for ; Wed, 1 Aug 2012 14:34:27 -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 3BC8711E818B for ; Wed, 1 Aug 2012 14:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=19959; q=dns/txt; s=iport; t=1343856863; x=1345066463; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=LOtspoH1kjIna5Dtm0J5L78sTpWXmQvlL7U2Y9mzMHs=; b=SPNFHcGbzDwdLAeuPvukygs5I+rK+XKIjJm93helX/JdoAuk+T8ytOfF 0dq+Kjh5ZOi+UzjdUtUlv0YfN0hPS5WsEuMYhvdK6nIUBdMRTLx9ySkPB 1DT6JMpQmuiDiTj26ZYZ++3P0gppyVR4Ju2ycy/aXbkPN8s+qbktrNfzX E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAMefGVCtJXG+/2dsb2JhbABCA4JKrXEBiFWBB4IgAQEBBBIBGkEEFwIBCA4DBAEBCx0HMhQJCAIEARIIARmHawucc6BDi0kFFQGDTYJBYAOWW40TgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,696,1336348800"; d="scan'208,217";a="107602580" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 01 Aug 2012 21:34:22 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q71LYM9t015584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 21:34:22 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.122]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 16:34:21 -0500 From: "Mouli Chandramouli (moulchan)" To: Bruce Nordman , eman mailing list Thread-Topic: [eman] Requirements comments Thread-Index: AQHNcBpn5o+LiwXMqkaa1fYhyN3E1ZdFbQUw Date: Wed, 1 Aug 2012 21:34:20 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA40E65A6E5@xmb-rcd-x08.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.001 x-tm-as-result: No--43.689900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA40E65A6E5xmbrcdx08ciscoc_" MIME-Version: 1.0 Subject: Re: [eman] Requirements 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, 01 Aug 2012 21:34:37 -0000 --_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA40E65A6E5xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Bruce, Thanks for your comments. Replies inline. Mouli From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Bru= ce Nordman Sent: Thursday, August 02, 2012 12:48 AM To: eman mailing list Subject: [eman] Requirements comments Comments on Requirements-08 Bruce Nordman July 31, 2012 Many thanks to the authors for advancing the draft. "Aggregate" or "aggregation" is used to reflect grouping of entities, as w= ell as to summation across such a group. It can also refer to a quantity which is inherently a summed quantity, such as a measurement of power being delivered to a collection of devices. We need a term for each of these concepts and assure that they are used consistently in all drafts. I would propose "Collection" for the process of creating a group of measurements, and "summation" for adding up values across a collection. [ycm] This is much discussed and clarified in the framework. An entity as defined here is either a device or a component. Interfaces ar= e not mentioned. I think that some of the references should really apply onl= y to devices, others to devices or components, some to all three, and some to either a device or interface. We need to be specific as to whether an inte= rface is included in "entity" (I think it should be) and it may be helpful to hav= e a terms that cover other groupings. An example where this may be important is that reference is made to communication with entities. Can the management system communicate with a component, or only with an entire device? [ycm] We are trying to list the physical objects that consume power. Entiti= es and components of entities (of network devices) are defined as in Entity= MIB. [ycm] For e.g. line cards and ports have IP addresses and management system= can directly communicate with those component. [ycm] Does an "interface" as you have defined consume power ? I think a definition of component would also be helpful - something like "an entity that is a subset of a device". In the Introduction, the concept of Power Interface has not yet been define= d so that referring to inlets and outlets seems quite appropriate. However, once we have the interface notion, then inlet and outlet should only be used when interface is not suitable, as they are not different concepts, bu= t only whether the power value is positive or negative. This applies in seve= ral places but particularly 5.2. Along these lines, 5.2.2 and 5.2.3 need to be combined, since as an interface can change inlet/outlet state dynamically, the connections are simply to other interfaces. Also, connections can be to multiple other interfaces and commonly are (the language implies only a 1:1 relationship). For 5.2.5, need only say that power is flowing -- the= re is no need to reference the direction. [ycm] actually, I am not sure we need these notions of power inlet and powe= r outlets in the requirements draft. 3.1. I disagree that "full" and "reduced" are different power states - ther= e is a continuum of levels within the fully on state - there are three basic typ= es of power states in general. [ycm] there are several standards, ACPI, DMTF which have much more than 3 p= ower states for devices 5.1.3,5.1.4. I don't think these are well enough defined to be included an= d would drop both. [ycm] This was discussed exhaustively on the list on the need for these att= ributes. http://www.ietf.org/mail-archive/web/eman/current/msg01230.html [ycm] power priority is used by other standard such as rfc 3621. The definition of Domain should be imported. It should be made clear if a device can be a member of multiple domains or only a single domain. 5.2.6. "... as well as for entire Powered Entity". Why include this phras= e? The entity may or may not have a single type, and this is duplicative of information available elsewhere. 5.3.3. With the accuracy data available, it seems unnecessary to include the measurement method. [ycm] I think it is quite useful to know how the measurement is obtained. 5.4.6. Maximum and average both seem ill-defined and not necessary to include. (Also, I think "typical" would be a better term than "average" for this type of usage). 5.5.2. "Time Interval" seems to imply a specific implementation and seems to exclude the simple "meter reading" approach (like a vehicle odometer) so "Time Stamp" or similar term would be more generic. That is needed regardless. 5.6. Shouldn't the text refer to modeling the battery as an individual com= ponent rather than an entity? 7.5. If we require to indicate what data are available in reports on other devices, shouldn't we require the same mechanism for reporting on oneself? 7.6. This seems problematic - I would remove. How would a device know what other devices know? why should we assume such knowledge is correct? Wouldn't it be better to simply ask the other device what it knows? A.2. This section, on standards of other bodies, is already covered by the applicability statement, which does this more thoroughly. Thus, this section can be removed and the entire appendix be about Existing IETF stand= ards. [ycm] Actually, the text s is complimentary to what Is covered Applicabilit= y statement and provides a good motivation why we need a new IETF standards= Energy monitoring. Minor points: --Does "Power State" need to be capitalized? I can see the sense for Entity and Interface. --3.3., last sentence. Add "functional" before "load" to distinguish this from electrical load. --6.2. "outlets" to "interfaces". --8. "controlling Power State or power supply of others" to "doing that con= trol". --8.1.1. Move "other" after "Powered Entities". --References: Applicability statement has an incorrect author. -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA40E65A6E5xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Bruce,

 <= /p>

Thanks for your comments.= Replies inline.

 <= /p>

Mouli

 <= /p>

From: eman-bou= nces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Bruce Nordman
Sent: Thursday, August 02, 2012 12:48 AM
To: eman mailing list
Subject: [eman] Requirements comments

 

Comments on Requireme= nts-08
Bruce Nordman
July 31, 2012

Many thanks to the authors for advancing the draft.

 "Aggregate" or "aggregation" is used to reflect g= rouping of entities, as well
as to summation across such a group.  It can also refer to a quantity = which
is inherently a summed quantity, such as a measurement of power being
delivered to a collection of devices.  We need a term for each of thes= e
concepts and assure that they are used consistently in all drafts.
I would propose "Collection" for the process of creating a group = of
measurements, and "summation" for adding up values across a colle= ction.

[ycm] This is much discussed and clarified in the framework.


An entity as defined here is either a device or a component.  Interfac= es are
not mentioned.  I think that some of the references should really appl= y only
to devices, others to devices or components, some to all three, and some to=
either a device or interface.  We need to be specific as to whether an= interface
is included in "entity" (I think it should be) and it may be help= ful to have a
terms that cover other groupings.
  An example where this may be important is that reference is made to =
communication with entities.  Can the management system communicate with a component, or only with an entire device?

[ycm] We are trying to list the physical objects that consume powe= r. Entities and components of entities (of network devices) are defined as in Entity MIB.  

[ycm] For e.g. line cards and ports have IP addresses and manageme= nt system can directly communicate with those component.<= /i>

[ycm] Does an “interface” as you have defined consume = power ?


  I think a definition of component would also be helpful - something = like
"an entity that is a subset of a device".

In the Introduction, the concept of Power Interface has not yet been define= d
so that referring to inlets and outlets seems quite appropriate.  Howe= ver,
once we have the interface notion, then inlet and outlet should only be used when interface is not suitable, as they are not different concepts, bu= t
only whether the power value is positive or negative.  This applies in= several
places but particularly 5.2.  Along these lines, 5.2.2 and 5.2.3 need = to be
combined, since as an interface can change inlet/outlet state dynamically,<= br> the connections are simply to other interfaces.  Also, connections can= be
to multiple other interfaces and commonly are (the language implies only a 1:1 relationship).  For 5.2.5, need only say that power is flowing -= - there
is no need to reference the direction.

[ycm] actually, I am not sure we need these notions of power in= let and power outlets in the requirements draft.

3.1. I disagree that "full" and "reduced" are different= power states - there is
a continuum of levels within the fully on state - there are three basic typ= es
of power states in general.=

[ycm] there are several standards, ACPI, DMTF which have much m= ore than 3 power states for devices

5.1.3,5.1.4.  I don't think these are well enough defined to be includ= ed and
would drop both.

[ycm] This was discussed exhaustively on the list on the need f= or these attributes.

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

[ycm] power priority is used by other standard such as rfc 3621= .



The definition of Domain should be imported.  It should be made clear = if
a device can be a member of multiple domains or only a single domain.

5.2.6.  "… as well as for entire Powered Entity". = ; Why include this phrase?
The entity may or may not have a single type, and this is duplicative of information available elsewhere.


5.3.3.  With the accuracy data available, it seems unnecessary to incl= ude
the measurement method.

[ycm] I think it is quite useful to know how the measurement is= obtained.


5.4.6.  Maximum and average both seem ill-defined and not necessary to include.  (Also, I think "typical" would be a better term= than "average"
for this type of usage).

5.5.2.  "Time Interval" seems to imply a specific implementa= tion and seems
to exclude the simple "meter reading" approach (like a vehicle od= ometer)
so "Time Stamp" or similar term would be more generic.  That= is needed
regardless.

5.6.  Shouldn't the text refer to modeling the battery as an individua= l component
rather than an entity?

7.5.  If we require to indicate what data are available in reports on = other
devices, shouldn't we require the same mechanism for reporting on oneself?<= br>
7.6.  This seems problematic - I would remove.  How would a devic= e know
what other devices know?  why should we assume such knowledge is corre= ct?
Wouldn't it be better to simply ask the other device what it knows?

A.2.  This section, on standards of other bodies, is already covered b= y the
applicability statement, which does this more thoroughly.  Thus, this<= br> section can be removed and the entire appendix be about Existing IETF stand= ards.

[ycm] Actually, the text s is complimentary to what Is covered = Applicability statement and provides a good motivation why we need a new IETF standards Energy monitoring.<= /p>




Minor points:
--Does "Power State" need to be capitalized?  I can see the = sense for
  Entity and Interface.
--3.3., last sentence.  Add "functional" before "load&q= uot; to distinguish this
  from electrical load.
--6.2. "outlets" to "interfaces".
--8. "controlling Power State or power supply of others" to "= ;doing that control".
--8.1.1.  Move "other" after "Powered Entities". --References: Applicability statement has an incorrect author.


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

--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA40E65A6E5xmbrcdx08ciscoc_-- From j.schoenwaelder@jacobs-university.de Wed Aug 1 17:28:58 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A1521F873B for ; Wed, 1 Aug 2012 17:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.2 X-Spam-Level: X-Spam-Status: No, score=-103.2 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5c4xrm1fLvsy for ; Wed, 1 Aug 2012 17:28:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 588BF11E80FD for ; Wed, 1 Aug 2012 17:28:57 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC65120BFD; Thu, 2 Aug 2012 02:28:56 +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 QlIhX0x32WRd; Thu, 2 Aug 2012 02:28: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 41E1120BEE; Thu, 2 Aug 2012 02:28:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 25B172100844; Thu, 2 Aug 2012 02:28:54 +0200 (CEST) Date: Thu, 2 Aug 2012 02:28:53 +0200 From: Juergen Schoenwaelder To: eman@ietf.org Message-ID: <20120802002853.GA84871@elstar.local> Mail-Followup-To: eman@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [eman] battery mib -05 section 7.5: augment or not augment? 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, 02 Aug 2012 00:28:58 -0000 Hi, this is what it says: 7.5. Entity MIB augmentation Should the batteryTable augment the entPhysicalTable from the Entity MIB? What will be the answer to this? Is the batteryTable going to augment the new ENTITY-MIB (thus you require a minimal ENTITY-MIB implementation) or do you keep the current "loose" binding? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@quittek.at Wed Aug 1 18:32:33 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E747A11E8152 for ; Wed, 1 Aug 2012 18:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60s23XJaSyQ1 for ; Wed, 1 Aug 2012 18:32:33 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id E00E311E8138 for ; Wed, 1 Aug 2012 18:32:32 -0700 (PDT) Received: from [192.168.0.9] (HSI-KBW-134-3-97-216.hsi14.kabel-badenwuerttemberg.de [134.3.97.216]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MeYyR-1T926E1SCF-00QCMd; Thu, 02 Aug 2012 03:32:29 +0200 References: <20120802002853.GA84871@elstar.local> In-Reply-To: <20120802002853.GA84871@elstar.local> 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: Thu, 2 Aug 2012 03:32:29 +0200 To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:NiqCVnv7rYc2ohRCT6Chggu2Ytm7GEVvEESXAUKdjK2 tZXnZd9df7pdx3tuxJUZrmRgdWoRczh6oLd7sdJmsFdBI6VfQx RLAix2qssdIwKGjR/vuC9gYVwD92QanZTTTzC+KvGql1NbMMBe z13iery8z3cTmeQHhXW6/LRufgw/h5Qadj2jIibObRkJ8QFjEl waWMchoWdB0nPI3iQRoJ6KzUyPrWz5nLwh4n4HhHOgli5sjckX wcR7l8vUbmZGALpVVTQ6y9lrdXOWFYzaKWoNyOy5mUVqFItucr 3YHmT0fcA4NAcUqmxWq+wzO34z575OD91oL7MmJON2Q8qdXHw6 TcRpm7Hje3PQr+nqKRGLEBoHts0n+PyXBbiw8sK/Y Cc: eman@ietf.org Subject: Re: [eman] battery mib -05 section 7.5: augment or not augment? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2012 01:32:34 -0000 Hi, Reading the Entity MIB v4, it does not look like this helps us a lot with the Battery MIB. We use the "loose" binding in the current draft in order to avoid the need to implement the complex Entity MIB v3 in cases where this is not needed. If we make the Entity MIB v4 mandatory to implement, we only have solved this issue for "constrained devices". Any regular (non-constrained) device (Laptop, touchpad, etc., that has a battery to be monitored, still would have to have a complex Entity MIB implementation because it cannot use the new simple entity4CRCompliance that by its definition is limited to "constrained devices": > "The compliance statement for SNMP entities that implement > version 4 of the Entity MIB on devices with constrained > resources." If the Entity MIB v4 remains like this, I would definitely prefer that the Battery MIB keeps its current loose binding to the entity MIB, which is fine and does not seem to create any problem. Thanks, Juergen Q. Am 02.08.2012 um 02:28 schrieb Juergen Schoenwaelder: > Hi, > > this is what it says: > > 7.5. Entity MIB augmentation > > Should the batteryTable augment the entPhysicalTable from the Entity > MIB? > > What will be the answer to this? Is the batteryTable going to augment > the new ENTITY-MIB (thus you require a minimal ENTITY-MIB > implementation) or do you keep the current "loose" binding? > > /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 brads@coraid.com Wed Aug 1 20:38:01 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9530A11E80EF for ; Wed, 1 Aug 2012 20:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUM7CW99DoYH for ; Wed, 1 Aug 2012 20:38:00 -0700 (PDT) Received: from server505.appriver.com (server505f.appriver.com [98.129.35.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF4711E809C for ; Wed, 1 Aug 2012 20:37:59 -0700 (PDT) X-Note-AR-ScanTimeLocal: 8/1/2012 10:37:59 PM X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Primary: brads@coraid.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @coraid.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: smtp.exg5.exghost.com X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G279 G280 G281 G282 G286 G287 G298 G389 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 307161237; Wed, 01 Aug 2012 22:37:59 -0500 Received: from MBX22.exg5.exghost.com ([169.254.1.186]) by HT04.exg5.exghost.com ([98.129.23.33]) with mapi; Wed, 1 Aug 2012 22:37:58 -0500 From: Brad Schoening To: Brad Schoening , Rolf Winter , eman mailing list Date: Wed, 1 Aug 2012 22:37:58 -0500 Thread-Topic: [eman] battery MIB open issues Thread-Index: Ac1wYDWuFpJTKuQFSMGTuR59Cbryyg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] battery MIB open issues X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2012 03:38:01 -0000 Hi Rolf, I realize you may be busy with meetings today, but can you confirm that these two items will be added to the list of open issues? These had been raised with the list several months back and not answered. Thanks, Brad On 7/31/12 8:27 AM, "Brad Schoening" wrote: >Rolf, > >I have not specific comments on those issues, but I like to add a few to >your open issues: > >1. Is is better to use powerSupply(6) instead of other(1) for kind of >entity in entPhysicalTable? If a managed entity already contains a >powerSupply(6) entity, it might be confusing to have a 2nd entity as >powerSupply(6) for a battery. > >2. For UNITS syntax, is it preferred to use "millivolt" or "0.1 Volt DC". > The UPS MIB uses the later format. > >There are many other smaller issues in my email, but they don't warrant >open issue status. However, I would note that in the you've used >"Silver, L" my town, instead of my surname "Schoening, B." in the >reference section. > >Thanks, > > >Brad > > >On 7/31/12 8:13 AM, "Rolf Winter" wrote: > >>Brad, >> >>thanks for re-sending but it doesn't contain anything regarding the open >>issues. Do you have an opinion on any of these? >> >>Best, >> >>Rolf >> >>NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>London W3 6BL | Registered in England 2832014 >> >> >>> -----Original Message----- >>> From: Brad Schoening [mailto:brads@coraid.com] >>> Sent: Dienstag, 31. Juli 2012 07:56 >>> To: Rolf Winter; eman mailing list >>> Subject: Re: [eman] battery MIB open issues >>>=20 >>> Rolf, >>>=20 >>> I had sent the attached comments to the eman mailing list back in >>>April. >>>=20 >>> Regards, >>>=20 >>> Brad >>>=20 >>>=20 >>>=20 >>> On 7/31/12 7:20 AM, "Rolf Winter" wrote: >>>=20 >>> >WG, >>> > >>> >we'd like to ask you again for feedback on the open issues in the >>> >battery MIB document. There are 5 left in the document, 4 of which are >>> >really >>> >open: >>> > >>> > >>> >1. Time estimations >>> >Things like AtRateTimeToFull, AtRateTimeToEmpty... do we want this >>> >information in the MIB? >>> > >>> >2. Capacity reduction per time >>> >Another measure of aging and battery quality. Do we want to have this >>> >in the MIB? >>> > >>> >3. Internal impedance >>> >Do we need this? >>> > >>> >4. Wireless charging >>> >Anything special about wireless charging (e.g. new states) >>> > >>> >We'd appreciate feedback on these open issues. >>> > >>> >Thanks, >>> > >>> >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 From brads@coraid.com Wed Aug 1 21:31:38 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7D011E812C for ; Wed, 1 Aug 2012 21:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBE1dmul8PrF for ; Wed, 1 Aug 2012 21:31:35 -0700 (PDT) Received: from server505.appriver.com (server505f.appriver.com [98.129.35.10]) by ietfa.amsl.com (Postfix) with ESMTP id 510F911E80D7 for ; Wed, 1 Aug 2012 21:31:35 -0700 (PDT) X-Note-AR-ScanTimeLocal: 8/1/2012 11:31:34 PM X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Primary: brads@coraid.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @coraid.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: smtp.exg5.exghost.com X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G279 G280 G281 G282 G286 G287 G298 G389 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 307165331; Wed, 01 Aug 2012 23:31:34 -0500 Received: from MBX22.exg5.exghost.com ([169.254.1.186]) by HT04.exg5.exghost.com ([98.129.23.33]) with mapi; Wed, 1 Aug 2012 23:31:34 -0500 From: Brad Schoening To: Bruce Nordman Date: Wed, 1 Aug 2012 23:31:33 -0500 Thread-Topic: [eman] Sec 3.1 Four basic power states from ECMA model (was: Requirements comments) Thread-Index: Ac1wZ7IBRBA+7Y7UTAClG/ExqlVPBg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC3F456F557ACbradscoraidcom_" MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] Sec 3.1 Four basic power states from ECMA model (was: Requirements 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, 02 Aug 2012 04:31:38 -0000 --_000_CC3F456F557ACbradscoraidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bruce, The four basic power states came, in large part, from ECMA : 4.1.4. Ecma SDC (http://tools.ietf.org/html/draft-ietf-eman-applicabili= ty-statement-01) The Ecma International committee on Smart Data Centre (TC38-TG2 SDC [Ecma-SDC]) is in the process of defining semantics fo= r management of entities in a data center such as servers, storage, and network equipment. It covers energy as one of many functional resources or attributes of systems for monitoring and control. It only defines messages and properties, and does not reference any specific protocol. Its goal is to enable interoperability of such protocols as SNMP, BACNET, and HTTP by ensuring a common semantic model across them. Four power states are defined, Off, Sleep, Idle and Active. The standard does not = include actual energy or power measurements in kWor kWh. Indeed, a paper you co-authored "Skilled in the Art of Being Idle", 2009 sh= ows the same four power states in Figure 1: "Off, Sleep, Idle, On". [http:= //tier.cs.berkeley.edu/docs/nedevschi_nsdi09.pdf] Re-reading your email, I believe you are probably not critiquing section 5.= 4 of the Requirements which would allow multiple operational power state le= vels (or which could be states, polices, etc). (http://tools.ietf.org/html/draft-ietf-eman-requirements-08) : 5.4= . Power State Many entities have a limited number of discrete Power States. There is a need to report the actual Power State of an entity, and means for retrieving the list of all supported Power States. Different standards bodies have already defined sets of Power States for some entities, and others are creating new Power State sets. In this context, it is desirable that the standard support many of these power state standards. In order to support multiple management systems possibly using different Power State sets, while simultaneously interfacing with a particular entity, the energy management standard must provide means for supporting multiple Power State sets used simultaneously at an entity. Power States have parameters that describe its properties. It is required to have standardized means for reporting some key properties, such as average power and maximum power of an entity in a certain state. There also is a need to report statistics on Power States including the time spent and the received and provided energy in a Power State. Brad Schoening Engineering | Coraid Tel: +1 917 304 7190 brads@coraid.com | www.coraid.com Coraid: Redefining Storage From: Bruce Nordman > Date: Wed, 1 Aug 2012 14:37:36 -0500 To: Brad Schoening > Cc: eman mailing list > Subject: Re: [eman] Requirements comments The section in question in the requirements draft refers to "basic types of= power states". I fully agree that many devices have a wide range of sub-states so that a f= ull list of states for a particular device might be one or might be dozens long. However, this is about "basic types" which groups these into a much smaller= number. The Windows 7 items below are not power states, but policies implemented by a device to manage how to move among power states and otherwise manage resources. --Bruce On Wed, Aug 1, 2012 at 12:30 PM, Brad Schoening > wrote: 3.1. I disagree that "full" and "reduced" are different power states - ther= e is a continuum of levels within the fully on state - there are three basic typ= es of power states in general. Bruce, as we have discussed at great length, there are many operational sta= tes that are supported by real, deployed systems. EMAN will be less usefu= l if it willfully ignores these. This was the motivation behind the propos= al to add IANA power states. I thought we had reached consensus on this, d= id we not? Windows Mobile (CE) has "Full on" and "Low on" http://msdn.microsoft.com/en-us/library/aa932261.aspx Windows 7 has by default three: "Balanced", "Power saver", "High performanc= e" http://windows.microsoft.com/en-us/windows-vista/Power-plans-frequently-ask= ed-questions Regards, Brad -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --_000_CC3F456F557ACbradscoraidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Bruce,

The four basic power states came, in large part, from = ECMA :

   =
 4.1.4. Ecma SDC (http://tools.ietf.org/html=
/draft-ietf-eman-applicability-statement-01)
        The Ecma International comm=
ittee on Smart Data Centre (TC38-TG2
        SDC [Ecma-SDC]) is in the process of d=
efining semantics for
        management of entities in a data center such as servers,
        storage, and network equipment.  It covers energy as one of many
        functional resources or attributes of systems for monitoring and

        control. It only defines messages and properties, an=
d does not
        reference any specific protocol. Its goal is to enable
        interoperability of such protocols as SNMP, BACNET, and HTTP by
        ensuring a common semantic model across them. Four power =
states
        are defined, Off, Sleep, Idle and Active. The standard does not=
        include actual energy or power measurements in kWor kWh.
    =20

Indeed, a paper you co-authored "Skilled in the Ar=
t of Being Idle", 2009 shows the same four power states in Figure 1: "Off, =
Sleep, Idle, On".  [http://tier.cs.berkeley.edu/docs/nedevschi_nsdi09.pdf]
=


=
Re-reading your email, I believe you are probably not critiquing section 5.=
4 of the Requirements which would allow multiple operational power state le=
vels (or which could be states, polices, etc).

 (http://tools.ietf.org/htm=
l/draft-ietf-eman-requirements-08) :
5.4.  Power State


   Many entities have a limited number of discrete Power States.

   There is a need to report the actual Power State of an entity, and
   means for retrieving the list of all supported Power States.

   Different standards bodies have already defined sets of Power States
   for some entities, and others are creating new Power State sets.  In
   this context, it is desirable that the standard support many of these
   power state standards.  In order to support multiple management
   systems possibly using different Power State sets, while
   simultaneously interfacing with a particular entity, the energy
   management standard must provide means for supporting multiple Power
   State sets used simultaneously at an entity.

   Power States have parameters that describe its properties.  It is
   required to have standardized means for reporting some key
   properties, such as average power and maximum power of an entity in a
   certain state.

   There also is a need to report statistics on Power States including
   the time spent and the received and provided energy in a Power State.


   
   
   
   
   
   
   
   
   
   
  




















Brad Schoening

Engineering | Coraid

Tel: +1 917 304 7190

brads@coraid.com | www.coraid.com 
<=
span style=3D"font-size:9.0pt;font-family:Arial;mso-fareast-font-family:
"Times New Roman";color:#00467F;mso-ansi-language:EN-US;mso-farea=
st-language:
EN-US;mso-bidi-language:AR-SA;mso-bidi-font-style:italic">Coraid: Redefinin=
g
Storage
From:  Bruce Nordman <bnordman@lbl.gov>
Date:  Wed, 1 Aug 2012 14:37:36 -0500
To:  Brad Schoening <brads@coraid.c=
om>
Cc:  eman mailing lis=
t <eman@ietf.org>
Subject:  Re: [eman] Requirements comments
=


The section in question in the requirements draft refe=
rs to "basic types of power states".
I fully agree that many devices hav=
e a wide range of sub-states so that a full list of
states for a particu=
lar device might be one or might be dozens long.

However, this is about "basic types" which groups these into a much smaller=
 number.

The Windows 7 items below are not power states, but policie=
s implemented by
a device to manage how to move among power states and o=
therwise manage

resources.

--Bruce

On Wed, Aug 1, =
2012 at 12:30 PM, Brad Schoening <brads@coraid.com> wrote:
3.1. I disagree that "full" and "reduced" are different power states - the=
re is

a continuum of levels within the fully on state - there are three basic typ=
es
of power states in general.

Bru= ce, as we have discussed at great length, there are many operational states= that are supported by real, deployed systems.   EMAN will be less use= ful if it willfully ignores these.  This was the motivation behind the= proposal to add IANA power states.  I thought we had reached consensu= s on this, did we not?

Windows Mobile (CE) has "Full on" and = "Low on"

Windows 7 has by default three: "= Balanced", "Power saver", "High performance"


=

Regards,

Brad



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

--_000_CC3F456F557ACbradscoraidcom_-- From karagian@cs.utwente.nl Thu Aug 2 09:31:44 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAF411E80F5 for ; Thu, 2 Aug 2012 09:31:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSlol3AjKY5R for ; Thu, 2 Aug 2012 09:31:43 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8696D11E80F1 for ; Thu, 2 Aug 2012 09:31:42 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 2 Aug 2012 18:31:49 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.41]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Thu, 2 Aug 2012 18:31:40 +0200 From: To: , Thread-Topic: comments on draft-ietf-eman-applicability-statement-01.txt Thread-Index: AQHNb35I9BjHlVF8ykukn1vjCIzjiZdFdHbwgAFDjjc= Date: Thu, 2 Aug 2012 16:31:40 +0000 Message-ID: References: , <852AF0ED49D9F24BBBFA1B4DEEBE3BA40E65A6B0@xmb-rcd-x08.cisco.com> In-Reply-To: <852AF0ED49D9F24BBBFA1B4DEEBE3BA40E65A6B0@xmb-rcd-x08.cisco.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [208.181.206.247] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] comments on draft-ietf-eman-applicability-statement-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:31:44 -0000 Hello Mouli, Okay thanks!=20 Can you then please mention in Section 2.7 something like: "This use case description is also relevant for the situation that Neighbo= rhood Energy Gateways are used, instead of Home Energy Gateways ." During the eman meeting there was a consensus that I should provide some br= ief description of Phasor Measrement Units and IEEE 37.118-2005 that could = be used in the applicability statement draft! I will provide this text after my summer holidays! Best regards, Georgios ________________________________________ Van: Mouli Chandramouli (moulchan) [moulchan@cisco.com] Verzonden: woensdag 1 augustus 2012 23:16 Aan: Karagiannis, G. (EWI); eman@ietf.org Onderwerp: RE: comments on draft-ietf-eman-applicability-statement-01.txt Hello Georgios, We have included some text you had proposed and added to the Home Energy Ga= teway Section 2.7. While the intent is to provide an exhaustive list of use= cases; we felt it is also important to have unique use cases that drive th= e requirements. Aggregation is covered in some other use cases also. Thanks Mouli -----Original Message----- From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] Sent: Wednesday, August 01, 2012 6:15 AM To: Mouli Chandramouli (moulchan); eman@ietf.org Subject: comments on draft-ietf-eman-applicability-statement-01.txt Hi Mouli, Hi all, I have two comments on draft-ietf-eman-applicability-statement-01.txt. Comment_1: On the 24th of June, see bottom of this email, I have had provid= ed input for a new subsection that describes the Neighborhood Energy Gatewa= ys use case. Hopefully it is not too late to include this section in the dr= aft. Comment_2: The description of the IEEE 37.118-2005 [IEEE37118] is missing. = This is a monitoring standard based on synchrophasors, like Phasor Measurem= ent Units (PMUs). Please note that an ongoing IEC standardization activity was defined that i= s focusing on the integration of this type of monitoring into IEC 61850, se= e reference [Mar11] below. [IEEE37118] IEEE 37.118-2005, "IEEE Standard for Synchrophasors for Power S= ystem", IEEE standard, 2005. [Mart11] K. E. Martin, "Synchrophasor Standards Development - IEEE C37.118 = & IEC 61850", Proc. of 44th Hawaii International Conference on System Scien= ces (ICSS'2011), pp. 1-8, 2011. Best regards, Georgios _______________________________________ Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens karagian@cs.utwen= te.nl [karagian@cs.utwente.nl] Verzonden: zondag 24 juni 2012 21:39 Aan: moulchan@cisco.com; eman@ietf.org Onderwerp: Re: [eman] draft-ietf-eman-applicability-statement-01.txt Hi Mouli, Hi all, During the IETF eman WG meeting in Paris I had promissed to send a proposal= text for a new section that describes the neighborhood energy gateways. This text can be found below: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2.x. Neighborhood Energy Gateways This use case describes the scenario of energy management of a neighborhood= , where a neighborhood energy gateway operates as a proxy that interfaces t= o the home energy gateways. It is expected that the number of photovoltaic stations (PV) on the roofs = of the houses in towns will increase significantly during the next years. = Moreover, a large scale deployment of some renewable energy sources, namely= wind and solar, imposes system integration challenges due to their variab= le and often unpredictable characteristics. Furthermore, current central s= ystems used for energy management are not able to efficiently coordinate distributed renewable energy in higher penetration. In order to increase the overall energy efficiency including the producers = and consumers, neighborhood energy gateways can be used to manage the consu= mption of the locally produced energy as locally as possible, within the ne= ighborhood and between the individual buildings/homes. If the energy produced by an individual building/home cannot be consumed by= the same building/home, then either another building/home in the neighborh= ood could be found to consume the energy or means need to be found to store= it. This can be supported using the neighborhood energy gateways that moni= tor and manage the home energy gateways. The EMAN information model can be applied to the protocols under considerat= ion for energy management of a neighborhood. The essential properties of this use case are: . Target devices: Neighborhood Energy Gateways and Home energy ga= teways . How powered: Any method. . Reporting: Neighborhood Energy Gateways can collect power consu= mption of a home via the home energy gateway and possibly report the meteri= ng reading to the utility. This use case illustrates the aggregation of the energy use in neighborhood= s. In particular, this use case differs from the Home Energy Gateway use ca= se from the point of how the aggregation of energy needs to be managed, how= frequent the energy objects need to be monitored and how they need to be m= anaged. =3D=3D=3D=3D=3D=3D=3D=3D=3D Best regards, Georgios ________________________________________ Van: eman-bounces@ietf.org [eman-bounces@ietf.org] namens Mouli Chandramoul= i (moulchan) [moulchan@cisco.com] Verzonden: dinsdag 19 juni 2012 8:29 Aan: eman@ietf.org Onderwerp: [eman] draft-ietf-eman-applicability-statement-01.txt Hello all, An updated version of the EMAN Applicability Statement has been submitted. http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-01 Most open issues from the previous version of the draft have been closed at the IETF 83 WG meeting. The remaining open issues are: 1. Relevance of ASHRAE SPC201P to EMAN standards (comment from Dave Robin @ WG meeting) ASHRAE standard has not been released for public review yet and should be available in a month or so. Hopefully, the next version of the applicability statement draft shall have a discussion on this topic. 2. Scope of Applicability Statement draft This was discussed in the last WG meeting and some overlap of among cases was considered fine. Secondly, the Applicability Statement draft should describe how the technology developed in the other drafts can be applied/implemented. In that sense, Applicability Statement can be completed after Requirements, Framework, MIB modules are stable. Please let us know if you have any comments, suggestions to improve the draft. Thanks Bruce, Brad and Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, June 19, 2012 11:39 AM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Energy Management Working Group of the IETF. Title : Energy Management (EMAN) Applicability Statement Author(s) : Brad Schoening Mouli Chandramouli Bruce Nordman Filename : draft-ietf-eman-applicability-statement-01.txt Pages : 30 Date : 2012-06-18 Abstract: The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN framework for a variety of scenarios. This document lists use cases and target devices that can potentially implement the EMAN framework and associated SNMP MIB modules. These use cases are useful for identifying requirements for the framework. Further, we describe the relationship of the EMAN framework to relevant other energy monitoring standards and architectures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-applicability-stateme nt-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman= From n.brownlee@auckland.ac.nz Thu Aug 2 11:27:35 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9349A21E8122 for ; Thu, 2 Aug 2012 11:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdlC6GOxv4Zg for ; Thu, 2 Aug 2012 11:27:34 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 453D811E8142 for ; Thu, 2 Aug 2012 11:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1343932053; x=1375468053; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=e2QQMoH7+8iF03I1dUPKlvfrHT7e/HvrThqCqq7zRYY=; b=pH7vDzGjMyZLkpi0tUDdm5VcaJVjFJ9++RljuUGFSPwvqjxSZq1O7kvX 1tAdvuvj7Gd73XwWnqYgHAiiETdt9xTnNh5QT+9wUZl3gFN+YcDQ1OZY7 XRUzqN4798d3QiT8WX/fAwTFqyCNOJiQjqGST0UpAdiy5VDuNi8MahV/5 M=; X-IronPort-AV: E=Sophos;i="4.77,702,1336305600"; d="scan'208";a="136450553" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.20.231 - Outgoing - Outgoing-SSL Received: from dhcp-14e7.meeting.ietf.org (HELO [130.129.20.231]) ([130.129.20.231]) by mx2-int.auckland.ac.nz with ESMTP; 03 Aug 2012 06:27:31 +1200 Message-ID: <501AC690.2010309@auckland.ac.nz> Date: Fri, 03 Aug 2012 06:27:28 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: eman@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eman] DRAFT minutes for Vancouver 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: Thu, 02 Aug 2012 18:27:35 -0000 Hi all: Here are my draft-00 minutes from our meeting yesterday. Please send me corrections, suggestions for improvements, etc. Cheers, Nevil DRAFT-00 Minutes of the EMAN meeting at IETF 84 in Vancouver Scribes: Nevil Brownlee & ? Co-chairs: Bruce Nordman & Nevil Brownlee Legend ------ [AR] = Alberto Retona [BC] = Benoit Claise [BN] = Bruce Nordman [DR] = Dan Romascanu [GK] = Georgios Karigianis [JP] = John Parello [MC] = Mouli Chandramouli Terminology draft ----------------- Presented by Jon Parello. - We use Entity = 'Device or Component' - Compared EMAN terminology with ASHRAE 201p They use Asset to describe 'Device or Component.' EMAN should use 'Entity,' to be consistent with Entity MIB [DR] - ASHRAE use 'Nameplate Power' EMAN should use 'Manufacture Rating' = The terminology is nearly all moved into the Requirements and Framework drafts. Requirements for Energy Management -08 -------------------------------------- Presented by Juergen Quittek (via Skype) - Made changes suggested since IETF-83 - Open issues: + Reporting of device info - "what info for which device(s)?" . Report for devices, components and interfaces? [JP] . Report for objects in Entity MIB [DR] = Use the Entity MIB - 'Phasor measurements' had been discussed on the list, should these be included in Requirements? [GK] Little support at the meeting, continue on list. - Need to add a requirement for windowing of measurements, as discussed on the list [MC] = The authors will publish one more revision, then we will start its WG Last Call. Energy Management Framework -05 ------------------------------- Presented by John Parello - Added 'reference topology and guidelines' for power sources, metering, proxies and aggregation - Open items . Edit pass: authors to check each section, and decide whether it should me kept/trimmed/moved/deleted . Check to see that draft's UML matches that in latest Monitoring MIB + States and Levels . ASHRAE uses 'curtailment levels,' should we? . The draft lists levels from several other organisations; should we set out an 'EMAN levels' list? [JP, AR] = Meeting was strongly in favour of this; discussion will continue on list * Our AD [BC] pointed out that we need to track issues more carefully, so that we don't revisit an issue once it's been closed. Chairs (Nevil, since BN is a document author) will so this using the DataTracker = New revision needed, WGLC once all issues are closed. Energy-aware Networks and Devices MIB -06 ----------------------------------------- Presented by John Parello. - Textual Convention added for EnergyRelations - Now compatible with object in Entity MIBv4 - Open issues + Persistence of objects (when they're power-cycled or moved) = Objects that can change should be represented by objects in Entity MIBv4, that's enough [DR] = New version once Requirements draft is frozen. Entity MIBv4 -01 ---------------- New draft written by Mouli Chandramouli, Presented by Dan Romascanu. - Identifies devices using the Energy-Aware MIB - Open Issue + Need a compact UUID for entPhysicalUris . Assume that devices comply with RFC 4122 [DR] - This is an initial version of the MIB, comments welcome on list - Is EMAN the right wg to produce this MIB? = Yes, Chairs will ask AD to add it to EMAN charter. Power and Energy Monitoring MIB -03 ----------------------------------- Presented by John Parello (for Mouli Chandramouli). - Complete, now waiting until Requirements and Framework are complete - Could Printer MIB be included? Support for this in meting. Battery MIB -05 --------------- Presented by Juergen Quittek. - Five open issues, need feedback from list! . Authors will make suggestions = Waiting on Entity MIBv4 Applicability Statement -01 --------------------------- Presented by Bruce Nordman. - Open issues from IETF-83 now closed - Use Cases and Related Standards sections almost complete . [BN. JP] have sent comments on ASHRAE 201p to the list; need EMAN folk to consider these and comment on the list . Could Implementation Guidelines be in this draft? Not yet, we need some implementation experience [BC] . Could other use cases be added? [GK] Yes, please send text to authors (via the list) = Could be ready for WGLC once Requirements and Framework are done. Milestones ---------- The Chairs presented a list of proposed new dates . - Requirements Oct 2012 - Framework (after discussion) April 2013 - MIBs, Applicability Statement June 2013 Other Drafts ------------ ECAP Requirements (Alberto Retona) - This draft is from rtwg, its goal is to optimise power consumption in the network while maintaining an acceptable service level. Green Usage MIB (Satoru Izumi) - A tiny MIB providing energy state information for various devices Nanogrids (Bruce Nordham) - No time for this, alas. Please read the draft -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From Rolf.Winter@neclab.eu Thu Aug 2 11:33:05 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98F311E822A for ; Thu, 2 Aug 2012 11:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1tywjui-f+5 for ; Thu, 2 Aug 2012 11:33:05 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B3FC011E8229 for ; Thu, 2 Aug 2012 11:33:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id F32761019CD; Thu, 2 Aug 2012 20:38:42 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8I0+P9d5OaFS; Thu, 2 Aug 2012 20:38:42 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id C93181019C5; Thu, 2 Aug 2012 20:38:32 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.252]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 20:32:32 +0200 From: Rolf Winter To: Brad Schoening , eman mailing list Thread-Topic: [eman] battery MIB open issues Thread-Index: AQHNcGA7M1DE4YaAQEGCBjxrzg2RhpdG2NLg Date: Thu, 2 Aug 2012 18:33:25 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D32E30E7D@PALLENE.office.hd> References: 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.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] battery MIB open issues X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2012 18:33:05 -0000 Sure. The document hasn't been updated since those comments were made. We w= ere hoping to have comments on the open issues and having the requirements = stabilize before publishing a new version. We'll publish a new version soon= ish. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Brad Schoening [mailto:brads@coraid.com] > Sent: Mittwoch, 1. August 2012 20:38 > To: Brad Schoening; Rolf Winter; eman mailing list > Subject: Re: [eman] battery MIB open issues >=20 > Hi Rolf, >=20 > I realize you may be busy with meetings today, but can you confirm that > these two items will be added to the list of open issues? These had > been raised with the list several months back and not answered. >=20 > Thanks, >=20 > Brad >=20 >=20 >=20 > On 7/31/12 8:27 AM, "Brad Schoening" wrote: >=20 > >Rolf, > > > >I have not specific comments on those issues, but I like to add a few > >to your open issues: > > > >1. Is is better to use powerSupply(6) instead of other(1) for kind of > >entity in entPhysicalTable? If a managed entity already contains a > >powerSupply(6) entity, it might be confusing to have a 2nd entity as > >powerSupply(6) for a battery. > > > >2. For UNITS syntax, is it preferred to use "millivolt" or "0.1 Volt > DC". > > The UPS MIB uses the later format. > > > >There are many other smaller issues in my email, but they don't > warrant > >open issue status. However, I would note that in the you've used > >"Silver, L" my town, instead of my surname "Schoening, B." in the > >reference section. > > > >Thanks, > > > > > >Brad > > > > > >On 7/31/12 8:13 AM, "Rolf Winter" wrote: > > > >>Brad, > >> > >>thanks for re-sending but it doesn't contain anything regarding the > >>open issues. Do you have an opinion on any of these? > >> > >>Best, > >> > >>Rolf > >> > >>NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >>London W3 6BL | Registered in England 2832014 > >> > >> > >>> -----Original Message----- > >>> From: Brad Schoening [mailto:brads@coraid.com] > >>> Sent: Dienstag, 31. Juli 2012 07:56 > >>> To: Rolf Winter; eman mailing list > >>> Subject: Re: [eman] battery MIB open issues > >>> > >>> Rolf, > >>> > >>> I had sent the attached comments to the eman mailing list back in > >>>April. > >>> > >>> Regards, > >>> > >>> Brad > >>> > >>> > >>> > >>> On 7/31/12 7:20 AM, "Rolf Winter" wrote: > >>> > >>> >WG, > >>> > > >>> >we'd like to ask you again for feedback on the open issues in the > >>> >battery MIB document. There are 5 left in the document, 4 of which > >>> >are really > >>> >open: > >>> > > >>> > > >>> >1. Time estimations > >>> >Things like AtRateTimeToFull, AtRateTimeToEmpty... do we want this > >>> >information in the MIB? > >>> > > >>> >2. Capacity reduction per time > >>> >Another measure of aging and battery quality. Do we want to have > >>> >this in the MIB? > >>> > > >>> >3. Internal impedance > >>> >Do we need this? > >>> > > >>> >4. Wireless charging > >>> >Anything special about wireless charging (e.g. new states) > >>> > > >>> >We'd appreciate feedback on these open issues. > >>> > > >>> >Thanks, > >>> > > >>> >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 From jparello@cisco.com Thu Aug 2 12:42:07 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033F311E8186 for ; Thu, 2 Aug 2012 12:42:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgOmfg8wC2Dz for ; Thu, 2 Aug 2012 12:42:06 -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 CDD0911E8183 for ; Thu, 2 Aug 2012 12:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=6864; q=dns/txt; s=iport; t=1343936525; x=1345146125; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=plTSTkCY6dyuE0YrUw9HpUE4VYseKWpGA+Bg+4ZjtGA=; b=itb1uagQBOmij5o9I3GaPxAkGmruAiAT6FrpWhpo6hJhaUfEGo3kOOQI VSkKUcg638N5mTVfwxO+jKIoopdlBLcpcObPMP9f88j2lzsQgkWd6l5dQ E65NO3+/9UcIJfUl2WNjx1knSPOQAg60muOWtNzDN8Gzig2EZdMNm0Nn+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAK/XGlCtJV2b/2dsb2JhbABFDrkNgQeCIAEBAQMBAQEBDwEnNAsOAgIBCA4oEBsMCyUCBA4FIodlBgucb6BLBASLRgUWhglgA5VHjieBZoImOQ X-IronPort-AV: E=Sophos;i="4.77,703,1336348800"; d="scan'208";a="107959614" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 02 Aug 2012 19:41:58 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q72JfvI9023784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 19:41:57 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.228]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 14:41:57 -0500 From: "John Parello (jparello)" To: Nevil Brownlee Thread-Topic: [eman] DRAFT minutes for Vancouver meeting Thread-Index: AQHNcNyDTX/pWqxd2EmKTGarB/lxpJdG7Ae4 Date: Thu, 2 Aug 2012 19:41:57 +0000 Message-ID: <7C80A18B-C956-447F-9505-4F752225E4E4@cisco.com> References: <501AC690.2010309@auckland.ac.nz> In-Reply-To: <501AC690.2010309@auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.000 x-tm-as-result: No--66.293900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] DRAFT minutes for Vancouver 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: Thu, 02 Aug 2012 19:42:07 -0000 See inline... Sent from my iPad=20 (expect ridiculous spelling mistakes)=20 On Aug 2, 2012, at 11:27 AM, "Nevil Brownlee" w= rote: >=20 > Hi all: >=20 > Here are my draft-00 minutes from our meeting yesterday. > Please send me corrections, suggestions for improvements, etc. >=20 > Cheers, Nevil >=20 >=20 > DRAFT-00 Minutes of the EMAN meeting at IETF 84 in Vancouver > Scribes: Nevil Brownlee & ? > Co-chairs: Bruce Nordman & Nevil Brownlee >=20 > Legend > ------ >=20 > [AR] =3D Alberto Retona > [BC] =3D Benoit Claise > [BN] =3D Bruce Nordman > [DR] =3D Dan Romascanu > [GK] =3D Georgios Karigianis > [JP] =3D John Parello > [MC] =3D Mouli Chandramouli >=20 > Terminology draft > ----------------- > Presented by Jon Parello. > - We use Entity =3D 'Device or Component' > - Compared EMAN terminology with ASHRAE 201p > They use Asset to describe 'Device or Component.' > EMAN should use 'Entity,' to be consistent with Entity MIB [DR] > - ASHRAE use 'Nameplate Power' > EMAN should use 'Manufacture Rating' correction of above it was should add manufacturer rating to the nameplate = definition - Benoit asked for clarification on interfaces so that they dont seem to be= for connecting components > =3D The terminology is nearly all moved into the Requirements and > Framework drafts. >=20 > Requirements for Energy Management -08 > -------------------------------------- > Presented by Juergen Quittek (via Skype) > - Made changes suggested since IETF-83 > - Open issues: > + Reporting of device info - "what info for which device(s)?" > . Report for devices, components and interfaces? [JP] > . Report for objects in Entity MIB [DR] > =3D Use the Entity MIB John - at mic in our implementations we keep the same model for interfaces,= components and devices. And thatbdesign should be in modelsmnot requiremen= ts. That keeps it simple to implement. Dan seconded in his comments at mic = as this is what entity does.=20 > - 'Phasor measurements' had been discussed on the list, should these > be included in Requirements? [GK] > Little support at the meeting, continue on list. > - Need to add a requirement for windowing of measurements, > as discussed on the list [MC] > =3D The authors will publish one more revision, then we will start > its WG Last Call. >=20 > Energy Management Framework -05 > ------------------------------- > Presented by John Parello > - Added 'reference topology and guidelines' for power sources, > metering, proxies and aggregation > - Open items > . Edit pass: authors to check each section, and decide whether it > should me kept/trimmed/moved/deleted > . Check to see that draft's UML matches that in latest Monitoring MIB > + States and Levels > . ASHRAE uses 'curtailment levels,' should we? > . The draft lists levels from several other organisations; > should we set out an 'EMAN levels' list? [JP, AR] > =3D Meeting was strongly in favour of this; discussion will > continue on list > * Our AD [BC] pointed out that we need to track issues more carefully, > so that we don't revisit an issue once it's been closed. > Chairs (Nevil, since BN is a document author) will so this using > the DataTracker -Alvarado from rtwg asked for a reccomended set of levels. Asked if EMAN co= uld be indicated as the prefered.=20 -We discussed John asked the floor for discussion and it concluded th= at we will add that to draft. -The chairs will send a note to the printer working group to ask if we shou= ld add their levels to the planned IANA regiatry for inclusion. > =3D New revision needed, WGLC once all issues are closed. >=20 > Energy-aware Networks and Devices MIB -06 > ----------------------------------------- > Presented by John Parello. > - Textual Convention added for EnergyRelations > - Now compatible with object in Entity MIBv4 > - Open issues > + Persistence of objects (when they're power-cycled or moved) > =3D Objects that can change should be represented by objects in > Entity MIBv4, that's enough [DR] > =3D New version once Requirements draft is frozen. >=20 > Entity MIBv4 -01 > ---------------- > New draft written by Mouli Chandramouli, Presented by Dan Romascanu. > - Identifies devices using the Energy-Aware MIB > - Open Issue > + Need a compact UUID for entPhysicalUris > . Assume that devices comply with RFC 4122 [DR] > - This is an initial version of the MIB, comments welcome on list > - Is EMAN the right wg to produce this MIB? > =3D Yes, Chairs will ask AD to add it to EMAN charter. >=20 >=20 > Power and Energy Monitoring MIB -03 > ----------------------------------- > Presented by John Parello (for Mouli Chandramouli). > - Complete, now waiting until Requirements and Framework are complete > - Could Printer MIB be included? Support for this in meting. >=20 > Battery MIB -05 > --------------- > Presented by Juergen Quittek. > - Five open issues, need feedback from list! > . Authors will make suggestions > =3D Waiting on Entity MIBv4 >=20 > Applicability Statement -01 > --------------------------- > Presented by Bruce Nordman. > - Open issues from IETF-83 now closed > - Use Cases and Related Standards sections almost complete > . [BN. JP] have sent comments on ASHRAE 201p to the list; > need EMAN folk to consider these and comment on the list > . Could Implementation Guidelines be in this draft? > Not yet, we need some implementation experience [BC] > . Could other use cases be added? [GK] > Yes, please send text to authors (via the list) > =3D Could be ready for WGLC once Requirements and Framework are done. >=20 > Milestones > ---------- > The Chairs presented a list of proposed new dates . > - Requirements Oct 2012 > - Framework (after discussion) April 2013 > - MIBs, Applicability Statement June 2013 >=20 > Other Drafts > ------------ > ECAP Requirements (Alberto Retona) > - This draft is from rtwg, its goal is to optimise power consumption > in the network while maintaining an acceptable service level. >=20 > Green Usage MIB (Satoru Izumi) > - A tiny MIB providing energy state information for various devices >=20 > Nanogrids (Bruce Nordham) > - No time for this, alas. Please read the draft >=20 > --=20 > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From Minoru.Teraoka@jp.yokogawa.com Thu Aug 2 15:14:48 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA3121E80A0 for ; Thu, 2 Aug 2012 15:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRfi1W4L-ZPn for ; Thu, 2 Aug 2012 15:14:47 -0700 (PDT) Received: from zns001-0m9001.yokogawa.co.jp (zns001-0m9001.yokogawa.co.jp [203.174.79.138]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7D721E8090 for ; Thu, 2 Aug 2012 15:14:46 -0700 (PDT) Received: from zns001-0m9001.yokogawa.co.jp (localhost.localdomain [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.13.8/8.13.8) with ESMTP id q72MEgBn014034; Fri, 3 Aug 2012 07:14:42 +0900 Received: from zex001-0m9026.jp.ykgw.net (zex001-0m9026.jp.ykgw.net [10.0.11.15]) by zns001-0m9001.yokogawa.co.jp (8.13.8/8.13.8) with ESMTP id q72MEgcl014031; Fri, 3 Aug 2012 07:14:42 +0900 Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9026.jp.ykgw.net ([10.0.11.15]) with mapi; Fri, 3 Aug 2012 07:14:42 +0900 From: To: , Date: Fri, 3 Aug 2012 07:14:41 +0900 Thread-Topic: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt Thread-Index: AQHNX0MUsD8/DD8mNE6B4Tg4arITD5cjx/sQgCNv8lE= Message-ID: <92A5C8A0221B31479EB7913C528ACC59017DA2DC1FD5@EXMAIL01.jp.ykgw.net> References: <20120711085632.3934.80262.idtracker@ietfa.amsl.com>, <852AF0ED49D9F24BBBFA1B4DEEBE3BA402D2E6@xmb-rcd-x08.cisco.com> In-Reply-To: <852AF0ED49D9F24BBBFA1B4DEEBE3BA402D2E6@xmb-rcd-x08.cisco.com> Accept-Language: en-US, ja-JP Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, ja-JP Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:14:48 -0000 Hi Mouli, We are trying to implement EMAN monitoring MIB and are having difficulty. In eoEnergyTable, there are two indices, eoEnergyParametersIndex and eoEnergyCollectionStartTime. The indices are needed to show which parameters and when it started and ended. At present, syntax of eoEnergyCollectionStartTime is TimeTicks. In this case, in order for NMS to acquire information, it is necessary to guess the value of the index. Although I am not an expert in MIB, I think that certain regularity is required for the index. eoEnergyTable OBJECT-TYPE SYNTAX SEQUENCE OF EoEnergyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists Energy Object energy measurements. Entries in this table are only created if the corresponding value of object eoPowerMeasurementCaliber is active(2), i.e., if the power is actually metered." ::= { energyObjectMibObjects 5 } eoEnergyEntry OBJECT-TYPE SYNTAX EoEnergyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing energy measurements." INDEX { eoEnergyParametersIndex, eoEnergyCollectionStartTime } ::= { eoEnergyTable 1 } EoEnergyEntry ::= SEQUENCE { eoEnergyCollectionStartTime TimeTicks, eoEnergyConsumed Integer32, eoEnergyProduced Integer32, eoEnergyNet Integer32, eoEnergyUnitMultiplier UnitMultiplier, eoEnergyAccuracy Integer32, eoEnergyMaxConsumed Integer32, eoEnergyMaxProduced Integer32, eoEnergyDiscontinuityTime TimeStamp } eoEnergyCollectionStartTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of seconds" MAX-ACCESS not-accessible STATUS current DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized, as specified in the sysUpTime [RFC3418]. This object is useful for reference of interval periods for which the energy is measured." ::= { eoEnergyEntry 1 } Best regards, Minoru -- Minoru Teraoka Yokogawa Electric Corporation ________________________________________ From: eman-bounces@ietf.org [eman-bounces@ietf.org] On Behalf Of Mouli Chandramouli (moulchan) [moulchan@cisco.com] Sent: Wednesday, July 11, 2012 6:04 PM To: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt Hello all, An updated draft of the Power and Energy Monitoring MIB has been submitted. The modifications in this version are: - the use of eoMeterCapabilities object which can be useful to quickly infer the capabilities of an "energy object". - closing the open issues that were discussed at IETF EMAN WG - terminology definitions deferred to EMAN-FRAMEWORK Please let us know if you have questions. Thanks Brad, Juergen, Thomas, Benoit and Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Wednesday, July 11, 2012 2:27 PM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Energy Management Working Group of the IETF. Title : Power and Energy Monitoring MIB Author(s) : Mouli Chandramouli Brad Schoening Juergen Quittek Thomas Dietz Benoit Claise Filename : draft-ietf-eman-energy-monitoring-mib-03.txt Pages : 81 Date : 2012-07-11 Abstract: This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-eman-energy-monitoring-mib-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman ----- CONFIDENTIAL: This e-mail may contain information that is confidential or otherwise protected from disclosure and intended only for the party to whom it is addressed. If you are not the intended recipient, please notify the sender by return and delete this e-mail. You are hereby formally advised that any unauthorized use, disclosure or copying of this email is strictly prohibited and may be unlawful. From jparello@cisco.com Thu Aug 2 15:31:46 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B86E21F8B1F for ; Thu, 2 Aug 2012 15:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.448 X-Spam-Level: X-Spam-Status: No, score=-11.448 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXEWPezSE+Fl for ; Thu, 2 Aug 2012 15:31:43 -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 1A4E621F8B20 for ; Thu, 2 Aug 2012 15:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30379; q=dns/txt; s=iport; t=1343946703; x=1345156303; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=orAxouLLkwdO3fGwQbF0eyMUJA4ly2hymOJprrimpJc=; b=bG1NThqEmyq8hqaV5nOsNApz6tuUnGhf7fOBANRjaI9IXtaHgB7+jCui TUoO3pOA4lilVVUClrOa4YTZeOlBxyFp/Ff7xmUFMbgZhnP4Vr7a4mo3N 7j/N8TcrE8mEHXeQwx3hu3FbipObh2M7bbywFdezYNvsKNt+MBOEZa7Pi c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwFAI3/GlCtJXHA/2dsb2JhbABFqCyIEQGIXYEHgiABAQECAhIBBzsTAwYWAgIBGQMBAg0UBwcbFxQDAQMCCAIEExkBAgaHawuceI1EkwIEhXeFTxoBhglgA5VHgRSJaoMpgWaCX4FYBw X-IronPort-AV: E=Sophos;i="4.77,703,1336348800"; d="scan'208,217";a="105025341" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 02 Aug 2012 22:31:35 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q72MVYKu020328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 2 Aug 2012 22:31:34 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.228]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 17:31:34 -0500 From: "John Parello (jparello)" To: "eman@ietf.org" Thread-Topic: Newsletter on IEC 61850 and 61400-25 - August 2012 Thread-Index: AQHNcOlJICUGJhnGXU2VaYiF5vgOZ5dHG1KE Date: Thu, 2 Aug 2012 22:31:34 +0000 Message-ID: <92EE8368-9528-4934-AF39-0F109E844C4E@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.000 x-tm-as-result: No--56.525800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_92EE836895284934AF390F109E844C4Eciscocom_" MIME-Version: 1.0 Subject: [eman] Fwd: Newsletter on IEC 61850 and 61400-25 - August 2012 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2012 22:31:46 -0000 --_000_92EE836895284934AF390F109E844C4Eciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable FYI new release of important standards. Jp Sent from my iPad (expect ridiculous spelling mistakes) Begin forwarded message: From: Karlheinz Schwarz > Date: August 2, 2012 12:59:27 PM PDT To: > Subject: Newsletter on IEC 61850 and 61400-25 - August 2012 Dear Expert interested in Power System Automation, Smart(er) Grids, IEC 618= 50, IEC 61400-25, Please find news and helpful information about IEC 61850, related standards= , product news, help, and market developments: 1. Highlights 2. IEC Standardization 3. Make your own IEC 61850 Stack or buy from third party? 4. Training opportunities 5. IEC 61850 Blog 6. Other issues Ad 1. Highlights =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IEC 61850 Edition 1, 2, 3 and UML --------------------------------- Several parts of IEC 61850 have been improved through a maintenance process= during the recent years. New features have been added as well. The latest = development is the conversion of models to UML. What are the differences be= tween the first parts published some five to ten years ago? NettedAutomation has been asked by many organizations for help ... here are= some results: http://blog.iec61850.com/2012/08/iec-61850-edition-1-2-or-3-and-uml.html IEC 61850 for PV Inverters in Italy ----------------------------------- As you may have heard, IEC 61850 is a crucial standard for PV inverters in = Italy. The requirements of the Italian CEI 0-21 standard (use of IEC 61850 = is recommended =96 expected to be mandatory soon) will be required for new = plants as of July 01, 2012. Even for plants up to 6 kW it is required to provide an IEC 61850 interface= to the network operator! SMA has reacted on the requirements for Italian customers =85 including a = =93=85 Piggy-back that will be able to receive the IEC-61850 commands to im= plement remote shutdown and narrow the frequency limits of the inverter.=94 http://blog.iec61850.com/2012/07/iec-61850-in-italy-sma-offers-iec-61850.ht= ml New IEC 61850 Test Lab ---------------------- T=DCV S=DCD Munich (Germany) has opened its new IEC 61850 Test Lab to the p= ublic on July, 23, 2012. They have spent huge efforts in helping the indust= ry to increase the trust in the new technology. T=DCV S=DCD reported that the preparations and accreditations for their IEC= 61850 testing laboratory are now almost finalized and first tests are alre= ady underway. T=DCV S=DCD has several "inter-related" labs on one floor: IEC 61850 confor= mance & interoperability, PV Inverter test according to VDE AR 4105, securi= ty and safety. http://www.tuev-sued.de/home-en/services-by-industry/cross-sector-services/= embedded-systems/smart-grid Additional labs in other countries (Asia, ...) are under planning. Ad 2. Standardization =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D a. List of all published Parts and Drafts of IEC 61850 ------------------------------------------------------ The series IEC 61850 comprises 21 parts (8 tagged as Edition 2 and 13 tagge= d Edition 1) and 20 draft parts (projects). The list of the title and further information (like edition of each part) o= f all 41 parts (standards and work under progress) can be downloaded: http://blog.iec61850.com/2012/07/list-of-all-published-parts-and-drafts.htm= l b. List of almost all IEC 61850 Logical Nodes --------------------------------------------- A list of some 280 Logical Nodes from the following documents has been post= ed: - IEC 61850-7-4 Ed2 - IEC 61850-7-410 Ed1 - IEC 61850-7-420 Ed1 -IEC 61400-25-2 Ed1 http://blog.iec61850.com/2012/07/list-of-almost-all-iec-61850-logical.html c. Abbreviations of the standard series IEC 61850 ------------------------------------------------- Some 550 updated Abbreviations of the standard series IEC 61850 (7-1, 7-2, = 7-3, 7-4, 7-410, 7-420, =85) are listed in the following document: http://www.nettedautomation.com/standardization/IEC_TC57/WG10-12/iec61850/A= bbreviations_2012-07-21.pdf d. SGIP will migrate to SGIP 2.0 in January 2013 ------------------------------------------------ The Smart Grid Interoperability Panel (SGIP) will transition from a public-= private partnership to a self-financed, legal entity that retains a working= partnership with government early 2013. http://blog.iec61850.com/2012/07/sgip-will-migrate-to-sgip-20-in-january.ht= ml e. IEC 61850-90-14 FACTS (Flexible AC Transmission Systems) data modeling ------------------------------------------------------------------------- IEC TC 57 has published a proposal to work on FACTS: IEC TR 61850-90-14 (57/1250/DC): Communication networks and systems for power utility automation =96 Part 90-14: Using IEC 61850 for FACTS (Flexible AC Transmission Systems) da= ta modeling f.IEC TR 61850-90-5 Communication for Synchrophasors ---------------------------------------------------- The new part IEC 61850-90-5 has been officially published: Communication networks and systems for power utility automation - Part 90-5: Use of IEC 61850 to transmit synchrophasor information according to IEEE C37.118 http://blog.iec61850.com/2012/05/iec-61850-90-5-synchrophasor.html g. IEC 61850 Approved for NIST SGIP Catalog of Standards -------------------------------------------------------- The SGIP (Smart Grid Interoperability Panel) membership voted to include the IEC 61850 Standard Series into the Catalog of Standards (CoS) with approval of some 100 per cent. http://blog.iec61850.com/2012/05/iec-61850-approved-for-nist-sgip.html Ad 3. Make your own IEC 61850 Stack or buy from third party? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The interest in implementing and using IEC 61850 is growing all over. Many = companies have started to figure out how to proceed getting their IEDs spea= king IEC 61850. Experts start to get some information from the Web, talk to= friends, contact company A and B ... and are totally confused! More and mo= re companies tap our long-term experience in this area. Often experts call = me after they have made the purchase ... figuring out that the efforts to g= et a running system are huge! Today I received an email from a developer: "Until a few months ago, we use= d the IEC 61850 driver based on ... Since the beginning we had problems wit= h losing data, timestamps, etc. Frustrated with constant problems I began t= o study the protocol, ..." then he developed a simple client. Detailed analysis of the different "Stack" offerings and field experiences = is key to get what you really are looking for. There are very crucial misun= derstandings and pitfalls occurring in the decision making processes. Most = accountants look at the purchase price - but what is the life-time cost? Wh= at you need to know and understand is one of our favorite services we provi= de. NettedAutomation has assisted many IED vendors and users in the purchasing = process. Ad 4. Training opportunities =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Asian Tour ---------- T=DCV S=DCD (Germany), SystemCorp (Australia), and NettedAutomation (German= y) are conducting three 2 days hands-on training in IEC 61850 in Asia: 1. Seoul (organized by T=DCV S=DCD Korea, Korean Testing Laboratory) Day 1 =96 Sep 4th Day 2 =96 Sep 5th 2. Beijing (T=DCV S=DCD China, China EPRI) Day 1 =96 Sep 6th Day 2 =96 Sep 7th 3. Taipei (T=DCV S=DCD Taiwan, ITRI, Metrologies) Day 1 =96 Sep 10th Day 2 =96 Sep 11th Program etc: http://www.tuev-sued.de/uploads/images/1343805837957674540174/tuev-sued-iec= 61850-training-tour-2012-web.pdf Remote Conference Denver (CO, USA) ---------------------------------- Communication and Security for smarter Energy systems Conference Workshop - Sept 18.-19., 2012 Two-Day Training on Key Standards for Smart Grids and SCADA Application Domains: IEC 61850, IEC 61400-25, DNP3, and Energy Protection Day 1: IEC 61850, IEC 61400-25, DNP3 (Karlheinz Schwarz, NettedAutomation) Day 2: Energy Protection, Security, =85 (Dan Nordell, Xcel Energy) NettedAutomation has also a booth (#45) at the Remote Exhibition http://nettedautomation.com/seminars/uca/sem.html#rem2012 Frankfurt (Germany), 17.-19. October 2012 ----------------------------------------- 3 day IEC 61850/61400-25 Seminar/Hands-on Training (NettedAutomation) with several embedded Controller Development Kits (Linux, RTOS, ...), Starter Kit (Windows DDL), and several other demo software: http://nettedautomation.com/seminars/uca/sem.html#fra12-05 http://nettedautomation.com/seminars/uca/sem.html#fra12-10 Get FREE IEC 61850 Development Kit (HW and SW)- worth 1,299 Euro; NettedAutomation has scheduled the next public training course to be held in Frankfurt from 17.-19. October, 2012. As a special GIFT we offer you a free IEC 61850/61400-25 Development Kit, with an ready to go API and example application source code in C/C++ and IEC 61131/CoDeSys (the kit is included in the regular attendan= ce fee). The DK61 will be used during the course. http://blog.iec61850.com/2012/03/get-free-iec-61850-development-kit-hw.html Ad 5. IEC 61850 Blog =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Download the IEC 61850 Blog Content as single PDF Document ... contains the 656 posts from 2008 until 2012-07-21 [14.5 MB, 470+ pages DIN A4] http://www.nettedautomation.com/download/Newsletter/IEC61850-Blog_until_201= 2-07-21.pdf Subscribe to the blog: http://blog.iec61850.com/feeds/posts/default Ad 6. Other Issues =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D a. TQ IEC 61850 Powerful Embedded Controllers at the Hanover Fair The following embedded controllers have been shown at the Hanover Fair; the= interest in getting a package of a hardware piece, LINUX and with an integ= rated IEC 61850 API for servers and clients is huge: http://blog.iec61850.com/2012/04/tq-iec-61850-embedded-controllers-at.html b. IEC 61850 ready for VHP-Ready (Virtual Heat and Power Ready) Vattenfall Europe New Energy GmbH and Vattenfall Europe W=E4rme AG seem to = be ahead of many other utilities in implementing =93virtual Power Plants=94= . They have set a standard on how to use renewable energy in a virtual powe= r plant. The information exchange is realized with two IEC TC 57 standards:= IEC 60870-5-104 (Fernwirktechnik) and IEC 61850-7-420 (DER). http://blog.iec61850.com/2012/04/iec-61850-ready-for-vhp-ready-virtual.html Hope you enjoyed the newsletter and got useful information for your work. If you have any question contact us please. Best Regards, Karlheinz Schwarz NettedAutomation GmbH Im Eichbaeumle 108 76139 Karlsruhe Germany Phone +49-721-684844 Fax +49-721-679387 karlheinz.schwarz@nettedautomation.com http://www.nettedautomation.com http://blog.iec61850.com -------------------------------------------------------------------------- You are registered with following e-mail address: jparello@cisco.com To unregister from the list please click here: -------------------------------------------------------------------------- --_000_92EE836895284934AF390F109E844C4Eciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
FYI new release of important standards.

Jp


Sent from my iPad 
(expect ridiculous spelling mistakes) 

Begin forwarded message:

From: Karlheinz Schwarz <newsletter@nettedautomation.com>
Date: August 2, 2012 12:59:27 PM PDT
To: <jparello@cisco.com= >
Subject: Newsletter on IEC 61850 and 61400-25 - August 2012
Dear Expert interested in Power System Automation, Smart(er) Gri= ds, IEC 61850, IEC 61400-25,

Please find news and helpful information about IEC 61850, related sta= ndards, product news, help, and market developments:

1. Highlights
2. IEC Standardization
3. Make your own IEC 61850 Stack or buy from third party?
4. Training opportunities
5. IEC 61850 Blog
6. Other issues

Ad 1. Highlights
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IEC 61850 Edition 1, 2, 3 and UML
---------------------------------
Several parts of IEC 61850 have been improved through a maintenance p= rocess during the recent years. New features have been added as well. The l= atest development is the conversion of models to UML. What are the differen= ces between the first parts published some five to ten years ago?

NettedAutomation has been asked by many organizations for help ... he= re are some results:

http://blog.iec61850.com/2012/08/iec-61850-edition-1-2-or-3= -and-uml.html

IEC 61850 for PV Inverters in Italy
-----------------------------------
As you may have heard, IEC 61850 is a crucial standard for PV inverte= rs in Italy. The requirements of the Italian CEI 0-21 standard (use of IEC = 61850 is recommended =96 expected to be mandatory soon) will be required fo= r new plants as of July 01, 2012.

Even for plants up to 6 kW it is required to provide an IEC 61850 int= erface to the network operator!

SMA has reacted on the requirements for Italian customers =85 includi= ng a =93=85 Piggy-back that will be able to receive the IEC-61850 commands = to implement remote shutdown and narrow the frequency limits of the inverte= r.=94

http://blog.iec61850.com/2012/07/iec-61850-in-italy-sm= a-offers-iec-61850.html

New IEC 61850 Test Lab
----------------------
T=DCV S=DCD Munich (Germany) has opened its new IEC 61850 Test Lab to= the public on July, 23, 2012. They have spent huge efforts in helping the = industry to increase the trust in the new technology.

T=DCV S=DCD reported that the preparations and accreditations for the= ir IEC 61850 testing laboratory are now almost finalized and first tests ar= e already underway.

T=DCV S=DCD has several "inter-related" labs on one floor: = IEC 61850 conformance & interoperability, PV Inverter test according to= VDE AR 4105, security and safety.

http://www.tuev-sued.de/home-= en/services-by-industry/cross-sector-services/embedded-systems/smart-grid

Additional labs in other countries (Asia, ...) are under planning.


Ad 2. Standardization
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

a. List of all published Parts and Drafts of IEC 61850
------------------------------------------------------
The series IEC 61850 comprises 21 parts (8 tagged as Edition 2 and 13= tagged Edition 1)
and 20 draft parts (projects).

The list of the title and further information (like edition of each p= art) of all 41 parts (standards and work under progress) can be downloaded:=

http://blog.iec61850.com/2012/07/list-of-all-published-= parts-and-drafts.html

b. List of almost all IEC 61850 Logical Nodes
---------------------------------------------
A list of some 280 Logical Nodes from the following documents has bee= n posted:
- IEC 61850-7-4 Ed2
- IEC 61850-7-410 Ed1
- IEC 61850-7-420 Ed1
-IEC 61400-25-2 Ed1

http://blog.iec61850.com/2012/07/list-of-almost-all-iec-6= 1850-logical.html

c. Abbreviations of the standard series IEC 61850
-------------------------------------------------
Some 550 updated Abbreviations of the standard series IEC 61850 (7-1,= 7-2, 7-3, 7-4, 7-410, 7-420, =85) are listed in the following document:

http://www.nettedautomation.c= om/standardization/IEC_TC57/WG10-12/iec61850/Abbreviations_2012-07-21.pdf

d. SGIP will migrate to SGIP 2.0 in January 2013
------------------------------------------------
The Smart Grid Interoperability Panel (SGIP) will transition from a p= ublic-private partnership to a self-financed, legal entity that retains a w= orking partnership with government early 2013.

http://blog.iec61850.com/2012/07/sgip-will-migrate-to-= sgip-20-in-january.html

e. IEC 61850-90-14 FACTS (Flexible AC Transmission Systems) data mode= ling
---------------------------------------------------------------------= ----
IEC TC 57 has published a proposal to work on FACTS:
IEC TR 61850-90-14 (57/1250/DC):
Communication networks and systems for power utility automation =96 <= /span>
Part 90-14: Using IEC 61850 for FACTS (Flexible AC Transmission Syste= ms) data modeling

f.IEC TR 61850-90-5 Communication for Synchrophasors
----------------------------------------------------
The new part IEC 61850-90-5 has been officially published:

Communication networks and systems for power utility automation -
Part 90-5: Use of IEC 61850 to transmit synchrophasor information
according to IEEE C37.118

http://blog.iec61850.com/2012/05/iec-61850-90-5-synchrophasor.htm= l

g. IEC 61850 Approved for NIST SGIP Catalog of Standards
--------------------------------------------------------
The SGIP (Smart Grid Interoperability Panel) membership voted to incl= ude
the IEC 61850 Standard Series into the Catalog of Standards (CoS) wit= h
approval of some 100 per cent.

http://blog.iec61850.com/2012/05/iec-61850-approved-for-nist-= sgip.html


Ad 3. Make your own IEC 61850 Stack or buy from third party? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The interest in implementing and using IEC 61850 is growing all over.= Many companies have started to figure out how to proceed getting their IED= s speaking IEC 61850. Experts start to get some information from the Web, t= alk to friends, contact company A and B ... and are totally confused! More and more companies tap our long= -term experience in this area. Often experts call me after they have made t= he purchase ... figuring out that the efforts to get a running system are h= uge!

Today I received an email from a developer: "Until a few months = ago, we used the IEC 61850 driver based on ... Since the beginning we had p= roblems with losing data, timestamps, etc. Frustrated with constant problem= s I began to study the protocol, ..." then he developed a simple client.

Detailed analysis of the different "Stack" offerings and fi= eld experiences is key to get what you really are looking for. There are ve= ry crucial misunderstandings and pitfalls occurring in the decision making = processes. Most accountants look at the purchase price - but what is the life-time cost? What you need to know and understa= nd is one of our favorite services we provide.

NettedAutomation has assisted many IED vendors and users in the purch= asing process.

Ad 4. Training opportunities
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Asian Tour
----------
T=DCV S=DCD (Germany), SystemCorp (Australia), and NettedAutomation (= Germany)
are conducting three 2 days hands-on training in IEC 61850 in Asia:

1. Seoul (organized by T=DCV S=DCD Korea, Korean Testing Laboratory)<= /span>
Day 1 =96 Sep 4th
Day 2 =96 Sep 5th

2. Beijing (T=DCV S=DCD China, China EPRI)
Day 1 =96 Sep 6th
Day 2 =96 Sep 7th

3. Taipei (T=DCV S=DCD Taiwan, ITRI, Metrologies)
Day 1 =96 Sep 10th
Day 2 =96 Sep 11th

Program etc:
http://www.tuev-sued.de/= uploads/images/1343805837957674540174/tuev-sued-iec61850-training-tour-2012= -web.pdf

Remote Conference Denver (CO, USA)
----------------------------------
Communication and Security for smarter Energy systems Conference Work= shop -
Sept 18.-19., 2012
Two-Day Training on Key Standards for Smart Grids and SCADA Application Domains: IEC 61850, IEC 61400-25, DNP3, and Energy Protec= tion
Day 1: IEC 61850, IEC 61400-25, DNP3 (Karlheinz Schwarz, NettedAutoma= tion)
Day 2: Energy Protection, Security, =85 (Dan Nordell, Xcel Energy)

NettedAutomation has also a booth (#45) at the Remote Exhibition
http://nettedautomation.com/seminars/uca/sem.html#rem2012

Frankfurt (Germany), 17.-19. October 2012
-----------------------------------------
3 day IEC 61850/61400-25 Seminar/Hands-on Training (NettedAutomation)=
with several embedded Controller Development Kits (Linux, RTOS, ...),=
Starter Kit (Windows DDL), and several other demo software:
http://nettedautomation.com/seminars/uca/sem.html#fra12-05
http://nettedautomation.com/seminars/uca/sem.html#fra12-10

Get FREE IEC 61850 Development Kit (HW and SW)- worth 1,299 Euro;
NettedAutomation has scheduled the next public training course
to be held in Frankfurt from 17.-19. October, 2012.
As a special GIFT we offer you a free IEC 61850/61400-25 Development = Kit,
with an ready to go API and example application source code in C/C++ and IEC 61131/CoDeSys (the kit is included in the re= gular attendance fee).
The DK61 will be used during the course.

http://blog.iec61850.com/2012/03/get-free-iec-61850-deve= lopment-kit-hw.html

Ad 5. IEC 61850 Blog
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Download the IEC 61850 Blog Content as single PDF Document ... contai= ns the
656 posts from 2008 until 2012-07-21 [14.5 MB, 470+ pages DIN A4]=

http://www.nettedautomation.com/download/News= letter/IEC61850-Blog_until_2012-07-21.pdf

Subscribe to the blog:
http://blog.= iec61850.com/feeds/posts/default

Ad 6. Other Issues
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
a. TQ IEC 61850 Powerful Embedded Controllers at the Hanover Fair

The following embedded controllers have been shown at the Hanover Fai= r; the interest in getting a package of a hardware piece, LINUX and with an= integrated IEC 61850 API for servers and clients is huge:

http://blog.iec61850.com/2012/04/tq-iec-61850-embedded-co= ntrollers-at.html

b. IEC 61850 ready for VHP-Ready (Virtual Heat and Power Ready)

Vattenfall Europe New Energy GmbH and Vattenfall Europe W=E4rme AG se= em to be ahead of many other utilities in implementing =93virtual Power Pla= nts=94. They have set a standard on how to use renewable energy in a virtua= l power plant. The information exchange is realized with two IEC TC 57 standards: IEC 60870-5-104 (Fernwirktechnik= ) and IEC 61850-7-420 (DER).

http://blog.iec61850.com/2012/04/iec-61850-ready-for-vhp= -ready-virtual.html


Hope you enjoyed the newsletter and got useful information for your w= ork.

If you have any question contact us please.


Best Regards,

Karlheinz Schwarz
NettedAutomation GmbH
Im Eichbaeumle 108
76139 Karlsruhe
Germany

Phone +49-721-684844
Fax   +49-721-679387
karlheinz.s= chwarz@nettedautomation.com
http://www.nettedautomati= on.com

http://blog.iec61850.com





---------------------------------------------------------------------= -----
You are registered with following e-mail address:
jparello@cisco.com To unregister from the list please click here:
<http://newsletter.schwarz-interactive.de/?= e=3Djparello%40cisco.com&n=3D1208022152>
---------------------------------------------------------------------= -----




--_000_92EE836895284934AF390F109E844C4Eciscocom_-- From bclaise@cisco.com Fri Aug 3 13:08:53 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C1121F8DD4 for ; Fri, 3 Aug 2012 13:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.518 X-Spam-Level: X-Spam-Status: No, score=-10.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wft5n3SLeSFK for ; Fri, 3 Aug 2012 13:08:51 -0700 (PDT) Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com [171.68.227.119]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDC921F8DC3 for ; Fri, 3 Aug 2012 13:08:49 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q73K8iOX021031; Fri, 3 Aug 2012 13:08:44 -0700 (PDT) Received: from [10.21.73.242] ([10.21.73.242]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q73K8hxK012748; Fri, 3 Aug 2012 13:08:43 -0700 (PDT) Message-ID: <501C2FCB.6000301@cisco.com> Date: Fri, 03 Aug 2012 13:08:43 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "John Parello (jparello)" References: <501AC690.2010309@auckland.ac.nz> <7C80A18B-C956-447F-9505-4F752225E4E4@cisco.com> In-Reply-To: <7C80A18B-C956-447F-9505-4F752225E4E4@cisco.com> Content-Type: multipart/alternative; boundary="------------040605030300040702060401" Cc: "eman@ietf.org" Subject: Re: [eman] DRAFT minutes for Vancouver 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, 03 Aug 2012 20:08:53 -0000 This is a multi-part message in MIME format. --------------040605030300040702060401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, See inline. > See inline... > > Sent from my iPad > (expect ridiculous spelling mistakes) > > On Aug 2, 2012, at 11:27 AM, "Nevil Brownlee" wrote: > >> Hi all: >> >> Here are my draft-00 minutes from our meeting yesterday. >> Please send me corrections, suggestions for improvements, etc. >> >> Cheers, Nevil >> >> >> DRAFT-00 Minutes of the EMAN meeting at IETF 84 in Vancouver >> Scribes: Nevil Brownlee & ? >> Co-chairs: Bruce Nordman & Nevil Brownlee >> >> Legend >> ------ >> >> [AR] = Alberto Retona >> [BC] = Benoit Claise >> [BN] = Bruce Nordman >> [DR] = Dan Romascanu >> [GK] = Georgios Karigianis >> [JP] = John Parello >> [MC] = Mouli Chandramouli >> >> Terminology draft >> ----------------- >> Presented by Jon Parello. >> - We use Entity = 'Device or Component' >> - Compared EMAN terminology with ASHRAE 201p >> They use Asset to describe 'Device or Component.' >> EMAN should use 'Entity,' to be consistent with Entity MIB [DR] >> - ASHRAE use 'Nameplate Power' >> EMAN should use 'Manufacture Rating' > correction of above it was should add manufacturer rating to the nameplate definition > - Benoit asked for clarification on interfaces so that they dont seem to be for connecting components >> = The terminology is nearly all moved into the Requirements and >> Framework drafts. >> >> Requirements for Energy Management -08 >> -------------------------------------- >> Presented by Juergen Quittek (via Skype) >> - Made changes suggested since IETF-83 >> - Open issues: >> + Reporting of device info - "what info for which device(s)?" >> . Report for devices, components and interfaces? [JP] >> . Report for objects in Entity MIB [DR] >> = Use the Entity MIB > John - at mic in our implementations we keep the same model for interfaces, components and devices. And thatbdesign should be in modelsmnot requirements. That keeps it simple to implement. Dan seconded in his comments at mic as this is what entity does. >> - 'Phasor measurements' had been discussed on the list, should these >> be included in Requirements? [GK] >> Little support at the meeting, continue on list. >> - Need to add a requirement for windowing of measurements, >> as discussed on the list [MC] >> = The authors will publish one more revision, then we will start >> its WG Last Call. >> >> Energy Management Framework -05 >> ------------------------------- >> Presented by John Parello >> - Added 'reference topology and guidelines' for power sources, >> metering, proxies and aggregation >> - Open items >> . Edit pass: authors to check each section, and decide whether it >> should me kept/trimmed/moved/deleted >> . Check to see that draft's UML matches that in latest Monitoring MIB >> + States and Levels >> . ASHRAE uses 'curtailment levels,' should we? >> . The draft lists levels from several other organisations; >> should we set out an 'EMAN levels' list? [JP, AR] >> = Meeting was strongly in favour of this; discussion will >> continue on list >> * Our AD [BC] pointed out that we need to track issues more carefully, >> so that we don't revisit an issue once it's been closed. >> Chairs (Nevil, since BN is a document author) will so this using >> the DataTracker > -Alvarado from rtwg asked for a reccomended set of levels. Asked if EMAN could be indicated as the prefered. > -We discussed John asked the floor for discussion and it concluded that we will add that to draft. > -The chairs will send a note to the printer working group to ask if we should add their levels to the planned IANA regiatry for inclusion. >> = New revision needed, WGLC once all issues are closed. >> >> Energy-aware Networks and Devices MIB -06 >> ----------------------------------------- >> Presented by John Parello. >> - Textual Convention added for EnergyRelations >> - Now compatible with object in Entity MIBv4 >> - Open issues >> + Persistence of objects (when they're power-cycled or moved) >> = Objects that can change should be represented by objects in >> Entity MIBv4, that's enough [DR] >> = New version once Requirements draft is frozen. >> >> Entity MIBv4 -01 >> ---------------- >> New draft written by Mouli Chandramouli, Presented by Dan Romascanu. >> - Identifies devices using the Energy-Aware MIB >> - Open Issue >> + Need a compact UUID for entPhysicalUris >> . Assume that devices comply with RFC 4122 [DR] >> - This is an initial version of the MIB, comments welcome on list >> - Is EMAN the right wg to produce this MIB? >> = Yes, Chairs will ask AD to add it to EMAN charter. My notes read: add a new MIB oid specifically for UUID, instead of reusing the ENTITY-MIB URI OID repeat that there is persistence, even if it's implicit from RFC4122 IANA considerations to be added for the new registry Regards, Benoit >> >> >> Power and Energy Monitoring MIB -03 >> ----------------------------------- >> Presented by John Parello (for Mouli Chandramouli). >> - Complete, now waiting until Requirements and Framework are complete >> - Could Printer MIB be included? Support for this in meting. >> >> Battery MIB -05 >> --------------- >> Presented by Juergen Quittek. >> - Five open issues, need feedback from list! >> . Authors will make suggestions >> = Waiting on Entity MIBv4 >> >> Applicability Statement -01 >> --------------------------- >> Presented by Bruce Nordman. >> - Open issues from IETF-83 now closed >> - Use Cases and Related Standards sections almost complete >> . [BN. JP] have sent comments on ASHRAE 201p to the list; >> need EMAN folk to consider these and comment on the list >> . Could Implementation Guidelines be in this draft? >> Not yet, we need some implementation experience [BC] >> . Could other use cases be added? [GK] >> Yes, please send text to authors (via the list) >> = Could be ready for WGLC once Requirements and Framework are done. >> >> Milestones >> ---------- >> The Chairs presented a list of proposed new dates . >> - Requirements Oct 2012 >> - Framework (after discussion) April 2013 >> - MIBs, Applicability Statement June 2013 >> >> Other Drafts >> ------------ >> ECAP Requirements (Alberto Retona) >> - This draft is from rtwg, its goal is to optimise power consumption >> in the network while maintaining an acceptable service level. >> >> Green Usage MIB (Satoru Izumi) >> - A tiny MIB providing energy state information for various devices >> >> Nanogrids (Bruce Nordham) >> - No time for this, alas. Please read the draft >> >> -- >> --------------------------------------------------------------------- >> Nevil Brownlee Computer Science Department | ITS >> Phone: +64 9 373 7599 x88941 The University of Auckland >> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand >> _______________________________________________ >> 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 > > --------------040605030300040702060401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

See inline.
See inline...

Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Aug 2, 2012, at 11:27 AM, "Nevil Brownlee" <n.brownlee@auckland.ac.nz> wrote:


Hi all:

Here are my draft-00 minutes from our meeting yesterday.
Please send me corrections, suggestions for improvements, etc.

Cheers, Nevil


DRAFT-00 Minutes of the EMAN meeting at IETF 84 in Vancouver
Scribes: Nevil Brownlee & ?
Co-chairs: Bruce Nordman & Nevil Brownlee

Legend
------

[AR] = Alberto Retona
[BC] = Benoit Claise
[BN] = Bruce Nordman
[DR] = Dan Romascanu
[GK] = Georgios Karigianis
[JP] = John Parello
[MC] = Mouli Chandramouli

Terminology draft
-----------------
Presented by Jon Parello.
- We use Entity = 'Device or Component'
- Compared EMAN terminology with ASHRAE 201p
   They use Asset to describe 'Device or Component.'
   EMAN should use 'Entity,' to be consistent with Entity MIB [DR]
- ASHRAE use 'Nameplate Power'
   EMAN should use 'Manufacture Rating'

correction of above it was should add manufacturer rating to the nameplate definition
- Benoit asked for clarification on interfaces so that they dont seem to be for connecting components

= The terminology is nearly all moved into the Requirements and
 Framework drafts.

Requirements for Energy Management -08
--------------------------------------
Presented by Juergen Quittek (via Skype)
- Made changes suggested since IETF-83
- Open issues:
  + Reporting of device info - "what info for which device(s)?"
    . Report for devices, components and interfaces? [JP]
    . Report for objects in Entity MIB [DR]
    = Use the Entity MIB

John - at mic in our implementations we keep the same model for interfaces, components and devices. And thatbdesign should be in modelsmnot requirements. That keeps it simple to implement. Dan seconded in his comments at mic as this is what entity does. 

- 'Phasor measurements' had been discussed on the list, should these
   be included in Requirements? [GK]
 Little support at the meeting, continue on list.
- Need to add a requirement for windowing of measurements,
   as discussed on the list [MC]
= The authors will publish one more revision, then we will start
 its WG Last Call.

Energy Management Framework -05
-------------------------------
Presented by John Parello
- Added 'reference topology and guidelines' for power sources,
 metering, proxies and aggregation
- Open items
 . Edit pass: authors to check each section, and decide whether it
     should me kept/trimmed/moved/deleted
 . Check to see that draft's UML matches that in latest Monitoring MIB
 + States and Levels
   . ASHRAE uses 'curtailment levels,' should we?
   . The draft lists levels from several other organisations;
     should we set out an 'EMAN levels' list? [JP, AR]
     = Meeting was strongly in favour of this; discussion will
       continue on list
 * Our AD [BC] pointed out that we need to track issues more carefully,
   so that we don't revisit an issue once it's been closed.
   Chairs (Nevil, since BN is a document author) will so this using
   the DataTracker

-Alvarado from rtwg asked for a reccomended set of levels. Asked if EMAN could be indicated as the prefered. 
     -We discussed John  asked the floor for discussion and it concluded that we will add that to draft.
-The chairs will send a note to the printer working group to ask if we should add their levels to the planned IANA regiatry for inclusion.

= New revision needed, WGLC once all issues are closed.

Energy-aware Networks and Devices MIB -06
-----------------------------------------
Presented by John Parello.
- Textual Convention added for EnergyRelations
- Now compatible with object in Entity MIBv4
- Open issues
 + Persistence of objects (when they're power-cycled or moved)
   = Objects that can change should be represented by objects in
     Entity MIBv4, that's enough [DR]
= New version once Requirements draft is frozen.

Entity MIBv4 -01
----------------
New draft written by Mouli Chandramouli, Presented by Dan Romascanu.
- Identifies devices using the Energy-Aware MIB
- Open Issue
 + Need a compact UUID for entPhysicalUris
   . Assume that devices comply with RFC 4122 [DR]
- This is an initial version of the MIB, comments welcome on list
- Is EMAN the right wg to produce this MIB?
= Yes, Chairs will ask AD to add it to EMAN charter.
My notes read:

add a new MIB oid specifically for UUID, instead of reusing the ENTITY-MIB URI OID

repeat that there is persistence, even if it's implicit from RFC4122

IANA considerations to be added for the new registry

Regards, Benoit


Power and Energy Monitoring MIB -03
-----------------------------------
Presented by John Parello (for Mouli Chandramouli).
- Complete, now waiting until Requirements and Framework are complete
- Could Printer MIB be included?  Support for this in meting.

Battery MIB -05
---------------
Presented by Juergen Quittek.
- Five open issues, need feedback from list!
 . Authors will make suggestions
= Waiting on Entity MIBv4

Applicability Statement -01
---------------------------
Presented by Bruce Nordman.
- Open issues from IETF-83 now closed
- Use Cases and Related Standards sections almost complete
 . [BN. JP] have sent comments on ASHRAE 201p to the list;
   need EMAN folk to consider these and comment on the list
 . Could Implementation Guidelines be in this draft?
   Not yet, we need some implementation experience [BC]
 . Could other use cases be added? [GK]
   Yes, please send text to authors (via the list)
= Could be ready for WGLC once Requirements and Framework are done.

Milestones
----------
The Chairs presented a list of proposed new dates .
- Requirements                    Oct 2012
- Framework (after discussion)  April 2013
- MIBs, Applicability Statement  June 2013

Other Drafts
------------
ECAP Requirements (Alberto Retona)
- This draft is from rtwg, its goal is to optimise power consumption
   in the network while maintaining an acceptable service level.

Green Usage MIB (Satoru Izumi)
- A tiny MIB providing energy state information for various devices

Nanogrids (Bruce Nordham)
- No time for this, alas.  Please read the draft

-- 
---------------------------------------------------------------------
Nevil Brownlee                    Computer Science Department | ITS
Phone: +64 9 373 7599 x88941             The University of Auckland
FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand
_______________________________________________
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

--------------040605030300040702060401-- From hiroto.ogaki@alaxala.com Sun Aug 5 18:26:20 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E6F21F8577 for ; Sun, 5 Aug 2012 18:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqBawjnvkzYx for ; Sun, 5 Aug 2012 18:26:20 -0700 (PDT) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by ietfa.amsl.com (Postfix) with ESMTP id F21C721F84F2 for ; Sun, 5 Aug 2012 18:26:19 -0700 (PDT) Received: from mlsv2.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 1E37733CC8; Mon, 6 Aug 2012 10:26:18 +0900 (JST) Received: from mfilter05.hitachi.co.jp by mlsv2.hitachi.co.jp (8.13.1/8.13.1) id q761QI65005761; Mon, 6 Aug 2012 10:26:18 +0900 Received: from vshuts2.hitachi.co.jp (vshuts2.hitachi.co.jp [10.201.6.71]) by mfilter05.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id q761QGtk013919; Mon, 6 Aug 2012 10:26:17 +0900 X-AuditID: b753bd60-92cf1ba000004f2e-92-501f1d385922 Received: from gmml01.itg.hitachi.co.jp (unknown [158.213.165.31]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id C42528B0392; Mon, 6 Aug 2012 10:26:16 +0900 (JST) Received: from [127.0.0.1] by gmml01.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id q761QGa8024250; Mon, 6 Aug 2012 10:26:16 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: , From: Date: Mon, 6 Aug 2012 10:25:47 +0900 References: <20120711085632.3934.80262.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA402D2E6@xmb-rcd-x08.cisco.com> Priority: normal Importance: normal X400-Content-Identifier: X501F1D0D00000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml031208061025342J8] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 01:26:20 -0000 Hi, Mouli Thank you for updating your draft. Now, we have a problem implementing EMAN monitoring MIB. In your draft, eoEnergyDiscontinuityTime is defined as the value of SysUpTime on the most recent occasion at which one or more of this entity's energy consumption counters suffered a discontinuity. But, we are confused which following case is applied to eoEnergyDiscontinuityTime. 1. sysUpTime at which one of the energy consumption counters is deleted because network management portion of the system is re-initialized. 2. sysUpTime at which eoEnergyTable is deleted by setting up the eoEnergyParametersStatus to destroy(1) or notInService(2). 3. sysUpTime at which one of the energy consumption counters is wrapped around. 4. other Please let us know and add to the document. eoEnergyDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime [RFC3418] on the most recent occasion at which any one or more of this entity's energy counters in this table suffered a discontinuity: eoEnergyConsumed, eoEnergyProduced or eoEnergyNet. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value." ::= { eoEnergyEntry 9 } Best regards, Hiroto -- Hiroto Ogaki Alaxala Networks Corp. >Hello all, > >An updated draft of the Power and Energy Monitoring MIB has been submitted. > >The modifications in this version are: > > - the use of eoMeterCapabilities object which can be useful to quickly infer the capabilities of an "energy object". > - closing the open issues that were discussed at IETF EMAN WG > - terminology definitions deferred to EMAN-FRAMEWORK > >Please let us know if you have questions. > >Thanks >Brad, Juergen, Thomas, Benoit and Mouli > > >-----Original Message----- >From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >Sent: Wednesday, July 11, 2012 2:27 PM >To: i-d-announce@ietf.org >Cc: eman@ietf.org >Subject: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Energy Management Working Group of the IETF. > > Title : Power and Energy Monitoring MIB > Author(s) : Mouli Chandramouli > Brad Schoening > Juergen Quittek > Thomas Dietz > Benoit Claise > Filename : draft-ietf-eman-energy-monitoring-mib-03.txt > Pages : 81 > Date : 2012-07-11 > >Abstract: > This document defines a subset of the Management Information > Base (MIB) for power and energy monitoring of devices. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-03 > >A diff from previous version is available at: >http://tools.ietf.org/rfcdiff?url2=draft-ietf-eman-energy-monitoring-mib-03 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman > From n.brownlee@auckland.ac.nz Tue Aug 28 20:07:12 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B7221F845E for ; Tue, 28 Aug 2012 20:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqg3TAkSrdwx for ; Tue, 28 Aug 2012 20:07:10 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA6F021F8464 for ; Tue, 28 Aug 2012 20:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1346209630; x=1377745630; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=ECs9rinG4uhGWPuEAy4I/MMzBzcP2OfxMjb233g8QQI=; b=MoMFBUjqYzNsf9/ywdu1zgcQoxM05Ixw+LvPmowXmAjVzsTrYAE8RzQd Q2Emq6zvELgWOD1d98SVFe0NXsrbNgYs3pH/8v7mMMJ11iyKQvpIPbQrB 6tjnA9LbQOntqOF7H/ow6D+zX+0729d+7CwaluOqWRxb53xbCiWQXj264 w=; X-IronPort-AV: E=Sophos;i="4.80,332,1344168000"; d="scan'208";a="142056309" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 29 Aug 2012 15:07:04 +1200 Message-ID: <503D8758.9070009@auckland.ac.nz> Date: Wed, 29 Aug 2012 15:07:04 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: eman@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eman] Minutes of Vancouver 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: Wed, 29 Aug 2012 03:07:12 -0000 Hi all: Catching up after Vancouver, here's the final version of the minutes, including all corrections received to date. Cheers, Nevil Minutes of the EMAN meeting at IETF 84 in Vancouver Scribes: Nevil Brownlee Co-chairs: Bruce Nordman & Nevil Brownlee Legend ------ [AR] = Alvaro Retona [GK] = Georgios Karigianis [BC] = Benoit Claise [JP] = John Parello [BN] = Bruce Nordman [MC] = Mouli Chandramouli [DR] = Dan Romascanu Terminology draft ----------------- Presented by Jon Parello. - We use Entity = 'Device or Component' - Compared EMAN terminology with ASHRAE 201p They use Asset to describe 'Device or Component.' EMAN should use 'Entity,' to be consistent with Entity MIB [DR] - ASHRAE use 'Nameplate Power' EMAN should add 'Manufacturer Rating' to the Nameplate definition - We need to clarify 'interfaces' so that they dont seem to be for connecting components [BC] = The terminology is nearly all moved into the Requirements and Framework drafts. Requirements for Energy Management -08 -------------------------------------- Presented by Juergen Quittek (via Skype) - Made changes suggested since IETF-83 - Open issues: + Reporting of device info - "what info for which device(s)?" . Report for devices, components and interfaces? [JP] . Report for objects in Entity MIB [DR] = Use the Entity MIB, so that interfaces, components and devices are treated in the same way [DR] - 'Phasor measurements' had been discussed on the list, should these be included in Requirements? [GK] . Little support at the meeting, continue on list. - Need to add a requirement for windowing of measurements, as discussed on the list [MC] - We need to keep the same model for interfaces, components and devices. That design should be in models, not requirements - that keeps it simple to implement [JP, DR] = The authors will publish one more revision, then we will start its WG Last Call. Energy Management Framework -05 ------------------------------- Presented by John Parello - Added 'reference topology and guidelines' for power sources, metering, proxies and aggregation - Open items . Edit pass: authors to check each section, and decide whether it should me kept/trimmed/moved/deleted . Check to see that draft's UML matches that in latest Monitoring MIB + States and Levels . ASHRAE uses 'curtailment levels,' should we? . The draft lists levels from several other organisations; should we set out an 'EMAN levels' list? [JP, AR] = Meeting was strongly in favour of this, with the EMAN levels indicated as the preferred set . Chairs to ask the printer working group to ask whether we should add their levels to the planned IANA registry * Our AD [BC] pointed out that we need to track issues more carefully, so that we don't revisit an issue once it's been closed. Chairs (Nevil, since BN is a document author) will do this using the DataTracker = New revision needed, WGLC once all issues are closed. Energy-aware Networks and Devices MIB -06 ----------------------------------------- Presented by John Parello. - Textual Convention added for EnergyRelations - Now compatible with object in Entity MIBv4 - Open issues + Persistence of objects (when they're power-cycled or moved) = Objects that can change should be represented by objects in Entity MIBv4, that's enough [DR] = New version once Requirements draft is frozen. Entity MIBv4 -01 ---------------- New draft written by Mouli Chandramouli, Presented by Dan Romascanu. - Identifies devices using the Energy-Aware MIB - Open Issue + Need a compact UUID for entPhysicalUris . Assume that devices comply with RFC 4122 [DR] - This is an initial version of the MIB, comments welcome on list - Is EMAN the right wg to produce this MIB? = Yes, Chairs will ask AD to add it to EMAN charter. . add a new MIB oid specifically for UUID, instead of reusing the ENTITY-MIB URI OID . repeat that there is persistence, even if it's implicit from RFC4122 . IANA considerations to be added for the new registry Power and Energy Monitoring MIB -03 ----------------------------------- Presented by John Parello (for Mouli Chandramouli). - Complete, now waiting until Requirements and Framework are complete - Could Printer MIB be included? Support for this in meting. Battery MIB -05 --------------- Presented by Juergen Quittek. - Five open issues, need feedback from list! . Authors will make suggestions = Waiting on Entity MIBv4 Applicability Statement -01 --------------------------- Presented by Bruce Nordman. - Open issues from IETF-83 now closed - Use Cases and Related Standards sections almost complete . [BN. JP] have sent comments on ASHRAE 201p to the list; need EMAN folk to consider these and comment on the list . Could Implementation Guidelines be in this draft? Not yet, we need some implementation experience [BC] . Could other use cases be added? [GK] Yes, please send text to authors (via the list) = Could be ready for WGLC once Requirements and Framework are done. Milestones ---------- The Chairs presented a list of proposed new dates . - Requirements Oct 2012 - Framework (after discussion) April 2013 - MIBs, Applicability Statement June 2013 Other Drafts ------------ ECAP Requirements (Alberto Retona) - This draft is from rtwg, its goal is to optimise power consumption in the network while maintaining an acceptable service level. Green Usage MIB (Satoru Izumi) - A tiny MIB providing energy state information for various devices Nanogrids (Bruce Nordham) - No time for this, alas. Please read the draft -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From bnordman@lbl.gov Thu Aug 30 21:11:33 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113DB21F8473 for ; Thu, 30 Aug 2012 21:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.795 X-Spam-Level: X-Spam-Status: No, score=-5.795 tagged_above=-999 required=5 tests=[AWL=0.181, 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 QmnNXwWBaxhd for ; Thu, 30 Aug 2012 21:11:32 -0700 (PDT) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 58E3621F8427 for ; Thu, 30 Aug 2012 21:11:32 -0700 (PDT) X-Ironport-SBRS: 4.7 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0CAOw4QFDRVdQsk2dsb2JhbABCAw6CPK92AYhMCCIBAQEBCQkLCRQEI4IhAQEEEgJlEAsEBwM4IhIBBQEcBhMbB4drnWQJA549iwUbg0WDIQOIT40IgRSNJz6DSVo X-IronPort-AV: E=Sophos;i="4.80,345,1344236400"; d="scan'208";a="84269532" Received: from mail-vb0-f44.google.com ([209.85.212.44]) by ironport4.lbl.gov with ESMTP; 30 Aug 2012 21:11:30 -0700 Received: by vbbez10 with SMTP id ez10so3120249vbb.31 for ; Thu, 30 Aug 2012 21:11:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=SYOFmtcmpD+iiRCq5v1u9tlxpAQGkZcEUA1wj60RCqU=; b=P5j/ge+AKAJZn25gDM32n/9BKJgF/LOMSn433sfKYxwUjrMiaFDPu2jyJDBaPNaNUv RaqKv72B6Pc6ZpfvBDbv2NJfjr7+TLW92FXmEoR4qOC6BE5L3ajL/+pSndH9ZuWDDxK+ 8ge4NXCG/GILQfLr4wh0tvRhmSRVIeBPOQWPZ8Ld/FRQ0FBZGFCxKE597oF3CnRfKS3R OEzNHhceUkK6zFaqNzgKv0mCQj/moV0IKL0uY5XFcjlU56cQ91/DdHv0qeZ6NN1z6anA ThSWcD+8kiwKuT9/+9XsN/77P/fIiM64x5d8WKH/DeC/Bzuy+06ppObl3g6d12Z0wjMK QAZA== MIME-Version: 1.0 Received: by 10.58.84.198 with SMTP id b6mr796128vez.10.1346386290564; Thu, 30 Aug 2012 21:11:30 -0700 (PDT) Received: by 10.58.125.73 with HTTP; Thu, 30 Aug 2012 21:11:30 -0700 (PDT) In-Reply-To: <503D8758.9070009@auckland.ac.nz> References: <503D8758.9070009@auckland.ac.nz> Date: Thu, 30 Aug 2012 21:11:30 -0700 Message-ID: From: Bruce Nordman To: Nevil Brownlee Content-Type: multipart/alternative; boundary=047d7b86c7f6945d1f04c887fc98 X-Gm-Message-State: ALoCoQlcBlwcSYZmDA1EP08xX45gr/gV/SOb6+izQzMJpcOOzArOP2rXBAw2EllhVyJLBxpegsEY Cc: eman@ietf.org Subject: Re: [eman] Minutes of Vancouver 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, 31 Aug 2012 04:11:33 -0000 --047d7b86c7f6945d1f04c887fc98 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 28, 2012 at 8:07 PM, Nevil Brownlee wrote: > > ... > > Energy Management Framework -05 > ------------------------------**- > Presented by John Parello > ... > + States and Levels > . ASHRAE uses 'curtailment levels,' should we? > . The draft lists levels from several other organisations; > should we set out an 'EMAN levels' list? [JP, AR] > = Meeting was strongly in favour of this, with the > EMAN levels indicated as the preferred set > . Chairs to ask the printer working group to ask whether we > should add their levels to the planned IANA registry > During the meeting I didn't want to derail the discussion on this but the "EMAN levels" I understood to be power levels distinct from the power state sets we have been discussing. Since no other power levels have been proposed, I think we can simply list them as "the" set of power levels - since they will be the only ones they are EMAN and clearly preferred. This seems to be a great solution. Also, I did confer with the printer working group and they would like their power state set added to the ones to the other power state sets that IANA sets up. --Bruce (as contributor) -- *Bruce Nordman* Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --047d7b86c7f6945d1f04c887fc98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 28, 2012 at 8:07 PM, Nevil B= rownlee <n.brownlee@auckland.ac.nz> wrote:

...

Energy Management Framework -05
-------------------------------
Presented by John Parello
...
=A0 + States and Levels
=A0 =A0 . ASHRAE uses 'curtailment levels,' should we?
=A0 =A0 . The draft lists levels from several other organisations;
=A0 =A0 =A0 should we set out an 'EMAN levels' list? [JP, AR]
=A0 =A0 =A0 =3D Meeting was strongly in favour of this, with the
=A0 =A0 =A0 =A0 EMAN levels indicated as the preferred set
=A0 =A0 . Chairs to ask the printer working group to ask whether we
=A0 =A0 =A0 =A0 should add their levels to the planned IANA registry

During the meeting I didn't want to de= rail the discussion
on this but the "EMAN levels" I understood= to be power
levels distinct from the power state sets we have been
discussing.=A0 Si= nce no other power levels have been
proposed, I think we can simply list= them as "the"
set of power levels - since they will be the on= ly ones
they are EMAN and clearly preferred.=A0 This seems
to be a great solutio= n.

Also, I did confer with the printer working group and they
wou= ld like their power state set added to the ones to the
other power state= sets that IANA sets up.

--Bruce (as contributor)

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

--047d7b86c7f6945d1f04c887fc98--