Re: [eman] Bclaise - draft-ietf-eman-framework-10: WGLC comments

[Benoit Claise <[e-mail]>]

Thanks John.

Regards, Benoit
> 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
>
>
>
>
>
>