[eman] eman framework issue: Do we start from a software design or do we start from the physical world?

[Juergen Quittek <[e-mail]>]

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