Subject: [eman] Bclaise - draft-ietf-eman-framework-10: WGLC comments
From: "John Parello (jparello)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Sun, 13 Oct 2013 21:57:58 +0000
List-Id: Discussions about the Energy Management Working Group <eman.ietf.org>

Thanks Benoit for the detailed review. I've applied the majority of your comments which will appear in -11
See inline:
(+) Applied in the draft
(-) Regretfully not applied for the reasons listed
(!) Not applied needing more clarification and/or see further comment or thread

I deleted the draft txt form your email for better reading....

Abstract:

    On the top of JÃ¼rgen's feedback on the abstract, I'm wondering: What is a "physical" reference model?

1. Introduction

    power state -> Power State.
    Some more instances: be consistent in terms of capitalization in the introduction.

    We need to introduce that there are different relationship types, to solve the different problems.

+ JP : Done

2. Terminology

    The final agreement on [EMAN-REQ] was http://www.rfc-editor.org/authors/rfc6988.txt The terms specified in the terminology section are capitalized throughout the document; the exceptions are the well-known terms "energy" and "power". These terms are generic and are used in generated terms such as "energy-saving", "low-power", etc.I suggest you do the same.

    I searched for a specific term in the terminology section, and realized that the order is not alphabetical. A sentence such as: "The terms in the terminology section are not classified alphabetically, but the order has been chosen to improve the document readiness, with terms building on the top of each others"

    Please change the "$" sign for all entries in the terminology section.

+ JP : Done

    Are Power Inlets and Power Oulets Power Interfaces? If yes, the definitions should be changed accordingly

+ JP : Scrubbed. outlets/inlets are the physical and Power Interfaces are the abstraction / model.

    Nameplate Power  s/a device/an Electrical Device?

! JP : this definition highly reviewed and we have no definition of an Electrical Device. Basic grammar would be to use Electric Device but no need to go there at all. Just device.

3. Concerns...

    Again "physical" reference model.

+ JP : thanks this was scrubbed in the entire document so can't list a specific line but please review as this should meet what you want

3.1 Target Devices

           I'm confused by the Device definition in the terminology, which is NOT used in this text, while "device" (paragraph above) and "target device" are used

+ JP : Revised definition use and this section.

3.2 Physical Reference Model

             Permutation of topologies or permutations of elements, which in turn, create different topologies?
I believe you meant the latter.

+ JP : changed
"""
While many more topologies can be created with combination of devices, the following are some basic ones that show how Energy Management topologies differ from Network Management topologies.
"""

        energy management system -> Energy Management System Pay attention to the terms capitalization in the figures as well. Here, we speak about device -> Device, monitoring -> Energy Monitoring control -> Energy Control You removed the fact that ######## is energy. Device versus device versus target device? I'm wondering if we should not add the Power Interfaces in the figures.

+ JP : done didn't add PI can add if we agree as a group this is needed.

3.4 Concerns not addressed

      One line of intro please: "concerns not addressed" is vague  Which concerns? Is "concerns" the right term? Should we have some concerns that some concerns are not addressed? :-) Not addressed by this framework, I guess. What you want to say is "out of scope of this framework", right?

+ JP : Done

      Non-Electrical equipments that do not convert-to or present-as equivalent to Electrical Equipments are not addressed.

! JP : Combined yours with  JQ text
"""
The primary focus of this framework is the management of Electrical Equipment. Non-Electrical Equipment can be covered by the framework by providing interfaces that comply with the framework. For example, using the same units for power and energy. Therefore, Non-Electrical Equipment that do not convert-to or present-as equivalent to Electrical Equipment are not addressed.
"""

4.1 Conceptual Model

          1st Para: No need.

      2nd Para: interconnections = relationships We introduced the notion of relationships already Proposal:
""
describe a means to report information, provide control, and model the relationships among physical entities (equipment).
Here, it's physical entities (equipment).
""
    We had already device, Device, target device, Electrical Object
    Be consistent.

+ JP : 1P edited from other comments. 2P changed to
"""
An information model for Energy Management will need to describe a means to monitor and control devices and components. The model will also need to describe the relationships among and connections between devices and components.
""

    3rd Para:
I finally get it, I think. You really want to Energy Object to be an (instance of the) Device, Component, or Power Interface class in the information model. The readers start with the terminology and since they don't know you will need an information model, they're puzzled by the Energy Object definition. Proposal: whenever you mean the information model class, just mention
    Device Class
    Component Class
    etc.
As you did with the subtitles below.
And no need to define Energy Object in the terminology section. If you really want, insert the definition in this information model section here, along with the Device Class definition. Same thing for component.
Btw, the Energy Object is not a class but an instance of the class.

+ JP : Ok scrubbed this as discussed.

nterconnection = relationship
 Energy Management may have no
relation to the interconnections for Network Management the Energy
Object
interconnection = topology

! JP : change interconnection where redundant but had to keep it in cases where we are describing a relationship. I can't describe a relationship by saying it's a relation etc.

4.2.3 Power Interface Class

The power
interface class is a sub-class of Energy Object that represents the
interconnection among devices and components.
Does it?
It represents the attach point for the relationship. I see later:
 Power Source relationships are intended
to identify the connections between Power Interfaces.
The Power Interface definition should be improved.

+ JP : moved definition into class description and clarified definition.

4.3.2 Context in General

Shouldn't this text be part of 4.3.4 [jp:keywords]?

! JP : Not sure what you mean there. Section 4.3.4 is regarding keywords which is part of context and 4.3.2 is talks about context in general

4.4.1 Measurements: Power

In the future, avoid the future tense for future RFCs. :-)

+ JP : done in the present ;)

4.5 Control

Power States that it implements.
that it supports
This is more precise.

+ JP : Done I think implements is clearer but ok changed to supports.

4.6.4 Guidelines: Aggregation

Since an EnMS is naturally a point of aggregation it is not necessary to
model aggregation for Energy Management Systems. Aggregation SHOULD be
used for power and energy. It MAY be

"Aggregation SHOULD be used for power and
energy" is misleading I guess you mean: "The Aggregation
Relationship is intended for power and energy" For the rest below.
Section 6 is a series of examples I'm fine with section 7, 8, and 9
(IANA, which I wrote) Regards, Benoit

+ JP : Done

Thanks!!

Jp