Subject: [eman] #39: Energy Control not effectively drawn out in the use cases, or defined

From: "eman issue tracker" <[email-masked]>
Date: Thu, 18 Jul 2013 15:34:34 -0000

#39: Energy Control not effectively drawn out in the use cases, or defined

 In the Applicability Statement, the "Control/Controlling" pattern is not
 drawn out in each use case, like the Metering/Powering/Reporting are.

 Use Case Section Description:
         In this section a selection of scenarios for energy management
         are presented.  The fundamental objective of the use cases is to
         list important network scenarios that the EMAN framework should
         solve.  These use cases then drive the requirements for the EMAN
         framework.

         Each scenario lists target devices for which the energy
         management framework can be applied, how the reported-on devices
         are powered, and how the reporting is accomplished.  While there
         is some overlap between some of the use cases, the use cases
         illustrate network scenarios that the EMAN framework supports.

 Each Use Case has:
 The essential properties of this use case are:

           . Target devices: network devices such as routers and
              switches as well as their components.
           . How powered: typically by a Power Distribution Unit (PDU)
              on a rack or from a wall outlet.  The components of a
              device are powered by the device chassis.
           . Reporting: direct power measurement can be performed at a
              device level.  Components can report their power
              consumption directly or the chassis/device that can report
              on behalf of some components.
 In addition, I do not see a thorough definition of control in the draft to
 explain the meaning in this context.  The definitions draft draft-parello-
 eman-definitions-08 provides a definition for Energy Control. This draft
 should reference that definition and use this term.  The term definition
 in the Definitions draft does not appear to restrict the definition of
 Control to changing the energy/power state of a device.  Is there a
 disconnect between these drafts in the meaning of "Control"?

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-eman-
  [email-masked]           |  applicability-
     Type:  defect                   |  [email-masked]
 Priority:  major                    |     Status:  new
Component:  applicability-statement  |  Milestone:
 Severity:  -                        |    Version:  2.0
                                     |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/eman/trac/ticket/39>
eman <http://tools.ietf.org/eman/>

---

From: Bruce Nordman <[email-masked]>
Date: Thu, 18 Jul 2013 13:56:19 -0700

In the EMAN charter, mention of control is mostly about power
state control, with a mention of proxy control the only other use
of the term.  Thus, while Energy Management does include control,
it is a small part of the total EMAN picture.

In the requirements, of the several dozen in the draft, there is
one on power state control, one on power interface control,
and four on proxy control.  So, control is also a modest part
of our requirements.

Given all this, I think it appropriate that control is given the
degree of attention in the applicability statement that it currently
has.

With definitions in the Requirements draft, I don't think we need
the definitions draft anymore.
While the requirements draft defines "energy control", it does not
use it.  It is not a term I am familiar with and don't see that it adds
value to have it.  Referencing power state control and power supply
control directly seems more clear.

So, I think for how control is treated in the Applicability Statement,
I think we are OK.

Thanks much,

--Bruce

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
*nordman.lbl.gov*
[email-masked]
510-486-7089
m: 510-501-7943

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Fri, 19 Jul 2013 11:09:32 +0000

> disconnect between these drafts in the meaning of "Control"?

Hi Brian,  

[EMAN-DEF] is the same terminology draft which has been integrated with
EMAN-Framework draft.
We shall update the applicability statement draft with after this WG
meeting. 

Secondly, we can add or call out for more context in terms of Control
aspect. 

For example in Section 2.2, Control has been mentioned in the use case
"For each port, the PSE can control the power supply (switching it on and
off) and meter actual power provided."

Thanks
Mouli

---

From: "John Parello (jparello)" <[email-masked]>
Date: Mon, 22 Jul 2013 17:19:12 +0000

Hi Brain,

Thanks!

+1 on your comments. So I see two things you want that I agree with.

1) Spell out the use case for control in line with the other use cases
2) Definitions should be uniform and map to a common glossary draft

I agree with those two points.

Bruce commented that control is a "small part of EMAN". I disagree with that.  It's either part of the standard or not. Whether it's a small or large portion is up to the deployment not the standard.  If I deploy a standard, the portions that are of concern to me may be much larger than that for others. So I may care about control more than some other deployment.

Either way to your point the use case should be defined thoroughly.

For the definitions I contend that the draft I proposed should be a WG item. Each draft is free to list the definitions that apply therein.  However there are definitions that apply to the energy management space in general that are handy to list, both for our WG and other SDOs.

Participating in other SDOs as I do I find this helpful and as you pointed out for the Cable group already references.

We've spent a lot of time gathering terms and concepts and to scatter them in different drafts doesn't do a service to the information we gathered.

We have precedence to define terms whether used in a draft or not AND whether used for internet applicability or not.
See RFCs: 1392, 2828, 4949 

The glossary both in my draft and in the examples help define the space that all the drafts use.

I propose that the definitions draft be made a WG item after an edit that places it in line with the formats of the drafts I cited.

Jp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of eman issue tracker
Sent: Thursday, July 18, 2013 8:35 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [eman] #39: Energy Control not effectively drawn out in the use cases, or defined

 In the Applicability Statement, the "Control/Controlling" pattern is not  drawn out in each use case, like the Metering/Powering/Reporting are.

 Each Use Case has:

 In addition, I do not see a thorough definition of control in the draft to  explain the meaning in this context.  The definitions draft draft-parello-
 eman-definitions-08 provides a definition for Energy Control. This draft  should reference that definition and use this term.  The term definition  in the Definitions draft does not appear to restrict the definition of  Control to changing the energy/power state of a device.  Is there a  disconnect between these drafts in the meaning of "Control"?

-- 
-------------------------------------+----------------------------------
-------------------------------------+---
 Reporter:                           |      Owner:  draft-ietf-eman-
  [email-masked]           |  applicability-
     Type:  defect                   |  [email-masked]
 Priority:  major                    |     Status:  new
Component:  applicability-statement  |  Milestone:
 Severity:  -                        |    Version:  2.0
                                     |   Keywords:
-------------------------------------+----------------------------------
-------------------------------------+---

_______________________________________________
eman mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eman

---

From: Bruce Nordman <[email-masked]>
Date: Thu, 25 Jul 2013 15:43:00 -0700

Comments inline below.

> 1) Spell out the use case for control in line with the other use cases

The applicability statement seems fine as it is.
The ability to control devices doesn't introduce new content into
the framework or its applicability in the way that reporting or
powering do.

> 2) Definitions should be uniform and map to a common glossary draft

I thought we already put the definitions into the framework draft making
it unnecessary to have a separate one only for definitions.
Otherwise, why were they put into the framework draft?

> Bruce commented that control is a "small part of EMAN". I disagree with
> that.  It's either part of the standard or not. Whether it's a small or
> large portion is up to the deployment not the standard.  If I deploy a
> standard, the portions that are of concern to me may be much larger than
> that for others. So I may care about control more than some other
> deployment.
>

No one said that control is not part of eman.
I simply observed objective facts about how large a
part of eman it is.  For example, of 65 requirements,
four are on the relatively obscure issue of proxy control,
and of the remaining sixty one, 2 are about control and
59 are not.  People may make good use of those
features that eman specifies, and that is all to the good,
but it doesn't change the objective facts about how
much of eman content is about control.

After today I am offline for a week and look forward
when I return to hearing about progress on the list
and at the meeting.  Thanks much,

--Bruce

> For the definitions I contend that the draft I proposed should be a WG
> item. Each draft is free to list the definitions that apply therein.
>  However there are definitions that apply to the energy management space in
> general that are handy to list, both for our WG and other SDOs.
>
> Participating in other SDOs as I do I find this helpful and as you pointed
> out for the Cable group already references.
>
> We've spent a lot of time gathering terms and concepts and to scatter them
> in different drafts doesn't do a service to the information we gathered.
>
> We have precedence to define terms whether used in a draft or not AND
> whether used for internet applicability or not.
> I propose that the definitions draft be made a WG item after an edit that
> places it in line with the formats of the drafts I cited.
>
> Jp
>
>
>
>  In addition, I do not see a thorough definition of control in the draft
> to  explain the meaning in this context.  The definitions draft
> draft-parello-

---

From: "John Parello (jparello)" <[email-masked]>
Date: Fri, 26 Jul 2013 04:03:22 +0000

Hi Bruce,

I agree with Brian the use cases needs to be further explained. He proposed great text for an addition which I think should be incorporated.

You didn't read my reply regarding glossary past your signature?. The drafts have only what they use not a full glossary of terms as in the examples  I sited. So I contend a glossary is useful for the reasons I cited.

ACK on your count of requirements if that's what you meant. If you meant control is a small part of the system or spec then NACK on that. You can have one requirement filling up more of the information model etc. Minor point.

Have a great time off!
Jp

-----Original Message-----
From: Bruce Nordman [mailto:[email-masked]] 
Sent: Thursday, July 25, 2013 3:43 PM
To: John Parello (jparello)
Cc: eman issue tracker; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [eman] #39: Energy Control not effectively drawn out in the use cases, or defined

Comments inline below.

On Mon, Jul 22, 2013 at 10:19 AM, John Parello (jparello) <[email-masked]> wrote:

	Hi Brain,
	
	Thanks!

The ability to control devices doesn't introduce new content into the framework or its applicability in the way that reporting or powering do.

 
I thought we already put the definitions into the framework draft making it unnecessary to have a separate one only for definitions.
Otherwise, why were they put into the framework draft?

I simply observed objective facts about how large a part of eman it is.  For example, of 65 requirements, four are on the relatively obscure issue of proxy control, and of the remaining sixty one, 2 are about control and

features that eman specifies, and that is all to the good, but it doesn't change the objective facts about how much of eman content is about control.

when I return to hearing about progress on the list and at the meeting.  Thanks much,

--Bruce 

	

	

	Jp

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On Behalf Of eman issue tracker
	Sent: Thursday, July 18, 2013 8:35 AM
	To: [email-masked]; [email-masked]
	Cc: [email-masked]
	Subject: [eman] #39: Energy Control not effectively drawn out in the use cases, or defined

	

	 Each Use Case has:

	

--
Bruce Nordman
nordman.lbl.gov
[email-masked]
510-486-7089
m: 510-501-7943