Re: [eman] review of draft-ietf-eman-framework-08

["John Parello (jparello)" <[e-mail]>]

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 station etc. 

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 submission it was easier to just put plain text in the drafts. All I did was take the UML and represent it as a class definition. See section 5 or attached clip.

Thanks!
JP


-----Original Message-----
From: Brian Hedstrom [mailto:[e-mail]] 
Sent: Friday, August 02, 2013 7:48 AM
To: John Parello (jparello); Juergen Quittek
Cc: [e-mail]
Subject: Re: [eman] review of draft-ietf-eman-framework-08

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
[e-mail]
 






On 7/29/13 9:00 AM, "John Parello (jparello)" <[e-mail]> 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
>(expect ridiculous spelling mistakes)
>
>On Jul 29, 2013, at 8:40 AM, "Juergen Quittek" <[e-mail]> wrote:
>
>> Dear all,
>> 
>> 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.  \
>> 
>> Here are my high-level comments on the new version -08 of 
>>draft-ietf-eman-framework. Detailed comments will follow in a separate 
>>message.
>> 
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> With this structure, the draft is much easier to read and to 
>>understand than previous versions.
>> 
>> 
>> 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.
>> 
>> 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?
>> 
>> 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.
>> 
>> As conclusion: there is a big improvement. The draft is moving 
>>towards the right direction, but still some way to go.
>> 
>> I look forward to a vivid discussion.
>> 
>> Cheers,
>>    Juergen
>> 
>> 
>> 
>> 
>> 
>> --
>> Juergen Quittek     [e-mail]       Tel: [phone]
>> General Manager     http://www.neclab.eu    Fax: [phone]
>> Network Research Division,   NEC Europe Ltd.
>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
>> 
>> 
>> _______________________________________________
>> eman mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/eman
>_______________________________________________
>eman mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/eman