Subject: [eman] WG Last Call for EMAN Framework -09

From: Nevil Brownlee <[email-masked]>
Date: Wed, 11 Sep 2013 09:27:59 +1200

Hi all:

A new revision of the EMAN Framework draft was published yesterday.
Version -09 has many changes, improvements and clarifications since
the -08 version (published just before IETF-87 in Berlin).

The WG Last Call for it starts now, and will end on
Friday, 27 September.

Please read it now, and send your comments/suggestions/etc to the EMAN
list.  Comments like "seems fine now" are good, as are suggestions for
further improvement (accompanied by OLD/NEW text).

Cheers, Nevil

-- 
---------------------------------------------------------------------
  Nevil Brownlee                          Computer Science Department
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

---

From: Rolf Winter <[email-masked]>
Date: Wed, 18 Sep 2013 12:16:14 +0000

Hi,

here are a bunch of comments. Generally speaking the framework has improved quite a bit. I have a larger number of editorial suggestions and a few not so editorial ones:

editorial:

- weird spelling (e.g. Battery is capitalized in the abstract)
- inconsistent spelling (e.g. "Energy Management System" and "energy management system" are both used throughout the text without apparent reason, same applies to "power", "demand" and a whole bunch of other terms)
- expand acronyms of first use (e.g. EnMS, CFO etc.)
- s/this frameworks relationship/this framework's relationship/
- s/will poll energy from/will poll energy readings from/ (or similar)
- s/devices appliances,/devices, appliances,/
- measured in kilowatt hours... I personally would write "measured in watt hours" as kilo is merely an SI prefix. Kilo is certainly a common prefix but I am sure there are consumers that are measured in other SI prefixes...
- I personally prefer the passive voice over active voice: s/For EMAN we use kilowatts/For EMAN kilowatts are used/
- s/the same deployments/the same deployment/
- At the end of section 3.1 you say that: "The target devices may also include those communicating via non-IP protocols deployed among the power distribution and IP communication network", whereas you say earlier that target devices are expected to be IP-enabled (which makes sense because we really talk about SNMP here). Could we add that these devices are to be managed through a gateway or something similar which in turn is IP-enabled?
- s/Multiple Power Supply with Single Devices/Multiple Power Supplies with Single Device/
- The enumeration starting with: "While an EnMS may be a central point for corporate reporting..." is strange as it reads the EnMS is the central point for cost etc. maybe cost reporting etc.
- I found this sentence weird " To address Energy Management this specification describes an information model that can exist along with Network Management while addressing issues specific to Energy Management.. I offer an alternative wording: "This document describes an information model addressing issues specific to Energy Management, which complements existing Network Management models."
- s/producer, or meter, distributor, or store/producer, meter, distributor, or store/
- s/a category attributed/a category attribute/
- "the purpose the Energy Object serves in the EnMS". I think you mean something else. It is the purpose in the deployment, isn't it?
- I found the example of a car to explain power vs. energy quite patronizing. We already defined those terms and the example (also that late in the document) felt strange.
- In 4.4.1. you have a single sentence saying "Power Measurement.".
- I think the rule regarding SI unit and numerical value is that there is a space in between the two. In either case, use one scheme consistently.
- the document seems to rely on IEC 61850 quite a bit but never references it
- s/Power States Sets/Power State Sets/
- "Limitation (curtailment) of the power used by an Energy Object in a state is specified by" I would add an "e.g." here, since not all of them have to be used at the same time.
- EMAN-MONITORING-MIB has changed to EMAN-MON-MIB at some point but not everywhere in the text
- s/power source. metering, and aggregations/power source, metering, and aggregation/
- This sentence "Since one point of a power distribution system may cover many Devices with a complex wiring topology, this relationship type can be seen as an arbitrary set." sounds strange to me. Why can this be seen as an arbitrary set. Complex != arbitrary.
- Then later you write: "In such cases the Device SHOULD be modeled as an Energy Object that meters all of its Power Outlets and each Power Outlet MAY be metered by the Energy Object representing the Device." But you describe two cases before this sentence, whereas this seems to only refer to the former case. This is quite confusing.
- regarding the PDU in section 6, shouldn't "among the inlets or outlet" 
be "among the inlet or outlets"
- "Given the following examples Devices.." there's something wrong in this sentence.
- In section 6.1 I found it confusing that the 4 cases were first enumerated, and then described one by one again. I would leave the enumeration at the beginning and pull the text into the case description (if that is needed at all as there is already enough text describing it). In particular since you refer to devices like "device W" etc. These details will make no sense when the actual figure is pages away.
- s/meter DEvice/meter device/

a bit more than a nit:

1037C doesn't seem to define energy management system

I wonder if the framework is already sometimes to prescriptive for a framework, i.e. it defines details which probably would be better handled by the respective MIB definitions. E.g. that the importance is a value between 1 and 100 or how the keywords are encoded. Isn't that already more like a data model rather than an information model? Also in the UML representation, I would add a note that the types used (such as int, long etc.) are to be understood as examples as the actual MIB definitions are defining these details.

I have a general question when it comes to the metering and power source relationship. A metering relationship may be established between a device and multiple meters but the same does not hold for power source relationships. The question is why? The document does not actually argue why that's the case. I feel it is somewhat arbitrary since both the meter and the power source could well be the exact same device (like a smart PDU). There might be good reasons, they are just not in the document. Also, I think there are inconsistencies since in section 6.2. you somewhere mention that you define power source relationships between a metering device and devices downstream from that meter (second paragraph below the case 2 figure - btw. you might want to add figure numbering and captions in general). Or do you mean metering relationship here?

I am again advocating the removal of the aggregation relationship. The reason I have is that the relationship itself is quite different (and more general purpose) compared to the other two relationships. It is also less well specified (actually it is reduced to summation in the framework and leaves a number of issues are left open). So my suggestion is the following. Add the aggregation relationship to section 4.6.5 and add another bullet to the list:
"Some Devices may collect energy management information from multiple devices and aggregate this information where possible, e.g. a summation of all the received energy. This can be modeled with an aggregation relationship between the aggregating device and the Energy Objects from which the information is collected. This type of aggregation relationship is left for further development."

Finally I would remove section 9.1.4. since there are no battery power state sets (they are called charging states in the battery MIB and are distinctively different). I think the removal of 9.1.4 will not change a thing because the only thing it does is name something that is not being defined and then declares that the framework will not say anything about it.

Best,

Rolf

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB | Registered in England 2832014

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Nevil Brownlee
> Sent: Dienstag, 10. September 2013 23:28
> To: [email-masked]
> Cc: [email-masked]
> Subject: [eman] WG Last Call for EMAN Framework -09
> 
> 
> Hi all:
> 
> Version -09 has many changes, improvements and clarifications since the
> -08 version (published just before IETF-87 in Berlin).
> 
> The WG Last Call for it starts now, and will end on Friday, 27
> September.
> 
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman

---

From: "John Parello (jparello)" <[email-masked]>
Date: Tue, 24 Sep 2013 03:01:22 +0000

HI Rolf,

Awesome! Thanks so much for the detailed comments and read through!

I've updated and published version 10 of the draft to address your comments and suggestions.  Overwelmingly applied them. See inline. I marked your comments inline here as:

(+) Applied in the draft
(-) Regretfully not applied for the reasons listed
(!) Not applied needing more clarification and/or see further comment

editorial:

! weird spelling (e.g. Battery is capitalized in the abstract)
! inconsistent spelling (e.g. "Energy Management System" and "energy management system" are both used throughout the text without apparent reason, same applies to "power", "demand" and a whole bunch of other terms)

JP : Yeah I'm not comfortable with the capitalization either. When we started the draft all the comments we  had were to capitalize everything in the terminology section. You're facing the same issue in the requirements. In order to help with this I am publishing a new version of the terminology draft with a proposed capitalization scheme that is more sane. Terms that are common are lower case and anything that originates in our WG is capitalized. Let's discuss / open a thread in that context them apply those minor edits to both drafts.

+ expand acronyms of first use (e.g. EnMS, CFO etc.)

+ s/this frameworks relationship/this framework's relationship/

+ s/will poll energy from/will poll energy readings from/ (or similar)
/measurements/

+ s/devices appliances,/devices, appliances,/

JP : direct quote so I left it kilo. I agree with you but it's a direct quote.

JP : The passive voice , especially pusillanimous passive, is not preferred by me. Any occurrences found representing me as hypocritical should be indicated and will be changed. ;)  Seriously though it's an editorial choice and thanks for the detailed reading!

+ s/the same deployments/the same deployment/

+ At the end of section 3.1 you say that: "The target devices may also include those communicating via non-IP protocols deployed among the power distribution and IP communication network", whereas you say earlier that target devices are expected to be IP-enabled (which makes sense because we really talk about SNMP here). Could we add that these devices are to be managed through a gateway or something similar which in turn is IP-enabled?

JP : Revised. Thanks and please remember we are not "really talking about SNMP here". The framework is agnostic toward data modelling so SNMP is very much not  the only concern. The info model should apply to other data modeling languages and purposes.

+ s/Multiple Power Supply with Single Devices/Multiple Power Supplies with Single Device/

+ The enumeration starting with: "While an EnMS may be a central point for corporate reporting..." is strange as it reads the EnMS is the central point for cost etc. maybe cost reporting etc.

+ I found this sentence weird " To address Energy Management this specification describes an information model that can exist along with Network Management while addressing issues specific to Energy Management.. I offer an alternative wording: "This document describes an information model addressing issues specific to Energy Management, which complements existing Network Management models."

+ s/producer, or meter, distributor, or store/producer, meter, distributor, or store/

+ s/a category attributed/a category attribute/

+ "the purpose the Energy Object serves in the EnMS". I think you mean something else. It is the purpose in the deployment, isn't it?

JP :  So sorry you read it that way. I looked for an alternative place to put it but it IMO it's best in the measurement section. In the definitions there's no way to contrast them. I think it's very necessary as it took quite some time to get this group to use the terms correctly and we've even "agreed/consensus" to use them incorrectly. For example "Power interface" . Power is the measurement. the interface is where energy is transfered (s.b. energy interface).  Also with power states and charging states, It's really all energy states with power as a measure. Charging is not rooted in any term. It's a vernacular  way of indicating the direction of the energy and use from the view of the battery (it's receving energy and storing). That's attributes of an "energy state" not a "charging state". Even at other SDOs ( ODVA) where we have deep expertise on  use of energy (manufacturing) we've opetd to explain it this since so many people use the terms incorrectly. I presented that quite some time ago and that was well received so we agreed to keep it in at that meeting.

+ In 4.4.1. you have a single sentence saying "Power Measurement.".

+ I think the rule regarding SI unit and numerical value is that there is a space in between the two. In either case, use one scheme consistently.

JP : I don't see a rule for space but the prefixes from use are clearly non spaced kilometer, miligram, picowatt. Scrubbed.
 
+ the document seems to rely on IEC 61850 quite a bit but never references it

+ s/Power States Sets/Power State Sets/

+ "Limitation (curtailment) of the power used by an Energy Object in a state is specified by" I would add an "e.g." here, since not all of them have to be used at the same time.

JP - I changed "is" to  "may" to indicate the choice

+ EMAN-MONITORING-MIB has changed to EMAN-MON-MIB at some point but not everywhere in the text

+ s/power source. metering, and aggregations/power source, metering, and aggregation/

+ This sentence "Since one point of a power distribution system may cover many Devices with a complex wiring topology, this relationship type can be seen as an arbitrary set." sounds strange to me. Why can this be seen as an arbitrary set. Complex != arbitrary.

JP -  "Since one point of a power distribution system may cover many Devices within a wiring topology"

+ Then later you write: "In such cases the Device SHOULD be modeled as an Energy Object that meters all of its Power Outlets and each Power Outlet MAY be metered by the Energy Object representing the Device." But you describe two cases before this sentence, whereas this seems to only refer to the former case. This is quite confusing.

JP - See section 4.6.3 for rewrite. We want to say that it's priamrily used between devices but may be used intra-device. The PDU folks call this specifically metering on the device so we are trying to accomodate them. See threads way back from PDU vendors.

- regarding the PDU in section 6, shouldn't "among the inlets or outlet" be "among the inlet or outlets"

JP - A  PDU  or (any device) may have multiple inlets (very common) so that was intentionally made plural.

+ "Given the following examples Devices.." there's something wrong in this sentence.

JP changed to "In the following example we show variations on modeling the reference topologies using relationships"

! In section 6.1 I found it confusing that the 4 cases were first enumerated, and then described one by one again. I would leave the enumeration at the beginning and pull the text into the case description (if that is needed at all as there is already enough text describing it). In particular since you refer to devices like "device W" etc. These details will make no sense when the actual figure is pages away.

JP - Can you elaborate more. in 6.1 I listed 4 devices that I use over again in each type of topology case. I'd like to get more feedback on that from the list.

+ s/meter DEvice/meter device/

a bit more than a nit:

+ 1037C doesn't seem to define energy management system

! I wonder if the framework is already sometimes to prescriptive for a framework, i.e. it defines details which probably would be better handled by the respective MIB definitions. E.g. that the importance is a value between 1 and 100 or how the keywords are encoded. Isn't that already more like a data model rather than an information model?

JP : For an IM I do't think it's too prescriptive to give the values. If we leave that to the data model then we will get different values per "language" or contruct (SNMP, Java etc). So IMO I don't find it too prescriptive in this case. We've carried this notion and discussed it at length so I feel we have agreement on this specific point.

+ Also in the UML representation, I would add a note that the types used (such as int, long etc.) are to be understood as examples as the actual MIB definitions are defining these details.

JP : See new editors note.

! I have a general question when it comes to the metering and power source relationship. A metering relationship may be established between a device and multiple meters but the same does not hold for power source relationships. The question is why? The document does not actually argue why that's the case. I feel it is somewhat arbitrary since both the meter and the power source could well be the exact same device (like a smart PDU). There might be good reasons, they are just not in the document. 

JP : There's no restriction on multiple power sources. In 6.1 Case 2 we are showing multiple inlets but from two outlets of the same device. I can add multiple inlets from two different devices as Case 2. ALL: How does the list feel on this Add another case or change this one?

! Also, I think there are inconsistencies since in section 6.2. you somewhere mention that you define power source relationships between a metering device and devices downstream from that meter (second paragraph below the case 2 figure - btw. you might want to add figure numbering and captions in general) (JP: thanks yes will add figures at next rev when we settle)
Or do you mean metering relationship here?

JP : I see your point, I'll work on that section with the authors and have a better paragraph in -11.

!  I am again advocating the removal of the aggregation relationship. The reason I have is that the relationship itself is quite different (and more general purpose) compared to the other two relationships. It is also less well specified (actually it is reduced to summation in the framework and leaves a number of issues are left open). So my suggestion is the following. Add the aggregation relationship to section 4.6.5 and add another bullet to the list:
"Some Devices may collect energy management information from multiple devices and aggregate this information where possible, e.g. a summation of all the received energy. This can be modeled with an aggregation relationship between the aggregating device and the Energy Objects from which the information is collected. This type of aggregation relationship is left for further development."

JP : I'm always happy to go with consensus but I feel the removal of this is more arbitrary. We included this relationship specifically to help with our liaison with manufacturing SDO. Specifically asked for. In CIP there is a relationship to an aggregating device and it's very well known and mature. Perhaps a reference to it here. I any case we would be removing something we got from an SDO and carried for quite some time. This is the same issue I had with proxy. I'd prefer to keep this in (and proxy btw since it's called for in the requirements)

! Finally I would remove section 9.1.4. since there are no battery power state sets (they are called charging states in the battery MIB and are distinctively different). I think the removal of 9.1.4 will not change a thing because the only thing it does is name something that is not being defined and then declares that the framework will not say anything about it.

JP : lets discuss this in another thread. See my previous comment on power and energy. IF we "normalize" our abstractions to be from the point of view of energy not the device/component we can unify the states. Charging states is not accurate. Energy direction and storing is more accurate. Also we received comments from Ted here   http://www.ietf.org/mail-archive/web/eman/current/msg02000.html so I hope you both can discuss and I'll monitor consensus. I'd like to unify the states to one series of "sets of states". Similar to a set of interfaces on one class. We'll accomplish something quite useful if we do.

Many thanks Rolf!
Jp

---

From: Rolf Winter <[email-masked]>
Date: Wed, 25 Sep 2013 09:59:32 +0000

Snipped most things. For some points I will open specific Email threads.

> ! weird spelling (e.g. Battery is capitalized in the abstract) !
> inconsistent spelling (e.g. "Energy Management System" and "energy
> management system" are both used throughout the text without apparent
> reason, same applies to "power", "demand" and a whole bunch of other
> terms)
> 
> JP : Yeah I'm not comfortable with the capitalization either. When we
> started the draft all the comments we  had were to capitalize
> everything in the terminology section. You're facing the same issue in
> the requirements. In order to help with this I am publishing a new
> version of the terminology draft with a proposed capitalization scheme
> that is more sane. Terms that are common are lower case and anything
> that originates in our WG is capitalized. Let's discuss / open a thread
> in that context them apply those minor edits to both drafts.

This is what the requirements draft converged to as well.

> - measured in kilowatt hours... I personally would write "measured in
> watt hours" as kilo is merely an SI prefix. Kilo is certainly a common
> prefix but I am sure there are consumers that are measured in other SI
> prefixes...
> 

If that's the case, I think it should be actually put in quotation marks to show that.
  > 
> + I think the rule regarding SI unit and numerical value is that there
> is a space in between the two. In either case, use one scheme
> consistently.
> 
> JP : I don't see a rule for space but the prefixes from use are clearly
> non spaced kilometer, miligram, picowatt. Scrubbed.

That's not what I meant. I meant between numerical value and the SI unit. So it is not 3mW but 3 mW. That's still in the document (both forms, so it is still inconsistent).

> 
> + "Limitation (curtailment) of the power used by an Energy Object in a
> state is specified by" I would add an "e.g." here, since not all of
> them have to be used at the same time.
> 

Then you should add a "be"
 
> + This sentence "Since one point of a power distribution system may
> cover many Devices with a complex wiring topology, this relationship
> type can be seen as an arbitrary set." sounds strange to me. Why can
> this be seen as an arbitrary set. Complex != arbitrary.
> 

Sure, but why would one call this arbitrary I still don't get.

> that was intentionally made plural.

But then I still don't get why you insist on a single outlet because a PDU surely has more than one?

Best,

Rolf