From B.Hedstrom@CableLabs.com Fri Aug 2 07:47:49 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DB021E8099 for ; Fri, 2 Aug 2013 07:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 3+wZeSlj6FiL for ; Fri, 2 Aug 2013 07:47:45 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id BBEB521E804C for ; Fri, 2 Aug 2013 07:47:45 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r72Elfpp023762; Fri, 2 Aug 2013 08:47:41 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 02 Aug 2013 08:47:41 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Fri, 2 Aug 2013 08:47:41 -0600 From: Brian Hedstrom To: "John Parello (jparello)" , Juergen Quittek Thread-Topic: [eman] review of draft-ietf-eman-framework-08 Thread-Index: Ac6MJkmDnQoFslRFT++xegCmeGxTPAAeG3iAALwhTQA= Date: Fri, 2 Aug 2013 14:47:41 +0000 Message-ID: In-Reply-To: <362176F4-8EE9-4CE7-8CD7-C00F2EDBB84E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <909F7479BA50034BBDFF830E0F5B8C96@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "eman@ietf.org" Subject: Re: [eman] review of draft-ietf-eman-framework-08 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 14:47:50 -0000 The UML simply specifies the Information Model, that is, the data or information that flows throughout the system. The interface where the data flows can be defined as the interface between the EnMS and the Network Layer, or more generally, the Network Management Layer and the Network Layer. It can also be between the Network Management Layer and the Business and Service Management Layer. Information is modeled with Class diagrams and a data dictionary. This is a static view of the information/data in the system. Business Processes and Business Process Workflows define those tasks which drive the need for information and data flow. These can be captured via Use Cases/User Stories, Sequence Diagrams, BPMN diagrams, etc. Can someone provide me an example of what an Information Model in pseudocode would look like? Why can't we stick to a standardized model of UML? Thanks, Brian Hedstrom Senior Architect, Business & Operational Support Systems CableLabs, Inc. 858 Coal Creek Circle Louisville, CO 80027 Direct: 303.661.3829 eFax: 303.664.8120 Google+: brian.hedstrom Skype IM: brian.hedstrom b.hedstrom@cablelabs.com =20 On 7/29/13 9:00 AM, "John Parello (jparello)" wrote: >Hi Juergen, > >I was about to send a detailed reply, but how about we just meet up and >go over the draft at a keyboard and work it through. > >I'm free anytime tomorrow and Thursday. >Jp > > >Sent from my iPad=20 >(expect ridiculous spelling mistakes) > >On Jul 29, 2013, at 8:40 AM, "Juergen Quittek" wrote: > >> Dear all, >>=20 >> It may not be common for a co-author to comment on a draft he >>contributed to, but since I commented the individual ER framework draft, >>I want to also comment on the WG's EMAN framework draft. \ >>=20 >> Here are my high-level comments on the new version -08 of >>draft-ietf-eman-framework. Detailed comments will follow in a separate >>message. >>=20 >>=20 >> The draft is improving, particularly in the direction of getting a >>cleaner structure, more consistency, and less redundant concepts and >>text. Still, further improvement in these directions seems to be >>desirable to me, particularly towards simplification. >>=20 >> The new structure starts with explaining specifics of energy management >>(compared to management tasks that we use to have) and then introduces >>an abstraction for energy management that models managed entities, their >>properties and attributes, monitoring and control. On top of this >>relationships are introduced. I wonder is relationships should not be >>introduced before discussing monitoring and control. >>=20 >> Then the draft contains a UML (or UML-like) model for all information >>elements used in the sections before, and helpful examples that explain >>how to use the model. It is debatable whether or not the model including >>data types should be contained in a framework draft or it should rather >>be in a separate document. >>=20 >> With this structure, the draft is much easier to read and to understand >>than previous versions. >>=20 >>=20 >> The biggest problem that I still have with the draft is that it rather >>describes how to build an Energy Management System (EnMS) than what >>needs to be on the wire or on the managed entities. Two examples >>illustrate this: >> 1. Concepts are introduced based on software-engineering aspects rather >>than on aspects describing the physical reality. An example is the >>Energy Object for which the draft explains: "An Energy Object is an >>abstract class that contains the base attributes for Energy Management." >>This may be a nice guideline for implementing it, but is not exactly >>what I want to understand the real world behind it. >> 2. The draft seems to propose that concepts and structures that in my >>opinion could be hidden in the EnMS get pushed down to the managed >>entities. The draft requests that many things that today are modeled in >>the management systems are visible at the devices. One example out of >>several is the request to write relations down to the devices >>(potentially beyond need): "In some situations, it is not possible [for >>the device] to discover the energy object relationships, and they must >>be set by an EnMS or administrator." I think it is OK if the EnMS knows >>them. No need to write them to the device. Similar considerations >>concern context-related information. >>=20 >> Without stating this anywhere explicitly, the draft is focusing on >>building management. Is this the dominant use case? Many statements in >>the draft are obviously relevant for building management and need a >>"translation" to energy management of other kinds of units. An example >>out of several is the definition of 'Importance': "An Energy Object can >>provide an importance value in the range of 1 to 100 to help rank a >>device's use or relative value to the site." What is a site? What if >>there is none? >>=20 >> I see room for improvement in Section 4.8 where recommendations for >>relationships are given. Here the draft over-specifies how an EnMS is >>implemented and what how an EnMS should work internally. >>=20 >> As conclusion: there is a big improvement. The draft is moving towards >>the right direction, but still some way to go. >>=20 >> I look forward to a vivid discussion. >>=20 >> Cheers, >> Juergen >>=20 >>=20 >>=20 >>=20 >>=20 >> -- >> Juergen Quittek quittek@neclab.eu Tel: +49 6221 4342-115 >> General Manager http://www.neclab.eu Fax: +49 6221 4342-155 >> Network Research Division, NEC Europe Ltd. >> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany >>=20 >>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman From luchuk@snmp.com Wed Aug 7 07:03:04 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7108F21E811F for ; Wed, 7 Aug 2013 07:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 lBagTlMahez1 for ; Wed, 7 Aug 2013 07:02:59 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id D7B2521E8117 for ; Wed, 7 Aug 2013 07:02:58 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA18050; Wed, 7 Aug 2013 10:02:56 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id KAA08004; Wed, 7 Aug 2013 10:00:25 -0400 (EDT) Date: Wed, 7 Aug 2013 10:00:25 -0400 (EDT) From: Alan Luchuk Message-Id: <201308071400.KAA08004@adminfs.snmp.com> To: eman@ietf.org Subject: [eman] [EMAN-AWARE] and [EMAN-MON] implementation status information X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Aug 2013 14:03:04 -0000 Hello all, Benoit asked for information about SNMP Research's EMAN prototype in a format suitable for inclusion in an Implementation Status Section of the [EMAN-AWARE] and [EMAN-MON] drafts. The following information was sent in a private E-mail, and Benoit suggested sharing it on the the EMAN WG E-mail list. I hope it provides useful information to the WG. For [EMAN-AWARE] and [EMAN-MON]: Source: SNMP Research, Inc., http://www.snmp.com/ Maturity: Prototype based upon early drafts of the MIBs. We anticipate updating it to more recent documents as development schedules allow. Coverage: Code was generated to implement all MIB objects in the ENTITY-MIB (Version 4), the ENERGY-OBJECT-CONTEXT-MIB, the ENERGY-OBJECT-MIB, the POWER-CHARACTERISTICS-MIB, and the BATTERY-MIB. Simulated instrumentation values were added to model a PC connected to a network, one use scenario described in section 2.3 of the Energy Management Applicability Statement. In a separate BATTERY-MIB simulation, instrumentation values were added to simulate a pair of continously discharging/recharging batteries. The simulated values include: From the ENTITY-MIB: - Objects in the entPhysicalTable; - Objects in the entLastChangeTime object; From the ENERGY-OBJECT-CONTEXT-MIB: - Objects in the eoTable; - Objects in the eoRelationTable; From the ENERGY-OBJECT-MIB: - Objects in the eoMeterCapabilitiesTable; - Objects in the eoPowerTable; - Objects in the eoPowerStateTable; - Objects in the eoEnergyParametersTable; - Objects in the eoEnergyTable; From the POWER-CHARACTERISTICS-MIB: - Objects in the eoACPwrCharacteristicsTable; From the BATTERY-MIB: - Objects in the batteryTable; Implementation experience: The documents are implementable. Comments: Technical comments about the ENERGY-OBJECT-CONTEXT-MIB, the ENERGY-OBJECT-MIB, and the BATTERY-MIB were submitted to the EMAN Working Group E-mail list. These should be available in the list archive. Licensing: Proprietary, royalty licensing Contact: Alan Luchuk, luchuk at snmp.com Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From ietf-ipr@ietf.org Tue Aug 6 10:10:43 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AD021F9C34; Tue, 6 Aug 2013 10:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 l1zR6mltJ5jq; Tue, 6 Aug 2013 10:10:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F31121F9E5B; Tue, 6 Aug 2013 10:10:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: bclaise@cisco.com, jparello@cisco.com, quittek@netlab.nec.de, brad.schoening@verizon.net X-Test-IDTracker: no X-IETF-IDTracker: 4.61 Message-ID: <20130806171035.6331.51432.idtracker@ietfa.amsl.com> Date: Tue, 06 Aug 2013 10:10:35 -0700 X-Mailman-Approved-At: Wed, 07 Aug 2013 13:54:38 -0700 Cc: eman@ietf.org, ipr-announce@ietf.org Subject: [eman] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-eman-framework-08 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:10:44 -0000 Dear Benoit Claise, John Parello, Juergen Quittek, Brad Schoening: An IPR disclosure that pertains to your Internet-Draft entitled "Energy Management Framework" (draft-ietf-eman-framework) was submitted to the IETF Secretariat on 2013-07-31 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2161/). The = title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-em= an- framework-08.""); The IETF Secretariat From ietf-ipr@ietf.org Tue Aug 6 10:52:08 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FBD21E8093; Tue, 6 Aug 2013 10:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 zTrgdbXMsRpz; Tue, 6 Aug 2013 10:52:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4329521E8090; Tue, 6 Aug 2013 10:52:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: quittek@neclab.eu, rolf.winter@neclab.eu, Thomas.Dietz@neclab.eu, bclaise@cisco.com, moulchan@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 4.70 Message-ID: <20130806175207.29308.91808.idtracker@ietfa.amsl.com> Date: Tue, 06 Aug 2013 10:52:07 -0700 X-Mailman-Approved-At: Wed, 07 Aug 2013 13:54:44 -0700 Cc: eman@ietf.org, ipr-announce@ietf.org Subject: [eman] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-eman-requirements-14 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:52:09 -0000 Dear Juergen Quittek, Rolf Winter, Thomas Dietz, Benoit Claise, Mouli Chand= ramouli: An IPR disclosure that pertains to your Internet-Draft entitled "Requireme= nts for Energy Management" (draft-ietf-eman-requirements) was submitted to the = IETF Secretariat on 2013-07-31 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2162/). The = title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-em= an- requirements-14.""); The IETF Secretariat From jparello@cisco.com Thu Aug 8 10:32:19 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FF521F9FCA for ; Thu, 8 Aug 2013 10:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 dgV2BWARuHij for ; Thu, 8 Aug 2013 10:32:14 -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 6E22521F9FE5 for ; Thu, 8 Aug 2013 10:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14932; q=dns/txt; s=iport; t=1375983132; x=1377192732; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=A2BdrCBvofzT9Ck6hh6GWpVClL1vbmYK1ZVkwG4XA3Q=; b=g17tlvwFljROQa7rTODQAUUwTNxPXmkAiwYBP77sbAshGWfPNvKyk/Qh 9KLy6L9s0ym7918ehAJ7L2pZ3QkIjlyXgZyGFZfaQa8+YZDgjhk+TiNru 7k+qS7aGaaewIzk75/AzGoU7Y8ml3lbFuF8FpF5msBasBe2+szr8Q8/Qa 0=; X-Files: clip.txt : 5405 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAPLUA1KtJXG8/2dsb2JhbABYA4MGNVC+SYEaFnSCJAEBAQQBAQFrBAcMBAIBCA4DBAEBAQodBwIlCxQJCAIEAQ0FCAaIAQEMuR+OZoEEBhALCwUHAgICAwiDCXQDkBSBLZdvgxiCKg X-IronPort-AV: E=Sophos;i="4.89,840,1367971200"; d="txt'?scan'208";a="245117631" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 08 Aug 2013 17:32:11 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r78HWB3H017805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Aug 2013 17:32:11 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.165]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 8 Aug 2013 12:32:11 -0500 From: "John Parello (jparello)" To: Brian Hedstrom , Juergen Quittek Thread-Topic: [eman] review of draft-ietf-eman-framework-08 Thread-Index: AQHOjGxs3SziTSTqUUuHFJzQcazEeJmCWXOAgAlGabA= Date: Thu, 8 Aug 2013 17:32:10 +0000 Message-ID: <9C213D38848B89428F46808B16F6F08633D618@xmb-aln-x04.cisco.com> References: <362176F4-8EE9-4CE7-8CD7-C00F2EDBB84E@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [171.71.223.13] Content-Type: multipart/mixed; boundary="_002_9C213D38848B89428F46808B16F6F08633D618xmbalnx04ciscocom_" MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] review of draft-ietf-eman-framework-08 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 17:32:19 -0000 --_002_9C213D38848B89428F46808B16F6F08633D618xmbalnx04ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Brian, Thanks I agree. The IM should be agnostic to the layer it's used at. So it = could be used as a transport between devices, an interchange between mgt st= ation etc.=20 For the standardized model of UML I'm all for that. I just wanted our work = to go faster in the group and with the ascii text means of review and submi= ssion it was easier to just put plain text in the drafts. All I did was tak= e the UML and represent it as a class definition. See section 5 or attached= clip. Thanks! JP -----Original Message----- From: Brian Hedstrom [mailto:B.Hedstrom@CableLabs.com]=20 Sent: Friday, August 02, 2013 7:48 AM To: John Parello (jparello); Juergen Quittek Cc: eman@ietf.org Subject: Re: [eman] review of draft-ietf-eman-framework-08 The UML simply specifies the Information Model, that is, the data or inform= ation that flows throughout the system. The interface where the data flows= can be defined as the interface between the EnMS and the Network Layer, or= more generally, the Network Management Layer and the Network Layer. It ca= n also be between the Network Management Layer and the Business and Service= Management Layer. Information is modeled with Class diagrams and a data d= ictionary. This is a static view of the information/data in the system. Business Processes and Business Process Workflows define those tasks which = drive the need for information and data flow. These can be captured via Use= Cases/User Stories, Sequence Diagrams, BPMN diagrams, etc. Can someone provide me an example of what an Information Model in pseudocod= e would look like? Why can't we stick to a standardized model of UML? Thanks, Brian Hedstrom Senior Architect, Business & Operational Support Systems CableLabs, Inc. 858 Coal Creek Circle Louisville, CO 80027 Direct: 303.661.3829 eFax: 303.664.8120 Google+: brian.hedstrom Skype IM: brian.hedstrom b.hedstrom@cablelabs.com =20 On 7/29/13 9:00 AM, "John Parello (jparello)" wrote: >Hi Juergen, > >I was about to send a detailed reply, but how about we just meet up and=20 >go over the draft at a keyboard and work it through. > >I'm free anytime tomorrow and Thursday. >Jp > > >Sent from my iPad >(expect ridiculous spelling mistakes) > >On Jul 29, 2013, at 8:40 AM, "Juergen Quittek" wrote: > >> Dear all, >>=20 >> It may not be common for a co-author to comment on a draft he=20 >>contributed to, but since I commented the individual ER framework=20 >>draft, I want to also comment on the WG's EMAN framework draft. \ >>=20 >> Here are my high-level comments on the new version -08 of=20 >>draft-ietf-eman-framework. Detailed comments will follow in a separate=20 >>message. >>=20 >>=20 >> The draft is improving, particularly in the direction of getting a=20 >>cleaner structure, more consistency, and less redundant concepts and=20 >>text. Still, further improvement in these directions seems to be=20 >>desirable to me, particularly towards simplification. >>=20 >> The new structure starts with explaining specifics of energy=20 >>management (compared to management tasks that we use to have) and then=20 >>introduces an abstraction for energy management that models managed=20 >>entities, their properties and attributes, monitoring and control. On=20 >>top of this relationships are introduced. I wonder is relationships=20 >>should not be introduced before discussing monitoring and control. >>=20 >> Then the draft contains a UML (or UML-like) model for all information=20 >>elements used in the sections before, and helpful examples that=20 >>explain how to use the model. It is debatable whether or not the model=20 >>including data types should be contained in a framework draft or it=20 >>should rather be in a separate document. >>=20 >> With this structure, the draft is much easier to read and to=20 >>understand than previous versions. >>=20 >>=20 >> The biggest problem that I still have with the draft is that it=20 >>rather describes how to build an Energy Management System (EnMS) than=20 >>what needs to be on the wire or on the managed entities. Two examples=20 >>illustrate this: >> 1. Concepts are introduced based on software-engineering aspects=20 >>rather than on aspects describing the physical reality. An example is=20 >>the Energy Object for which the draft explains: "An Energy Object is=20 >>an abstract class that contains the base attributes for Energy Management= ." >>This may be a nice guideline for implementing it, but is not exactly=20 >>what I want to understand the real world behind it. >> 2. The draft seems to propose that concepts and structures that in my=20 >>opinion could be hidden in the EnMS get pushed down to the managed=20 >>entities. The draft requests that many things that today are modeled=20 >>in the management systems are visible at the devices. One example out=20 >>of several is the request to write relations down to the devices=20 >>(potentially beyond need): "In some situations, it is not possible=20 >>[for the device] to discover the energy object relationships, and they=20 >>must be set by an EnMS or administrator." I think it is OK if the EnMS=20 >>knows them. No need to write them to the device. Similar=20 >>considerations concern context-related information. >>=20 >> Without stating this anywhere explicitly, the draft is focusing on=20 >>building management. Is this the dominant use case? Many statements in=20 >>the draft are obviously relevant for building management and need a=20 >>"translation" to energy management of other kinds of units. An example=20 >>out of several is the definition of 'Importance': "An Energy Object=20 >>can provide an importance value in the range of 1 to 100 to help rank=20 >>a device's use or relative value to the site." What is a site? What if=20 >>there is none? >>=20 >> I see room for improvement in Section 4.8 where recommendations for=20 >>relationships are given. Here the draft over-specifies how an EnMS is=20 >>implemented and what how an EnMS should work internally. >>=20 >> As conclusion: there is a big improvement. The draft is moving=20 >>towards the right direction, but still some way to go. >>=20 >> I look forward to a vivid discussion. >>=20 >> Cheers, >> Juergen >>=20 >>=20 >>=20 >>=20 >>=20 >> -- >> Juergen Quittek quittek@neclab.eu Tel: +49 6221 4342-115 >> General Manager http://www.neclab.eu Fax: +49 6221 4342-155 >> Network Research Division, NEC Europe Ltd. >> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany >>=20 >>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman --_002_9C213D38848B89428F46808B16F6F08633D618xmbalnx04ciscocom_ Content-Type: text/plain; name="clip.txt" Content-Description: clip.txt Content-Disposition: attachment; filename="clip.txt"; size=5405; creation-date="Thu, 08 Aug 2013 17:31:17 GMT"; modification-date="Thu, 08 Aug 2013 17:31:57 GMT" Content-Transfer-Encoding: base64 IEVESVRPUidzIE5PVEU6ICBQc2V1ZG8tY29kZSB1c2VkIHVudGlsIGNvbnNlbnN1cyB0aGVuIFVN TCANCiAgICAgICAgZGlhZ3JhbSB3aWxsIGJlIHN1YnN0aXR1dGVkIA0KICAgICAgICAgDQogICAg ICAgIGNsYXNzIEVuZXJneU9iamVjdCB7IA0KICAgICAgICAgDQogICAgICAgICAgIC8vIGlkZW50 aWZpY2F0aW9uIC8gY2xhc3NpZmljYXRpb24gDQogICAgICAgICAgIGluZGV4ICAgICAgICA6IGlu dCANCiAgICAgICAgICAgaWRlbnRpZmllciAgIDogdXVpZCANCiAgICAgICAgICAgYWx0ZXJuYXRl a2V5IDogc3RyaW5nIA0KICAgICAgICAgDQogICAgICAgICAgIC8vIGNvbnRleHQgDQogICAgICAg ICAgIGRvbWFpbk5hbWUgICAgICA6IHN0cmluZyANCiAgICAgICAgICAgcm9sZSAgICAgICAgICAg IDogc3RyaW5nIA0KICAgICAgICAgICBrZXl3b3JkcyBbMC4ubl0gOiBzdHJpbmcgDQogICAgICAg ICAgIGltcG9ydGFuY2UgICAgICA6IGludCANCiAgICAgICAgIA0KICAgICAgICAgICAvLyByZWxh dGlvbnNoaXAgDQogICAgICAgICANCiAgICAgICAgICAgcmVsYXRpb25zaGlwcyBbMC4ubl0gOiBS ZWxhdGlvbnNoaXAgDQogICAgICAgICANCiAgICAgICAgICAgLy8gbWVhc3VyZW1lbnRzICANCiAg ICAgICAgICAgbmFtZXBsYXRlICAgIDogTmFtZXBsYXRlIA0KICAgICAgICAgICBwb3dlciAgICAg OiBQb3dlck1lYXN1cmVtZW50IA0KICAgICAgICAgICBlbmVyZ3kgICAgOiBFbmVyZ3lNZWFzdXJt ZW50IA0KICAgICAgICAgICBkZW1hbmQgICAgOiBEZW1hbmRNZWFzdXJlbWVudCANCiAgICAgICAg IA0KICAgICAgICAgICAvLyBjb250cm9sIA0KICAgICAgICAgICBwb3dlckNvbnRyb2wgWzAuLm5d IDogUG93ZXJTdGF0ZVNldCANCiAgICAgICAgIA0KICAgICAgICB9ICANCiAgICAgICAgIA0KICAg ICAgICBjbGFzcyBEZXZpY2UgZXh0ZW5kcyBFbmVyZ3lPYmplY3QgeyANCiAgICAgICAgICAgICAg ZW9jYXRlZ29yeSAgIDogZW51bSB7IHByb2R1Y2VyLCBjb25zdW1lciwgbWV0ZXIsIA0KICAgICAg ICBkaXN0cmlidXRvciB9ICANCiAgICAgICAgfSANCiAgICAgICAgIA0KICAgICAgICBjbGFzcyBD b21wb25lbnQgZXh0ZW5kcyBFbmVyZ3lPYmplY3QgDQogICAgICAgICAgICAgIGVvY2F0ZWdvcnkg ICA6IGVudW0geyBwcm9kdWNlciwgY29uc3VtZXIsIG1ldGVyLCANCiAgICAgICAgZGlzdHJpYnV0 b3IgfSAgDQogICAgICAgIH0gDQogICAgICAgICANCiAgICAgICAgY2xhc3NJbnRlcmZhY2UgZXh0 ZW5kcyBFbmVyZ3lPYmplY3R7IA0KICAgICAgICAgICAgICBlb0lmVHlwZSA6IGVudW0gKCBpbmxl dCwgb3V0bGV0LCBib3RofSANCiAgICAgICAgfSANCiAgICAgICAgIA0KDQogICAgICANCiAgICAg ICAgY2xhc3MgTmFtZXBsYXRlIHsgDQogICAgICAgICAgICAgIG5vbWluYWxQb3dlciA6IFBvd2Vy TWVhc3VyZW1lbnQgDQogICAgICAgICAgICAgIGRldGFpbHMgICAgICA6IFVSSSANCiAgICAgICAg fSAgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICBjbGFzcyBSZWxhdGlvbnNoaXAgeyAN CiAgICAgICAgICAgICAgcmVsYXRpb25zaGlwVHlwZSAgICA6IGVudW0geyBtZXRlcnMsIG1ldGVy ZWRieSwgcG93ZXJzLCANCiAgICAgICAgcG93ZXJlZGJ5LCBhZ2dyZWdhdGVzLCBhZ2dyZWdhdGVk YnkgfSANCiAgICAgICAgICAgICAgcmVsYXRpb25zaGlwT2JqZWN0ICA6IHV1aWQgDQogICAgICAg IH0gDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICBjbGFzcyBNZWFzdXJlbWVudCB7IA0K ICAgICAgICAgICAgICBtdWx0aXBsaWVyOiBlbnVtIHsgLTI0Li4yNH0gDQogICAgICAgICAgICAg IGNhbGliZXIgICA6IGVudW0geyBhY3R1YWwsIGVzdGltYXRlZCwgdHJ1c3RlZCwgYXNzdW1lZCB9 ICANCiAgICAgICAgICAgICAgYWNjdXJhY3kgIDogZW51bSB7IDAuLjEwMDAwfSAvLyBodW5kcmVk cyBvZiBwZXJjZW50ICANCiAgICAgICAgfSANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAg IGNsYXNzIFBvd2VyTWVhc3VyZW1lbnQgZXh0ZW5kcyBNZWFzdXJlbWVudCB7ICANCiAgICAgICAg ICAgICAgdmFsdWUgICAgICAgICAgOiBsb25nIA0KICAgICAgICAgICAgICB1bml0cyAgICAgICAg ICA6ICJXIiANCiAgICAgICAgICAgICAgcG93ZXJBdHRyaWJ1dGUgOiBQb3dlckF0dHJpYnV0ZSAN CiAgICAgICAgfSAgICAgICAgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICBjbGFzcyBF bmVyZ3lNZWFzdXJlbWVudCBleHRlbmRzIE1lYXN1cmVtZW50IHsgDQogICAgICAgICAgICAgIHN0 YXJ0VGltZSA6IHRpbWUgDQogICAgICAgICAgICAgIHVuaXRzICAgICA6ICJrV2giIA0KICAgICAg ICAgICAgICBwcm92aWRlZCAgOiBsb25nIA0KICAgICAgICAgICAgICB1c2VkICAgICAgOiBsb25n IA0KICAgICAgICAgICAgICBwcm9kdWNlZCAgOiBsb25nICAgDQogICAgICAgIH0gDQogICAgICAg ICANCiAgICAgICAgIA0KICAgICAgICBjbGFzcyBUaW1lZE1lYXN1cmVtZW50IGV4dGVuZHMgTWVh c3VyZW1lbnQgeyANCiAgICAgICAgICAgICAgc3RhcnRUaW1lICA6IHRpbWVzdGFtcCANCiAgICAg ICAgICAgICAgdmFsdWUgICAgICA6IE1lYXN1cmVtZW50IA0KICAgICAgICAgICAgICBtYXhpbXVt ICAgIDogTWVhc3VyZW1lbnQgDQogICAgICAgIH0gDQogICAgICAgICANCiAgICAgICAgIA0KICAg ICAgICBjbGFzcyBUaW1lSW50ZXJ2YWwgeyANCiAgICAgICAgICAgICAgdmFsdWUgICAgICA6IGxv bmcgDQogICAgICAgICAgICAgIHVuaXRzICAgICAgOiBlbnVtIHsgc2Vjb25kcywgbWlsaXNlY29u ZHMsLi4ufSANCiAgICAgICAgfSANCiAgICAgICAgIA0KICAgICAgDQogICAgICAgICANCiAgICAg ICAgY2xhc3MgRGVtYW5kTWVhc3VyZW1lbnQgZXh0ZW5kcyBNZWFzdXJlbWVudCB7IA0KICAgICAg ICAgICAgICBpbnRlcnZhbExlbmd0aCA6IFRpbWVJbnRlcnZhbCANCiAgICAgICAgICAgICAgaW50 ZXJ2YWwgICAgICAgOiBsb25nIA0KICAgICAgICAgICAgICBpbnRlcnZhbE1vZGUgICA6IGVudW0g eyBwZXJpb2RpYywgc2xpZGluZywgdG90YWwgfSANCiAgICAgICAgICAgICAgaW50ZXJ2YWxXaW5k b3cgOiBUaW1lSW50ZXJ2YWwgDQogICAgICAgICAgICAgIHNhbXBsZVJhdGUgICAgIDogVGltZUlu dGVydmFsIA0KICAgICAgICAgICAgICBzdGF0dXMgICAgICAgICA6IGVudW0geyBhY3RpdmUsIGlu YWN0aXZlIH0gDQogICAgICAgICAgICAgIG1lYXN1cmVtZW50c1swLi5uXSA6IFRpbWVkTWVhc3Vy ZW1lbnRzIA0KICAgICAgICB9IA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgY2xhc3Mg UG93ZXJTdGF0ZVNldCB7IA0KICAgICAgICAgICAgICBwb3dlclNldElkZW50aWZpZXIgOiBpbnQg ICANCiAgICAgICAgICAgICAgbmFtZSAgICAgICAgICAgICAgIDogc3RyaW5nIA0KICAgICAgICAg ICAgICBwb3dlclN0YXRlcyBbMC4ubl0gOiBQb3dlclN0YXRlICANCiAgICAgICAgICAgICAgb3Bl clN0YXRlICAgICAgICAgIDogaW50IA0KICAgICAgICAgICAgICBhZG1pblN0YXRlICAgICAgICAg OiBpbnQgDQogICAgICAgICAgICAgIHJlYXNvbiAgICAgICAgICAgICA6IHN0cmluZyANCiAgICAg ICAgICAgICAgY29uZmlndXJlZFRpbWUgICAgIDogdGltZXN0YW1wIA0KICAgICAgICB9IA0KICAg ICAgICAgDQogICAgICAgICANCiAgICAgICAgY2xhc3MgUG93ZXJTdGF0ZSB7IA0KICAgICAgICAg ICAgICBwb3dlclN0YXRlSWRlbnRpZmllciAgOiBpbnQgDQogICAgICAgICAgICAgIG5hbWUgICAg ICAgICAgICAgOiBzdHJpbmcgDQogICAgICAgICAgICAgIGNhcmRpbmFsaXR5ICAgICAgOiBpbnQg DQogICAgICAgICAgICAgIG1heGltdW1Qb3dlciAgICAgOiBQb3dlck1lYXN1cmVtZW50IA0KICAg ICAgICAgICAgICB0b3RhbFRpbWVJblN0YXRlIDogdGltZSANCiAgICAgICAgICAgICAgZW50cnlD b3VudCAgICAgICA6IGxvbmcgDQogICAgICAgIH0gDQogICAgICAgICANCiAgICAgICAgY2xhc3Mg UG93ZXJBdHRyaWJ1dGUgeyANCiAgICAgICAgIA0KICAgICAgICAgIC8vIGNvbnRhaW5lciBmb3Ig YXR0cmlidXRlcyANCiAgICAgICAgICAgICAgIGFjUXVhbGl0eSAgICAgIDogQUNRdWFsaXR5IA0K ICAgICAgICAgDQogICAgICAgIH0gDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICBjbGFz cyBBQ1F1YWxpdHkgeyANCiAgICAgICAgICBhY0NvbmZpZ3VyYXRpb24gOiBlbnVtIHtTTkdMLCBE RUwsV1lFfSAgDQogICAgICAgICAgYXZnVm9sdGFnZSAgIDogbG9uZyAgICANCiAgICAgICAgICBh dmdDdXJyZW50ICAgOiBsb25nICANCiAgICAgICAgICBmcmVxdWVuY3kgICAgOiBsb25nICAgDQog ICAgICAgICAgdW5pdE11bHRpcGxpZXIgIDogaW50ICANCiAgICAgICAgICBhY2N1cmFjeSAgICAg ICA6IGludCAgIA0KICAgICAgICAgIHRvdGFsQWN0aXZlUG93ZXIgICA6IGxvbmcgICANCiAgICAg ICAgICB0b3RhbFJlYWN0aXZlUG93ZXIgOiBsb25nICANCiAgICAgICAgICB0b3RhbEFwcGFyZW50 UG93ZXIgOiBsb25nICAgDQogICAgICAgICAgdG90YWxQb3dlckZhY3RvciA6IGxvbmcgDQogICAg ICAgICAgcGhhc2VzIFswLi4yXSAgOiBBQ1BoYXNlICANCiAgICAgICAgIA0KICAgICAgICAgIC8v IENvdWxkIGhhdmUgYWJzdHJhY3QgY2xhc3MgUGhhc2UgdG8gYmUgY2xlYXIgaXQncyBBQ1BoYXNl IA0KICAgICAgICBvciBvbmUgb2YgdGhlIHN1YmNsYXNzZXMgICAgICAgICAgICAgICANCiAgICAg ICAgIA0KICAgICAgICB9IA0KICAgICAgICAgDQogICAgICAgIGNsYXNzIEFDUGhhc2UgeyANCiAg ICAgICAgICBwaGFzZUluZGV4IDogbG9uZyAgDQogICAgICAgICAgYXZnQ3VycmVudCA6IGxvbmcg IA0KICAgICAgICAgIGFjdGl2ZVBvd2VyIDogbG9uZyAgIA0KICAgICAgICAgIHJlYWN0aXZlUG93 ZXIgOiBsb25nICAgDQogICAgICAgICAgYXBwYXJlbnRQb3dlciA6IGxvbmcgICANCiAgICAgICAg ICBwb3dlckZhY3RvciA6IGxvbmcgIA0KICAgICAgICB9IA0KICAgICAgICAgDQogICAgICAgIGNs YXNzIERlbFBoYXNlIGV4dGVuZHMgQUNQaGFzZSB7ICAgICAgICAgICAgICAgICANCiAgICAgICAg ICBwaGFzZVRvTmV4dFBoYXNlVm9sdGFnZSAgOiBsb25nICAgDQogICAgICAgICAgdGhkVm9sdGFn ZSA6IGxvbmcgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgdGhkQ3VycmVudCA6IGxvbmcg DQogICAgICAgIH0gDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICBjbGFzcyBXWUVQaGFz ZSBleHRlbmRzIEFDUGhhc2UgeyANCiAgICAgICAgICBwaGFzZVRvTmV1dHJhbFZvbHRhZ2UgOiBs b25nICAgDQogICAgICAgICAgdGhkQ3VycmVudCA6IGxvbmcgICAgICAgICAgICAgIA0KICAgICAg ICAgIHRoZFZvbHRhZ2UgOiBsb25nICAgICAgICAgICAgICANCiAgICAgICAgfSA= --_002_9C213D38848B89428F46808B16F6F08633D618xmbalnx04ciscocom_-- From jparello@cisco.com Thu Aug 8 10:46:14 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4CB11E8153 for ; Thu, 8 Aug 2013 10:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 Jcl61bJkAUNh for ; Thu, 8 Aug 2013 10:46:09 -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 604B211E81FD for ; Thu, 8 Aug 2013 10:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5541; q=dns/txt; s=iport; t=1375983968; x=1377193568; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oIGiht+DFyxGDp+SJisIOWVD6ioikfT7ueAZdV/STC0=; b=ZE6f7jdtT65yFBbdqEtbxHg8ZL88Kd/mtGNHg7RaYa/BLPFkR/3iI/Xy jAzQ+Mbz8uY30RH35jejUXTc2p0jJsUUBq3pLluo+n2iousGuRJ2YsbL/ qJjL3VNNWElHVnXWJjiHr79QQCEFr8SqibW4NxOszqpHi+WIAnHwPbpix A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAAbYA1KtJV2b/2dsb2JhbABbgwaBBb5JgRoWdIIkAQEBAwEOLCsNBwULAgEIIhQQMiUBAQQOBQiIAgUBuTKPagYrBwKDGHQDqTCDGIIq X-IronPort-AV: E=Sophos;i="4.89,840,1367971200"; d="scan'208";a="245151009" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 08 Aug 2013 17:46:07 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r78Hk7nc027729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Aug 2013 17:46:07 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.165]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 8 Aug 2013 12:46:06 -0500 From: "John Parello (jparello)" To: Juergen Quittek Thread-Topic: [eman] review of draft-ietf-eman-framework-08 Thread-Index: Ac6MJkmDnQoFslRFT++xegCmeGxTPAAcAweAAfG+bqA= Date: Thu, 8 Aug 2013 17:46:05 +0000 Message-ID: <9C213D38848B89428F46808B16F6F08633D639@xmb-aln-x04.cisco.com> References: <9AB93E4127C26F4BA7829DEFDCE5A6E85A384B90@DAPHNIS.office.hd> <362176F4-8EE9-4CE7-8CD7-C00F2EDBB84E@cisco.com> In-Reply-To: <362176F4-8EE9-4CE7-8CD7-C00F2EDBB84E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.223.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] review of draft-ietf-eman-framework-08 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 17:46:14 -0000 HI Juergen, Thanks so much, sorry we couldn't sync up in Berlin but the feedback is gre= at and I'll incorporate in next revision. Like the adage says you know you= 're ready when there's nothing left to remove not nothing more to add! See inline.... Jp Sent from my iPad=20 (expect ridiculous spelling mistakes)=20 On Jul 29, 2013, at 8:40 AM, "Juergen Quittek" wrote: > Dear all, >=20 > It may not be common for a co-author to comment on a draft he contributed= to, but since I commented the individual ER framework draft, I want to als= o comment on the WG's EMAN framework draft. \ >=20 > Here are my high-level comments on the new version -08 of draft-ietf-eman= -framework. Detailed comments will follow in a separate message. >=20 >=20 > The draft is improving, particularly in the direction of getting a cleane= r structure, more consistency, and less redundant concepts and text. Still,= further improvement in these directions seems to be desirable to me, part= icularly towards simplification. >=20 > The new structure starts with explaining specifics of energy management (= compared to management tasks that we use to have) and then introduces an ab= straction for energy management that models managed entities, their propert= ies and attributes, monitoring and control. On top of this relationships ar= e introduced. I wonder is relationships should not be introduced before dis= cussing monitoring and control. >=20 > Then the draft contains a UML (or UML-like) model for all information ele= ments used in the sections before, and helpful examples that explain how to= use the model. It is debatable whether or not the model including data typ= es should be contained in a framework draft or it should rather be in a sep= arate document. >=20 > With this structure, the draft is much easier to read and to understand t= han previous versions. >=20 >=20 [jp] thanks! > The biggest problem that I still have with the draft is that it rather de= scribes how to build an Energy Management System (EnMS) than what needs to = be on the wire or on the managed entities. Two examples illustrate this: > 1. Concepts are introduced based on software-engineering aspects rather t= han on aspects describing the physical reality. An example is the Energy Ob= ject for which the draft explains: "An Energy Object is an abstract class t= hat contains the base attributes for Energy Management." This may be a nice= guideline for implementing it, but is not exactly what I want to understan= d the real world behind it. [jp] Ok I think we'll have to balance between what is in management and on = the wire. I agree with Brian that the IM model should be applicable for bot= h so that a data model for wire or mgt stations could be derived from the I= M. For the real world I think we have the sections on that I'll make that c= learer. > 2. The draft seems to propose that concepts and structures that in my opi= nion could be hidden in the EnMS get pushed down to the managed entities. T= he draft requests that many things that today are modeled in the management= systems are visible at the devices. One example out of several is the requ= est to write relations down to the devices (potentially beyond need): "In s= ome situations, it is not possible [for the device] to discover the energy = object relationships, and they must be set by an EnMS or administrator." I = think it is OK if the EnMS knows them. No need to write them to the device.= Similar considerations concern context-related information. >=20 [jp] That's an interesting premise. So are you saying if a device can't det= ermine the source of the data it should not be specified? I'm not sure how = that works for analogous information things like- location for example. A = device may not be able to determine its location but that' s not hidden in = the NMS. Most modern deployments provision this on a device and the NMS get= s the information from the device. So I'm not sure why that's a restrictio= n for this IM.=20 Taking it a bit further what happens if it is only specified in an NMS. Wha= t's the interchange format between NMS'?=20 Most modern systems want a JSON or XML model of information at the NMS lay= er. So I think it's helpful to specify a model that can be used at device a= nd mgt level and the data models can restrict / label optional if they want= ed. We stated that in the new version. > Without stating this anywhere explicitly, the draft is focusing on buildi= ng management. Is this the dominant use case? Many statements in the draft = are obviously relevant for building management and need a "translation" to = energy management of other kinds of units. An example out of several is the= definition of 'Importance': "An Energy Object can provide an importance va= lue in the range of 1 to 100 to help rank a device's use or relative value = to the site." What is a site? What if there is none? >=20 [jp]OK Is the word site not general enough? By site we meant deployment - i= s that better. That would suggest in a datacenter, building etc. That's the= idea. "Context to the deployment" > I see room for improvement in Section 4.8 where recommendations for relat= ionships are given. Here the draft over-specifies how an EnMS is implemente= d and what how an EnMS should work internally.=20 >=20 [jp] Any text you think is better? Or things to delete? Thanks! Jp From ietf@quittek.at Tue Aug 13 02:17:34 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE26E21E80E1 for ; Tue, 13 Aug 2013 02:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.748 X-Spam-Level: * X-Spam-Status: No, score=1.748 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 RSHalnLabO5J for ; Tue, 13 Aug 2013 02:17:29 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id A9A7B21E80F4 for ; Tue, 13 Aug 2013 02:17:24 -0700 (PDT) Received: from [172.20.4.115] (mail.cedarbrookcenter.com [50.203.87.99]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LgNIi-1VwU2w0E20-00oINA; Tue, 13 Aug 2013 11:17:15 +0200 From: Juergen Quittek Content-Type: multipart/alternative; boundary=Apple-Mail-33CFE9E1-A844-436C-940A-04900FFD7FB4 X-Mailer: iPhone Mail (10B329) Message-Id: <373368AB-D347-4BDF-8BE0-EC2C2F3615EE@quittek.at> Date: Tue, 13 Aug 2013 02:17:10 -0700 To: eman mailing list Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-Provags-ID: V02:K0:jSV/rZFwa/rLN9Apet1xwgo4TB7s3MtuDgF35x+j5pu RuDY+2/txBfEWDFBDDgcb19a1pjch0Iv3H4d3SyzUMIQN+ugkZ ApZT1Kbe4c3DTZOkB9rArI2abvYwJP8ie7HVe5Lw2N1W0Rju3l tKjmbQm5uJiVzt2oJt3MCzJtilkfkHAIPCf8EgQ7wv6gep8Jnt zKU5NLeQsPAQjgXexYXAdYPI5Kzsls75P64Eqrn1I8+agCS1e/ Ai08L+/Lz4ghF2LAhwrW5MoSx0mKIt8MuPD+R/+UkHf8Ar8/DN C9cdXTbzPifKQzAniArX7HCO5q4iz79NnCnZzfYwH7yZN7oM2T ZkuEazbtW8lP1QEaCBDKMzdnQ7mLCa/w+V7SXWIhX Subject: [eman] eman framework issue: Do we start from a software design or do we start from the physical world? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 09:17:35 -0000 --Apple-Mail-33CFE9E1-A844-436C-940A-04900FFD7FB4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Dear all,=20 Before the IETF meeting I posted high-level comments on the new version of o= ur framework draft (draft-ietf-eman-framework-08) and on the alternative fra= mework proposal from Bruce (draft-nordman-eman-er-framework-01).=20 Now I send a series of individuals mails each focusing on a particular issue= that I found in one or the other draft. For each issue I try to point out h= ow the drafts address it and what the differences are.=20 My first point is about our very general approach to describe the eman frame= work: Do we start with describing a software design and map this to the real= world? Or do we start with describing the physical world an derive a model f= rom it? The two drafts are quite different in that respect. draft-ietf-eman-framewor= k-08 (EMAN Framework) rather develops the framework from a software model wh= ile draft-nordman-eman-er-framework-01 (ER Framework) starts from the physic= al world. Here is an example that illustrate the difference.=20 EMAN Framework section 4.2 Energy Object: > 4.2 Energy Object > An Energy Object is an abstract class that contains the base attributes fo= r Energy Management. There are three types of Energy Objects: Device, Compon= ent and Power Interface. ER Framework, section 2.5 Energy Object: > 2.5. Energy Object =20 > Devices, Power Interfaces, and Components are all Energy Objects (EOs). Th= e term "entity" in the Requirements draft generally corresponds to Energy Ob= ject. The kinds of data available for an EO depends on its type as shown in = Figure 1. This is just one example out of many similar instances that can easily be fo= und in those drafts.=20 The different choices made by the drafts result in different ways of describ= ing the framework.=20 The ER Framework describes which information is reported for an Energy Objec= t (power, state, voltage, etc.) while the EMAN framework tells us which attr= ibutes (power, state, voltage, etc) the class Energy Object has.=20 So the basic question that occurs to me is: Do we want to define our energy m= anagement framework as an object-oriented (software) model or do we want to d= escribe a view of physical systems? This would be the core question to be answered for addressing this issue.=20= Of course, in the end we need a data model for interoperable exchange of inf= ormation based on our framework.=20 But for this purpose we already have other documents. Here the candidates fo= r are MIB modules using SMI that do not support the concepts of classes and= inheritance (which also holds for YANG modules using XML).=20 : Cheers, Juergen= --Apple-Mail-33CFE9E1-A844-436C-940A-04900FFD7FB4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
= Dear all, 

Before the IETF meeting I= posted high-level comments on the new version of our framework draft (draft= -ietf-eman-framework-08) and on the alternative framework proposal from Bruc= e (draft-nordman-eman-er-framework-01). 

Now I send a series of individuals mails each focusing on a particular i= ssue that I found in one or the other draft. For each issue I try to point o= ut how the drafts address it and what the differences are. 

My first point is about our very general approach to= describe the eman framework: Do we start with describing a software design a= nd map this to the real world? Or do we start with describing the physical w= orld an derive a model from it?

The two d= rafts are quite different in that respect. draft-ietf-eman-framework-08 (EMAN Framework) rather deve= lops the framework from a software model while draft-nordman-eman-er-framework-01 (ER Framew= ork) starts from the physical world. Here is an example that illustrate the d= ifference. 

EMAN Framework sectio= n 4.2 Energy Object:
        4.2 Energy Object
An E=
nergy Object is an abstract class that contains the base=20
        attributes for Energy Management.  There are three types of=20
        Energy Objects: Device, Component and Power Interface.=

ER Framework, section 2.5 Energy Object:
2.5.  Energy Object  =

De=
vices, Power Interfaces, and Components are all Energy Objects (EOs).  The t=
erm
   "entity" in the Requirements draft generally corresponds to Energy
   Object.  The kinds of data available for an EO depends on its type as
   shown in Figure 1.
This is just one example out of many simil= ar instances that can easily be found in those drafts. 

The different choices m= ade by the drafts result in different ways of describing the framework. = ;

The ER= Framework describes which information is reported for an Energy Object (pow= er, state, voltage, etc.) while the EMAN framework tells us which attributes=  (power, state, v= oltage, etc) the c= lass Energy Object has. 

So the basic question that occurs to me is: Do we want= to define our energy management framework as an object-oriented (software) m= odel or do we want to describe a view of physical systems?

This would be the core qu= estion to be answered for addressing this issue. 

= Of course, in the end we nee= d a data model for interoperable exchange of information based on our framew= ork. 
But for this purpose we already h= ave other documents. Here the candidates for  are MIB modules using SMI= that do not support the concepts of classes and inheritance (which also holds for YANG modu= les using XML). =
:
Cheers,
    Juergen
= --Apple-Mail-33CFE9E1-A844-436C-940A-04900FFD7FB4-- From ietf@quittek.at Tue Aug 20 01:09:54 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286D511E81A3 for ; Tue, 20 Aug 2013 01:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.747 X-Spam-Level: * X-Spam-Status: No, score=1.747 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] 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 am+IBE+QBTm9 for ; Tue, 20 Aug 2013 01:09:45 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 02BE011E81EA for ; Tue, 20 Aug 2013 01:09:44 -0700 (PDT) Received: from [192.168.0.7] (24-156-3-113.npg.sta.suddenlink.net [24.156.3.113]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0M40YM-1W29Ei0hP8-00ra4b; Tue, 20 Aug 2013 10:09:42 +0200 From: Juergen Quittek Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (10B329) Message-Id: Date: Tue, 20 Aug 2013 01:09:39 -0700 To: eman mailing list Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Provags-ID: V02:K0:17YyUt4hzW/pk5UkeBtACW0ka6rhN0EHcSy0TNXWuSE 8vofr9IDDL479+tm+2JFKtu3tyCAPO5VEWk5hLWGXT76+AJQcj HGJBeOS32lEEQd5M/+UfRuKWAG4d/MHNR1xh/H3BUEPXC63aZ2 I5SLUQGmBALs0gRymq7hww6wPpZL1Ctgnd7svFsfwYWIOJeQR6 o3YBtvK9aPz2qP/98HRstTA9Nb+cj1PCnROEyWOQTCsBNeF+ZY AUhzq0xzcFOF3kKuMwgEC+XmqMmQHAo3M4a5Ao4Ke7rev6xUeB y81sz1GyawYJ53dqGyTeJsYUBu9dkdH4gvPbV7spNeowoAqrNW Wp0igMzDiLm3vIcACWSG1qhqbQm52bPXoZ0dim+5K Subject: [eman] eman framework issue: How to model a meter? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 08:09:54 -0000 Dear all,=20 Here is another framework issue: How to model metering capabilities of devic= es? Our framework draft (draft-ietf-eman-framework-08) models metering capabilit= y by categorizing devices and components into either a producer, a comsumer,= a meter, or a distributor, see pseudocode on page 43.=20 I think this approach is broken. It may be useful for modeling simple scenar= ios, but it does not work as general model.=20 There are two problems with this approach.=20 1. The either-or classification. A meter is typically not just a meter, but a= s well a consumer that consumes energy when doing it's job. A PDU that meter= s power at it's outlets is a meter and a distributor and a consumer. The sam= e holds for a PoE switch. These are not either meters or consumers, they are= meters and consumers and some of them are also distributors at the same tim= e.=20 2. The categorization as 'meter' is only available for devices and component= s, not for power interfaces. But obviously a device with metering capabiliti= es meters at (some of) its interfaces. Take the PoE switch that meters power= at some or all of its PoE outlets. It would be natural to label the power i= nterfaces at which metering capabilities are available as 'metered'. It appe= ars strange to classify the device as 'meter'.=20 The basic question here is: Do we need to model metering capability at all? = If yes, we should model it as an attribute, not as a category; and we shoul= d model it as attribute of the power interfaces as well.=20 BTW, if we model metering capability (monitoring), we should consequently mo= del circuit breaker capability (control) at power interfaces as well. Cheers, Juergen= From brads@coraid.com Tue Aug 20 10:06:14 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E517D11E8273 for ; Tue, 20 Aug 2013 10:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bpczNAoDSf7 for ; Tue, 20 Aug 2013 10:06:10 -0700 (PDT) Received: from server506.appriver.com (server506j.appriver.com [50.56.144.148]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3F011E8247 for ; Tue, 20 Aug 2013 10:05:57 -0700 (PDT) X-Note-AR-ScanTimeLocal: 8/20/2013 12:05:27 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-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-84/SG:2 8/20/2013 12:04:30 PM X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.944557 Source White X-Signature-Violations: 0-0-0-7096-c X-Note-419: 15.5998 ms. Fail:0 Chk:1343 of 1343 total X-Note: SCH-CT/SI:0-1343/SG:1 8/20/2013 12:05:12 PM X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->PRIVATE->UNITED STATES X-Note-Sending-IP: 10.242.229.139 X-Note-Reverse-DNS: X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G340 G341 G342 G343 G347 G348 G455 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 11061270; Tue, 20 Aug 2013 12:05:27 -0500 Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.218]) by HT05-E6.exg6.exghost.com ([10.242.230.112]) with mapi id 14.03.0123.003; Tue, 20 Aug 2013 12:05:22 -0500 From: Brad Schoening To: Juergen Quittek , eman mailing list Thread-Topic: [eman] eman framework issue: How to model a meter? Thread-Index: AQHOnXyszg2BALUwJE2Ri+M1j328Q5meMmYA Date: Tue, 20 Aug 2013 17:05:22 +0000 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 x-originating-ip: [50.56.144.247] x-rerouted-by-exchange: Content-Type: text/plain; charset="us-ascii" Content-ID: <53F136F82A051A42BD3D03C025858910@fwd6.exghost.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] eman framework issue: How to model a meter? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 17:06:15 -0000 Juergen, My experience has been that usually a meter was just a meter. While many devices such as PoE switches and PDUs can internally meter, we have to recognize that there is a real use case for stand-alone metering. Intelligent smart meters from vendors such as Shark, SATEC, and Crompton are but a few examples of these widely used products An ethernet switch is a device who's primary purpose is networking, but may have metering relationships. But a smart meter is a device with the primary purpose of metering. =20 =20 A common sense approach to classification should be more than adequate to distinguish between products which consume energy to provide some function, products that primarily produce energy, and products which are designed for metering. If we clarify that classification should involve the primary purpose of a device it would this address this nit? You ask "Do we need to model metering capability at all"? Yes, because smart meters, in particular sub-meters, are a key part of real time energy monitoring. Regards, Brad On 8/20/13 1:09 AM, "Juergen Quittek" wrote: >Dear all,=20 > >Here is another framework issue: How to model metering capabilities of >devices? > >Our framework draft (draft-ietf-eman-framework-08) models metering >capability by categorizing devices and components into either a producer, >a comsumer, a meter, or a distributor, see pseudocode on page 43. > >I think this approach is broken. It may be useful for modeling simple >scenarios, but it does not work as general model. > >There are two problems with this approach. > >1. The either-or classification. A meter is typically not just a meter, >but as well a consumer that consumes energy when doing it's job. A PDU >that meters power at it's outlets is a meter and a distributor and a >consumer. The same holds for a PoE switch. These are not either meters or >consumers, they are meters and consumers and some of them are also >distributors at the same time. > >2. The categorization as 'meter' is only available for devices and >components, not for power interfaces. But obviously a device with >metering capabilities meters at (some of) its interfaces. Take the PoE >switch that meters power at some or all of its PoE outlets. It would be >natural to label the power interfaces at which metering capabilities are >available as 'metered'. It appears strange to classify the device as >'meter'.=20 > >The basic question here is: Do we need to model metering capability at >all? If yes, we should model it as an attribute, not as a category; and >we should model it as attribute of the power interfaces as well. > >BTW, if we model metering capability (monitoring), we should consequently >model circuit breaker capability (control) at power interfaces as well. > >Cheers, > Juergen >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman From jparello@cisco.com Tue Aug 20 10:39:52 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B400311E80E4 for ; Tue, 20 Aug 2013 10:39:52 -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 sYCTJYgY2Lpw for ; Tue, 20 Aug 2013 10:39:44 -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 F2ECB11E810F for ; Tue, 20 Aug 2013 10:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5250; q=dns/txt; s=iport; t=1377020384; x=1378229984; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iOCc7N2LXuUU67XwT8tek8RAQRz1rlWe40Z9JhsrgkY=; b=TTZb8UHG+KX022NSncMAOOZvJCY0fa7GBefgUMHnFMZJq4x5J+Wu08eI T4QOV2MCkthF8IHkomnqV3NDebmzsYJ/ky4/8jVc/7BodxWsZ61MXtT9s 6wKE37ypAGh1thp7hT8spn6bj6fph5u7qiTc/ypi3SiPMf8aiIyBBGffr 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAJaoE1KtJV2d/2dsb2JhbABagwXAX4EkFnSCJAEBAQMBOjgHBQsCAQgYHhAyJQIEDgWICgatPI8dgQUzB4MbeQOXZZFWgxw X-IronPort-AV: E=Sophos;i="4.89,921,1367971200"; d="scan'208";a="249529805" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 20 Aug 2013 17:39:43 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7KHdhIo030133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Aug 2013 17:39:43 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.176]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Tue, 20 Aug 2013 12:39:43 -0500 From: "John Parello (jparello)" To: Brad Schoening Thread-Topic: [eman] eman framework issue: How to model a meter? Thread-Index: AQHOnXyq7tpuq+6Q/0CDBwtkFHCxz5mep8EA//+1x+I= Date: Tue, 20 Aug 2013 17:39:42 +0000 Message-ID: <5133F0CE-6966-4A20-B384-5E60587E2DF3@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] eman framework issue: How to model a meter? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 17:39:52 -0000 +1 on that Brad. The category broadly classifies the device so a mgt system can determine if= its behaving beyond its intent. For example power in the wrong direction f= rom a producer (motor or or solar panel for example) that starts to consume= . So the category attribute answered the question "is a" The power interface by their by their nature only measure power so it "is" = not a meter but "can" measure. A meter can contain power interfaces. So if you are looking for a capability first I suggest not using the word = "meter" to answer that question. What you are looking for is "measure". =20 A device is a "meter" and can "measure". An interface can "measure" but "i= s not" a meter (a meter may contain multiple power interfaces). If you use = the word "meter" there for capability then yes thats confusing but we are n= ot doing that. See inline Jp Sent from my iPad=20 (expect ridiculous spelling mistakes)=20 On Aug 20, 2013, at 10:06 AM, "Brad Schoening" wrote: > Juergen, >=20 > My experience has been that usually a meter was just a meter. While many > devices such as PoE switches and PDUs can internally meter, we have to > recognize that there is a real use case for stand-alone metering. > Intelligent smart meters from vendors such as Shark, SATEC, and Crompton > are but a few examples of these widely used products An ethernet switch > is a device who's primary purpose is networking, but may have metering > relationships. But a smart meter is a device with the primary purpose of > metering. =20 >=20 >=20 > A common sense approach to classification should be more than adequate to > distinguish between products which consume energy to provide some > function, products that primarily produce energy, and products which are > designed for metering. If we clarify that classification should involve > the primary purpose of a device it would this address this nit? >=20 > You ask "Do we need to model metering capability at all"? Yes, because > smart meters, in particular sub-meters, are a key part of real time energ= y > monitoring. >=20 > Regards, >=20 > Brad >=20 > On 8/20/13 1:09 AM, "Juergen Quittek" wrote: >=20 >> Dear all,=20 >>=20 >> Here is another framework issue: How to model metering capabilities of >> devices? >>=20 >> Our framework draft (draft-ietf-eman-framework-08) models metering >> capability by categorizing devices and components into either a producer= , >> a comsumer, a meter, or a distributor, see pseudocode on page 43. >>=20 >> I think this approach is broken. It may be useful for modeling simple >> scenarios, but it does not work as general model. >>=20 >> There are two problems with this approach. >>=20 >> 1. The either-or classification. A meter is typically not just a meter, >> but as well a consumer that consumes energy when doing it's job. A PDU >> that meters power at it's outlets is a meter and a distributor and a >> consumer. The same holds for a PoE switch. These are not either meters o= r >> consumers, they are meters and consumers and some of them are also >> distributors at the same time. >>=20 [jp] for poe switch : is a "consumer", contains power interfaces that can "= measure". A switch is certainly not a meter. I proposed "distributor" as a= nother category for pdu and/or a Poe switch. That may be clearer. The model reads well to me with a clear distinction between category and ca= pability to me. Don't see how that's broken unless you use meter as a capab= ility which I agree is wrong but we don't do that. >> 2. The categorization as 'meter' is only available for devices and >> components, not for power interfaces. But obviously a device with >> metering capabilities meters at (some of) its interfaces. Take the PoE >> switch that meters power at some or all of its PoE outlets. It would be >> natural to label the power interfaces at which metering capabilities are >> available as 'metered'. It appears strange to classify the device as >> 'meter'.=20 >>=20 [jp] you're confusing "is a" versus "can" and overloading meter in both tho= se attributes. Meter is a classification not a capability. Measuring is the= capability. >> The basic question here is: Do we need to model metering capability at >> all? If yes, we should model it as an attribute, not as a category; and >> we should model it as attribute of the power interfaces as well. >>=20 >> BTW, if we model metering capability (monitoring), we should consequentl= y >> model circuit breaker capability (control) at power interfaces as well. >>=20 [jp] sounds like you want an additional field for capabilities. We had that= in the model quite some time ago and from feedback deleted that from the M= ib and framework. Are your proposing we revisit that issue and then add cap= ability back? IMO and experience these capability type attributes need a re= gistry and then get used rather loosely when implemented. So I think it muc= h simpler to categorize devices and component broadly and then the capabili= ty is inferred from the presence of a measurement with caliber. Much simple= r. Jp= From jparello@cisco.com Tue Aug 20 10:51:52 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9018C11E811E for ; Tue, 20 Aug 2013 10:51:52 -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 RkPOetUhIsYy for ; Tue, 20 Aug 2013 10:51:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B724121F99F8 for ; Tue, 20 Aug 2013 10:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2851; q=dns/txt; s=iport; t=1377021107; x=1378230707; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XyHzlit0gI86asGIcS16IcY/652CGq0ylbzdnHIwvDU=; b=DY7R/w+VZM36eQUDGfpxC4ysDazkv1szVmqI4yhn1Y9y+7d4g6V9isV5 jsAZIjkqkiViGwPN/iVg2Frt0VjNulSaxyU2yX12udrYfoAXqlRQeAo1W ftg1/kKIeN+IdHUM9uobD+3ZnhyrB5scDNQkwKcCUKfUL5kf9SIJWa2zT k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAOSrE1KtJXG9/2dsb2JhbABagwU1wCqBJBZ0giQBAQEDAQEBATc0CwULAgEIGB4QJwslAgQOBYgKBgytNASPHYEFMweDG3kDl2WRVoMc X-IronPort-AV: E=Sophos;i="4.89,921,1367971200"; d="scan'208";a="249646442" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 20 Aug 2013 17:51:46 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7KHpkM6029815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Aug 2013 17:51:46 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.176]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 20 Aug 2013 12:51:46 -0500 From: "John Parello (jparello)" To: Brad Schoening Thread-Topic: [eman] eman framework issue: How to model a meter? Thread-Index: AQHOnXyq7tpuq+6Q/0CDBwtkFHCxz5mep8EA//+5JWQ= Date: Tue, 20 Aug 2013 17:51:45 +0000 Message-ID: <3B0EE04D-E5F5-46C9-8539-E22FBEB07CE1@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] eman framework issue: How to model a meter? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 17:51:52 -0000 >=20 > You ask "Do we need to model metering capability at all"? Yes, because > smart meters, in particular sub-meters, are a key part of real time energ= y > monitoring. >=20 Just to be clear we used "meter" is a type of device (which acknowledges yo= u other points, and if you want to model capability the value would be "mea= suring". So a "metering capability" doesn't make sense. It would be "measur= ing capability". Again we removed the capabilities attribute. After quite some years deploying these systems that distinction is second = nature for me but we should be precise. Jp > Regards, >=20 > Brad >=20 > On 8/20/13 1:09 AM, "Juergen Quittek" wrote: >=20 >> Dear all,=20 >>=20 >> Here is another framework issue: How to model metering capabilities of >> devices? >>=20 >> Our framework draft (draft-ietf-eman-framework-08) models metering >> capability by categorizing devices and components into either a producer= , >> a comsumer, a meter, or a distributor, see pseudocode on page 43. >>=20 >> I think this approach is broken. It may be useful for modeling simple >> scenarios, but it does not work as general model. >>=20 >> There are two problems with this approach. >>=20 >> 1. The either-or classification. A meter is typically not just a meter, >> but as well a consumer that consumes energy when doing it's job. A PDU >> that meters power at it's outlets is a meter and a distributor and a >> consumer. The same holds for a PoE switch. These are not either meters o= r >> consumers, they are meters and consumers and some of them are also >> distributors at the same time. >>=20 >> 2. The categorization as 'meter' is only available for devices and >> components, not for power interfaces. But obviously a device with >> metering capabilities meters at (some of) its interfaces. Take the PoE >> switch that meters power at some or all of its PoE outlets. It would be >> natural to label the power interfaces at which metering capabilities are >> available as 'metered'. It appears strange to classify the device as >> 'meter'.=20 >>=20 >> The basic question here is: Do we need to model metering capability at >> all? If yes, we should model it as an attribute, not as a category; and >> we should model it as attribute of the power interfaces as well. >>=20 >> BTW, if we model metering capability (monitoring), we should consequentl= y >> model circuit breaker capability (control) at power interfaces as well. >>=20 >> Cheers, >> Juergen >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From bnordman@lbl.gov Tue Aug 20 11:44:26 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C717F11E8260 for ; Tue, 20 Aug 2013 11:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvQB+IwSlqfm for ; Tue, 20 Aug 2013 11:44:22 -0700 (PDT) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEA711E812F for ; Tue, 20 Aug 2013 11:44:22 -0700 (PDT) X-Ironport-SBRS: 4.7 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkCAIW4E1LRVaAtk2dsb2JhbABXA4JBeVG3DohLgRwIFg4BAQEBBwsLCRQEJIIkAQEBAwEBAQFrCwULCwsNLiIFDQEFARwGE4gKBgyWXpZijx2BKAwEBxGEAwOJLY44gS2ORBYphGIc X-IronPort-AV: E=Sophos;i="4.89,921,1367996400"; d="scan'208";a="25793229" Received: from mail-pb0-f45.google.com ([209.85.160.45]) by fe1.lbl.gov with ESMTP; 20 Aug 2013 11:44:20 -0700 Received: by mail-pb0-f45.google.com with SMTP id mc17so728801pbc.4 for ; Tue, 20 Aug 2013 11:44:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/5nJpNRGJkl2Td0sa5uoH7kva0jz3szJEy/Q+i9Edd0=; b=pOS3wJUWe3tQzLiWF5sYPXWrwwHV14eVRtbqC7D1PhC/ujrbg0DlttovcioplriWPG LR9AS4nOy00Bxo95kzORLf5KY9nkvt5cwzNrmIolSEtEwDIFuok3iItQ94jFe+Cdm5cW D0l06hjiPZskA4IA4y+j7cxmwymLwfPbbohCpzX0LH0kaIXksQhJ3bwloKGKSTzzmrb/ kCIvtfQ+ED4gKwWsslbk8x7h2fWde/429LPyfBcfByUvpwX2RH0JQN7PXd7hFPjFspts llH6LzETwdwjOFQRS5BZ3KbuhDDtWhEdHVKgDtmzrIREWgCskAxba+bUvfN5o3cOMX0B Xuxg== X-Gm-Message-State: ALoCoQmewwr/FPXK/GeLcMjDt6GXQT3rqoc9revONwOloLfkzVV+kRxQyekSeocynct8BOSHj+2DKK8MTu9KCYdeX8KlV1C5RLHa7f2o/Kfb0AxwnSUOAb80hbwStJkJDGDIM3Mzq7ed X-Received: by 10.66.121.234 with SMTP id ln10mr5366502pab.20.1377024260491; Tue, 20 Aug 2013 11:44:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.121.234 with SMTP id ln10mr5366492pab.20.1377024260381; Tue, 20 Aug 2013 11:44:20 -0700 (PDT) Received: by 10.68.235.9 with HTTP; Tue, 20 Aug 2013 11:44:20 -0700 (PDT) In-Reply-To: <3B0EE04D-E5F5-46C9-8539-E22FBEB07CE1@cisco.com> References: <3B0EE04D-E5F5-46C9-8539-E22FBEB07CE1@cisco.com> Date: Tue, 20 Aug 2013 11:44:20 -0700 Message-ID: From: Bruce Nordman To: "John Parello (jparello)" Content-Type: multipart/alternative; boundary=047d7b2e100be32eea04e46571b1 Cc: eman mailing list Subject: Re: [eman] eman framework issue: How to model a meter? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 18:44:26 -0000 --047d7b2e100be32eea04e46571b1 Content-Type: text/plain; charset=ISO-8859-1 The current draft of the EMAN framework says: "A meter is a type Energy Object and any Energy Object can perform metering." This seems to indicate that devices can meter, components can meter, and power interfaces can meter. On the other hand, Juergen notes that the meter classification is not available to power interfaces. This appears to be a contradiction. It is possible to require declaring a "primary function" for a device, including whether it is a device that can only perform metering, but that seems to be an unnecessary complication and not derivative of any requirement. Juergen's point is that metering (or measuring--I defer on that choice of wording) can be simply and flexibly modeled as just a capability that any EO can have. It is unnecessary to make the Framework more complicated than that. There are plenty of additional complications that could be added that don't derive from any requirement. --Bruce On Tue, Aug 20, 2013 at 10:51 AM, John Parello (jparello) < jparello@cisco.com> wrote: > > > > > > > You ask "Do we need to model metering capability at all"? Yes, because > > smart meters, in particular sub-meters, are a key part of real time > energy > > monitoring. > > > > Just to be clear we used "meter" is a type of device (which acknowledges > you other points, and if you want to model capability the value would be > "measuring". So a "metering capability" doesn't make sense. It would be > "measuring capability". > > Again we removed the capabilities attribute. > > After quite some years deploying these systems that distinction is second > nature for me but we should be precise. > > Jp > > > > > Regards, > > > > Brad > > > > On 8/20/13 1:09 AM, "Juergen Quittek" wrote: > > > >> Dear all, > >> > >> Here is another framework issue: How to model metering capabilities of > >> devices? > >> > >> Our framework draft (draft-ietf-eman-framework-08) models metering > >> capability by categorizing devices and components into either a > producer, > >> a comsumer, a meter, or a distributor, see pseudocode on page 43. > >> > >> I think this approach is broken. It may be useful for modeling simple > >> scenarios, but it does not work as general model. > >> > >> There are two problems with this approach. > >> > >> 1. The either-or classification. A meter is typically not just a meter, > >> but as well a consumer that consumes energy when doing it's job. A PDU > >> that meters power at it's outlets is a meter and a distributor and a > >> consumer. The same holds for a PoE switch. These are not either meters > or > >> consumers, they are meters and consumers and some of them are also > >> distributors at the same time. > >> > >> 2. The categorization as 'meter' is only available for devices and > >> components, not for power interfaces. But obviously a device with > >> metering capabilities meters at (some of) its interfaces. Take the PoE > >> switch that meters power at some or all of its PoE outlets. It would be > >> natural to label the power interfaces at which metering capabilities are > >> available as 'metered'. It appears strange to classify the device as > >> 'meter'. > >> > >> The basic question here is: Do we need to model metering capability at > >> all? If yes, we should model it as an attribute, not as a category; and > >> we should model it as attribute of the power interfaces as well. > >> > >> BTW, if we model metering capability (monitoring), we should > consequently > >> model circuit breaker capability (control) at power interfaces as well. > >> > >> Cheers, > >> Juergen > >> _______________________________________________ > >> eman mailing list > >> eman@ietf.org > >> https://www.ietf.org/mailman/listinfo/eman > > > > _______________________________________________ > > eman mailing list > > eman@ietf.org > > https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --047d7b2e100be32eea04e46571b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The current draft of the EMAN framewor= k says:
=A0 "A meter is a type Energy Object and any Energy Object can perform metering."
=09
This seems to indicate that devices can meter, components can met= er, and power
interfaces can meter.=A0 On the other hand, Juergen notes = that the meter classification
is not available to power interfaces.=A0 T= his appears to be a contradiction.

It is possible to require declaring a "primary function"= ; for a device, including whether it is a
device that can only perform m= etering, but that seems to be an unnecessary complication
and not deriva= tive of any requirement.

Juergen's point is that metering (or measuring--I defer on th= at choice of wording) can be
simply and flexibly modeled as just a capab= ility that any EO can have.=A0 It is unnecessary
to make the Framework m= ore complicated than that.=A0 There are plenty of additional
complications that could be added that don't derive from any requiremen= t.

--Bruce



On Tue, Aug 20, 20= 13 at 10:51 AM, John Parello (jparello) <jparello@cisco.com> wrote:

<snip>

>
> You ask "Do we need to model metering capability at all"? = =A0Yes, because
> smart meters, in particular sub-meters, are a key part of real time en= ergy
> monitoring.
>

Just to be clear we used "meter" is a type of device (which= acknowledges you other points, and if you want to model capability the val= ue would be "measuring". So a "metering capability" doe= sn't make sense. It would be "measuring capability".

Again we removed the capabilities attribute.

After quite some years deploying these systems that distinction is second = =A0nature for me but we should be precise.

Jp



> Regards,
>
> Brad
>
> On 8/20/13 1:09 AM, "Juergen Quittek" <ietf@quittek.at> wrote:
>
>> Dear all,
>>
>> Here is another framework issue: How to model metering capabilitie= s of
>> devices?
>>
>> Our framework draft (draft-ietf-eman-framework-08) models metering=
>> capability by categorizing devices and components into either a pr= oducer,
>> a comsumer, a meter, or a distributor, see pseudocode on page 43.<= br> >>
>> I think this approach is broken. It may be useful for modeling sim= ple
>> scenarios, but it does not work as general model.
>>
>> There are two problems with this approach.
>>
>> 1. The either-or classification. A meter is typically not just a m= eter,
>> but as well a consumer that consumes energy when doing it's jo= b. A PDU
>> that meters power at it's outlets is a meter and a distributor= and a
>> consumer. The same holds for a PoE switch. These are not either me= ters or
>> consumers, they are meters and consumers and some of them are also=
>> distributors at the same time.
>>
>> 2. The categorization as 'meter' is only available for dev= ices and
>> components, not for power interfaces. But obviously a device with<= br> >> metering capabilities meters at (some of) its interfaces. Take the= PoE
>> switch that meters power at some or all of its PoE outlets. It wou= ld be
>> natural to label the power interfaces at which metering capabiliti= es are
>> available as 'metered'. It appears strange to classify the= device as
>> 'meter'.
>>
>> The basic question here is: Do we need to model metering capabilit= y at
>> all? =A0If yes, we should model it as an attribute, not as a categ= ory; and
>> we should model it as attribute of the power interfaces as well. >>
>> BTW, if we model metering capability (monitoring), we should conse= quently
>> model circuit breaker capability (control) at power interfaces as = well.
>>
>> Cheers,
>> =A0Juergen
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman



--
Bruce Nordman
La= wrence Berkeley National Laboratory
nordman.lbl.g= ov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--047d7b2e100be32eea04e46571b1-- From jparello@cisco.com Tue Aug 20 12:17:09 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0324611E8145 for ; Tue, 20 Aug 2013 12:17:09 -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 44HZp5t2pW1v for ; Tue, 20 Aug 2013 12:17:04 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 46BE121F9A7E for ; Tue, 20 Aug 2013 12:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12258; q=dns/txt; s=iport; t=1377026224; x=1378235824; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yp8GBdNhntJQbprHVRenuOAeCA555nA77pkRgCUWsbY=; b=JTfDmv8n2zLQF0+KfImgft1flqw8nRXt4rmgEmZK6mrUQAAvfPxe4Bw+ vORkMUM1rMEDtHbY3/CS94Vxvz/pgtrqeIUg0mbBDM4hUpG16AD3qOTDZ t6HdRtyU9V/jnk0SgGCsrYabHpI+QXnsc0LaVbYjspvRpJKBjmNmMraLd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAETAE1KtJV2c/2dsb2JhbABXA4JBRDW3X4hLgSYWdIIkAQEBAwEBAQFrCwULAgEIDgonBycLFBECBA4FiAoGDK0+jx2BKAwEBgEJCIMKeQOXZYEtkCmDHA X-IronPort-AV: E=Sophos;i="4.89,921,1367971200"; d="scan'208,217";a="249625455" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 20 Aug 2013 19:17:03 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7KJH2He015033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Aug 2013 19:17:02 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.176]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 20 Aug 2013 14:17:01 -0500 From: "John Parello (jparello)" To: Bruce Nordman Thread-Topic: [eman] eman framework issue: How to model a meter? Thread-Index: AQHOnXyq7tpuq+6Q/0CDBwtkFHCxz5mep8EA//+5JWSAAGKCAP//tVB9 Date: Tue, 20 Aug 2013 19:17:01 +0000 Message-ID: References: <3B0EE04D-E5F5-46C9-8539-E22FBEB07CE1@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_BB79100DBCE84D74B47B882BB92AF0E9ciscocom_" MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] eman framework issue: How to model a meter? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 19:17:09 -0000 --_000_BB79100DBCE84D74B47B882BB92AF0E9ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good catch let's change "perform metering" to "perform measuring" then yes = go with simple. So broad categorization of the device/component and continue to leave compl= ex capability modeling out. Jp Sent from my iPad (expect ridiculous spelling mistakes) On Aug 20, 2013, at 11:44 AM, "Bruce Nordman" > wrote: The current draft of the EMAN framework says: "A meter is a type Energy Object and any Energy Object can perform meteri= ng." This seems to indicate that devices can meter, components can meter, and po= wer interfaces can meter. On the other hand, Juergen notes that the meter clas= sification is not available to power interfaces. This appears to be a contradiction. It is possible to require declaring a "primary function" for a device, incl= uding whether it is a device that can only perform metering, but that seems to be an unnecessary = complication and not derivative of any requirement. Juergen's point is that metering (or measuring--I defer on that choice of w= ording) can be simply and flexibly modeled as just a capability that any EO can have. It = is unnecessary to make the Framework more complicated than that. There are plenty of addi= tional complications that could be added that don't derive from any requirement. --Bruce On Tue, Aug 20, 2013 at 10:51 AM, John Parello (jparello) > wrote: > > You ask "Do we need to model metering capability at all"? Yes, because > smart meters, in particular sub-meters, are a key part of real time energ= y > monitoring. > Just to be clear we used "meter" is a type of device (which acknowledges yo= u other points, and if you want to model capability the value would be "mea= suring". So a "metering capability" doesn't make sense. It would be "measur= ing capability". Again we removed the capabilities attribute. After quite some years deploying these systems that distinction is second = nature for me but we should be precise. Jp > Regards, > > Brad > > On 8/20/13 1:09 AM, "Juergen Quittek" > wrote: > >> Dear all, >> >> Here is another framework issue: How to model metering capabilities of >> devices? >> >> Our framework draft (draft-ietf-eman-framework-08) models metering >> capability by categorizing devices and components into either a producer= , >> a comsumer, a meter, or a distributor, see pseudocode on page 43. >> >> I think this approach is broken. It may be useful for modeling simple >> scenarios, but it does not work as general model. >> >> There are two problems with this approach. >> >> 1. The either-or classification. A meter is typically not just a meter, >> but as well a consumer that consumes energy when doing it's job. A PDU >> that meters power at it's outlets is a meter and a distributor and a >> consumer. The same holds for a PoE switch. These are not either meters o= r >> consumers, they are meters and consumers and some of them are also >> distributors at the same time. >> >> 2. The categorization as 'meter' is only available for devices and >> components, not for power interfaces. But obviously a device with >> metering capabilities meters at (some of) its interfaces. Take the PoE >> switch that meters power at some or all of its PoE outlets. It would be >> natural to label the power interfaces at which metering capabilities are >> available as 'metered'. It appears strange to classify the device as >> 'meter'. >> >> The basic question here is: Do we need to model metering capability at >> all? If yes, we should model it as an attribute, not as a category; and >> we should model it as attribute of the power interfaces as well. >> >> BTW, if we model metering capability (monitoring), we should consequentl= y >> model circuit breaker capability (control) at power interfaces as well. >> >> Cheers, >> Juergen >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --_000_BB79100DBCE84D74B47B882BB92AF0E9ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Good catch let's change "perform metering" to "perform = measuring" then yes go with simple.

So broad categorization of the device/component and continue to leave = complex capability modeling out.

Jp

Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Aug 20, 2013, at 11:44 AM, "Bruce Nordman" <bnordman@lbl.gov> wrote:

The current draft of the EMAN framework says:
  "A meter is= a type Energy Object and any Energy Object can perform metering."

This seems to indicate that devices can meter, components can meter, and po= wer
interfaces can meter.  On the other hand, Juergen notes that the meter= classification
is not available to power interfaces.  This appears to be a contradict= ion.

It is possible to require declaring a "primary function" for a de= vice, including whether it is a
device that can only perform metering, but that seems to be an unnecessary = complication
and not derivative of any requirement.

Juergen's point is that metering (or measuring--I defer on that choice of w= ording) can be
simply and flexibly modeled as just a capability that any EO can have. = ; It is unnecessary
to make the Framework more complicated than that.  There are plenty of= additional
complications that could be added that don't derive from any requirement.
--Bruce



On Tue, Aug 20, 2013 at 10:51 AM, John Parello (= jparello) <jparello@cisco.com> wrote:

<snip>

>
> You ask "Do we need to model metering capability at all"? &n= bsp;Yes, because
> smart meters, in particular sub-meters, are a key part of real time en= ergy
> monitoring.
>

Just to be clear we used "meter" is a type of device (which ackno= wledges you other points, and if you want to model capability the value wou= ld be "measuring". So a "metering capability" doesn't m= ake sense. It would be "measuring capability".

Again we removed the capabilities attribute.

After quite some years deploying these systems that distinction is second &= nbsp;nature for me but we should be precise.

Jp



> Regards,
>
> Brad
>
> On 8/20/13 1:09 AM, "Juergen Quittek" <ietf@quittek.at> wrote:
>
>> Dear all,
>>
>> Here is another framework issue: How to model metering capabilitie= s of
>> devices?
>>
>> Our framework draft (draft-ietf-eman-framework-08) models metering=
>> capability by categorizing devices and components into either a pr= oducer,
>> a comsumer, a meter, or a distributor, see pseudocode on page 43.<= br> >>
>> I think this approach is broken. It may be useful for modeling sim= ple
>> scenarios, but it does not work as general model.
>>
>> There are two problems with this approach.
>>
>> 1. The either-or classification. A meter is typically not just a m= eter,
>> but as well a consumer that consumes energy when doing it's job. A= PDU
>> that meters power at it's outlets is a meter and a distributor and= a
>> consumer. The same holds for a PoE switch. These are not either me= ters or
>> consumers, they are meters and consumers and some of them are also=
>> distributors at the same time.
>>
>> 2. The categorization as 'meter' is only available for devices and=
>> components, not for power interfaces. But obviously a device with<= br> >> metering capabilities meters at (some of) its interfaces. Take the= PoE
>> switch that meters power at some or all of its PoE outlets. It wou= ld be
>> natural to label the power interfaces at which metering capabiliti= es are
>> available as 'metered'. It appears strange to classify the device = as
>> 'meter'.
>>
>> The basic question here is: Do we need to model metering capabilit= y at
>> all?  If yes, we should model it as an attribute, not as a ca= tegory; and
>> we should model it as attribute of the power interfaces as well. >>
>> BTW, if we model metering capability (monitoring), we should conse= quently
>> model circuit breaker capability (control) at power interfaces as = well.
>>
>> Cheers,
>>  Juergen
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman



--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--_000_BB79100DBCE84D74B47B882BB92AF0E9ciscocom_-- From bnordman@lbl.gov Tue Aug 20 12:24:11 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F56211E825E for ; Tue, 20 Aug 2013 12:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBMfzWZRiGxm for ; Tue, 20 Aug 2013 12:24:07 -0700 (PDT) Received: from fe2.lbl.gov (fe2.lbl.gov [128.3.41.134]) by ietfa.amsl.com (Postfix) with ESMTP id DC7F311E816B for ; Tue, 20 Aug 2013 12:24:05 -0700 (PDT) X-Ironport-SBRS: 5.5 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkCAKzBE1LRVcCum2dsb2JhbABXA4JBeVG3DohLgR4IFg4BAQEBAQYLCwkUKIIkAQEBAwEBAQFrCwULCwsDLQsiBQ0BBQEcBhOICgYMll2WYI8dD4EZDAQHEYQDA4ktiUeEcYEtjkQWKYMHgVsc X-IronPort-AV: E=Sophos;i="4.89,921,1367996400"; d="scan'208";a="27452465" Received: from mail-pd0-f174.google.com ([209.85.192.174]) by fe2.lbl.gov with ESMTP; 20 Aug 2013 12:24:04 -0700 Received: by mail-pd0-f174.google.com with SMTP id y13so810393pdi.19 for ; Tue, 20 Aug 2013 12:24:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=li/0uFchAZ5VAEvfFSXeMZzwNBaU9trbwWp4Y+CQyVs=; b=WhtDtL9RIIt0EfQvmykeioxl9vSv6x/VQ2e+OGdTkj9szZxSrBElsfP/KZp443DUwj WGz4qoJfr+6U0ScFW5bJir7pOwM0cVkRZ1nLs0kU2sYbBzFB110vLx8aH3TqqVeMedWh q3YJD7uI7I5Q0MBeXcZrB5kpHA7Ji7BCvxTOuY59zuBvzDh82B+HBvy0iUUqq6i4sKj0 9Kl8/Kha8yYiqcbP9DpyREUedovShPZE7CQNHOviB/13MVZOil42Fx1x2BbU6IzcvmxJ 4AY+ZRWttCizQPRnfqI6zZPEkvAsyKG/vY5Cil69EKRnuXSSyAgPxeQNBvGm20sxfCYC qjJQ== X-Gm-Message-State: ALoCoQlcgInoDltffNFSLhIx3Uw62fLvWId4OcRqyDkB8u/gc2JNLYHa0zofGbXhPQPb/slmQz7T8cvvov8oCuORvnjc6iB8SBOn2XzOBHghoCp56rxC7OAgTfxyRKeMp++LpcHCCChv X-Received: by 10.66.102.1 with SMTP id fk1mr5600230pab.90.1377026644084; Tue, 20 Aug 2013 12:24:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.102.1 with SMTP id fk1mr5600219pab.90.1377026643964; Tue, 20 Aug 2013 12:24:03 -0700 (PDT) Received: by 10.68.235.9 with HTTP; Tue, 20 Aug 2013 12:24:03 -0700 (PDT) In-Reply-To: <373368AB-D347-4BDF-8BE0-EC2C2F3615EE@quittek.at> References: <373368AB-D347-4BDF-8BE0-EC2C2F3615EE@quittek.at> Date: Tue, 20 Aug 2013 12:24:03 -0700 Message-ID: From: Bruce Nordman To: Juergen Quittek Content-Type: multipart/alternative; boundary=047d7bf18b1cf5c78604e465ff44 Cc: eman mailing list Subject: Re: [eman] eman framework issue: Do we start from a software design or do we start from the physical world? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 19:24:11 -0000 --047d7bf18b1cf5c78604e465ff44 Content-Type: text/plain; charset=ISO-8859-1 I concur with Juergen's concern about how to approach the Framework. A key concern I have is that the software modeling approach seems to lead to a document which has more apparent complexity to the reader than the alternative. I say apparent because for implementation, the result might be the same. However, the apparent complexity is likely to deter some people from implementing or using EMAN at all. --Bruce On Tue, Aug 13, 2013 at 2:17 AM, Juergen Quittek wrote: > Dear all, > > Before the IETF meeting I posted high-level comments on the new version of > our framework draft (draft-ietf-eman-framework-08) and on the alternative > framework proposal from Bruce (draft-nordman-eman-er-framework-01). > > Now I send a series of individuals mails each focusing on a particular > issue that I found in one or the other draft. For each issue I try to point > out how the drafts address it and what the differences are. > > My first point is about our very general approach to describe the eman > framework: Do we start with describing a software design and map this to > the real world? Or do we start with describing the physical world an derive > a model from it? > > The two drafts are quite different in that respect. draft-ietf-eman-framework-08 > (EMAN Framework) rather develops the framework from a software model while draft-nordman-eman-er-framework-01 > (ER Framework) starts from the physical world. Here is an example that > illustrate the difference. > > EMAN Framework section 4.2 Energy Object: > > 4.2 Energy Object > > An Energy Object is an abstract class that contains the base > attributes for Energy Management. There are three types of > Energy Objects: Device, Component and Power Interface. > > > ER Framework, section 2.5 Energy Object: > > 2.5. Energy Object > > Devices, Power Interfaces, and Components are all Energy Objects (EOs). The term > "entity" in the Requirements draft generally corresponds to Energy > Object. The kinds of data available for an EO depends on its type as > shown in Figure 1. > > > This is just one example out of many similar instances that can easily be > found in those drafts. > > The different choices made by the drafts result in different ways of > describing the framework. > > The ER Framework describes which information is reported for an Energy > Object (power, state, voltage, etc.) while the EMAN framework tells us > which attributes (power, state, voltage, etc) the class Energy Object > has. > > So the basic question that occurs to me is: Do we want to define our > energy management framework as an object-oriented (software) model or do we > want to describe a view of physical systems? > > This would be the core question to be answered for addressing this issue. > > Of course, in the end we need a data model for interoperable exchange of > information based on our framework. > But for this purpose we already have other documents. Here the candidates > for are MIB modules using SMI that do not support the concepts of classes > and inheritance (which also holds for YANG modules using XML). > : > Cheers, > Juergen > > _______________________________________________ > 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 --047d7bf18b1cf5c78604e465ff44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I concur with Juergen's concern about how to= approach the Framework.
A key concern I have is that the software model= ing approach seems to
lead to a document which has more apparent complex= ity to the reader
than the alternative.=A0=A0 I say apparent because for implementation, the<= br>
result might be the same.=A0 However, the apparent complexity is l= ikely
to deter some people from implementing or using EMAN at all.
--Bruce


On Tue, Aug 13, 2013 at 2:17 AM, Juergen Quittek <= ietf@quittek.at>= ; wrote:
Dear all,=A0

Before the IETF meetin= g I posted high-level comments on the new version of our framework draft (d= raft-ietf-eman-framework-08) and on the alternative framework proposal from= Bruce (draft-nordman-eman-er-framework-01).=A0

Now I send a series of individuals mails each focusing = on a particular issue that I found in one or the other draft. For each issu= e I try to point out how the drafts address it and what the differences are= .=A0

My first point is about our very general approach to de= scribe the eman framework: Do we start with describing a software design an= d map this to the real world? Or do we start with describing the physical w= orld an derive a model from it?

The two drafts are quite different in that respect.=A0<= span>draft-ietf-eman-framework-08 (EMAN Framework) rather develops the fram= ework from a software model while=A0draft-nordman-eman-er-fram= ework-01 (ER Framework) starts from the physical world. Here is an example = that illustrate the difference.=A0

EMAN Framew= ork section 4.2 Energy Object:
        4.2 Energy Object
An=
 Energy Object is an abstract class that contains the base=20
        attributes for Energy Management.  There are three types of=20
        Energy Objects: Device, Component and Power Interface.

ER Framewo= rk, section 2.5 Energy Object:
2.5.  Energy Object=A0=A0


Devices, Power Interfaces, and=
 Components are all Energy Objects (EOs).  The term
   "entity" in the Requirements draft generally corresponds to En=
ergy
   Object.  The kinds of data available for an EO depends on its type as
   shown in Figure 1.

=
This is just one example out of many similar instances tha= t can easily be found in those drafts.=A0

The different choices made by the drafts result in different way= s of describing the framework.=A0

<= div>The ER Framework describes which information is reported for an E= nergy Object (power, state, voltage, etc.) while the EMAN framework tells u= s which attributes=A0(power, state, voltage, etc)= =A0the class Energy Object has.=A0

So the basic question that occurs to= me is: Do we want to define our energy management framework as an object-o= riented (software) model or do we want to describe a view of physical syste= ms?

This would be the core question to b= e answered for addressing this issue.=A0

=
Of course, in the end we need a data model for interoperab= le exchange of information based on our framework.=A0
But for this purpose we already have other documents. Here the c= andidates for =A0are MIB modules using SMI that do not support the concepts= of classes and inheritance=A0(which also holds for YANG modul= es using XML).=A0
:
Cheers,
= =A0 =A0 Juergen

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




--
Bruce Nordman
Lawrence Be= rkeley National Laboratory
= nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--047d7bf18b1cf5c78604e465ff44-- From brads@coraid.com Tue Aug 20 14:11:04 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E34021F9C6E for ; Tue, 20 Aug 2013 14:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fYTk7Emk1dC for ; Tue, 20 Aug 2013 14:11:00 -0700 (PDT) Received: from server506.appriver.com (server506l.appriver.com [50.56.144.158]) by ietfa.amsl.com (Postfix) with ESMTP id C741621F9A27 for ; Tue, 20 Aug 2013 14:10:59 -0700 (PDT) X-Note-AR-ScanTimeLocal: 8/20/2013 4:10:58 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-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-170/SG:5 8/20/2013 4:10:01 PM X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.968428 Source White X-Signature-Violations: 0-0-0-32767-c X-Note-419: 31.2022 ms. Fail:1 Chk:1343 of 1343 total X-Note: SCH-CT/SI:1-1343/SG:1 8/20/2013 4:10:46 PM X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->PRIVATE->UNITED STATES X-Note-Sending-IP: 10.242.229.139 X-Note-Reverse-DNS: X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G340 G341 G342 G343 G347 G348 G455 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 3177274; Tue, 20 Aug 2013 16:10:58 -0500 Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.218]) by HT07-E6.exg6.exghost.com ([50.56.144.149]) with mapi id 14.03.0123.003; Tue, 20 Aug 2013 16:10:57 -0500 From: Brad Schoening To: Bruce Nordman , Juergen Quittek Thread-Topic: [eman] eman framework issue: Do we start from a software design or do we start from the physical world? Thread-Index: AQHOndrnKAvrpVqnv0+WIfjGmeaLHpmedkKA Date: Tue, 20 Aug 2013 21:10:57 +0000 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 x-originating-ip: [50.56.144.247] x-rerouted-by-exchange: Content-Type: multipart/alternative; boundary="_000_CE392745D0572bradscoraidcom_" MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] eman framework issue: Do we start from a software design or do we start from the physical world? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 21:11:04 -0000 --_000_CE392745D0572bradscoraidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bruce & Juergen, NIST uses the same modeling language and creates a meter as a distinct clas= s of device, so we appear to be in good company. For example, pg 29 of ASHRAE 201 'Facility Smart Grid Information Model': ElectricMeter (Class) The ElectricMeter Class is a subclass of the Meter Class. It is an abstract= representation of devices that measure real optionally reactive, energy consumption. These devices optionally measure o= ther electrical parameters such as Present Subinterval Demand or Power Quality. Brad Schoening Engineering | Coraid Tel: +1 917 304 7190 brads@coraid.com | www.coraid.com Coraid: Redefining Storage From: Bruce Nordman > Date: Tue, 20 Aug 2013 12:24:03 -0700 To: Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] eman framework issue: Do we start from a software desig= n or do we start from the physical world? I concur with Juergen's concern about how to approach the Framework. A key concern I have is that the software modeling approach seems to lead to a document which has more apparent complexity to the reader than the alternative. I say apparent because for implementation, the result might be the same. However, the apparent complexity is likely to deter some people from implementing or using EMAN at all. --Bruce On Tue, Aug 13, 2013 at 2:17 AM, Juergen Quittek > wrote: Dear all, Before the IETF meeting I posted high-level comments on the new version of = our framework draft (draft-ietf-eman-framework-08) and on the alternative f= ramework proposal from Bruce (draft-nordman-eman-er-framework-01). Now I send a series of individuals mails each focusing on a particular issu= e that I found in one or the other draft. For each issue I try to point out= how the drafts address it and what the differences are. My first point is about our very general approach to describe the eman fram= ework: Do we start with describing a software design and map this to the re= al world? Or do we start with describing the physical world an derive a mod= el from it? The two drafts are quite different in that respect. draft-ietf-eman-framewo= rk-08 (EMAN Framework) rather develops the framework from a software model = while draft-nordman-eman-er-framework-01 (ER Framework) starts from the phy= sical world. Here is an example that illustrate the difference. EMAN Framework section 4.2 Energy Object: 4.2 Energy Object An Energy Object is an abstract class that contains the base attributes for Energy Management. There are three types of Energy Objects: Device, Component and Power Interface. ER Framework, section 2.5 Energy Object: 2.5. Energy Object Devices, Power Interfaces, and Components are all Energy Objects (EOs). Th= e term "entity" in the Requirements draft generally corresponds to Energy Object. The kinds of data available for an EO depends on its type as shown in Figure 1. This is just one example out of many similar instances that can easily be f= ound in those drafts. The different choices made by the drafts result in different ways of descri= bing the framework. The ER Framework describes which information is reported for an Energy Obje= ct (power, state, voltage, etc.) while the EMAN framework tells us which at= tributes (power, state, voltage, etc) the class Energy Object has. So the basic question that occurs to me is: Do we want to define our energy= management framework as an object-oriented (software) model or do we want = to describe a view of physical systems? This would be the core question to be answered for addressing this issue. Of course, in the end we need a data model for interoperable exchange of in= formation based on our framework. But for this purpose we already have other documents. Here the candidates f= or are MIB modules using SMI that do not support the concepts of classes a= nd inheritance (which also holds for YANG modules using XML). : Cheers, Juergen _______________________________________________ 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 _______________________________________________ eman mailing list eman@ietf= .org https://www.ietf.org/mailman/listinfo/eman --_000_CE392745D0572bradscoraidcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Bruce & Juergen,

NIST uses the same modeling language and creates a meter as a distinct= class of device, so we appear to be in good company.

For example, pg 29 of ASHRAE 201 'Facility Smart Grid Information Mode= l':

ElectricMeter (Class)
The ElectricMeter Class is a subclass of the Meter Class. It is an abs= tract representation of devices that measure real
optionally reactive, energy consumption. These devices optionally meas= ure other electrical parameters such as Present
Subinterval Demand or Power Quality.

Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190
brads@coraid.com | www.coraid.com
Coraid: Redefinin= g Storage


From: Bruce Nordman <bnordman@lbl.gov>
Date: Tue, 20 Aug 2013 12:24:03 -07= 00
To: Juergen Quittek <ietf@quittek.at>
Cc: eman mailing list <eman@ietf.org>
Subject: Re: [eman] eman framework = issue: Do we start from a software design or do we start from the physical = world?

I concur with Juergen's concern about how to approach the Framework. A key concern I have is that the software modeling approach seems to
lead to a document which has more apparent complexity to the reader
than the alternative.   I say apparent because for implementation= , the
result might be the same.  However, the apparent complexity is likely<= br> to deter some people from implementing or using EMAN at all.
--Bruce


On Tue, Aug 13, 2013 at 2:17 AM, Juergen Quittek= <ietf@quittek.at> wrote:
Dear all, 

Before the IETF meeting I posted high-level comments on the new versio= n of our framework draft (draft-ietf-eman-framework-08) and on the alternat= ive framework proposal from Bruce (draft-nordman-eman-er-framework-01).&nbs= p;

Now I send a series of individuals mails each focusing on a particular= issue that I found in one or the other draft. For each issue I try to poin= t out how the drafts address it and what the differences are. 

My first point is about our very general approach to describe the eman= framework: Do we start with describing a software design and map this to t= he real world? Or do we start with describing the physical world an derive = a model from it?

The two drafts are quite different in that respect. draft-i= etf-eman-framework-08 (EMAN Framework) rather develops the framework from a= software model while draft-nordman-eman-er-framework-01 = (ER Framework) starts from the physical world. Here is an example that illustrate the difference. 

EMAN Framework section 4.2 Energy Object:
        4.2 Energy Object
An Energy Object is an abstract class tha=
t contains the base=20
        attributes for Energy Management.  There are three types of=20
        Energy Objects: Device, Component and Power Interface.

ER Framework, section 2.5 Energy Object:
2.5.  Energy Object  
Devices, Pow=
er Interfaces, and Components are all Energy Objects (EOs).  The term
   "entity" in the Requirements draft generally corresponds to En=
ergy
   Object.  The kinds of data available for an EO depends on its type as
   shown in Figure 1.

This is just one example out of many similar instances that can = easily be found in those drafts. 

The different choices made by the drafts result in different way= s of describing the framework. 

The ER Framework describes which information is reported for an = Energy Object (power, state, voltage, etc.) while the EMAN framework tells = us which attributes (power, state, voltage, etc) the class Energy Object has. 

So the basic question that occurs to me is: Do we want to define= our energy management framework as an object-oriented (software) model or = do we want to describe a view of physical systems?

This would be the core question to be answered for addressing th= is issue. 

Of course, in the end we need a data model for interoperable exc= hange of information based on our framework. 
But for this purpose we already have other documents. Here the c= andidates for  are MIB modules using SMI that do not support the conce= pts of classes and inheritance (which also holds for YANG= modules using XML). 
:
Cheers,
    Juergen

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




--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
_______________________________________________ eman mailing list eman@ietf.org ht= tps://www.ietf.org/mailman/listinfo/eman --_000_CE392745D0572bradscoraidcom_-- From ted@ghose.us Wed Aug 21 20:21:05 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3EC11E820E for ; Wed, 21 Aug 2013 20:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 PC2B9MvPg9lN for ; Wed, 21 Aug 2013 20:20:53 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id A144011E8179 for ; Wed, 21 Aug 2013 20:20:48 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wo10so2596734obc.27 for ; Wed, 21 Aug 2013 20:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghose.us; s=ghose; h=mime-version:date:message-id:subject:from:to:content-type; bh=z3MS/gpI2BZqQMHJoj3mH4qL5xXfVizWIoCdgwsP/VQ=; b=lNj1f4kHQLMuEbKkxHpm/mah5FNsBD4W8dL/2Tw/JYo6WSdlE42LLSiQYvfN+IrHQb zChEO4A+8TsHuVOGIj7JxL6r/JIEfaga1zgrTcWHC0a/dS+z5IVDZmzSGQW2WJCjdUeN CPMbxOWykmnEYVEXjgVJAKmXIlWZdKEAeHOxg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=z3MS/gpI2BZqQMHJoj3mH4qL5xXfVizWIoCdgwsP/VQ=; b=aD8MOfoRaKSzDz4kWs3zFiqpI6Q4wiCbIu4sDQ00eXVL42rS3mxI4sVoU3mxRARV6K uwnMiVDMN8s+BJMfgKFkVeCs0GdxznrrPIJrXuiGSUZHtzBWnJa0dTQflfoqhx7+tXBr xahLaVa82tMHF2dnH+PVzWf7O0zF78g+w4vmqJpCJBOWYhgg9bbEqX6aqD3eBP9AT+ak BmzS9QdVqCHH1F4LP/JqYsDQt0mD+8flpycSBce0XXq8bAl8oiqgJBrNBXoBPyoisy7i ugTgOgtQZfEyrZOT5KCbF5/G/lp5yrH+tG8m51o6d+V9bU39rMman3BTBBJYuKFW8OSw CNsw== X-Gm-Message-State: ALoCoQlniU8f+Kxkgkug4yruRcMS1T5AapCcUJX0qA978qfUO25zZTWrCe8Ye9C3KuUdhTE9ODc8 MIME-Version: 1.0 X-Received: by 10.182.65.1 with SMTP id t1mr11926392obs.5.1377141647939; Wed, 21 Aug 2013 20:20:47 -0700 (PDT) Received: by 10.76.130.148 with HTTP; Wed, 21 Aug 2013 20:20:47 -0700 (PDT) Date: Wed, 21 Aug 2013 20:20:47 -0700 Message-ID: From: Ted Ghose To: eman mailing list Content-Type: multipart/alternative; boundary=089e015389babb2bf504e480c60d Subject: [eman] Moving on to my official email X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 Aug 2013 03:21:06 -0000 --089e015389babb2bf504e480c60d Content-Type: text/plain; charset=ISO-8859-1 Hi all, I'll be following Eman WG from my newly registered tghose@juniper.net from now on thanks -ted- --089e015389babb2bf504e480c60d Content-Type: text/html; charset=ISO-8859-1
Hi all,

I'll be following Eman WG from my newly registered tghose@juniper.net from now on

thanks

-ted-
--089e015389babb2bf504e480c60d-- From tghose@juniper.net Wed Aug 21 20:55:52 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC31611E81BC for ; Wed, 21 Aug 2013 20:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 9DmIAAjS3dwx for ; Wed, 21 Aug 2013 20:55:40 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 7793C11E811D for ; Wed, 21 Aug 2013 20:55:39 -0700 (PDT) Received: from mail214-co1-R.bigfish.com (10.243.78.226) by CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id 14.1.225.22; Thu, 22 Aug 2013 03:55:38 +0000 Received: from mail214-co1 (localhost [127.0.0.1]) by mail214-co1-R.bigfish.com (Postfix) with ESMTP id CFF75D000D9 for ; Thu, 22 Aug 2013 03:55:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 14 X-BigFish: VPS14(z56e1h3b76p90cnzc85fhdbeehde40hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h34h1155h) Received-SPF: pass (mail214-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=tghose@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(51856001)(222413001)(74366001)(76176001)(36756003)(80022001)(65816001)(59766001)(77982001)(76796001)(83072001)(16236675002)(81686001)(76786001)(83322001)(81816001)(63696002)(47976001)(46102001)(50986001)(49866001)(79102001)(4396001)(53806001)(81542001)(74876001)(69226001)(54316002)(54356001)(56816003)(66066001)(47736001)(74706001)(77096001)(56776001)(74502001)(74662001)(47446002)(31966008)(81342001)(76482001)(80976001)(152223002)(23163001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB202; H:BN1PR05MB201.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail214-co1 (localhost.localdomain [127.0.0.1]) by mail214-co1 (MessageSwitch) id 1377143737513447_18381; Thu, 22 Aug 2013 03:55:37 +0000 (UTC) Received: from CO1EHSMHS005.bigfish.com (unknown [10.243.78.249]) by mail214-co1.bigfish.com (Postfix) with ESMTP id 7A074CC004C for ; Thu, 22 Aug 2013 03:55:37 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS005.bigfish.com (10.243.66.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 22 Aug 2013 03:55:37 +0000 Received: from BN1PR05MB202.namprd05.prod.outlook.com (10.255.206.18) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.347.3; Thu, 22 Aug 2013 03:55:31 +0000 Received: from BN1PR05MB201.namprd05.prod.outlook.com (10.255.206.23) by BN1PR05MB202.namprd05.prod.outlook.com (10.255.206.18) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 22 Aug 2013 03:55:30 +0000 Received: from BN1PR05MB201.namprd05.prod.outlook.com ([169.254.3.117]) by BN1PR05MB201.namprd05.prod.outlook.com ([169.254.3.117]) with mapi id 15.00.0745.000; Thu, 22 Aug 2013 03:55:29 +0000 From: Ted Ghose To: "eman@ietf.org" Thread-Topic: Hello from my new email Thread-Index: AQHOnutwGI9L6pq+OEWfyNnRuslTzg== Date: Thu, 22 Aug 2013 03:55:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [66.129.224.36] x-forefront-prvs: 0946DC87A1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3459963330_76923183" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [eman] Hello from my new email X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 Aug 2013 03:55:52 -0000 --B_3459963330_76923183 Content-type: multipart/alternative; boundary="B_3459963330_76964157" --B_3459963330_76964157 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hello again, I was on a break from the workgroup for a while, and I'm really amaze on the progress that has been made. The framework has taken a great shape. Interesting email threads I'm still catching on. I like the relationship topology. It will be really useful to make a topological graph and visualize the power network. I belief it can further enhanced by allowing NMS (or the device if capable) to dynamically add remove rows as devices joins or leave the power network. I like the cloud concept too, as devices that are powered off might not be able to persist relationship topology. We can open a healthy debate on this one. The measurement definition looks great too. I was thinking a simple positive or negative sign on the value could indicate direction of the flow. I'm absolutely on board with designing the system mimicking physical world, not the other way around. We have a device and that has components. Each device have an unique id (uuid of entity mib will suffice) and unique index to address each component. Each component has its own attributes (name length, weight, etc.), and energy is one among them. Components could meter, produce, store, distribute, consume, recharge energy. I'd like to vision it like big data, each component, depending on its role, populates some part of its spare vector. They also will put the topology info as part of their vector. Now the NMS could very easily construct an energy flow across the network down to component level. As I'm catching up, I'll start putting more of my thoughts in writing. -Ted Ghose- --B_3459963330_76964157 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hello again,

<= /div>
I was on a break from the workgroup for a while, and I'm really am= aze on the progress that has been made. The framework has taken a great shap= e. Interesting email threads I'm still catching on.

I like the relationship topology. It will be really useful to make a topolo= gical  graph and visualize the power network. I belief it can further e= nhanced by allowing NMS (or the device if capable) to dynamically add remove= rows as devices joins or leave the power network. I like the cloud concept = too, as devices that are powered off might not be able to persist relationsh= ip topology. We can open a healthy debate on this one.

<= div>The measurement definition looks great too. I was thinking a simple posi= tive or negative sign on the value could indicate direction of the flow.

I'm absolutely on board with designing the system mimi= cking physical world, not the other way around. We have a device and that ha= s components. Each device have an unique id (uuid of entity mib will suffice= ) and unique index to address each component. Each component has its own att= ributes (name length, weight, etc.), and energy is one among them.  Com= ponents could meter, produce, store, distribute, consume, recharge energy. I= 'd like to vision it like big data, each component, depending on its role, p= opulates some part of its spare vector. They also will put the topology info= as part of their vector. Now the NMS could very easily construct an energy = flow across the network down to component level. 

<= div>As I'm catching up, I'll start putting more of my thoughts in writing.

-Ted Ghose-
--B_3459963330_76964157-- --B_3459963330_76923183 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIJowYJKoZIhvcNAQcCoIIJlDCCCZACAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggb6MIIG9jCCBl+gAwIBAgIKMnD3XQADAABcrjANBgkqhkiG9w0BAQUFADCBxzEjMCEG CSqGSIb3DQEJARYUY2EtYWRtaW5AanVuaXBlci5uZXQxCzAJBgNVBAYTAlVTMRMwEQYDVQQI EwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlTdW5ueXZhbGUxHzAdBgNVBAoTFkp1bmlwZXIgTmV0 d29ya3MsIEluYy4xJjAkBgNVBAsTHUp1bmlwZXIgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSEw HwYDVQQDExhKdW5pcGVyIE5ldHdvcmtzIFJvb3QgQ0EwHhcNMTMwMjAxMTgyMTU4WhcNMTQw MjAxMTgyMTU4WjCBkzETMBEGCgmSJomT8ixkARkWA25ldDEUMBIGCgmSJomT8ixkARkWBGpu cHIxDDAKBgNVBAsTA0VuZzEOMAwGA1UECxMFVXNlcnMxETAPBgNVBAsTCEFtZXJpY2FzMRIw EAYDVQQDEwlUZWQgR2hvc2UxITAfBgkqhkiG9w0BCQEWEnRnaG9zZUBqdW5pcGVyLm5ldDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOCtIgsjc+bJ9bjk1a7UTjvIxzJ76L9x xclO6EnXrKTDK561Ksj6ti9ArAq1o6Q/TDgd0fYLTSQ8tmbAmaI8PUHzVj19nI4WJp8t8brY QS+9jF7AAGvylF9DiMsn04Xukj26wBlT5t6e//LtBLkfr7970kI9PgLEP8Y7cRaPHXK1eudw lgYEWU/ZU8thKATVFTYZIitFwqKsA3LFDHS0oolaVxLg+JINH9DhB/HwJoaraXgMddYUnj9j haLBh+C/8Pc2LU+Ko4lbAq9GK2E/gzjELJFmssDAjuYXrTDoswFaTLnj2pywMl6WjYYfFS0W RYSr50lSgIohu1tEzy8jticCAwEAAaOCA5UwggORMB0GA1UdDgQWBBRG8Hd1TU4AFixRnsXY 3yu6XuR7yjAfBgNVHSMEGDAWgBTgvS53E5ouW1GY+pBQXdgU0VIsWTCCASsGA1UdHwSCASIw ggEeMIIBGqCCARagggEShoHFbGRhcDovLy9DTj1KdW5pcGVyJTIwTmV0d29ya3MlMjBSb290 JTIwQ0EoMyksQ049ZGNqbnByMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1qbnByLERDPW5ldD9jZXJ0aWZpY2F0 ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSG SGh0dHA6Ly9kY2pucHIxLmpucHIubmV0L0NlcnRFbnJvbGwvSnVuaXBlciUyME5ldHdvcmtz JTIwUm9vdCUyMENBKDMpLmNybDCCATYGCCsGAQUFBwEBBIIBKDCCASQwgboGCCsGAQUFBzAC hoGtbGRhcDovLy9DTj1KdW5pcGVyJTIwTmV0d29ya3MlMjBSb290JTIwQ0EsQ049QUlBLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24s REM9am5wcixEQz1uZXQ/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwZQYIKwYBBQUHMAKGWWh0dHA6Ly9kY2pucHIxLmpucHIubmV0L0Nl cnRFbnJvbGwvZGNqbnByMS5qbnByLm5ldF9KdW5pcGVyJTIwTmV0d29ya3MlMjBSb290JTIw Q0EoMykuY3J0MBcGCSsGAQQBgjcUAgQKHggAVQBzAGUAcjAMBgNVHRMBAf8EAjAAMAsGA1Ud DwQEAwIFoDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYD VR0RBDowOKAiBgorBgEEAYI3FAIDoBQMEnRnaG9zZUBqdW5pcGVyLm5ldIESdGdob3NlQGp1 bmlwZXIubmV0MEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzANBgkqhkiG9w0BAQUFAAOBgQCKqbitK1XoMMO+ TeBnsYfkHxAZoqUqcmhcHYz4XLMt3R2N3ZTay3xWNL02F4YQ4hqVlQbnDeILXFsLZPkqoNb3 Zwle9TUe86qhZExvpBtjhsjzBZdqBSRAHhB6ejU255VjV42t/dugSHgNVZOM0OTvlLhExhYL ThfzsxyrQmzcaTGCAm0wggJpAgEBMIHWMIHHMSMwIQYJKoZIhvcNAQkBFhRjYS1hZG1pbkBq dW5pcGVyLm5ldDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcT CVN1bm55dmFsZTEfMB0GA1UEChMWSnVuaXBlciBOZXR3b3JrcywgSW5jLjEmMCQGA1UECxMd SnVuaXBlciBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxITAfBgNVBAMTGEp1bmlwZXIgTmV0d29y a3MgUm9vdCBDQQIKMnD3XQADAABcrjANBglghkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEi BCCAe48mwbJqFEkDUzFiMB+jAmNCWsthOOH0RCr/E4trujAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA4MjIwMzU1MzBaMA0GCSqGSIb3DQEBAQUABIIB AIdkPXrfX2CzCwevA/8BnSusSeLtMjpJ+EcLZmc3AVascjIexDGdgo9BycJngbMgh3m28kic 0V8EUPn9mnSN/ihfl6Z/hwzIaIO5PYgyqbaLtw3uLg1k2HAvtihmQC+bMHnps2g47+bBwSl/ ee+g54WfdHHgICM3sQ4FjKfiF1eCbSpHTwGNPKd7LoDTuQX7ItgfHuba0TZAWeaJX4r3lswe dyNjp599J/hdtU1Kk9+p8PRcbS04h1sLpZrkwo2RTvSeQNsXADrcZ97G3WZne7Db9E4KGqY5 ZJXgObdF4unAdvRiMNGPoUaqp9iA+IRWeLMTONsuRBxVeS+yacyl1a0= --B_3459963330_76923183-- From izumi@shiratori.riec.tohoku.ac.jp Fri Aug 23 00:16:27 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A117B1F0D38 for ; Fri, 23 Aug 2013 00:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 ndLirAfCzASy for ; Fri, 23 Aug 2013 00:16:22 -0700 (PDT) Received: from mail.shiratori.riec.tohoku.ac.jp (falcon.shiratori.riec.tohoku.ac.jp [130.34.209.8]) by ietfa.amsl.com (Postfix) with ESMTP id 236E91F0D37 for ; Fri, 23 Aug 2013 00:16:19 -0700 (PDT) Received: from [192.168.11.3] (ai-dhcp47.ci.isc.tohoku.ac.jp [130.34.243.47]) by mail.shiratori.riec.tohoku.ac.jp (Postfix) with ESMTP id 3876D55C3; Fri, 23 Aug 2013 16:16:14 +0900 (JST) Message-ID: <52170C34.7020806@shiratori.riec.tohoku.ac.jp> Date: Fri, 23 Aug 2013 16:16:04 +0900 From: Satoru Izumi User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "John Parello (jparello)" References: <51F767A6.4010407@shiratori.riec.tohoku.ac.jp> <25A341DD-5641-448C-9973-FA287902BFD7@cisco.com> In-Reply-To: <25A341DD-5641-448C-9973-FA287902BFD7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "eman@ietf.org" Subject: Re: [eman] Should the framework cover devices in which we can not measure energy consumption directly? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Aug 2013 07:16:27 -0000 Hi John, I understand your concept. However, for devices with serial connection or ip connection or no connection i.e. devices which do not have some means of measuring power consumption directly, what will happen? Will these devices be out of scope? Unless the devices are supplemented with energy measurement mechanisms? Does the framework cover the existing devices which do not have functions to translate data from serial to ip networks? For the devices with no serial connection or ip connection, could we estimate their energy consumption without using energy meters? (e.g., I can see the light is on, I may or may not know its wattage, there is no energy meter, but I know it is consuming energy. That is valuable information. Estimating the energy consumption is another step from there. Same for the TV, the fan, etc. etc.). The act of seeing that a device is on can be automated using simpler indirect mechanisms. This is much simpler than introducing energy meters in the devices themselves. Is it not better to separate the device on/off detection mechanism from the energy estimation and the energy control mechanisms? That way we have a wider scope of the devices within the energy management framework, today. Makes sense? Satoru Izumi Research Institute of Electrical Communication Tohoku University izumi@shiratori.riec.tohoku.ac.jp -------- Original Message -------- Subject: Re: [eman] Should the framework cover devices in which we can not measure energy consumption directly? From: John Parello (jparello) To: Satoru Izumi CC: "eman@ietf.org" Date: Tue Jul 30 2013 21:23:47 GMT+0900 > Hi Satoru, > > I think I miss understood your question during the session. I thought you were asking if we modeled connectivity (network information) in our framework information model. > > For your question below I take it that you are asking about devices that are not network (ip) connected. > > The framework defines an information model that we would like devices to implement. If they are not ip connected they may be accessible via other serial protocol like knx, mod-bus, bacnet etc. > > If these devices implement the information model they can then be easily managed via gateways that translate data from serial to ip networks. > > The reason we want a common information model is so that manufacturers of these gateways can have a clear understanding of what to translate and the semantics of the information they translate. > > I run such a program with Cisco and we have lots of partners who translate bacnet for example to our information model. Take a look at a company call FieldServer and their Energywise gateway. > > For devices with no serial connection or ip connection, then we have no direct visibility to those devices. If we measure the meter readings from an area and some portion are readable then there is benefit from the simple subtraction of your total energy and the energy you can monitor. > > Does that help? > Jp > > Sent from my iPad > (expect ridiculous spelling mistakes) > > On Jul 30, 2013, at 9:14 AM, "Satoru Izumi" wrote: > >> John, >> >> This is Izumi, I asked you about device connectivity at yesterday's >> Eman meeting. >> >> At this time, I would like to reconfirm, that you said that the >> framework does not cover devices for which we can not measure >> energy consumption directly. >> >> Is this O.K.? Note, there are several ways in which we can infer >> that a device is consuming energy, but few devices offer means of >> measuring how much energy is consumed. Almost all electrical devices >> of today fall in this category. Lights, heaters, mobile devices, >> home appliances, computer devices just name them. We may figure >> out that the device is on but the devices do offer means of >> measuring energy consumption. (Not without introducing additional >> devices.) >> >> The above restriction will severly constrain the applicability of >> the framework in todays environment. >> >> What do you think this? >> >> Regard, >> Satoru Izumi, Ph.D >> Research Fellow >> Research Institute of Electrical Communication, Tohoku University >> Tel&FAX: +81-22-217-5080 >> izumi@shiratori.riec.tohoku.ac.jp >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Tue Aug 27 01:53:54 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07CA21F935A for ; Tue, 27 Aug 2013 01:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] 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 zf-N16MmmOnR for ; Tue, 27 Aug 2013 01:53:50 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id B91EE11E816F for ; Tue, 27 Aug 2013 01:53:49 -0700 (PDT) Received: from [10.10.1.126] (65-60-110-235.static-ip.telepacific.net [65.60.110.235]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LcC9p-1VvWLX2xuv-00jI9Y; Tue, 27 Aug 2013 10:53:47 +0200 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <76851939-4781-4290-85EE-91DCDEEB92AF@quittek.at> X-Mailer: iPhone Mail (10B329) From: Juergen Quittek Date: Tue, 27 Aug 2013 01:53:42 -0700 To: Brad Schoening X-Provags-ID: V02:K0:vGNrekbkX0anXD6wXH9NBHK4G7FIJJI6aCusn8JY86x 4lW92WYMHSGVOQtaHTGvndzrnjMmKYlqYfMqOUd70BpW69hxSO UBiF3OLvAFJkh+W6hkqkmS2kmMZOwFsyAI41GIqvzoNe3P0khC 1XPI9ybZsS/vnRUy/zCZp8XCX8etYqRIuRfyoYP8E7vL/wwhQc aCM5nWFlVKAYnF9XkOrd0rqW/vGb3Ekq8vV7tfpdR8LKwycXLs b10YCsUQRGDqUnSNrNI8ivjN+Kxz4e1vJuTxh916HQ1EhlnCot 6cNZqPTsyWLMlt1aI/I5yvoFs4OG5LRSKw7uaHMTQR+xqGtU46 1tHjJRr2WO5N3ZGJWGQU+tN1VnvaKyxozFS4JW6/XotDm/7W5t 5RDJQwLKSPOJg== Cc: eman mailing list Subject: Re: [eman] eman framework issue: How to model a meter? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 08:53:54 -0000 Hi Brad, Thanks for your replies. I am still on vacation. That's why I did not answer= immediately. Please see replies inline.=20 Am 20.08.2013 um 10:05 schrieb Brad Schoening : > Juergen, >=20 > My experience has been that usually a meter was just a meter. While many > devices such as PoE switches and PDUs can internally meter, we have to > recognize that there is a real use case for stand-alone metering. > Intelligent smart meters from vendors such as Shark, SATEC, and Crompton > are but a few examples of these widely used products An ethernet switch > is a device who's primary purpose is networking, but may have metering > relationships. But a smart meter is a device with the primary purpose of > metering. =20 I fully agree that there are devices that have energy metering as their prim= ary purpose. Similarly, we have probe devices in the Internet with their tha= t have traffic metering as their main purpose. But we in the Internet we sti= ll can live well without having a special MIB variable classifying a device a= s 'probe'. Why do we need this for energy management? >=20 > A common approach to classification should be more than adequate to > distinguish between products which consume energy to provide some > function, products that primarily produce energy, and products which are > designed for metering. If we clarify that classification should involve > the primary purpose of a device it would this address this nit? >=20 > You ask "Do we need to model metering capability at all"? Yes, because > smart meters, in particular sub-meters, are a key part of real time energy= > monitoring. You say 'yes' for modeling the metering capability. But if you only indicate= the capability for devices that have metering as their main funktion, then y= ou rather mean 'no'. What you want is not anymore capability modeling but de= vice categorization.=20 Cheers, Juergen=20 >=20 > Regards, >=20 > Brad >=20 > On 8/20/13 1:09 AM, "Juergen Quittek" wrote: >=20 >> Dear all,=20 >>=20 >> Here is another framework issue: How to model metering capabilities of >> devices? >>=20 >> Our framework draft (draft-ietf-eman-framework-08) models metering >> capability by categorizing devices and components into either a producer,= >> a comsumer, a meter, or a distributor, see pseudocode on page 43. >>=20 >> I think this approach is broken. It may be useful for modeling simple >> scenarios, but it does not work as general model. >>=20 >> There are two problems with this approach. >>=20 >> 1. The either-or classification. A meter is typically not just a meter, >> but as well a consumer that consumes energy when doing it's job. A PDU >> that meters power at it's outlets is a meter and a distributor and a >> consumer. The same holds for a PoE switch. These are not either meters or= >> consumers, they are meters and consumers and some of them are also >> distributors at the same time. >>=20 >> 2. The categorization as 'meter' is only available for devices and >> components, not for power interfaces. But obviously a device with >> metering capabilities meters at (some of) its interfaces. Take the PoE >> switch that meters power at some or all of its PoE outlets. It would be >> natural to label the power interfaces at which metering capabilities are >> available as 'metered'. It appears strange to classify the device as >> 'meter'.=20 >>=20 >> The basic question here is: Do we need to model metering capability at >> all? If yes, we should model it as an attribute, not as a category; and >> we should model it as attribute of the power interfaces as well. >>=20 >> BTW, if we model metering capability (monitoring), we should consequently= >> model circuit breaker capability (control) at power interfaces as well. >>=20 >> Cheers, >> Juergen >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >=20 From ietf@quittek.at Tue Aug 27 02:06:34 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7677721F9DC9 for ; Tue, 27 Aug 2013 02:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] 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 wU4IPfwZEJFq for ; Tue, 27 Aug 2013 02:06:25 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1227D21F9A6A for ; Tue, 27 Aug 2013 02:06:25 -0700 (PDT) Received: from [10.10.1.126] (65-60-110-235.static-ip.telepacific.net [65.60.110.235]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LlrOO-1Vna2n3pFg-00ZcCl; Tue, 27 Aug 2013 11:06:15 +0200 References: <5133F0CE-6966-4A20-B384-5E60587E2DF3@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5133F0CE-6966-4A20-B384-5E60587E2DF3@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Juergen Quittek Date: Tue, 27 Aug 2013 02:06:10 -0700 To: "John Parello (jparello)" X-Provags-ID: V02:K0:26ADDLoZNz7TFjJzjV5roD5Injnc6hDMUCVvw2gSFkA T3KeebSkoHCfDYFXT8w8IWP2EImhiwcgc83wPcFqBbk63d7o0M /UBIh955EvNv+DUENLOd1uCf+NZuI8HM2/L72YPKrxC3H52Tp6 s3emaOzAmqqIMFGeNk9AeXM6ocxNFVUX/+8Dxfn5cjJ092P9Y4 gdHLaKBNvm81m0yvohyod15L6D20dvetPqGIgcICKUBk1YAEJ/ lx3DUs65hhYmZPmzLzS97bjmhN7dnE0OzqC201oP846RDU/3hS U8BZKqtpw9h1U20H6RQQGCStglbUAVsk7kpuyaNaTBmt4irUSc 24TB1W8DJM6mZXYT+NB+7xwFxrV2kwY2Y1xkmwmT/AcYAMEmXO MWi6h4S0PUGng== Cc: eman mailing list Subject: Re: [eman] eman framework issue: How to model a meter? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 09:06:34 -0000 Hi John, I have the same answer to you as for Brad. What you want is categories for d= evices, not capability modeling.=20 Then my question is: do we need this? We live well in the Internet without p= robes having a MIB object saying: "I am a probe". Of course, a well designed network management system may classify devices an= d that is probably what EnergyWise does as well for meters, consumers, etc. T= he question is how much of the energy management system design needs to be p= ushed down to the devices? If we think we need more for energy management than we have so far needed fo= r managing traffic in the Internet, I would like to understand why.=20 Thanks, Juergen=20 Am 20.08.2013 um 10:39 schrieb "John Parello (jparello)" : > +1 on that Brad. >=20 > The category broadly classifies the device so a mgt system can determine i= f its behaving beyond its intent. For example power in the wrong direction f= rom a producer (motor or or solar panel for example) that starts to consume.= >=20 > So the category attribute answered the question "is a" >=20 > The power interface by their by their nature only measure power so it "is"= not a meter but "can" measure. A meter can contain power interfaces. >=20 > So if you are looking for a capability first I suggest not using the word= "meter" to answer that question. What you are looking for is "measure". =20= >=20 > A device is a "meter" and can "measure". An interface can "measure" but "= is not" a meter (a meter may contain multiple power interfaces). If you use t= he word "meter" there for capability then yes thats confusing but we are not= doing that. >=20 > See inline >=20 > Jp >=20 >=20 >=20 > Sent from my iPad=20 > (expect ridiculous spelling mistakes)=20 >=20 > On Aug 20, 2013, at 10:06 AM, "Brad Schoening" wrote: >=20 >> Juergen, >>=20 >> My experience has been that usually a meter was just a meter. While many= >> devices such as PoE switches and PDUs can internally meter, we have to >> recognize that there is a real use case for stand-alone metering. >> Intelligent smart meters from vendors such as Shark, SATEC, and Crompton >> are but a few examples of these widely used products An ethernet switch= >> is a device who's primary purpose is networking, but may have metering >> relationships. But a smart meter is a device with the primary purpose of= >> metering. =20 >>=20 >>=20 >> A common sense approach to classification should be more than adequate to= >> distinguish between products which consume energy to provide some >> function, products that primarily produce energy, and products which are >> designed for metering. If we clarify that classification should involve >> the primary purpose of a device it would this address this nit? >>=20 >> You ask "Do we need to model metering capability at all"? Yes, because >> smart meters, in particular sub-meters, are a key part of real time energ= y >> monitoring. >>=20 >> Regards, >>=20 >> Brad >>=20 >> On 8/20/13 1:09 AM, "Juergen Quittek" wrote: >>=20 >>> Dear all,=20 >>>=20 >>> Here is another framework issue: How to model metering capabilities of >>> devices? >>>=20 >>> Our framework draft (draft-ietf-eman-framework-08) models metering >>> capability by categorizing devices and components into either a producer= , >>> a comsumer, a meter, or a distributor, see pseudocode on page 43. >>>=20 >>> I think this approach is broken. It may be useful for modeling simple >>> scenarios, but it does not work as general model. >>>=20 >>> There are two problems with this approach. >>>=20 >>> 1. The either-or classification. A meter is typically not just a meter, >>> but as well a consumer that consumes energy when doing it's job. A PDU >>> that meters power at it's outlets is a meter and a distributor and a >>> consumer. The same holds for a PoE switch. These are not either meters o= r >>> consumers, they are meters and consumers and some of them are also >>> distributors at the same time. > [jp] for poe switch : is a "consumer", contains power interfaces that can "= measure". A switch is certainly not a meter. I proposed "distributor" as an= other category for pdu and/or a Poe switch. That may be clearer. >=20 > The model reads well to me with a clear distinction between category and c= apability to me. Don't see how that's broken unless you use meter as a capab= ility which I agree is wrong but we don't do that. >=20 >=20 >=20 >>> 2. The categorization as 'meter' is only available for devices and >>> components, not for power interfaces. But obviously a device with >>> metering capabilities meters at (some of) its interfaces. Take the PoE >>> switch that meters power at some or all of its PoE outlets. It would be >>> natural to label the power interfaces at which metering capabilities are= >>> available as 'metered'. It appears strange to classify the device as >>> 'meter'. > [jp] you're confusing "is a" versus "can" and overloading meter in both th= ose attributes. Meter is a classification not a capability. Measuring is the= capability. >=20 >=20 >>> The basic question here is: Do we need to model metering capability at >>> all? If yes, we should model it as an attribute, not as a category; and= >>> we should model it as attribute of the power interfaces as well. >=20 >>> BTW, if we model metering capability (monitoring), we should consequentl= y >>> model circuit breaker capability (control) at power interfaces as well. > [jp] sounds like you want an additional field for capabilities. We had tha= t in the model quite some time ago and from feedback deleted that from the M= ib and framework. Are your proposing we revisit that issue and then add capa= bility back? IMO and experience these capability type attributes need a regi= stry and then get used rather loosely when implemented. So I think it much s= impler to categorize devices and component broadly and then the capability i= s inferred from the presence of a measurement with caliber. Much simpler. >=20 > Jp From ietf@quittek.at Tue Aug 27 02:09:17 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E900021E80BF for ; Tue, 27 Aug 2013 02:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 fe9SFC1ZPY99 for ; Tue, 27 Aug 2013 02:09:12 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3C99A21E80B8 for ; Tue, 27 Aug 2013 02:09:11 -0700 (PDT) Received: from [10.10.1.126] (65-60-110-235.static-ip.telepacific.net [65.60.110.235]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0Lx0hB-1W7Ynz3iI5-016iKL; Tue, 27 Aug 2013 11:09:09 +0200 References: <3B0EE04D-E5F5-46C9-8539-E22FBEB07CE1@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-D31093E5-C968-47C0-94A5-D92578790580 Content-Transfer-Encoding: 7bit Message-Id: <667845EE-4EE9-4366-B850-8537E4875194@quittek.at> X-Mailer: iPhone Mail (10B329) From: Juergen Quittek Date: Tue, 27 Aug 2013 02:09:02 -0700 To: "John Parello (jparello)" X-Provags-ID: V02:K0:2lTbbG7tWSSK0WYRB11alGTsdxHKeAg+jmhZ7gLPVRb 91DbfWsLdcP7uCYprN/P0fsprExAGjuFmabZoFEXp2I3tcq66+ zWeNWYAbeNhdk27p4SV2dJI5OgIIKgCIdZymcyI5S/A33svzdH jNQ0l3xvDYHtgC8aHQPtnu54tTBDJyliO2FM1oNamhZMiX0ZZn L/pYOUpowbdTj6bw33UdhSnKskb127qBuvREF5SJqjogtKtHr3 oOvhPziAyMIRhHdxOrf554+qluM8IQ6+0gtf76Pu4EoPLNA1/G uFp/lseo7gNQVB6kBuv4TXu1MIOilqGtGSnE0tpbp/x4JXbZEP z/DA8RK+HO1F+zaoOYytmqWAzGEBtHBYSulPY6dqITFmMdMFXh eGRrzlgBQK/eA== Cc: eman mailing list Subject: Re: [eman] eman framework issue: How to model a meter? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 09:09:18 -0000 --Apple-Mail-D31093E5-C968-47C0-94A5-D92578790580 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Dear all, Unfortunately, I am not a native speaker. Can someone explain to me the exac= t difference between 'metering' and 'measuring'? Thanks, Juergen Am 20.08.2013 um 12:17 schrieb "John Parello (jparello)" : > Good catch let's change "perform metering" to "perform measuring" then yes= go with simple. >=20 > So broad categorization of the device/component and continue to leave comp= lex capability modeling out. >=20 > Jp >=20 > Sent from my iPad=20 > (expect ridiculous spelling mistakes)=20 >=20 > On Aug 20, 2013, at 11:44 AM, "Bruce Nordman" wrote: >=20 >> The current draft of the EMAN framework says: >> "A meter is a type Energy Object and any Energy Object can perform mete= ring." >>=20 >> This seems to indicate that devices can meter, components can meter, and p= ower >> interfaces can meter. On the other hand, Juergen notes that the meter cl= assification >> is not available to power interfaces. This appears to be a contradiction= . >>=20 >> It is possible to require declaring a "primary function" for a device, in= cluding whether it is a >> device that can only perform metering, but that seems to be an unnecessar= y complication >> and not derivative of any requirement. >>=20 >> Juergen's point is that metering (or measuring--I defer on that choice of= wording) can be >> simply and flexibly modeled as just a capability that any EO can have. I= t is unnecessary >> to make the Framework more complicated than that. There are plenty of ad= ditional >> complications that could be added that don't derive from any requirement.= >>=20 >> --Bruce >>=20 >>=20 >>=20 >> On Tue, Aug 20, 2013 at 10:51 AM, John Parello (jparello) wrote: >>>=20 >>> >>>=20 >>> > >>> > You ask "Do we need to model metering capability at all"? Yes, becaus= e >>> > smart meters, in particular sub-meters, are a key part of real time en= ergy >>> > monitoring. >>> > >>>=20 >>> Just to be clear we used "meter" is a type of device (which acknowledges= you other points, and if you want to model capability the value would be "m= easuring". So a "metering capability" doesn't make sense. It would be "measu= ring capability". >>>=20 >>> Again we removed the capabilities attribute. >>>=20 >>> After quite some years deploying these systems that distinction is secon= d nature for me but we should be precise. >>>=20 >>> Jp >>>=20 >>>=20 >>>=20 >>> > Regards, >>> > >>> > Brad >>> > >>> > On 8/20/13 1:09 AM, "Juergen Quittek" wrote: >>> > >>> >> Dear all, >>> >> >>> >> Here is another framework issue: How to model metering capabilities o= f >>> >> devices? >>> >> >>> >> Our framework draft (draft-ietf-eman-framework-08) models metering >>> >> capability by categorizing devices and components into either a produ= cer, >>> >> a comsumer, a meter, or a distributor, see pseudocode on page 43. >>> >> >>> >> I think this approach is broken. It may be useful for modeling simple= >>> >> scenarios, but it does not work as general model. >>> >> >>> >> There are two problems with this approach. >>> >> >>> >> 1. The either-or classification. A meter is typically not just a mete= r, >>> >> but as well a consumer that consumes energy when doing it's job. A PD= U >>> >> that meters power at it's outlets is a meter and a distributor and a >>> >> consumer. The same holds for a PoE switch. These are not either meter= s or >>> >> consumers, they are meters and consumers and some of them are also >>> >> distributors at the same time. >>> >> >>> >> 2. The categorization as 'meter' is only available for devices and >>> >> components, not for power interfaces. But obviously a device with >>> >> metering capabilities meters at (some of) its interfaces. Take the Po= E >>> >> switch that meters power at some or all of its PoE outlets. It would b= e >>> >> natural to label the power interfaces at which metering capabilities a= re >>> >> available as 'metered'. It appears strange to classify the device as >>> >> 'meter'. >>> >> >>> >> The basic question here is: Do we need to model metering capability a= t >>> >> all? If yes, we should model it as an attribute, not as a category; a= nd >>> >> we should model it as attribute of the power interfaces as well. >>> >> >>> >> BTW, if we model metering capability (monitoring), we should conseque= ntly >>> >> model circuit breaker capability (control) at power interfaces as wel= l. >>> >> >>> >> Cheers, >>> >> Juergen >>> >> _______________________________________________ >>> >> eman mailing list >>> >> eman@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/eman >>> > >>> > _______________________________________________ >>> > eman mailing list >>> > eman@ietf.org >>> > https://www.ietf.org/mailman/listinfo/eman >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman >>=20 >>=20 >>=20 >> --=20 >> Bruce Nordman >> Lawrence Berkeley National Laboratory >> nordman.lbl.gov >> BNordman@LBL.gov >> 510-486-7089 >> m: 510-501-7943 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-D31093E5-C968-47C0-94A5-D92578790580 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Dear all,

Unfortunately, I am not a native speaker. Can someone explain to me the exact difference between 'metering' and 'measuring'?

Thanks,
    Juergen

Am 20.08.2013 um 12:17 schrieb "John Parello (jparello)" <jparello@cisco.com>:

Good catch let's change "perform metering" to "perform measuring" then yes go with simple.

So broad categorization of the device/component and continue to leave complex capability modeling out.

Jp

Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Aug 20, 2013, at 11:44 AM, "Bruce Nordman" <bnordman@lbl.gov> wrote:

The current draft of the EMAN framework says:
  "A meter is a type Energy Object and any Energy Object can perform metering."

This seems to indicate that devices can meter, components can meter, and power
interfaces can meter.  On the other hand, Juergen notes that the meter classification
is not available to power interfaces.  This appears to be a contradiction.

It is possible to require declaring a "primary function" for a device, including whether it is a
device that can only perform metering, but that seems to be an unnecessary complication
and not derivative of any requirement.

Juergen's point is that metering (or measuring--I defer on that choice of wording) can be
simply and flexibly modeled as just a capability that any EO can have.  It is unnecessary
to make the Framework more complicated than that.  There are plenty of additional
complications that could be added that don't derive from any requirement.

--Bruce



On Tue, Aug 20, 2013 at 10:51 AM, John Parello (jparello) <jparello@cisco.com> wrote:

<snip>

>
> You ask "Do we need to model metering capability at all"?  Yes, because
> smart meters, in particular sub-meters, are a key part of real time energy
> monitoring.
>

Just to be clear we used "meter" is a type of device (which acknowledges you other points, and if you want to model capability the value would be "measuring". So a "metering capability" doesn't make sense. It would be "measuring capability".

Again we removed the capabilities attribute.

After quite some years deploying these systems that distinction is second  nature for me but we should be precise.

Jp



> Regards,
>
> Brad
>
> On 8/20/13 1:09 AM, "Juergen Quittek" <ietf@quittek.at> wrote:
>
>> Dear all,
>>
>> Here is another framework issue: How to model metering capabilities of
>> devices?
>>
>> Our framework draft (draft-ietf-eman-framework-08) models metering
>> capability by categorizing devices and components into either a producer,
>> a comsumer, a meter, or a distributor, see pseudocode on page 43.
>>
>> I think this approach is broken. It may be useful for modeling simple
>> scenarios, but it does not work as general model.
>>
>> There are two problems with this approach.
>>
>> 1. The either-or classification. A meter is typically not just a meter,
>> but as well a consumer that consumes energy when doing it's job. A PDU
>> that meters power at it's outlets is a meter and a distributor and a
>> consumer. The same holds for a PoE switch. These are not either meters or
>> consumers, they are meters and consumers and some of them are also
>> distributors at the same time.
>>
>> 2. The categorization as 'meter' is only available for devices and
>> components, not for power interfaces. But obviously a device with
>> metering capabilities meters at (some of) its interfaces. Take the PoE
>> switch that meters power at some or all of its PoE outlets. It would be
>> natural to label the power interfaces at which metering capabilities are
>> available as 'metered'. It appears strange to classify the device as
>> 'meter'.
>>
>> The basic question here is: Do we need to model metering capability at
>> all?  If yes, we should model it as an attribute, not as a category; and
>> we should model it as attribute of the power interfaces as well.
>>
>> BTW, if we model metering capability (monitoring), we should consequently
>> model circuit breaker capability (control) at power interfaces as well.
>>
>> Cheers,
>>  Juergen
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman



--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman
--Apple-Mail-D31093E5-C968-47C0-94A5-D92578790580-- From ietf@quittek.at Tue Aug 27 02:31:26 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE2721E80C9 for ; Tue, 27 Aug 2013 02:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 5kvtflUHbDTR for ; Tue, 27 Aug 2013 02:31:22 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC5721E80C6 for ; Tue, 27 Aug 2013 02:31:21 -0700 (PDT) Received: from [10.10.1.126] (65-60-110-235.static-ip.telepacific.net [65.60.110.235]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MbF3n-1VUPpG3zQZ-00Kdcd; Tue, 27 Aug 2013 11:31:20 +0200 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-8C807694-B1EC-442F-9870-E8D67BC152B4 Content-Transfer-Encoding: 7bit Message-Id: <21AD4998-825F-4C7F-819E-AB4045D5E178@quittek.at> X-Mailer: iPhone Mail (10B329) From: Juergen Quittek Date: Tue, 27 Aug 2013 02:31:12 -0700 To: Brad Schoening X-Provags-ID: V02:K0:twLEHrRtpJ8oE8DKnRoIGdOtRB1xBUs+tQMcGiQZbL2 aO5dzAfjqK/aPz9Xem0AMNYSNb4YejdLU3i0CNhWSU0TR/RwtP O3hA1eqSFJfeZ/6bS2lWgu2pZdm4PVneCc9L8YW2vblgJMJ88X 9FpgP1/nLzLBikKFRwN2bRRKjXy+AsgVclocoUK00rYPlbvKrC +94SjEysdDhTrhiScUTzWCP8gayWIdB9ullvUjNhCy+j16d9TK TlEzlrsBr2prMYpvklKP49qAkAsLOrIxA22JAafJj58q6Pypll uVUcZq7XKMu8yiCsyoALA3qs7QeBb8TK1yGV2z629o0oQtSQXw G8FjQYS1eJYk0hrMEcVAJOguArtCHy22P3RzBuVhc1miJanhTD Gf2dNqQGi2s0A== Cc: eman mailing list Subject: Re: [eman] eman framework issue: Do we start from a software design or do we start from the physical world? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 09:31:26 -0000 --Apple-Mail-8C807694-B1EC-442F-9870-E8D67BC152B4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Dear Brad,=20 Thank you for picking the ASHRAE example. It fully illustrates my concern.=20= If you read the text before the ASHRAE model elaboration that you cited on p= age 26, you will find on page 10 that ASHRAE first says > 3.1.21. Meter > "Meters are devices which measure the amount of electricity used at a part= icular site. ..." So ASHRAE exactly follows the approach to FIRST talk about the real world an= d THEN about a model of it.=20 We should follow the same approach in eman.=20 Cheers, Juergen=20 Am 20.08.2013 um 14:10 schrieb Brad Schoening : > Bruce & Juergen, >=20 > NIST uses the same modeling language and creates a meter as a distinct cla= ss of device, so we appear to be in good company. >=20 > For example, pg 29 of ASHRAE 201 'Facility Smart Grid Information Model': >=20 > ElectricMeter (Class) > The ElectricMeter Class is a subclass of the Meter Class. It is an abstrac= t representation of devices that measure real > optionally reactive, energy consumption. These devices optionally measure o= ther electrical parameters such as Present > Subinterval Demand or Power Quality. >=20 > Brad Schoening > Engineering | Coraid > Tel: +1 917 304 7190 > brads@coraid.com | www.coraid.com=20 > Coraid: Redefining Storage >=20 >=20 > From: Bruce Nordman > Date: Tue, 20 Aug 2013 12:24:03 -0700 > To: Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] eman framework issue: Do we start from a software desi= gn or do we start from the physical world? >=20 > I concur with Juergen's concern about how to approach the Framework. > A key concern I have is that the software modeling approach seems to > lead to a document which has more apparent complexity to the reader > than the alternative. I say apparent because for implementation, the > result might be the same. However, the apparent complexity is likely > to deter some people from implementing or using EMAN at all. > --Bruce >=20 >=20 > On Tue, Aug 13, 2013 at 2:17 AM, Juergen Quittek wrote: >> Dear all,=20 >>=20 >> Before the IETF meeting I posted high-level comments on the new version o= f our framework draft (draft-ietf-eman-framework-08) and on the alternative f= ramework proposal from Bruce (draft-nordman-eman-er-framework-01).=20 >>=20 >> Now I send a series of individuals mails each focusing on a particular is= sue that I found in one or the other draft. For each issue I try to point ou= t how the drafts address it and what the differences are.=20 >>=20 >> My first point is about our very general approach to describe the eman fr= amework: Do we start with describing a software design and map this to the r= eal world? Or do we start with describing the physical world an derive a mod= el from it? >>=20 >> The two drafts are quite different in that respect. draft-ietf-eman-frame= work-08 (EMAN Framework) rather develops the framework from a software model= while draft-nordman-eman-er-framework-01 (ER Framework) starts from the phy= sical world. Here is an example that illustrate the difference.=20 >>=20 >> EMAN Framework section 4.2 Energy Object: >>> 4.2 Energy Object >>> An Energy Object is an abstract class that contains the base attributes f= or Energy Management. There are three types of Energy Objects: Device, Comp= onent and Power Interface. >>=20 >>=20 >> ER Framework, section 2.5 Energy Object: >>> 2.5. Energy Object =20 >>> Devices, Power Interfaces, and Components are all Energy Objects (EOs). T= he term "entity" in the Requirements draft generally corresponds to Energy O= bject. The kinds of data available for an EO depends on its type as shown in= Figure 1. >>=20 >>=20 >> This is just one example out of many similar instances that can easily be= found in those drafts.=20 >>=20 >> The different choices made by the drafts result in different ways of desc= ribing the framework.=20 >>=20 >> The ER Framework describes which information is reported for an Energy Ob= ject (power, state, voltage, etc.) while the EMAN framework tells us which a= ttributes (power, state, voltage, etc) the class Energy Object has.=20 >>=20 >> So the basic question that occurs to me is: Do we want to define our ener= gy management framework as an object-oriented (software) model or do we want= to describe a view of physical systems? >>=20 >> This would be the core question to be answered for addressing this issue.= =20 >>=20 >> Of course, in the end we need a data model for interoperable exchange of i= nformation based on our framework.=20 >> But for this purpose we already have other documents. Here the candidates= for are MIB modules using SMI that do not support the concepts of classes a= nd inheritance (which also holds for YANG modules using XML).=20 >> : >> Cheers, >> Juergen >>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >=20 >=20 >=20 > --=20 > Bruce Nordman > Lawrence Berkeley National Laboratory > nordman.lbl.gov > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > _______________________________________________ eman mailing list eman@iet= f.org https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-8C807694-B1EC-442F-9870-E8D67BC152B4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear Brad, 

<= div>Thank you for picking the ASHRAE example. It fully illustrates my concer= n. 

If you read the text before the ASHRAE model elaboration that you cite= d on page 26, you will find on page 10 that ASHRAE first says

3.1.21= . Meter
"Me= ters are devices which measure the amount of electricity used at a particula= r site. ..."

So ASHRAE exactly follows the approach to FIRST talk about the real= world and THEN about a model of it. 

We should follow the same approach in eman. 

<= /div>
Cheers,
    Juergen=  


Am 20.08.2013 um 14:10 schrieb Brad Schoening= <brads@coraid.com>:

=
Bruce & Juergen,

NIST uses the same modeling language and creates a meter as a distinct c= lass of device, so we appear to be in good company.

For example, pg 29 of ASHRAE 201 'Facility Smart Grid Information Model= ':

ElectricMeter (Class)
The ElectricMeter Class is a subclass of the Meter Class. It is an abst= ract representation of devices that measure real
optionally reactive, energy consumption. These devices optionally measu= re other electrical parameters such as Present
Subinterval Demand or Power Quality.

Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190
brads@coraid.com | www.coraid.com
Coraid: Redefining= Storage


From: Bruce Nordman <bnordman@lbl.gov>
Date: Tue, 20 Aug 2013 12:24:03 -070= 0
To: Juergen Quittek <ietf@quittek.at>
Cc: eman mailing list <eman@ietf.org>
Subject: Re: [eman] eman framework i= ssue: Do we start from a software design or do we start from the physical wo= rld?

I concur with Juergen's concern about how to approach the Framework. A key concern I have is that the software modeling approach seems to
lead to a document which has more apparent complexity to the reader
than the alternative.   I say apparent because for implementation,= the
result might be the same.  However, the apparent complexity is likely to deter some people from implementing or using EMAN at all.
--Bruce


On Tue, Aug 13, 2013 at 2:17 AM, Juergen Quittek <= span dir=3D"ltr"> <ietf@quittek.at= > wrote:
Dear all, 

Before the IETF meeting I posted high-level comments on the new version= of our framework draft (draft-ietf-eman-framework-08) and on the alternativ= e framework proposal from Bruce (draft-nordman-eman-er-framework-01). <= /div>

Now I send a series of individuals mails each focusing on a particular i= ssue that I found in one or the other draft. For each issue I try to point o= ut how the drafts address it and what the differences are. 

My first point is about our very general approach to describe the eman f= ramework: Do we start with describing a software design and map this to the r= eal world? Or do we start with describing the physical world an derive a mod= el from it?

The two drafts are quite different in that respect. draft-ie= tf-eman-framework-08 (EMAN Framework) rather develops the framework from a s= oftware model while draft-nordman-eman-er-framework-01 (ER= Framework) starts from the physical world. Here is an example that illustrate the difference. 

EMAN Framework section 4.2 Energy Object:
        4.2 Energy Object
An Energy Object is an abstract class that conta=
ins the base=20
        attributes for Energy Management.  There are three types of=20
        Energy Objects: Device, Component and Power Interface.=

ER Framework, section 2.5 Energy Object:
2.5.  Energy Object  
Devices, Power Int=
erfaces, and Components are all Energy Objects (EOs).  The term
   "entity" in the Requirements draft generally corresponds to Energy
   Object.  The kinds of data available for an EO depends on its type as
   shown in Figure 1.

This is just one example out of many similar instances that can e= asily be found in those drafts. 

The different choices made by the drafts result in different ways= of describing the framework. 

The ER Framework describes which information is reported for an E= nergy Object (power, state, voltage, etc.) while the EMAN framework tells us= which attributes (power, state, voltage, etc) the class Energy Object has. 

So the basic question that occurs to me is: Do we want to define o= ur energy management framework as an object-oriented (software) model or do w= e want to describe a view of physical systems?

This would be the core question to be answered for addressing thi= s issue. 

Of course, in the end we need a data model for interoperable exch= ange of information based on our framework. 
But for this purpose we already have other documents. Here the ca= ndidates for  are MIB modules using SMI that do not support the concept= s of classes and inheritance (which also holds for YANG mo= dules using XML). 
:
Cheers,
    Juergen

_______________________________________________
eman mailing list
eman@ietf.org
htt= ps://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
_______________________________________________ eman mailing list eman@ietf.org htt= ps://www.ietf.org/mailman/listinfo/eman
= --Apple-Mail-8C807694-B1EC-442F-9870-E8D67BC152B4-- From brads@coraid.com Tue Aug 27 07:23:54 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232BB11E834B for ; Tue, 27 Aug 2013 07:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0cEOsi08YSg for ; Tue, 27 Aug 2013 07:23:45 -0700 (PDT) Received: from server506.appriver.com (server506i.appriver.com [50.56.144.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2F74A11E8354 for ; Tue, 27 Aug 2013 07:23:43 -0700 (PDT) X-Note-AR-ScanTimeLocal: 8/27/2013 9:23:40 AM X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Primary: brads@coraid.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-180/SG:5 8/27/2013 9:23:17 AM X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.939696 Source White X-Signature-Violations: 0-0-0-28427-c X-Note-419: 31.2 ms. Fail:0 Chk:1343 of 1343 total X-Note: SCH-CT/SI:0-1343/SG:1 8/27/2013 9:23:31 AM X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->PRIVATE->UNITED STATES X-Note-Sending-IP: 10.242.229.139 X-Note-Reverse-DNS: X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G340 G341 G342 G343 G347 G348 G455 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 12562255; Tue, 27 Aug 2013 09:23:39 -0500 Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.218]) by HT02-E6.exg6.exghost.com ([50.56.144.20]) with mapi id 14.03.0158.001; Tue, 27 Aug 2013 09:23:36 -0500 From: Brad Schoening To: Juergen Quittek , "John Parello (jparello)" Thread-Topic: [eman] eman framework issue: How to model a meter? Thread-Index: AQHOnXyszg2BALUwJE2Ri+M1j328Q5meMmYAgACCUYCAAA6xAIAACSGAgApWdACAABTOAA== Date: Tue, 27 Aug 2013 14:23:36 +0000 Message-ID: In-Reply-To: <667845EE-4EE9-4366-B850-8537E4875194@quittek.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [50.56.144.247] x-rerouted-by-exchange: Content-Type: multipart/alternative; boundary="_000_CE422A2FD57B1bradscoraidcom_" MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] eman framework issue: How to model a meter? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 14:23:54 -0000 --_000_CE422A2FD57B1bradscoraidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, Metering is generally used when there is a continuos flow with the amount t= otalized. Metering is usually facilitated by the presence of a physical me= ter which may have to meet regulatory requirements. In the US, electric me= ters are divided into "Revenue Grade" and "Non-Revenue Grade" classes. This is a noteworthy point, as an electrical device such as a PoE switch ma= y be able to measure its instantaneous energy consumption, but typically do= esn't have the ability to meter it and totalized it over time periods. Regards, Brad From: Juergen Quittek > Date: Tue, 27 Aug 2013 02:09:02 -0700 To: "John Parello (jparello)" > Cc: eman mailing list > Subject: Re: [eman] eman framework issue: How to model a meter? Dear all, Unfortunately, I am not a native speaker. Can someone explain to me the exa= ct difference between 'metering' and 'measuring'? Thanks, Juergen Am 20.08.2013 um 12:17 schrieb "John Parello (jparello)" >: Good catch let's change "perform metering" to "perform measuring" then yes = go with simple. So broad categorization of the device/component and continue to leave compl= ex capability modeling out. Jp Sent from my iPad (expect ridiculous spelling mistakes) On Aug 20, 2013, at 11:44 AM, "Bruce Nordman" > wrote: The current draft of the EMAN framework says: "A meter is a type Energy Object and any Energy Object can perform meteri= ng." This seems to indicate that devices can meter, components can meter, and po= wer interfaces can meter. On the other hand, Juergen notes that the meter clas= sification is not available to power interfaces. This appears to be a contradiction. It is possible to require declaring a "primary function" for a device, incl= uding whether it is a device that can only perform metering, but that seems to be an unnecessary = complication and not derivative of any requirement. Juergen's point is that metering (or measuring--I defer on that choice of w= ording) can be simply and flexibly modeled as just a capability that any EO can have. It = is unnecessary to make the Framework more complicated than that. There are plenty of addi= tional complications that could be added that don't derive from any requirement. --Bruce On Tue, Aug 20, 2013 at 10:51 AM, John Parello (jparello) > wrote: > > You ask "Do we need to model metering capability at all"? Yes, because > smart meters, in particular sub-meters, are a key part of real time energ= y > monitoring. > Just to be clear we used "meter" is a type of device (which acknowledges yo= u other points, and if you want to model capability the value would be "mea= suring". So a "metering capability" doesn't make sense. It would be "measur= ing capability". Again we removed the capabilities attribute. After quite some years deploying these systems that distinction is second = nature for me but we should be precise. Jp > Regards, > > Brad > > On 8/20/13 1:09 AM, "Juergen Quittek" > wrote: > >> Dear all, >> >> Here is another framework issue: How to model metering capabilities of >> devices? >> >> Our framework draft (draft-ietf-eman-framework-08) models metering >> capability by categorizing devices and components into either a producer= , >> a comsumer, a meter, or a distributor, see pseudocode on page 43. >> >> I think this approach is broken. It may be useful for modeling simple >> scenarios, but it does not work as general model. >> >> There are two problems with this approach. >> >> 1. The either-or classification. A meter is typically not just a meter, >> but as well a consumer that consumes energy when doing it's job. A PDU >> that meters power at it's outlets is a meter and a distributor and a >> consumer. The same holds for a PoE switch. These are not either meters o= r >> consumers, they are meters and consumers and some of them are also >> distributors at the same time. >> >> 2. The categorization as 'meter' is only available for devices and >> components, not for power interfaces. But obviously a device with >> metering capabilities meters at (some of) its interfaces. Take the PoE >> switch that meters power at some or all of its PoE outlets. It would be >> natural to label the power interfaces at which metering capabilities are >> available as 'metered'. It appears strange to classify the device as >> 'meter'. >> >> The basic question here is: Do we need to model metering capability at >> all? If yes, we should model it as an attribute, not as a category; and >> we should model it as attribute of the power interfaces as well. >> >> BTW, if we model metering capability (monitoring), we should consequentl= y >> model circuit breaker capability (control) at power interfaces as well. >> >> Cheers, >> Juergen >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf= .org https://www.ietf.org/mailman/listinfo/eman --_000_CE422A2FD57B1bradscoraidcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1FB9716C250771419620C44E962E3F71@fwd6.exghost.com> Content-Transfer-Encoding: quoted-printable
Juergen,

Metering is generally used when there is a continuos flow with the amo= unt totalized.  Metering is usually facilitated by the presence of a p= hysical meter which may have to meet regulatory requirements.  In the = US, electric meters are divided into "Revenue Grade" and "Non-Revenue Grade" classes.

This is a noteworthy point, as an electrical device such as a PoE swit= ch may be able to measure its instantaneous energy consumption, but typical= ly doesn't have the ability to meter it and totalized it over time periods.=

Regards,

Brad

From: Juergen Quittek <ietf@quittek.at>
Date: Tue, 27 Aug 2013 02:09:02 -07= 00
To: "John Parello (jparello)&q= uot; <jparello@cisco.com> Cc: eman mailing list <eman@ietf.org>
Subject: Re: [eman] eman framework = issue: How to model a meter?

Dear all,

Unfortunately, I am not a native speaker. Can someone explain to me th= e exact difference between 'metering' and 'measuring'?

Thanks,
    Juergen

Am 20.08.2013 um 12:17 schrieb "John Parello (jparello)" <jparello@cisco.com>:

Good catch let's change "perform metering" to "perform = measuring" then yes go with simple.

So broad categorization of the device/component and continue to leave = complex capability modeling out.

Jp

Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Aug 20, 2013, at 11:44 AM, "Bruce Nordman" <bnordman@lbl.gov> wrote:

The current draft of the EMAN framework says:
  "A meter is= a type Energy Object and any Energy Object can perform metering."

This seems to indicate that devices can meter, components can meter, and po= wer
interfaces can meter.  On the other hand, Juergen notes that the meter= classification
is not available to power interfaces.  This appears to be a contradict= ion.

It is possible to require declaring a "primary function" for a de= vice, including whether it is a
device that can only perform metering, but that seems to be an unnecessary = complication
and not derivative of any requirement.

Juergen's point is that metering (or measuring--I defer on that choice of w= ording) can be
simply and flexibly modeled as just a capability that any EO can have. = ; It is unnecessary
to make the Framework more complicated than that.  There are plenty of= additional
complications that could be added that don't derive from any requirement.
--Bruce



On Tue, Aug 20, 2013 at 10:51 AM, John Parello (= jparello) <jparello@cisco.com> wrote:

<snip>

>
> You ask "Do we need to model metering capability at all"? &n= bsp;Yes, because
> smart meters, in particular sub-meters, are a key part of real time en= ergy
> monitoring.
>

Just to be clear we used "meter" is a type of device (which ackno= wledges you other points, and if you want to model capability the value wou= ld be "measuring". So a "metering capability" doesn't m= ake sense. It would be "measuring capability".

Again we removed the capabilities attribute.

After quite some years deploying these systems that distinction is second &= nbsp;nature for me but we should be precise.

Jp



> Regards,
>
> Brad
>
> On 8/20/13 1:09 AM, "Juergen Quittek" <ietf@quittek.at> wrote:
>
>> Dear all,
>>
>> Here is another framework issue: How to model metering capabilitie= s of
>> devices?
>>
>> Our framework draft (draft-ietf-eman-framework-08) models metering=
>> capability by categorizing devices and components into either a pr= oducer,
>> a comsumer, a meter, or a distributor, see pseudocode on page 43.<= br> >>
>> I think this approach is broken. It may be useful for modeling sim= ple
>> scenarios, but it does not work as general model.
>>
>> There are two problems with this approach.
>>
>> 1. The either-or classification. A meter is typically not just a m= eter,
>> but as well a consumer that consumes energy when doing it's job. A= PDU
>> that meters power at it's outlets is a meter and a distributor and= a
>> consumer. The same holds for a PoE switch. These are not either me= ters or
>> consumers, they are meters and consumers and some of them are also=
>> distributors at the same time.
>>
>> 2. The categorization as 'meter' is only available for devices and=
>> components, not for power interfaces. But obviously a device with<= br> >> metering capabilities meters at (some of) its interfaces. Take the= PoE
>> switch that meters power at some or all of its PoE outlets. It wou= ld be
>> natural to label the power interfaces at which metering capabiliti= es are
>> available as 'metered'. It appears strange to classify the device = as
>> 'meter'.
>>
>> The basic question here is: Do we need to model metering capabilit= y at
>> all?  If yes, we should model it as an attribute, not as a ca= tegory; and
>> we should model it as attribute of the power interfaces as well. >>
>> BTW, if we model metering capability (monitoring), we should conse= quently
>> model circuit breaker capability (control) at power interfaces as = well.
>>
>> Cheers,
>>  Juergen
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://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
_______________________________________________
eman mailing list
eman@ietf.org
https://www.ie= tf.org/mailman/listinfo/eman
_______________________________________________ eman mailing list eman@ietf.org ht= tps://www.ietf.org/mailman/listinfo/eman --_000_CE422A2FD57B1bradscoraidcom_-- From jparello@cisco.com Tue Aug 27 08:08:27 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052BC11E8313 for ; Tue, 27 Aug 2013 08:08:27 -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=[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 3xxedDhOCRKb for ; Tue, 27 Aug 2013 08:08:22 -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 2AB3811E819D for ; Tue, 27 Aug 2013 08:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20152; q=dns/txt; s=iport; t=1377616102; x=1378825702; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KxdIRMBBISNMueXGDTqThXorG9GPj0iT2Cc09RT1iHQ=; b=gnuZ4s2f621Qv66sV9lxTveRt8OMboFt8gPhRk8nlwSo2vhMUhCezrYu qDrO20doktoD4n5JZ88CuySrCeUquSTr9mMnUC1o3z/q6I7u0V6ZTsnsA LQqhyMoGXf0+UiUy7LF4Rgdy2/+LeJ0O97NRhfidNjGcrdoLVJLiLI0I1 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAG3AHFKtJV2d/2dsb2JhbABWA4JDRDVRt2aIPYEjFnSCJAEBAQMBAQEBawsFCwIBCBEDAQEBAQodBycLFAkIAgQBDQUIh3MFAQy4Vo4sgQcgAQwEBgEJCIMLfQOIeZAjkDODIIIq X-IronPort-AV: E=Sophos;i="4.89,968,1367971200"; d="scan'208,217";a="252162292" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 27 Aug 2013 15:08:21 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7RF8LKx023703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Aug 2013 15:08:21 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.176]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 27 Aug 2013 10:08:20 -0500 From: "John Parello (jparello)" To: Brad Schoening , Juergen Quittek Thread-Topic: [eman] eman framework issue: How to model a meter? Thread-Index: AQHOnXyq7tpuq+6Q/0CDBwtkFHCxz5mep8EA//+5JWSAAGKCAP//tVB9gAqqRQCAAFfjAP//tokR Date: Tue, 27 Aug 2013 15:08:19 +0000 Message-ID: <9C213D38848B89428F46808B16F6F086015DF300@xmb-aln-x04.cisco.com> References: <667845EE-4EE9-4366-B850-8537E4875194@quittek.at>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.223.104] Content-Type: multipart/alternative; boundary="_000_9C213D38848B89428F46808B16F6F086015DF300xmbalnx04ciscoc_" MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] eman framework issue: How to model a meter? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 15:08:27 -0000 --_000_9C213D38848B89428F46808B16F6F086015DF300xmbalnx04ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Brad, JQ to answer your two question I think Brad addressed the latter it but in = simple language terms. A meter (n) is a device that measures (v) thus perfo= rms metering(g). simple reference: http://en.wikipedia.org/wiki/Electricity_meter Your second question and comment on category we seem to agree. The attribut= e is category so yes I was modeling category not capability and labelled t= he attribute as such. As to why we would need categorization you contended that we don't do that = in internet modeling of devices today. We do. Each mib is a broad classific= ation and I added category so as to simplify the need for sub-classes of bo= th devices and components. For non mib implementation this is simpler than= subclassing both device and component. As Brad references from 201p they have classes to distinguish these categor= ies we can certainly do that if that's clearer but imo a category was simpl= er and would lead to fewer MIBs and keep it simple with device and componen= t. Jp ________________________________ From: Brad Schoening [brads@coraid.com] Sent: Tuesday, August 27, 2013 7:23 AM To: Juergen Quittek; John Parello (jparello) Cc: eman mailing list Subject: Re: [eman] eman framework issue: How to model a meter? Juergen, Metering is generally used when there is a continuos flow with the amount t= otalized. Metering is usually facilitated by the presence of a physical me= ter which may have to meet regulatory requirements. In the US, electric me= ters are divided into "Revenue Grade" and "Non-Revenue Grade" classes. This is a noteworthy point, as an electrical device such as a PoE switch ma= y be able to measure its instantaneous energy consumption, but typically do= esn't have the ability to meter it and totalized it over time periods. Regards, Brad From: Juergen Quittek > Date: Tue, 27 Aug 2013 02:09:02 -0700 To: "John Parello (jparello)" > Cc: eman mailing list > Subject: Re: [eman] eman framework issue: How to model a meter? Dear all, Unfortunately, I am not a native speaker. Can someone explain to me the exa= ct difference between 'metering' and 'measuring'? Thanks, Juergen Am 20.08.2013 um 12:17 schrieb "John Parello (jparello)" >: Good catch let's change "perform metering" to "perform measuring" then yes = go with simple. So broad categorization of the device/component and continue to leave compl= ex capability modeling out. Jp Sent from my iPad (expect ridiculous spelling mistakes) On Aug 20, 2013, at 11:44 AM, "Bruce Nordman" > wrote: The current draft of the EMAN framework says: "A meter is a type Energy Object and any Energy Object can perform meteri= ng." This seems to indicate that devices can meter, components can meter, and po= wer interfaces can meter. On the other hand, Juergen notes that the meter clas= sification is not available to power interfaces. This appears to be a contradiction. It is possible to require declaring a "primary function" for a device, incl= uding whether it is a device that can only perform metering, but that seems to be an unnecessary = complication and not derivative of any requirement. Juergen's point is that metering (or measuring--I defer on that choice of w= ording) can be simply and flexibly modeled as just a capability that any EO can have. It = is unnecessary to make the Framework more complicated than that. There are plenty of addi= tional complications that could be added that don't derive from any requirement. --Bruce On Tue, Aug 20, 2013 at 10:51 AM, John Parello (jparello) > wrote: > > You ask "Do we need to model metering capability at all"? Yes, because > smart meters, in particular sub-meters, are a key part of real time energ= y > monitoring. > Just to be clear we used "meter" is a type of device (which acknowledges yo= u other points, and if you want to model capability the value would be "mea= suring". So a "metering capability" doesn't make sense. It would be "measur= ing capability". Again we removed the capabilities attribute. After quite some years deploying these systems that distinction is second = nature for me but we should be precise. Jp > Regards, > > Brad > > On 8/20/13 1:09 AM, "Juergen Quittek" > wrote: > >> Dear all, >> >> Here is another framework issue: How to model metering capabilities of >> devices? >> >> Our framework draft (draft-ietf-eman-framework-08) models metering >> capability by categorizing devices and components into either a producer= , >> a comsumer, a meter, or a distributor, see pseudocode on page 43. >> >> I think this approach is broken. It may be useful for modeling simple >> scenarios, but it does not work as general model. >> >> There are two problems with this approach. >> >> 1. The either-or classification. A meter is typically not just a meter, >> but as well a consumer that consumes energy when doing it's job. A PDU >> that meters power at it's outlets is a meter and a distributor and a >> consumer. The same holds for a PoE switch. These are not either meters o= r >> consumers, they are meters and consumers and some of them are also >> distributors at the same time. >> >> 2. The categorization as 'meter' is only available for devices and >> components, not for power interfaces. But obviously a device with >> metering capabilities meters at (some of) its interfaces. Take the PoE >> switch that meters power at some or all of its PoE outlets. It would be >> natural to label the power interfaces at which metering capabilities are >> available as 'metered'. It appears strange to classify the device as >> 'meter'. >> >> The basic question here is: Do we need to model metering capability at >> all? If yes, we should model it as an attribute, not as a category; and >> we should model it as attribute of the power interfaces as well. >> >> BTW, if we model metering capability (monitoring), we should consequentl= y >> model circuit breaker capability (control) at power interfaces as well. >> >> Cheers, >> Juergen >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf= .org https://www.ietf.org/mailman/listinfo/eman --_000_9C213D38848B89428F46808B16F6F086015DF300xmbalnx04ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks Brad,

JQ to answer your two question I think Brad addressed the latter it but in = simple language terms. A meter (n) is a device that measures (v) thus perfo= rms metering(g).

simple reference: http://en.wikipedia.org/wiki/Electricity_meter

Your second question and comment on category we seem to agree. The attribut= e  is category so yes I was modeling category not capability and label= led the attribute as such.

As to why we would need categorization you contended that we don't do that = in internet modeling of devices today. We do. Each mib is a broad classific= ation and I added category so as to simplify the need for sub-classes of bo= th devices and components.  For non mib implementation this is simpler than subclassing both device and co= mponent.

As Brad references from 201p they have classes to distinguish these categor= ies we can certainly do that if that's clearer but imo a category was simpl= er and would lead to fewer MIBs and keep it simple with device and componen= t.


Jp


From: Brad Schoening [brads@coraid.com]=
Sent: Tuesday, August 27, 2013 7:23 AM
To: Juergen Quittek; John Parello (jparello)
Cc: eman mailing list
Subject: Re: [eman] eman framework issue: How to model a meter?

Juergen,

Metering is generally used when there is a continuos flow with the amo= unt totalized.  Metering is usually facilitated by the presence of a p= hysical meter which may have to meet regulatory requirements.  In the = US, electric meters are divided into "Revenue Grade" and "Non-Revenue Grade" classes.

This is a noteworthy point, as an electrical device such as a PoE swit= ch may be able to measure its instantaneous energy consumption, but typical= ly doesn't have the ability to meter it and totalized it over time periods.=

Regards,

Brad

From: Juergen Quittek <ietf@quittek.at>
Date: Tue, 27 Aug 2013 02:09:02 -07= 00
To: "John Parello (jparello)&q= uot; <jparello@c= isco.com>
Cc: eman mailing list <eman@ietf.org>
Subject: Re: [eman] eman framework = issue: How to model a meter?

Dear all,

Unfortunately, I am not a native speaker. Can someone explain to me th= e exact difference between 'metering' and 'measuring'?

Thanks,
    Juergen

Am 20.08.2013 um 12:17 schrieb "John Parello (jparello)" <jparello@cisco.com&= gt;:

Good catch let's change "perform metering" to "perform = measuring" then yes go with simple.

So broad categorization of the device/component and continue to leave = complex capability modeling out.

Jp

Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Aug 20, 2013, at 11:44 AM, "Bruce Nordman" <bnordman@lbl.gov> wrote:

The current draft of the EMAN framework says:
  "A meter i= s a type Energy Object and any Energy Object can perform metering."

This seems to indicate that devices can meter, components can meter, and po= wer
interfaces can meter.  On the other hand, Juergen notes that the meter= classification
is not available to power interfaces.  This appears to be a contradict= ion.

It is possible to require declaring a "primary function" for a de= vice, including whether it is a
device that can only perform metering, but that seems to be an unnecessary = complication
and not derivative of any requirement.

Juergen's point is that metering (or measuring--I defer on that choice of w= ording) can be
simply and flexibly modeled as just a capability that any EO can have. = ; It is unnecessary
to make the Framework more complicated than that.  There are plenty of= additional
complications that could be added that don't derive from any requirement.
--Bruce



On Tue, Aug 20, 2013 at 10:51 AM, John Parello (= jparello) <jparello@cisco.com> wrote:

<snip>

>
> You ask "Do we need to model metering capability at all"? &n= bsp;Yes, because
> smart meters, in particular sub-meters, are a key part of real time en= ergy
> monitoring.
>

Just to be clear we used "meter" is a type of device (which ackno= wledges you other points, and if you want to model capability the value wou= ld be "measuring". So a "metering capability" doesn't m= ake sense. It would be "measuring capability".

Again we removed the capabilities attribute.

After quite some years deploying these systems that distinction is second &= nbsp;nature for me but we should be precise.

Jp



> Regards,
>
> Brad
>
> On 8/20/13 1:09 AM, "Juergen Quittek" <ietf@quittek.at> wrote:
>
>> Dear all,
>>
>> Here is another framework issue: How to model metering capabilitie= s of
>> devices?
>>
>> Our framework draft (draft-ietf-eman-framework-08) models metering=
>> capability by categorizing devices and components into either a pr= oducer,
>> a comsumer, a meter, or a distributor, see pseudocode on page 43.<= br> >>
>> I think this approach is broken. It may be useful for modeling sim= ple
>> scenarios, but it does not work as general model.
>>
>> There are two problems with this approach.
>>
>> 1. The either-or classification. A meter is typically not just a m= eter,
>> but as well a consumer that consumes energy when doing it's job. A= PDU
>> that meters power at it's outlets is a meter and a distributor and= a
>> consumer. The same holds for a PoE switch. These are not either me= ters or
>> consumers, they are meters and consumers and some of them are also=
>> distributors at the same time.
>>
>> 2. The categorization as 'meter' is only available for devices and=
>> components, not for power interfaces. But obviously a device with<= br> >> metering capabilities meters at (some of) its interfaces. Take the= PoE
>> switch that meters power at some or all of its PoE outlets. It wou= ld be
>> natural to label the power interfaces at which metering capabiliti= es are
>> available as 'metered'. It appears strange to classify the device = as
>> 'meter'.
>>
>> The basic question here is: Do we need to model metering capabilit= y at
>> all?  If yes, we should model it as an attribute, not as a ca= tegory; and
>> we should model it as attribute of the power interfaces as well. >>
>> BTW, if we model metering capability (monitoring), we should conse= quently
>> model circuit breaker capability (control) at power interfaces as = well.
>>
>> Cheers,
>>  Juergen
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>
> _______________________________________________
> eman mailing list
> eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman
_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman



--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov<= br> 510-486-7089
m: 510-501-7943
_______________________________________________
eman mailing list
eman@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/eman
_______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman
--_000_9C213D38848B89428F46808B16F6F086015DF300xmbalnx04ciscoc_-- From jparello@cisco.com Tue Aug 27 08:58:42 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A02E21E80EF for ; Tue, 27 Aug 2013 08:58:42 -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=[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 fkwvZB45ZKZ3 for ; Tue, 27 Aug 2013 08:58:35 -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 1C40D21E80F0 for ; Tue, 27 Aug 2013 08:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33971; q=dns/txt; s=iport; t=1377619099; x=1378828699; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=80JvmUQ+tSH81W2R/RL1LNUaGEC+ZcIBCDtjaCiQ/S0=; b=ABjwLGf3LmjOn/zqHTVfnxNlEJGnDHMGzN7eCElbrTYc32i77E9p2Tsw Di2AXt2VjPiNXFnMI6jCseF1QuyKMPygG30jX+7L34zVEWl03+hyTLUKr x0jRpNqmBHCReD1j+Yk1bXHhVRGqfTq5WfJCq53NyoeHZHSRpcidGDbFP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFACLMHFKtJV2c/2dsb2JhbABWA4JDRDVRt2aIPYEjFnSCJAEBAQQBAQEkIiULEAIBCA4DAwEBAQsWAQIEBycLFAkIAgQBDQUIh3gBDLhYjiwFCnggAQYGBAYBCQiDC30DhUmDMIoDhiCQM4FjgT2BaUE X-IronPort-AV: E=Sophos;i="4.89,968,1367971200"; d="scan'208,217";a="249213115" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 27 Aug 2013 15:58:08 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7RFw8Pc027388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Aug 2013 15:58:08 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.176]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 27 Aug 2013 10:58:07 -0500 From: "John Parello (jparello)" To: Juergen Quittek , Brad Schoening Thread-Topic: [eman] eman framework issue: Do we start from a software design or do we start from the physical world? Thread-Index: AQHOowg3ghWAoaI5gUutWTBPSiWP3ZmpNCDO Date: Tue, 27 Aug 2013 15:58:07 +0000 Message-ID: <9C213D38848B89428F46808B16F6F086015DF3C4@xmb-aln-x04.cisco.com> References: , <21AD4998-825F-4C7F-819E-AB4045D5E178@quittek.at> In-Reply-To: <21AD4998-825F-4C7F-819E-AB4045D5E178@quittek.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.223.104] Content-Type: multipart/alternative; boundary="_000_9C213D38848B89428F46808B16F6F086015DF3C4xmbalnx04ciscoc_" MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] eman framework issue: Do we start from a software design or do we start from the physical world? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 15:58:42 -0000 --_000_9C213D38848B89428F46808B16F6F086015DF3C4xmbalnx04ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ah simple edit! We already start with physical equipment, then a physical Device then talk = about the Device Class abstraction, so thanks we got that concenr of yours = covered in the last rev. Let's use the same notation ASHRAE used for (class) and we need to add a ph= ysical meter to be even clearer. For reference the flow in the doc for device (which I'll make sure we follo= w for meter:) Terminology: Electrical Equipment A general term including materials, fittings, devices, appliances, fixtures= , apparatus, machines, etc., used as a part of, or in connection with, an e= lectric installation. Reference: [IEEE100] Device A piece of electrical or non-electrical equipment. Reference: Adapted from [IEEE100] Abstraction Section: 4.2.1 Device Class The Device Class is a sub-class of Energy Object that represents a physical= piece of equipment. A Device Class instance may represent a physical device that contains other= components. BTW. The ashrae definition of Meter fits nicely to our evolution of equipme= nt->device for physical. Thanks! Jp ________________________________ From: eman-bounces@ietf.org [eman-bounces@ietf.org] on behalf of Juergen Qu= ittek [ietf@quittek.at] Sent: Tuesday, August 27, 2013 2:31 AM To: Brad Schoening Cc: eman mailing list Subject: Re: [eman] eman framework issue: Do we start from a software desig= n or do we start from the physical world? Dear Brad, Thank you for picking the ASHRAE example. It fully illustrates my concern. If you read the text before the ASHRAE model elaboration that you cited on = page 26, you will find on page 10 that ASHRAE first says 3.1.21. Meter "Meters are devices which measure the amount of electricity used at a parti= cular site. ..." So ASHRAE exactly follows the approach to FIRST talk about the real world a= nd THEN about a model of it. We should follow the same approach in eman. Cheers, Juergen Am 20.08.2013 um 14:10 schrieb Brad Schoening >: Bruce & Juergen, NIST uses the same modeling language and creates a meter as a distinct clas= s of device, so we appear to be in good company. For example, pg 29 of ASHRAE 201 'Facility Smart Grid Information Model': ElectricMeter (Class) The ElectricMeter Class is a subclass of the Meter Class. It is an abstract= representation of devices that measure real optionally reactive, energy consumption. These devices optionally measure o= ther electrical parameters such as Present Subinterval Demand or Power Quality. Brad Schoening Engineering | Coraid Tel: +1 917 304 7190 brads@coraid.com | www.coraid.com Coraid: Redefining Storage From: Bruce Nordman > Date: Tue, 20 Aug 2013 12:24:03 -0700 To: Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] eman framework issue: Do we start from a software desig= n or do we start from the physical world? I concur with Juergen's concern about how to approach the Framework. A key concern I have is that the software modeling approach seems to lead to a document which has more apparent complexity to the reader than the alternative. I say apparent because for implementation, the result might be the same. However, the apparent complexity is likely to deter some people from implementing or using EMAN at all. --Bruce On Tue, Aug 13, 2013 at 2:17 AM, Juergen Quittek > wrote: Dear all, Before the IETF meeting I posted high-level comments on the new version of = our framework draft (draft-ietf-eman-framework-08) and on the alternative f= ramework proposal from Bruce (draft-nordman-eman-er-framework-01). Now I send a series of individuals mails each focusing on a particular issu= e that I found in one or the other draft. For each issue I try to point out= how the drafts address it and what the differences are. My first point is about our very general approach to describe the eman fram= ework: Do we start with describing a software design and map this to the re= al world? Or do we start with describing the physical world an derive a mod= el from it? The two drafts are quite different in that respect. draft-ietf-eman-framewo= rk-08 (EMAN Framework) rather develops the framework from a software model = while draft-nordman-eman-er-framework-01 (ER Framework) starts from the phy= sical world. Here is an example that illustrate the difference. EMAN Framework section 4.2 Energy Object: 4.2 Energy Object An Energy Object is an abstract class that contains the base attributes for Energy Management. There are three types of Energy Objects: Device, Component and Power Interface. ER Framework, section 2.5 Energy Object: 2.5. Energy Object Devices, Power Interfaces, and Components are all Energy Objects (EOs). Th= e term "entity" in the Requirements draft generally corresponds to Energy Object. The kinds of data available for an EO depends on its type as shown in Figure 1. This is just one example out of many similar instances that can easily be f= ound in those drafts. The different choices made by the drafts result in different ways of descri= bing the framework. The ER Framework describes which information is reported for an Energy Obje= ct (power, state, voltage, etc.) while the EMAN framework tells us which at= tributes (power, state, voltage, etc) the class Energy Object has. So the basic question that occurs to me is: Do we want to define our energy= management framework as an object-oriented (software) model or do we want = to describe a view of physical systems? This would be the core question to be answered for addressing this issue. Of course, in the end we need a data model for interoperable exchange of in= formation based on our framework. But for this purpose we already have other documents. Here the candidates f= or are MIB modules using SMI that do not support the concepts of classes a= nd inheritance (which also holds for YANG modules using XML). : Cheers, Juergen _______________________________________________ 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 _______________________________________________ eman mailing list eman@ietf= .org https://www.ietf.org/mailman/listinfo/eman --_000_9C213D38848B89428F46808B16F6F086015DF3C4xmbalnx04ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ah simple edit!

We already start with physical equipment, then a physical Device then talk = about the Device Class abstraction, so thanks we got that concenr of yours = covered in the last rev.

Let's use the same notation ASHRAE used for (class) and we need to add a ph= ysical meter to be even clearer.

For reference the flow in the doc for device (which I'll make sure we follo= w for meter:)

Terminology:

Electrical Equipment

A general term including materials, fittings, devices, appliances, fixtures= , apparatus, machines, etc., used as a part of, or in connection with, an e= lectric installation.

Reference: [IEEE100]


Device

A piece of electrical or no= n-electrical equipment.

Reference: Adapted from [IE= EE100]


Abstraction Section:

4.2.1 Device Class

The Device Class is a sub-class of Energy Object tha= t represents a physical piece of equipment.

A Device Class instance may represent a physical dev= ice that contains othe= r components.

BTW. The ashrae definition of Meter fits nicely to our evolution of equipment-&= gt;device for physical.

Thanks!
Jp



From: eman-bounces@ietf.org [eman-bounc= es@ietf.org] on behalf of Juergen Quittek [ietf@quittek.at]
Sent: Tuesday, August 27, 2013 2:31 AM
To: Brad Schoening
Cc: eman mailing list
Subject: Re: [eman] eman framework issue: Do we start from a softwar= e design or do we start from the physical world?

Dear Brad, 

Thank you for picking the ASHRAE example. It fully illustrates my conc= ern. 

If you read the text before the ASHRAE model elaborat= ion that you cited on page 26, you will find on page 10 that ASHRAE first s= ays

3.1.21. Meter
"Meters are devices which measure the amount of = electricity used at a particular site. ..."

So ASHRAE exactly follows the approach to FIRST talk = about the real world and THEN about a model of it. 

We should follow the same approach in eman. 

Cheers,
    Juergen 


Am 20.08.2013 um 14:10 schrieb Brad Schoening <brads@coraid.com>:

Bruce & Juergen,

NIST uses the same modeling language and creates a meter as a distinct= class of device, so we appear to be in good company.

For example, pg 29 of ASHRAE 201 'Facility Smart Grid Information Mode= l':

ElectricMeter (Class)
The ElectricMeter Class is a subclass of the Meter Class. It is an abs= tract representation of devices that measure real
optionally reactive, energy consumption. These devices optionally meas= ure other electrical parameters such as Present
Subinterval Demand or Power Quality.

Brad S= choening
Engineering | Coraid
Tel: +1 917 304 7190
brads@coraid.com = | www.coraid.com
C= oraid: Redefining Storage


From: Bruce Nordman <bnordman@lbl.gov>
Date: Tue, 20 Aug 2013 12:24:03 -07= 00
To: Juergen Quittek <ietf@quittek.at>
Cc: eman mailing list <eman@ietf.org>
Subject: Re: [eman] eman framework = issue: Do we start from a software design or do we start from the physical = world?

I concur with Juergen's concern about how to approach the Framework. A key concern I have is that the software modeling approach seems to
lead to a document which has more apparent complexity to the reader
than the alternative.   I say apparent because for implementation= , the
result might be the same.  However, the apparent complexity is likely<= br> to deter some people from implementing or using EMAN at all.
--Bruce


On Tue, Aug 13, 2013 at 2:17 AM, Juergen Quittek= <ietf@quittek.at> wrote:
Dear all, 

Before the IETF meeting I posted high-level comments on the new versio= n of our framework draft (draft-ietf-eman-framework-08) and on the alternat= ive framework proposal from Bruce (draft-nordman-eman-er-framework-01).&nbs= p;

Now I send a series of individuals mails each focusing on a particular= issue that I found in one or the other draft. For each issue I try to poin= t out how the drafts address it and what the differences are. 

My first point is about our very general approach to describe the eman= framework: Do we start with describing a software design and map this to t= he real world? Or do we start with describing the physical world an derive = a model from it?

The two drafts are quite different in that respect. draft-i= etf-eman-framework-08 (EMAN Framework) rather develops the framework from a= software model while draft-nordman-eman-er-framework-01 = (ER Framework) starts from the physical world. Here is an example that illustrate the difference. 

EMAN Framework section 4.2 Energy Object:
        4.2 Energy Object
=
An Energy Object is an abstract class th=
at contains the base =0A=
        attributes for Energy Management.  There are three types of =0A=
        Energy Objects: Device, Component and Power Interface.

ER Framework, section 2.5 Energy Object:
2.5.  Energy Object  =

Devices, Power Interfaces, and Components are =
all Energy Objects (EOs).  The term=0A=
   "entity" in the Requirements draft generally corresponds to En=
ergy=0A=
   Object.  The kinds of data available for an EO depends on its type as=0A=
   shown in Figure 1.

This is just one example out of many similar instances that can = easily be found in those drafts. 

The different choices made by the drafts result in different way= s of describing the framework. 

The ER Framework describes which information is reported for an = Energy Object (power, state, voltage, etc.) while the EMAN framework tells = us which attributes (power, state, voltage, etc) the class Energy Object has. 

So the basic question that occurs to me is: Do we want to define= our energy management framework as an object-oriented (software) model or = do we want to describe a view of physical systems?

This would be the core question to be answered for addressing th= is issue. 

Of course, in the end we need a data model for interoperable exc= hange of information based on our framework. 
But for this purpose we already have other documents. Here the c= andidates for  are MIB modules using SMI that do not support the conce= pts of classes and inheritance (which also holds for YANG= modules using XML). 
:
Cheers,
    Juergen

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




--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov<= br> 510-486-7089
m: 510-501-7943
_______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman
--_000_9C213D38848B89428F46808B16F6F086015DF3C4xmbalnx04ciscoc_-- From bnordman@lbl.gov Tue Aug 27 22:18:55 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD7011E8142 for ; Tue, 27 Aug 2013 22:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.143 X-Spam-Level: X-Spam-Status: No, score=-5.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] 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 en+--mr9wvlf for ; Tue, 27 Aug 2013 22:18:51 -0700 (PDT) Received: from fe2.lbl.gov (fe2.lbl.gov [128.3.41.134]) by ietfa.amsl.com (Postfix) with ESMTP id 54C0C11E8128 for ; Tue, 27 Aug 2013 22:18:51 -0700 (PDT) X-Ironport-SBRS: 4.7 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMCAGCHHVLRVaAwk2dsb2JhbABXAw6CNXlRt22IPYEdCBYOAQEBAQcLFBQEJIIkAQEBAwEBAQFrAwgFBwQLCwYDAQIBIwsiBQ0BBQEUCAYTCIdzBgyaHZ5IjiyBJwELAQQHBguECAOJM44+gS2OSxgpgmMofl8c X-IronPort-AV: E=Sophos;i="4.89,974,1367996400"; d="scan'208";a="28083109" Received: from mail-pb0-f48.google.com ([209.85.160.48]) by fe2.lbl.gov with ESMTP; 27 Aug 2013 22:18:38 -0700 Received: by mail-pb0-f48.google.com with SMTP id ma3so5766859pbc.21 for ; Tue, 27 Aug 2013 22:18:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=etO8GHkknou1fU+tXQWwZ1HuiWZZeqmR3uUKDldlmf0=; b=Qnm0pcS1SOOdifq/KjbqTlMP0WtL+aU0+51GnHrAkfcR27pjrdxqxl+DoKOrbZeKE6 l5Ah2NLanRAgl9rJUmoixCjs+PrKWFn3Zs8gteJ0c/xL4QQCiCOJameJwTon9zP3viOL 06TpGTquDEgQRyj9vStxsQY/em9Fm552kgQZfEXljbTPEnbCq67ohwTaFhSeYAIwzsJQ nLV9PDNnFJ4GOjgBrQF+HVUQisma5kaYxfCFH3fuA6hdw9aWSaiFKuFmyPK63WUBd9ZM yQ2pMn/AGUTI4XbMvVR7hPrTzN4hAn+DvN6czZIOcpk4A0LXoAVIux0TycLbGZi7ORwq XIWw== X-Gm-Message-State: ALoCoQlH5zY83n4D5keDq5hBrz7cnxMK47pnZwsiC4unKwGHxhqGkrg82A8yErtIqAoIFbIJ8D4n0+x5h4Xhm3MgpRi1G57pzEDJxevoCf5AcROFFOrjsdKuwcfbuHXZspQy4ST9eQhi X-Received: by 10.66.189.194 with SMTP id gk2mr12895796pac.166.1377667118767; Tue, 27 Aug 2013 22:18:38 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.189.194 with SMTP id gk2mr12895780pac.166.1377667118574; Tue, 27 Aug 2013 22:18:38 -0700 (PDT) Received: by 10.68.235.9 with HTTP; Tue, 27 Aug 2013 22:18:38 -0700 (PDT) In-Reply-To: <52170C34.7020806@shiratori.riec.tohoku.ac.jp> References: <51F767A6.4010407@shiratori.riec.tohoku.ac.jp> <25A341DD-5641-448C-9973-FA287902BFD7@cisco.com> <52170C34.7020806@shiratori.riec.tohoku.ac.jp> Date: Tue, 27 Aug 2013 22:18:38 -0700 Message-ID: From: Bruce Nordman To: Satoru Izumi Content-Type: multipart/alternative; boundary=047d7bdc837438bf1d04e4fb1f16 Cc: "eman@ietf.org" Subject: Re: [eman] Should the framework cover devices in which we can not measure energy consumption directly? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Aug 2013 05:18:55 -0000 --047d7bdc837438bf1d04e4fb1f16 Content-Type: text/plain; charset=ISO-8859-1 Satoru-- If a device does not have the ability to measure its energy use, it may have ways to estimate it. The framework includes an assessment of accuracy. Some devices may be able to make fairly accurate estimates - some much less so, but for many purposes, even a rough estimate is much better than having no information at all. A device could also usefully report its power state, but not report any power levels or energy values. You mention the example of a switch would might not know the consumption level of the attached device; power state covers this case. Finally, one could even just report characteristics of products and so know that they are present, even if no power, energy, or power state information available. John already mentioned the proxy cases for non-IP devices, and devices measured by second devices. In summary, the framework does not need to exclude any device. Thanks, --Bruce On Fri, Aug 23, 2013 at 12:16 AM, Satoru Izumi < izumi@shiratori.riec.tohoku.ac.jp> wrote: > Hi John, > > I understand your concept. However, for devices with serial > connection or ip connection or no connection i.e. devices > which do not have some means of measuring power consumption > directly, what will happen? Will these devices be out of > scope? Unless the devices are supplemented with energy > measurement mechanisms? > > Does the framework cover the existing devices which do not > have functions to translate data from serial to ip networks? > > For the devices with no serial connection or ip connection, could > we estimate their energy consumption without using energy meters? > (e.g., I can see the light is on, I may or may not know its wattage, > there is no energy meter, but I know it is consuming energy. That is > valuable information. Estimating the energy consumption is another > step from there. Same for the TV, the fan, etc. etc.). The act of seeing > that a device is on can be automated using simpler indirect > mechanisms. This is much simpler than introducing energy meters in > the devices themselves. > > Is it not better to separate the device on/off detection mechanism > from the energy estimation and the energy control mechanisms? That > way we have a wider scope of the devices within the energy management > framework, today. > > Makes sense? > > Satoru Izumi > Research Institute of Electrical Communication > Tohoku University > izumi@shiratori.riec.tohoku.**ac.jp > > > -------- Original Message -------- > Subject: Re: [eman] Should the framework cover devices in which we can not > measure energy consumption directly? > From: John Parello (jparello) > To: Satoru Izumi > > > CC: "eman@ietf.org" > Date: Tue Jul 30 2013 21:23:47 GMT+0900 > > Hi Satoru, >> >> I think I miss understood your question during the session. I thought you >> were asking if we modeled connectivity (network information) in our >> framework information model. >> >> For your question below I take it that you are asking about devices that >> are not network (ip) connected. >> >> The framework defines an information model that we would like devices to >> implement. If they are not ip connected they may be accessible via other >> serial protocol like knx, mod-bus, bacnet etc. >> >> If these devices implement the information model they can then be easily >> managed via gateways that translate data from serial to ip networks. >> >> The reason we want a common information model is so that manufacturers of >> these gateways can have a clear understanding of what to translate and the >> semantics of the information they translate. >> >> I run such a program with Cisco and we have lots of partners who >> translate bacnet for example to our information model. Take a look at a >> company call FieldServer and their Energywise gateway. >> >> For devices with no serial connection or ip connection, then we have no >> direct visibility to those devices. If we measure the meter readings from >> an area and some portion are readable then there is benefit from the simple >> subtraction of your total energy and the energy you can monitor. >> >> Does that help? >> Jp >> >> Sent from my iPad >> (expect ridiculous spelling mistakes) >> >> On Jul 30, 2013, at 9:14 AM, "Satoru Izumi" > **ac.jp > wrote: >> >> John, >>> >>> This is Izumi, I asked you about device connectivity at yesterday's >>> Eman meeting. >>> >>> At this time, I would like to reconfirm, that you said that the >>> framework does not cover devices for which we can not measure >>> energy consumption directly. >>> >>> Is this O.K.? Note, there are several ways in which we can infer >>> that a device is consuming energy, but few devices offer means of >>> measuring how much energy is consumed. Almost all electrical devices >>> of today fall in this category. Lights, heaters, mobile devices, >>> home appliances, computer devices just name them. We may figure >>> out that the device is on but the devices do offer means of >>> measuring energy consumption. (Not without introducing additional >>> devices.) >>> >>> The above restriction will severly constrain the applicability of >>> the framework in todays environment. >>> >>> What do you think this? >>> >>> Regard, >>> Satoru Izumi, Ph.D >>> Research Fellow >>> Research Institute of Electrical Communication, Tohoku University >>> Tel&FAX: +81-22-217-5080 >>> izumi@shiratori.riec.tohoku.**ac.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 --047d7bdc837438bf1d04e4fb1f16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Satoru--
= =A0 If a device does not have the ability to measure its energy
use, it = may have ways to estimate it.=A0 The framework includes
an assessm= ent of accuracy.=A0 Some devices may be able
to make fairly accurate estimates - some much less so, but for
many purp= oses, even a rough estimate is much better than
having no information at= all.
=A0 A device could also usefully report its power state, but= not
report any power levels or energy values.=A0 You mention the
example of = a switch would might not know the consumption
level of the attached devi= ce; power state covers this case.
=A0 Finally, one could even just= report characteristics of products
and so know that they are present, even if no power, energy,
or power st= ate information available.
=A0 John already mentioned the proxy ca= ses for non-IP devices,
and devices measured by second device= s.
=A0 In summary, the framework does not need to exclude any
device.=
=A0 Thanks,
--Bruce
=

On Fri, Aug 23, 2013 at 12:16 AM, Satoru= Izumi <izumi@shiratori.riec.tohoku.ac.jp> w= rote:
Hi John,

I understand your concept. However, for devices with serial
connection or ip connection or no connection i.e. devices
which do not have some means of measuring power consumption
directly, what will happen? Will these devices be out of
scope? Unless the devices are supplemented with energy
measurement mechanisms?

Does the framework cover the existing devices which do not
have functions to translate data from serial to ip networks?

For the devices with no serial connection or ip connection, could
we estimate their energy consumption without using energy meters?
(e.g., I can see the light is on, I may or may not know its wattage,
there is no energy meter, but I know it is consuming energy. That is
valuable information. Estimating the energy consumption is another
step from there. Same for the TV, the fan, etc. etc.). The act of seeing that a device is on can be automated using simpler indirect
mechanisms. This is much simpler than introducing energy meters in
the devices themselves.

Is it not better to separate the device on/off detection mechanism
from the energy estimation and the energy control mechanisms? That
way we have a wider scope of the devices within the energy management
framework, today.

Makes sense?

Satoru Izumi
Research Institute of Electrical Communication
Tohoku University
izum= i@shiratori.riec.tohoku.ac.jp


-------- Original Message --------
Subject: Re: [eman] Should the framework cover devices in which we can not = measure energy consumption directly?
From: John Parello (jparello) <jparello@cisco.com>
To: Satoru Izumi <izumi@shiratori.riec.tohoku.ac.jp>
CC: "eman@ietf.org<= /a>" <eman@ietf.= org>
Date: Tue Jul 30 2013 21:23:47 GMT+0900

Hi Satoru,

I think I miss understood your question during the session. I thought you w= ere asking if we modeled connectivity (network information) in our framewor= k information model.

For your question below I take it that you are asking about devices that ar= e not network (ip) connected.

The framework defines an information model that we would like devices to im= plement. If they are not ip connected they may be accessible via other seri= al protocol like knx, mod-bus, bacnet etc.

If these devices implement the information model they can then be easily ma= naged via gateways that translate data from serial to ip networks.

The reason we want a common information model is so that manufacturers of t= hese gateways can have a clear understanding of what to translate and the s= emantics of the information they translate.

I run such a program with Cisco and we have lots of partners who translate = bacnet for example to our information model. Take a look at a company call = FieldServer and their Energywise gateway.

For devices with no serial connection or ip connection, then we have no dir= ect visibility to those devices. If we measure the meter readings from an a= rea and some portion are readable then there is benefit from the simple sub= traction of your total energy and the energy you can monitor.

Does that help?
Jp

Sent from my iPad
(expect ridiculous spelling mistakes)

On Jul 30, 2013, at 9:14 AM, "Satoru Izumi" <izumi@shiratori.riec.= tohoku.ac.jp> wrote:

John,

This is Izumi, I asked you about device connectivity at yesterday's
Eman meeting.

At this time, I would like to reconfirm, that you said that the
framework does not cover devices for which we can not measure
energy consumption directly.

Is this O.K.? Note, there are several ways in which we can infer
that a device is consuming energy, but few devices offer means of
measuring how much energy is consumed. Almost all electrical devices
of today fall in this category. Lights, heaters, mobile devices,
home appliances, computer devices just name them. We may figure
out that the device is on but the devices do offer means of
measuring energy consumption. (Not without introducing additional
devices.)

The above restriction will severly constrain the applicability of
the framework in todays environment.

What do you think this?

Regard,
Satoru Izumi, Ph.D
Research Fellow
Research Institute of Electrical Communication, Tohoku University
Tel&FAX: +81-22-217-5080
izum= i@shiratori.riec.tohoku.ac.jp
_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman

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



--
Bruce Nordman
La= wrence Berkeley National Laboratory
nordman.lbl.g= ov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--047d7bdc837438bf1d04e4fb1f16-- From karagian@cs.utwente.nl Wed Aug 28 01:42:02 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4773111E8224 for ; Wed, 28 Aug 2013 01:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[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 uWi4gRX52Kz8 for ; Wed, 28 Aug 2013 01:41:57 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 61E9A11E822D for ; Wed, 28 Aug 2013 01:41:51 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 28 Aug 2013 10:41:53 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.13]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0328.009; Wed, 28 Aug 2013 10:41:50 +0200 From: To: Thread-Topic: [eman] Should the framework cover devices in which we can not measure energy consumption directly? Thread-Index: AQHOjPRp8p9OvrTK3keCqT9302oAzJl9A9eAgCVh+gCAB7rZAIAAWKzw Date: Wed, 28 Aug 2013 08:41:49 +0000 Message-ID: References: <51F767A6.4010407@shiratori.riec.tohoku.ac.jp> <25A341DD-5641-448C-9973-FA287902BFD7@cisco.com> <52170C34.7020806@shiratori.riec.tohoku.ac.jp> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3C0C1FEXMBX23adutwent_" MIME-Version: 1.0 Cc: eman@ietf.org Subject: Re: [eman] Should the framework cover devices in which we can not measure energy consumption directly? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Aug 2013 08:42:02 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3C0C1FEXMBX23adutwent_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Satoru, I agree with John and Bruce that the framework does not exclude any device,= as long as this device supports the eman information model. Best regards, Georgios From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Bru= ce Nordman Sent: woensdag 28 augustus 2013 7:19 To: Satoru Izumi Cc: eman@ietf.org Subject: Re: [eman] Should the framework cover devices in which we can not = measure energy consumption directly? Satoru-- If a device does not have the ability to measure its energy use, it may have ways to estimate it. The framework includes an assessment of accuracy. Some devices may be able to make fairly accurate estimates - some much less so, but for many purposes, even a rough estimate is much better than having no information at all. A device could also usefully report its power state, but not report any power levels or energy values. You mention the example of a switch would might not know the consumption level of the attached device; power state covers this case. Finally, one could even just report characteristics of products and so know that they are present, even if no power, energy, or power state information available. John already mentioned the proxy cases for non-IP devices, and devices measured by second devices. In summary, the framework does not need to exclude any device. Thanks, --Bruce On Fri, Aug 23, 2013 at 12:16 AM, Satoru Izumi > wrote: Hi John, I understand your concept. However, for devices with serial connection or ip connection or no connection i.e. devices which do not have some means of measuring power consumption directly, what will happen? Will these devices be out of scope? Unless the devices are supplemented with energy measurement mechanisms? Does the framework cover the existing devices which do not have functions to translate data from serial to ip networks? For the devices with no serial connection or ip connection, could we estimate their energy consumption without using energy meters? (e.g., I can see the light is on, I may or may not know its wattage, there is no energy meter, but I know it is consuming energy. That is valuable information. Estimating the energy consumption is another step from there. Same for the TV, the fan, etc. etc.). The act of seeing that a device is on can be automated using simpler indirect mechanisms. This is much simpler than introducing energy meters in the devices themselves. Is it not better to separate the device on/off detection mechanism from the energy estimation and the energy control mechanisms? That way we have a wider scope of the devices within the energy management framework, today. Makes sense? Satoru Izumi Research Institute of Electrical Communication Tohoku University izumi@shiratori.riec.tohoku.ac.jp -------- Original Message -------- Subject: Re: [eman] Should the framework cover devices in which we can not = measure energy consumption directly? From: John Parello (jparello) > To: Satoru Izumi > CC: "eman@ietf.org" > Date: Tue Jul 30 2013 21:23:47 GMT+0900 Hi Satoru, I think I miss understood your question during the session. I thought you w= ere asking if we modeled connectivity (network information) in our framewor= k information model. For your question below I take it that you are asking about devices that ar= e not network (ip) connected. The framework defines an information model that we would like devices to im= plement. If they are not ip connected they may be accessible via other seri= al protocol like knx, mod-bus, bacnet etc. If these devices implement the information model they can then be easily ma= naged via gateways that translate data from serial to ip networks. The reason we want a common information model is so that manufacturers of t= hese gateways can have a clear understanding of what to translate and the s= emantics of the information they translate. I run such a program with Cisco and we have lots of partners who translate = bacnet for example to our information model. Take a look at a company call = FieldServer and their Energywise gateway. For devices with no serial connection or ip connection, then we have no dir= ect visibility to those devices. If we measure the meter readings from an a= rea and some portion are readable then there is benefit from the simple sub= traction of your total energy and the energy you can monitor. Does that help? Jp Sent from my iPad (expect ridiculous spelling mistakes) On Jul 30, 2013, at 9:14 AM, "Satoru Izumi" > wrote: John, This is Izumi, I asked you about device connectivity at yesterday's Eman meeting. At this time, I would like to reconfirm, that you said that the framework does not cover devices for which we can not measure energy consumption directly. Is this O.K.? Note, there are several ways in which we can infer that a device is consuming energy, but few devices offer means of measuring how much energy is consumed. Almost all electrical devices of today fall in this category. Lights, heaters, mobile devices, home appliances, computer devices just name them. We may figure out that the device is on but the devices do offer means of measuring energy consumption. (Not without introducing additional devices.) The above restriction will severly constrain the applicability of the framework in todays environment. What do you think this? Regard, Satoru Izumi, Ph.D Research Fellow Research Institute of Electrical Communication, Tohoku University Tel&FAX: +81-22-217-5080 izumi@shiratori.riec.tohoku.ac.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 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3C0C1FEXMBX23adutwent_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Satoru,=

 = ;

I agree wi= th John and Bruce that the framework does not exclude any device, as long a= s this device supports the eman information model.

 = ;

Best regar= ds,

Georgios

 = ;

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Bruce Nordman
Sent: woensdag 28 augustus 2013 7:19
To: Satoru Izumi
Cc: eman@ietf.org
Subject: Re: [eman] Should the framework cover devices in which we c= an not measure energy consumption directly?

 

Satoru--

  If a device does not have the ability to meas= ure its energy
use, it may have ways to estimate it.  The framework includes

an assessment of accuracy.  Some devices may be= able
to make fairly accurate estimates - some much less so, but for
many purposes, even a rough estimate is much better than
having no information at all.

  A device could also usefully report its power= state, but not
report any power levels or energy values.  You mention the
example of a switch would might not know the consumption
level of the attached device; power state covers this case.

  Finally, one could even just report character= istics of products
and so know that they are present, even if no power, energy,
or power state information available.

  John already mentioned the proxy cases for no= n-IP devices,

and devices measured by second devices.

  In summary, the framework does not need to ex= clude any
device.

  Thanks,

--Bruce

 

On Fri, Aug 23, 2013 at 12:16 AM, Satoru Izumi <<= a href=3D"mailto:izumi@shiratori.riec.tohoku.ac.jp" target=3D"_blank">izumi= @shiratori.riec.tohoku.ac.jp> wrote:

Hi John,

I understand your concept. However, for devices with serial
connection or ip connection or no connection i.e. devices
which do not have some means of measuring power consumption
directly, what will happen? Will these devices be out of
scope? Unless the devices are supplemented with energy
measurement mechanisms?

Does the framework cover the existing devices which do not
have functions to translate data from serial to ip networks?

For the devices with no serial connection or ip connection, could
we estimate their energy consumption without using energy meters?
(e.g., I can see the light is on, I may or may not know its wattage,
there is no energy meter, but I know it is consuming energy. That is
valuable information. Estimating the energy consumption is another
step from there. Same for the TV, the fan, etc. etc.). The act of seeing that a device is on can be automated using simpler indirect
mechanisms. This is much simpler than introducing energy meters in
the devices themselves.

Is it not better to separate the device on/off detection mechanism
from the energy estimation and the energy control mechanisms? That
way we have a wider scope of the devices within the energy management
framework, today.

Makes sense?

Satoru Izumi
Research Institute of Electrical Communication
Tohoku University
izumi@shiratori.riec.tohoku.ac.jp=



-------- Original Message --------
Subject: Re: [eman] Should the framework cover devices in which we can not = measure energy consumption directly?
From: John Parello (jparello) <jparello@cisco.com>
To: Satoru Izumi <izumi@shiratori.riec.tohoku.ac.jp>
CC: "eman@ietf.org<= /a>" <eman@ietf.= org>
Date: Tue Jul 30 2013 21:23:47 GMT+0900

Hi Satoru,

I think I miss understood your question during the session. I thought you w= ere asking if we modeled connectivity (network information) in our framewor= k information model.

For your question below I take it that you are asking about devices that ar= e not network (ip) connected.

The framework defines an information model that we would like devices to im= plement. If they are not ip connected they may be accessible via other seri= al protocol like knx, mod-bus, bacnet etc.

If these devices implement the information model they can then be easily ma= naged via gateways that translate data from serial to ip networks.

The reason we want a common information model is so that manufacturers of t= hese gateways can have a clear understanding of what to translate and the s= emantics of the information they translate.

I run such a program with Cisco and we have lots of partners who translate = bacnet for example to our information model. Take a look at a company call = FieldServer and their Energywise gateway.

For devices with no serial connection or ip connection, then we have no dir= ect visibility to those devices. If we measure the meter readings from an a= rea and some portion are readable then there is benefit from the simple sub= traction of your total energy and the energy you can monitor.

Does that help?
Jp

Sent from my iPad
(expect ridiculous spelling mistakes)

On Jul 30, 2013, at 9:14 AM, "Satoru Izumi" <izumi@shiratori.riec.= tohoku.ac.jp> wrote:

John,

This is Izumi, I asked you about device connectivity at yesterday's
Eman meeting.

At this time, I would like to reconfirm, that you said that the
framework does not cover devices for which we can not measure
energy consumption directly.

Is this O.K.? Note, there are several ways in which we can infer
that a device is consuming energy, but few devices offer means of
measuring how much energy is consumed. Almost all electrical devices
of today fall in this category. Lights, heaters, mobile devices,
home appliances, computer devices just name them. We may figure
out that the device is on but the devices do offer means of
measuring energy consumption. (Not without introducing additional
devices.)

The above restriction will severly constrain the applicability of
the framework in todays environment.

What do you think this?

Regard,
Satoru Izumi, Ph.D
Research Fellow
Research Institute of Electrical Communication, Tohoku University
Tel&FAX: +81-22= -217-5080
izum= i@shiratori.riec.tohoku.ac.jp
_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman


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




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

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3C0C1FEXMBX23adutwent_-- From ietf@quittek.at Fri Aug 30 10:37:18 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E2021F9E04 for ; Fri, 30 Aug 2013 10:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] 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 FH4QrMCx5+bx for ; Fri, 30 Aug 2013 10:37:12 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0C76221F9E12 for ; Fri, 30 Aug 2013 10:37:08 -0700 (PDT) Received: from [10.42.187.143] (tmo-097-25.customers.d1-online.com [80.187.97.25]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lu2Cs-1VywWD0bHq-011W5J; Fri, 30 Aug 2013 19:37:07 +0200 From: Juergen Quittek Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (10B329) Message-Id: <2D7EBF2B-D82C-49ED-BC96-159C5326233F@quittek.at> Date: Fri, 30 Aug 2013 19:37:01 +0200 To: eman mailing list Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Provags-ID: V02:K0:moWKL0Caou4a8l/uoGjbfA+JX2Ze3U4yNCEfXB8rpV8 jKhLS2nqNUhc66ZTc+WcbsFinBvMzsJRz4OPpPfceHCAZCgqx+ erzmW1fC7AEFzhGlwANhRq835Pc47Zr8f7f2frasB6vhfhekAJ jhTmZJHCoHVWy1vuwvzD/Yb3Xm8Nh/hJIF3jLktMJmfu82EXCU fEzRcfphkhddjvrJKsKAUBzhjd8gszsnL69bG9j9imAh6xsL3z YBxuLwcEqkYEgn/rbqcJ3E4L3yL4DJtx1pF5Rt1bMg0G1kILQZ ENcwTxAJaNNXXEyWYraj7tjMuVqkaLlX3dCaZ7hRAS8o9sygKD FRcP8NZMMUExHfJ06ump09bsVjgV/wQ/Ao9vjS0D6 Subject: [eman] eman framework issue: Lacking differentiation between devices, components, and interfaces X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 17:37:18 -0000 Dear all,=20 Here is another framework issue: Do we report the same Information for devic= es, interfaces, and components? Our framework draft (draft-ietf-eman-framework-08) uses an object-oriented m= odel for describing the Information model for eman. The model has classes fo= r devices, components, meters and the classes have attributes for carrying i= nformation on UUIDs, power values, etc.=20 My issue with the model is that it uses the same set of attributes for all k= inds of energy objects (device, component, power interface). The only exception is a single category/type object that varies among the di= fferent classes. (Ironically, here I would use the same attribute for all cl= asses in oder to use the same mechanism for all energy objects to retrieve t= heir type.) In the requirements document (draft-ietf-eman-requirements-14) there are cle= ar differences between the sets of information elements to be reported for d= evices, components, and interfaces. The current model does not reflect this.= This is different for the model in draft-nordman-eman-er-framework-01. Here t= he model is fully aligned with the requirements and supports different sets o= f information provided for different kinds of energy objects. It uses simple= tables to show which information needs to be reported for which type of ene= rgy object.=20 I think the differentiation between devices, components, and power interface= s as it is made in the requirements draft needs to be reflected by the eman f= ramework.=20 Cheers, Juergen= From ietf@quittek.at Fri Aug 30 10:43:42 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E72B11E8111 for ; Fri, 30 Aug 2013 10:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 9FRYV9puO1Qc for ; Fri, 30 Aug 2013 10:43:31 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 059DE21F9EB8 for ; Fri, 30 Aug 2013 10:43:31 -0700 (PDT) Received: from [10.42.187.143] (tmo-097-25.customers.d1-online.com [80.187.97.25]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0LqacI-1VtSNE0CQM-00eIR3; Fri, 30 Aug 2013 19:43:25 +0200 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-CAEC3AD5-9B81-4E3D-9690-194863951C6F Content-Transfer-Encoding: 7bit Message-Id: <22513F63-D109-413B-8AD8-F22C90626F47@quittek.at> X-Mailer: iPhone Mail (10B329) From: Juergen Quittek Date: Fri, 30 Aug 2013 19:43:19 +0200 To: Brad Schoening X-Provags-ID: V02:K0:S4O1WnNngox6fL+KKKg3p5eWHm5BdYMvNFX532S4M3a LO88l4W/g3aGwln2lL15OdvUQtjMcPEZIJYL+g9ciVZRCffZZl 4uoetKhlpMH2MkxSQxDvgg6Qo8NWk+6lZUHFVa0afa+brI/cmt k7T2fVEmYVsZHigfKWUf5X+Cr7gWrWiYkI7dUW99lUYP9ezIL3 /qslpByBcEu67vKSBB+FeK93JYvaMRqMcl+S74X2oH9CGDdyyq NDrU1zupHf8eJ08SrKB/baVb5E+bCvkiFLJsTO26oFtiRDN1Gb ELb53EyO6Fgvlopcl9FwgEKKD7th2IMBpV14GBmbtn7q1Os3ZY mhU0ABF1Cjn+xK9F6q1g26IBAJzyXYMPwMZXNdfdb Cc: eman mailing list Subject: Re: [eman] eman framework issue: How to model a meter? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Aug 2013 17:43:42 -0000 --Apple-Mail-CAEC3AD5-9B81-4E3D-9690-194863951C6F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Brad, Thank you for the explanation. So, do I understand correctly that if you mea= sure power you do not meteri, but if you measure energy you are? Thanks, Juergen=20 Am 27.08.2013 um 16:23 schrieb Brad Schoening : > Juergen, >=20 > Metering is generally used when there is a continuos flow with the amount t= otalized. Metering is usually facilitated by the presence of a physical met= er which may have to meet regulatory requirements. In the US, electric mete= rs are divided into "Revenue Grade" and "Non-Revenue Grade" classes. >=20 > This is a noteworthy point, as an electrical device such as a PoE switch m= ay be able to measure its instantaneous energy consumption, but typically do= esn't have the ability to meter it and totalized it over time periods. >=20 > Regards, >=20 > Brad >=20 > From: Juergen Quittek > Date: Tue, 27 Aug 2013 02:09:02 -0700 > To: "John Parello (jparello)" > Cc: eman mailing list > Subject: Re: [eman] eman framework issue: How to model a meter? >=20 > Dear all, >=20 > Unfortunately, I am not a native speaker. Can someone explain to me the ex= act difference between 'metering' and 'measuring'? >=20 > Thanks, > Juergen >=20 > Am 20.08.2013 um 12:17 schrieb "John Parello (jparello)" : >=20 >> Good catch let's change "perform metering" to "perform measuring" then ye= s go with simple. >>=20 >> So broad categorization of the device/component and continue to leave com= plex capability modeling out. >>=20 >> Jp >>=20 >> Sent from my iPad=20 >> (expect ridiculous spelling mistakes)=20 >>=20 >> On Aug 20, 2013, at 11:44 AM, "Bruce Nordman" wrote: >>=20 >>> The current draft of the EMAN framework says: >>> "A meter is a type Energy Object and any Energy Object can perform met= ering." >>>=20 >>> This seems to indicate that devices can meter, components can meter, and= power >>> interfaces can meter. On the other hand, Juergen notes that the meter c= lassification >>> is not available to power interfaces. This appears to be a contradictio= n. >>>=20 >>> It is possible to require declaring a "primary function" for a device, i= ncluding whether it is a >>> device that can only perform metering, but that seems to be an unnecessa= ry complication >>> and not derivative of any requirement. >>>=20 >>> Juergen's point is that metering (or measuring--I defer on that choice o= f wording) can be >>> simply and flexibly modeled as just a capability that any EO can have. I= t is unnecessary >>> to make the Framework more complicated than that. There are plenty of a= dditional >>> complications that could be added that don't derive from any requirement= . >>>=20 >>> --Bruce >>>=20 >>>=20 >>>=20 >>> On Tue, Aug 20, 2013 at 10:51 AM, John Parello (jparello) wrote: >>>>=20 >>>> >>>>=20 >>>> > >>>> > You ask "Do we need to model metering capability at all"? Yes, becau= se >>>> > smart meters, in particular sub-meters, are a key part of real time e= nergy >>>> > monitoring. >>>> > >>>>=20 >>>> Just to be clear we used "meter" is a type of device (which acknowledge= s you other points, and if you want to model capability the value would be "= measuring". So a "metering capability" doesn't make sense. It would be "meas= uring capability". >>>>=20 >>>> Again we removed the capabilities attribute. >>>>=20 >>>> After quite some years deploying these systems that distinction is seco= nd nature for me but we should be precise. >>>>=20 >>>> Jp >>>>=20 >>>>=20 >>>>=20 >>>> > Regards, >>>> > >>>> > Brad >>>> > >>>> > On 8/20/13 1:09 AM, "Juergen Quittek" wrote: >>>> > >>>> >> Dear all, >>>> >> >>>> >> Here is another framework issue: How to model metering capabilities o= f >>>> >> devices? >>>> >> >>>> >> Our framework draft (draft-ietf-eman-framework-08) models metering >>>> >> capability by categorizing devices and components into either a prod= ucer, >>>> >> a comsumer, a meter, or a distributor, see pseudocode on page 43. >>>> >> >>>> >> I think this approach is broken. It may be useful for modeling simpl= e >>>> >> scenarios, but it does not work as general model. >>>> >> >>>> >> There are two problems with this approach. >>>> >> >>>> >> 1. The either-or classification. A meter is typically not just a met= er, >>>> >> but as well a consumer that consumes energy when doing it's job. A P= DU >>>> >> that meters power at it's outlets is a meter and a distributor and a= >>>> >> consumer. The same holds for a PoE switch. These are not either mete= rs or >>>> >> consumers, they are meters and consumers and some of them are also >>>> >> distributors at the same time. >>>> >> >>>> >> 2. The categorization as 'meter' is only available for devices and >>>> >> components, not for power interfaces. But obviously a device with >>>> >> metering capabilities meters at (some of) its interfaces. Take the P= oE >>>> >> switch that meters power at some or all of its PoE outlets. It would= be >>>> >> natural to label the power interfaces at which metering capabilities= are >>>> >> available as 'metered'. It appears strange to classify the device as= >>>> >> 'meter'. >>>> >> >>>> >> The basic question here is: Do we need to model metering capability a= t >>>> >> all? If yes, we should model it as an attribute, not as a category;= and >>>> >> we should model it as attribute of the power interfaces as well. >>>> >> >>>> >> BTW, if we model metering capability (monitoring), we should consequ= ently >>>> >> model circuit breaker capability (control) at power interfaces as we= ll. >>>> >> >>>> >> Cheers, >>>> >> Juergen >>>> >> _______________________________________________ >>>> >> eman mailing list >>>> >> eman@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/eman >>>> > >>>> > _______________________________________________ >>>> > eman mailing list >>>> > eman@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/eman >>>> _______________________________________________ >>>> eman mailing list >>>> eman@ietf.org >>>> https://www.ietf.org/mailman/listinfo/eman >>>=20 >>>=20 >>>=20 >>> --=20 >>> Bruce Nordman >>> Lawrence Berkeley National Laboratory >>> nordman.lbl.gov >>> BNordman@LBL.gov >>> 510-486-7089 >>> m: 510-501-7943 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ eman mailing list eman@iet= f.org https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-CAEC3AD5-9B81-4E3D-9690-194863951C6F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Brad,

Thank you for the explanation. So, do I understand correctly that if you measure power you do not meteri, but if you measure energy you are?

Thanks,
    Juergen 

Am 27.08.2013 um 16:23 schrieb Brad Schoening <brads@coraid.com>:

Juergen,

Metering is generally used when there is a continuos flow with the amount totalized.  Metering is usually facilitated by the presence of a physical meter which may have to meet regulatory requirements.  In the US, electric meters are divided into "Revenue Grade" and "Non-Revenue Grade" classes.

This is a noteworthy point, as an electrical device such as a PoE switch may be able to measure its instantaneous energy consumption, but typically doesn't have the ability to meter it and totalized it over time periods.

Regards,

Brad

From: Juergen Quittek <ietf@quittek.at>
Date: Tue, 27 Aug 2013 02:09:02 -0700
To: "John Parello (jparello)" <jparello@cisco.com>
Cc: eman mailing list <eman@ietf.org>
Subject: Re: [eman] eman framework issue: How to model a meter?

Dear all,

Unfortunately, I am not a native speaker. Can someone explain to me the exact difference between 'metering' and 'measuring'?

Thanks,
    Juergen

Am 20.08.2013 um 12:17 schrieb "John Parello (jparello)" <jparello@cisco.com>:

Good catch let's change "perform metering" to "perform measuring" then yes go with simple.

So broad categorization of the device/component and continue to leave complex capability modeling out.

Jp

Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Aug 20, 2013, at 11:44 AM, "Bruce Nordman" <bnordman@lbl.gov> wrote:

The current draft of the EMAN framework says:
  "A meter is a type Energy Object and any Energy Object can perform metering."

This seems to indicate that devices can meter, components can meter, and power
interfaces can meter.  On the other hand, Juergen notes that the meter classification
is not available to power interfaces.  This appears to be a contradiction.

It is possible to require declaring a "primary function" for a device, including whether it is a
device that can only perform metering, but that seems to be an unnecessary complication
and not derivative of any requirement.

Juergen's point is that metering (or measuring--I defer on that choice of wording) can be
simply and flexibly modeled as just a capability that any EO can have.  It is unnecessary
to make the Framework more complicated than that.  There are plenty of additional
complications that could be added that don't derive from any requirement.

--Bruce



On Tue, Aug 20, 2013 at 10:51 AM, John Parello (jparello) <jparello@cisco.com> wrote:

<snip>

>
> You ask "Do we need to model metering capability at all"?  Yes, because
> smart meters, in particular sub-meters, are a key part of real time energy
> monitoring.
>

Just to be clear we used "meter" is a type of device (which acknowledges you other points, and if you want to model capability the value would be "measuring". So a "metering capability" doesn't make sense. It would be "measuring capability".

Again we removed the capabilities attribute.

After quite some years deploying these systems that distinction is second  nature for me but we should be precise.

Jp



> Regards,
>
> Brad
>
> On 8/20/13 1:09 AM, "Juergen Quittek" <ietf@quittek.at> wrote:
>
>> Dear all,
>>
>> Here is another framework issue: How to model metering capabilities of
>> devices?
>>
>> Our framework draft (draft-ietf-eman-framework-08) models metering
>> capability by categorizing devices and components into either a producer,
>> a comsumer, a meter, or a distributor, see pseudocode on page 43.
>>
>> I think this approach is broken. It may be useful for modeling simple
>> scenarios, but it does not work as general model.
>>
>> There are two problems with this approach.
>>
>> 1. The either-or classification. A meter is typically not just a meter,
>> but as well a consumer that consumes energy when doing it's job. A PDU
>> that meters power at it's outlets is a meter and a distributor and a
>> consumer. The same holds for a PoE switch. These are not either meters or
>> consumers, they are meters and consumers and some of them are also
>> distributors at the same time.
>>
>> 2. The categorization as 'meter' is only available for devices and
>> components, not for power interfaces. But obviously a device with
>> metering capabilities meters at (some of) its interfaces. Take the PoE
>> switch that meters power at some or all of its PoE outlets. It would be
>> natural to label the power interfaces at which metering capabilities are
>> available as 'metered'. It appears strange to classify the device as
>> 'meter'.
>>
>> The basic question here is: Do we need to model metering capability at
>> all?  If yes, we should model it as an attribute, not as a category; and
>> we should model it as attribute of the power interfaces as well.
>>
>> BTW, if we model metering capability (monitoring), we should consequently
>> model circuit breaker capability (control) at power interfaces as well.
>>
>> Cheers,
>>  Juergen
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman



--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman
_______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman
--Apple-Mail-CAEC3AD5-9B81-4E3D-9690-194863951C6F-- From brads@coraid.com Fri Aug 30 11:04:40 2013 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5DD21E80E0 for ; Fri, 30 Aug 2013 11:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 l4DuvQJ8MLnw for ; Fri, 30 Aug 2013 11:04:35 -0700 (PDT) Received: from server506.appriver.com (server506l.appriver.com [50.56.144.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3C73521F9D70 for ; Fri, 30 Aug 2013 11:04:34 -0700 (PDT) X-Note-AR-ScanTimeLocal: 8/30/2013 1:04:32 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-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-54/SG:2 8/30/2013 1:04:30 PM X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.973204 Source White X-Signature-Violations: 0-0-0-5133-c X-Note-419: 15.6004 ms. Fail:0 Chk:1343 of 1343 total X-Note: SCH-CT/SI:0-1343/SG:1 8/30/2013 1:04:23 PM X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->PRIVATE->UNITED STATES X-Note-Sending-IP: 10.242.229.139 X-Note-Reverse-DNS: X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G340 G341 G342 G343 G347 G348 G455 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 5540088; Fri, 30 Aug 2013 13:04:31 -0500 Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.11]) by HT01-E6.exg6.exghost.com ([50.56.144.19]) with mapi id 14.03.0158.001; Fri, 30 Aug 2013 13:04:26 -0500 From: Brad Schoening To: Juergen Quittek , eman mailing list Thread-Topic: [eman] eman framework issue: Lacking differentiation between devices, components, and interfaces Thread-Index: AQHOpatd0ZPnAVxX/0aNa1e37uzkYA== Date: Fri, 30 Aug 2013 18:04:26 +0000 Message-ID: In-Reply-To: <2D7EBF2B-D82C-49ED-BC96-159C5326233F@quittek.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [50.56.144.245] x-rerouted-by-exchange: Content-Type: text/plain; charset="us-ascii" Content-ID: <18237AE2AF1F7644A9185D6AB2BC05C0@fwd6.exghost.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] eman framework issue: Lacking differentiation between devices, components, and interfaces X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 18:04:40 -0000 Juergen, The framework uses a UML-like model, similar to ASHRAE 201 and IEC 6180. As we've discussed, we could also produce syntactically corrected UML if that is the consensues. On 8/30/13 1:37 PM, "Juergen Quittek" wrote: >Dear all,=20 > >Here is another framework issue: Do we report the same Information for >devices, interfaces, and components? > >Our framework draft (draft-ietf-eman-framework-08) uses an >object-oriented model for describing the Information model for eman. The >model has classes for devices, components, meters and the classes have >attributes for carrying information on UUIDs, power values, etc. > >My issue with the model is that it uses the same set of attributes for >all kinds of energy objects (device, component, power interface). > >The only exception is a single category/type object that varies among the >different classes. (Ironically, here I would use the same attribute for >all classes in oder to use the same mechanism for all energy objects to >retrieve their type.) > >In the requirements document (draft-ietf-eman-requirements-14) there are >clear differences between the sets of information elements to be reported >for devices, components, and interfaces. The current model does not >reflect this. > >This is different for the model in draft-nordman-eman-er-framework-01. >Here the model is fully aligned with the requirements and supports >different sets of information provided for different kinds of energy >objects. It uses simple tables to show which information needs to be >reported for which type of energy object. > >I think the differentiation between devices, components, and power >interfaces as it is made in the requirements draft needs to be reflected >by the eman framework. > >Cheers, > Juergen >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman