Return-Path: X-Original-To: eman@ietfa.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_--