Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A6021E8130 for ; Sun, 13 Oct 2013 14:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.576 X-Spam-Level: X-Spam-Status: No, score=-9.576 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_6x6=0.4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRlL3tGZrvXU for ; Sun, 13 Oct 2013 14:58:11 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EDDE421F9A1C for ; Sun, 13 Oct 2013 14:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17870; q=dns/txt; s=iport; t=1381701489; x=1382911089; h=from:to:cc:subject:date:message-id:mime-version; bh=ihP+Gra4grSRcSajdWIXBMTZJmbGXIupLqmikJUXtK4=; b=UBnWDvb9Tc2PkYdOL6ObYCAN2pLMPM/QZrkOaYjTDZETJavabDjD3pFZ Aapc4eHTGi2kIsZe4t3fBCGPG6Nf0GogsLZfrmR5EmEn/MSwaFqtjtysc Ji+BdbG5CkiCmQrLYyu3pViQboA381+4f3S/gk6zmsV4/Q1SQ5CHRsXPa I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsGANEWW1KtJXG9/2dsb2JhbABPCoJDRDhSwW2BGhZtB4InAQQnSwcSASpWJgEEDg2Hfgy8aY4JBguBBzGDJoEEA4kEiySVX4MkgXA5 X-IronPort-AV: E=Sophos; i="4.93,487,1378857600"; d="scan'208,217"; a="268625253" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 13 Oct 2013 21:58:00 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9DLvxbu021490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 13 Oct 2013 21:57:59 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Sun, 13 Oct 2013 16:57:59 -0500 From: "John Parello (jparello)" To: "eman@ietf.org" Thread-Topic: Bclaise - draft-ietf-eman-framework-10: WGLC comments Thread-Index: Ac7IX0dtXM1E5X8eSmaK2EjI0mefNA== Date: Sun, 13 Oct 2013 21:57:58 +0000 Message-ID: <9C213D38848B89428F46808B16F6F08601667938@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.78.193] Content-Type: multipart/alternative; boundary="_000_9C213D38848B89428F46808B16F6F08601667938xmbalnx04ciscoc_" MIME-Version: 1.0 Subject: [eman] Bclaise - draft-ietf-eman-framework-10: WGLC comments X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 21:58:16 -0000 --_000_9C213D38848B89428F46808B16F6F08601667938xmbalnx04ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Benoit for the detailed review. I've applied the majority of your co= mments 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 th= read I deleted the draft txt form your email for better reading.... Abstract: On the top of J=C3=BCrgen's feedback on the abstract, I'm wondering: Wh= at is a "physical" reference model? 1. Introduction power state -> Power State. Some more instances: be consistent in terms of capitalization in the in= troduction. We need to introduce that there are different relationship types, to so= lve 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 a= s "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 be= en 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 definit= ions should be changed accordingly + JP : Scrubbed. outlets/inlets are the physical and Power Interfaces are t= he abstraction / model. Nameplate Power s/a device/an Electrical Device? ! JP : this definition highly reviewed and we have no definition of an Elec= trical 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 spec= ific 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 devi= ce" are used + JP : Revised definition use and this section. 3.2 Physical Reference Model Permutation of topologies or permutations of elements, which i= n 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 di= ffer 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 de= vice -> Device, monitoring -> Energy Monitoring control -> Energy Control Y= ou removed the fact that ######## is energy. Device versus device versus ta= rget 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 co= ncerns? Is "concerns" the right term? Should we have some concerns that som= e 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 equiva= lent to Electrical Equipments are not addressed. ! JP : Combined yours with JQ text """ The primary focus of this framework is the management of Electrical Equipme= nt. Non-Electrical Equipment can be covered by the framework by providing i= nterfaces that comply with the framework. For example, using the same units= for power and energy. Therefore, Non-Electrical Equipment that do not conv= ert-to or present-as equivalent to Electrical Equipment are not addressed. """ 4.1 Conceptual Model 1st Para: No need. 2nd Para: interconnections =3D relationships We introduced the notion= of relationships already Proposal: "" describe a means to report information, provide control, and model the rela= tionships 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 de= scribe the relationships among and connections between devices and componen= ts. "" 3rd Para: I finally get it, I think. You really want to Energy Object to be an (insta= nce 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 defin= ition. Proposal: whenever you mean the information model class, just mentio= n 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 real= ly want, insert the definition in this information model section here, alon= g 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 =3D relationship Energy Management may have no relation to the interconnections for Network Management the Energy Object interconnection =3D topology ! JP : change interconnection where redundant but had to keep it in cases w= here we are describing a relationship. I can't describe a relationship by s= aying 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 wh= ich 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 --_000_9C213D38848B89428F46808B16F6F08601667938xmbalnx04ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
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 th= read

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



Abstract:

    On the top of J=C3=BCrgen'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 capitaliz= ation in the introduction.

    We need to introduce that there are different relationsh= ip types, to solve the different problems.

+ JP : Done

2. Terminology

    The final agreement on [EMAN-REQ] was http://www.rfc-edi= tor.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", "l= ow-power", etc.I suggest you do the same.

    I searched for a specific term in the terminology sectio= n, and realized that the order is not alphabetical. A sentence such as: &qu= ot;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 y= es, the definitions should be changed accordingly

+ JP : Scrubbed. outlets/inlets are the physical and Power Interfaces a= re the abstraction / model.
       
    Nameplate Power  s/a device/an Electrical Device?
! JP : this definition highly reviewed and we have no definition of an Elec= trical 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 Devi= ce definition in the terminology, which is NOT used in this text, while &qu= ot;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 di= ffer from Network Management topologies.
"""


        energy management system -> Energy Mana= gement System Pay attention to the terms capitalization in the figures as w= ell. Here, we speak about device -> Device, monitoring -> Energy Moni= toring 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 addr= essed" is vague  Which concerns? Is "concerns" the righ= t 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 Equipme= nt. Non-Electrical Equipment can be covered by the framework by providing i= nterfaces 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 t= o Electrical Equipment are not addressed.
"""

4.1 Conceptual Model

          1st Para: No need.

      2nd Para: interconnections =3D relationships We i= ntroduced the notion of relationships already Proposal:
""
describe a means to report information, provide control, and model the rela= tionships 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 de= scribe the relationships among and connections between devices and componen= ts.
""

    3rd Para:
I finally get it, I think. You really want to Energy Object to be an (insta= nce 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 me= an 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 real= ly want, insert the definition in this information model section here, alon= g 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 =3D relationship
 Energy Management may have no
relation to the interconnections for Network Management the Energy
Object
interconnection =3D topology

! JP : change interconnection where redundant but had to keep it in cases w= here we are describing a relationship. I can't describe a relationship by s= aying 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 wh= ich 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






--_000_9C213D38848B89428F46808B16F6F08601667938xmbalnx04ciscoc_--