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

From: Brian Hedstrom <[email-masked]>
Date: Fri, 2 Aug 2013 14:47:41 +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
[email-masked]

On 7/29/13 9:00 AM, "John Parello (jparello)" <[email-masked]> 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" <[email-masked]> 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     [email-masked]       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
>> 
>> 
>> _______________________________________________
>> eman mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/eman
>_______________________________________________
>eman mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/eman

---

From: "John Parello (jparello)" <[email-masked]>
Date: Thu, 8 Aug 2013 17:32:10 +0000

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:[email-masked]] 
Sent: Friday, August 02, 2013 7:48 AM
To: John Parello (jparello); Juergen Quittek
Cc: [email-masked]
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
[email-masked]

On 7/29/13 9:00 AM, "John Parello (jparello)" <[email-masked]> wrote:

>>contributed to, but since I commented the individual ER framework 
>>draft, I want to also comment on the WG's EMAN framework draft.  \
>> 
>> 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.
>> 
>>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."
>>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.
>> 
>>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?
>> 
>> As conclusion: there is a big improvement. The draft is moving 
>>towards the right direction, but still some way to go.
>>

---

From: "John Parello (jparello)" <[email-masked]>
Date: Thu, 8 Aug 2013 17:46:05 +0000

HI Juergen,

Thanks so much, sorry we couldn't sync up in Berlin but the feedback is great 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 

On Jul 29, 2013, at 8:40 AM, "Juergen Quittek" <[email-masked]> 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.
> 
> 

[jp] thanks!

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

[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 both so that a data model for wire or mgt stations could be derived from the IM. For the real world I think we have the sections on that I'll make that clearer.

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

[jp] That's an interesting premise. So are you saying if a device can't determine 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 gets the information from the device.  So I'm not sure why that's a restriction for this IM. 

Taking it a bit further what happens if it is only specified in an NMS. What's the interchange format between NMS'? 

Most  modern systems want a JSON or XML model of information at the NMS layer. So I think it's helpful to specify a model that can be used at device and mgt level and the data models can restrict / label optional if they wanted.  We stated that in the new version.

> 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?
> 

[jp]OK Is the word site not general enough? By site we meant deployment - is 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 relationships are given. Here the draft over-specifies how an EnMS is implemented and what how an EnMS should work internally. 
> 

[jp] Any text you think is better? Or things to delete?

Thanks!
Jp