Re: [eman] EMAN-REQ: the notion of importance

[Juergen Quittek <[e-mail]>]

Hi Benoit,

This is a difficult Diskussion for me as a non-native speaker. Initially I thought "power down priority" would be great, because it is about bringing the power down to a lower state. Unfortunatrly, the common use of "power down" is equivalent to "power off". If as you say "power shedding" limits the use case, then let's look for another term. What about "power reduction priority"?

Thanks,
    Juergen


On 01.03.2012, at 20:30, "Benoit Claise" <[e-mail]<mailto:[e-mail]>> wrote:

Hi Juergen,

Taking back your words:

I would like to standardize a mechanism, in this case the power down
priority.  That's what standards do.  I do not see reason to limit
the application of the mechanism (power down priority) to a single
Use case (power down less business relevant devices first).

On one side, you want a mechanism not limited to a single case (which I agree with).
On the other side, you're ready to call it "power shedding", which limit this to a single use case.

To leads me to think that the generic term "importance" was maybe not perfect, but actually better as it took into account more use cases...

Regards, Benoit.

Hi Brad,

Thanks for this hint.  Being not a native user I thought about powering
down to a lower power state, not about powering off.  But this doesn't
seem to be the way the term is commonly used.  Power shedding appears to
be much better suited.

Thanks,
    Juergen


On 01.03.12 17:25, "Brad Schoening" <<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>> wrote:



Juergen,

Power shedding is probably a more accurate term for the use cases here for
priority/importance than just simply power down.  There are many things in
a commercial setting that can be turned down, but not necessarily off.
Things such as variable speed fans, battery chargers, etc.



On 3/1/12 7:53 AM, "Juergen Quittek" <<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>> wrote:



Hi Benoit,

I would like to standardize a mechanism, in this case the power down
priority.  That's what standards do.  I do not see reason to limit
the application of the mechanism (power down priority) to a single
Use case (power down less business relevant devices first).

Why should the IETF do so?  Our task is to define useful mechanisms.
I do not like excluding other use cases.  Take for example a network
with two kinds of devices:
 - a few devices consuming a lot of energy and having high energy
   saving potential
 - a huge amount of devices with low power demand and very little
   Power saving potential when turned to sleep mode.

Even if the business importance of the few major power consumers
is higher than the business importance of the many small devices,
an energy manager may decide to achieve its power saving objectives
easier by powering down a just few main energy consumers instead of
powering down myriads of small devices that only marginally
contribute to energy saving.

We can't foresee constraints to be considered for powering down
Devices.  Giving the operator a "priority" allows the operator
to implement any scheme, may it be based on importance or mot.

Thanks,
   Juergen


On 01.03.12 16:03, "Benoit Claise" <<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>> wrote:





   Juergen, Rolf, John

   Looking at Rolf's feedback:

     I thought this is what you refer to as importance. If you have to
switch
something off because you cannot power all devices and you have to
decide
between 911 services or the phone in the janitors office, the priority
will tell you. So this is EMAN and I think we can say that, whatever
this
object means it has to do with energy and I agree with your example that
it helps you to decide what to power-off first in case you need to/want
to. If this is what importance means (I personally would still call it
something less ambiguous, but if we describe it better I am fine with
it)
I think it is something relevant. But you were referring to other use
cases. Care to share more?


   Would you guys be happier with a compromise such as "business
   importance", "context importance" or "Energy Management Importance"?

   Expanding on Juergen's proposal:
   OLD:
      5.1.3. Power-down priority

  The standard must provide means for retrieving and reporting
  power priorities of powered entities. Power-down priorities indicate
  an order in which powered entities should be switched to lower power
  states in case lower power states are desired.


   NEW:
      5.1.3. xxxxx

  The standard must provide means for ranking devices in the context
  of a site or deployment, indicating which devices are more critical
  to the operation. The value is useful during peak demand when
deciding
  which devices could be turned off. A ranking of devices gives an
  operator or control system a way to determine which devices should
  receive power or could be turned off for cost savings during peak
  hours of operation. In other words, if an operator is asked to turn
off
  devices during a certain period, xxxx indicates an order in which
powered
  entities should be switched to lower power states.


Regarding your role proposal 5.1.2, I believe it's fine.

Regards, Benoit (as a contributor)


     Dear all,

The requirements draft is the first one to be agreed on.
We can do this without having to deal with all details
that the framework and the MIB modules can solve.

In the current version draft-ietf-eman-requirements-05 there
is a requirement

OLD
  5.1.2.  Context information on powered entities

  The energy management standard must provide means for retrieving and
  reporting context information on powered entities, for example, tags
  associated with a powered entity that indicate the powered entity's
  role, or importance.


Seeing the ongoing discussion I suggest separating "role" and
"importance"
and moving from the fuzzy term "importance" to "power-down priority".
This would look like the following:

NEW
  5.1.2.  Context information on powered entities

  The standard must provide means for retrieving and reporting context
  information on powered entities, for example, tags associated with a
  powered entity that indicate the powered entity's role.

  5.1.3. Power-down priority

  The standard must provide means for retrieving and reporting
  power priorities of powered entities. Power-down priorities indicate
  an order in which powered entities should be switched to lower power
  states in case lower power states are desired.

I think that the proposed requirement 5.1.3 covers Rolf's requirements


for accurate naming and John's requirements for the functionality he
calls "importance".

Thanks,
   Juergen


On 29.02.12 10:02, "Rolf Winter" <<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>>
<<mailto:[e-mail]>mailto:[e-mail]> wrote:



       Hey John,

I am not asking for an IANA registry but a good description and
justification of importance. For most requirements it is just naturally
clear to have them such as having the ability to monitor power states.
No
justification needed in my opinion. Then a half sentences in the
document
requires something that is called "importance". Here I see a need for a
description and justification because it means different things to
different people.

BTW, I don't think that priority means the order in which devices need
to
be powered up. It certainly doesn’t mean that in the PoE context:

"This object controls the priority of the port from the point
of view of a power management algorithm.  The priority that
is set by this variable could be used by a control mechanism
that prevents over current situations by disconnecting first
ports with lower power priority.  Ports that connect devices
critical to the operation of the network - like the E911
telephones ports - should be set to higher priority."

I thought this is what you refer to as importance. If you have to switch
something off because you cannot power all devices and you have to
decide
between 911 services or the phone in the janitors office, the priority
will tell you. So this is EMAN and I think we can say that, whatever
this
object means it has to do with energy and I agree with your example that
it helps you to decide what to power-off first in case you need to/want
to. If this is what importance means (I personally would still call it
something less ambiguous, but if we describe it better I am fine with
it)
I think it is something relevant. But you were referring to other use
cases. Care to share more?

Best,

Rolf


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014




         -----Original Message-----
From: John Parello (jparello) [<mailto:[e-mail]>mailto:[e-mail]]
Sent: Dienstag, 28. Februar 2012 20:05
To: Rolf Winter; Mouli Chandramouli (moulchan); Ira McDonald; Brad
Schoening
Cc: eman mailing list
Subject: RE: [eman] EMAN-REQ: the notion of importance

Hi Rolf,

I used the terms in the email - it's defined in the framework,
definitions and MIB.  I'm not just throwing terms out I'm trying to
help to show *you* the difference in the email text. So let's focus on
the problem not try to discredit my word selection and  transitively
my premise in the drafts.

On to the concept you're not seeing.

Here's an example of the different concepts. Priority is ordering
(precedence) like boot ordering,   while importance is context
(significance).

Example:

So say I have devices on my trading floor and it is completely powered
off. I may have to power  them up in a certain order based on priority
but once they are up their running importance is different.

(PRIORITY)
Network Services
File Services
Software / Application Repository servers Database Servers Clients
Access Lobby Phones Trading Phones

Once they are running the importance to the business is different and
could be

(IMPORTANCE)
Network Services  (90-100)
Trading Phones  (80-90)
File Services (70-80)
Databases Servers (60-80)
Client Access (30-50)
Lobby Phones (10-30)
Software / Application Repository Servers (1-20)

The former is precedence the latter is significance.  Since priority is
already used in the PoE world for this I used "importance" to
distinguish the concepts. Especially since the word priority us used
for an action or process more times than for a device or thing. So
priority IMO seemed more natural to the process or power versus a
description of the device.

Simply put importance is needed to know what you can power off during
peak demand (but not solely that's just one very major use case)

BTW Notice my use of a "fuzzy"  name space for the device roles and
importance. Not all data needs IANA registry to be useful. So "fuzzy"
does not equal bad. Site defined guided data is extremely useful.

I've used importance with nearly a dozen EnMS vendors and scores of
vendors  and it's been easy to explain versus PoE priority. Happy to
show a running system if that clears it up. Suggest any new word you
like for the glossary and happy to discuss and select one but let's
make sure the concepts are retained.

A bit shocked this is being debated for re-justification though as  I
first presented at IETF-78 and it's been in the drafts since then.

To the Chairs: We need more input in this WG from EnMS vendors and BMS
vendors because personally, dealing with over 100 vendors in a
community of developers who use these concepts daily, I'm finding those
actively participating in the group woefully not representative of
problem space at all. We need more diverse input because these concepts
are in common use and a call for re-justification at this point
highlights that weakness.

Perhaps a demo of existing EnMS' to help educate the WG?

Jp


-----Original Message-----
From: <mailto:[e-mail]> [e-mail]<mailto:[e-mail]> [<mailto:[e-mail]>mailto:[e-mail]] On Behalf Of
Rolf Winter
Sent: Tuesday, February 28, 2012 1:16 AM
To: Mouli Chandramouli (moulchan); Ira McDonald; Brad Schoening
Cc: eman mailing list
Subject: Re: [eman] EMAN-REQ: the notion of importance

Well let me make myself clearer then.

You said: "Given the precedence of use of priority in other IETF MIBs,
I think the value of importance is clearly illustrated." I disagree
here because some proponents of importance state that "Priority
describes precedence while importance describes significance. Those are
two different concepts.". If that indeed is the case then you
conclusion seems wrong. If priority != importance then we should
clearly describe what importance is. I think saying importance ==
significance doesn't do the job. It is just a substitute of the word
using a thesaurus but not a definition of how this is used and why this
is a requirement. But please go ahead and come forward with a good
definition of it and a good justification of it as a requirement. We
can more concretely discuss about it then.

Best,

Rolf




NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014




           -----Original Message-----
From: Mouli Chandramouli (moulchan) [<mailto:[e-mail]>mailto:[e-mail]]
Sent: Dienstag, 28. Februar 2012 10:02
To: Rolf Winter; Ira McDonald; Brad Schoening
Cc: eman mailing list
Subject: RE: [eman] EMAN-REQ: the notion of importance

Rolf,

I do not know what you disagree on.

Initially, some folks jumped on the bandwagon it is not useful in
Energy Management.
And then a clear example of a similar term from the IETF PoE MIB was
shown.

Now the question is definition of the term.

I had mentioned in my email, that if it is a question of a clearer
definition of the term, that can be provided.

Thanks
Mouli


-----Original Message-----
From: Rolf Winter [<mailto:[e-mail]>mailto:[e-mail]]
Sent: Tuesday, February 28, 2012 2:05 PM
To: Mouli Chandramouli (moulchan); Ira McDonald; Brad Schoening
Cc: eman mailing list
Subject: RE: [eman] EMAN-REQ: the notion of importance

Mouli,

I disagree. There are people on the list that seem to disagree that
importance and priority are the same concept. Just the word



         importance


           is utterly confusing. It could relate to security, cost,
power-up or
power-down priority etc. Somebody mentioned PoE and there I agree it
is clearly defined. Importance is not. Let us first clearly define



         how


           it is used, then let’s make a requirement out of it in case
the WG
feels it should be. And let us not forget to make clear what it means
in the context of EMAN.

Best,

Rolf


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014




             -----Original Message-----
From: <mailto:[e-mail]> [e-mail]<mailto:[e-mail]> [<mailto:[e-mail]>mailto:[e-mail]] On





         Behalf



             Of Mouli Chandramouli (moulchan)
Sent: Dienstag, 28. Februar 2012 06:57
To: Ira McDonald; Brad Schoening
Cc: eman mailing list
Subject: Re: [eman] EMAN-REQ: the notion of importance

Given the precedence of use of priority in other IETF MIBs, I think
the value of importance is clearly illustrated.



Regarding Role, it is not intended to be an IANA registry.  This
concept is already used by deployments.  Should not be dismissed as
not useful.



If the question is – clearer description of these terms, in the
requirements draft, it is possible to provide some text and also





         how



             these concepts can be useful.



Thanks

Mouli



From: <mailto:[e-mail]> [e-mail]<mailto:[e-mail]> [<mailto:[e-mail]>mailto:[e-mail]] On





         Behalf



             Of Ira McDonald
Sent: Monday, February 27, 2012 11:15 PM
To: Brad Schoening; Ira McDonald
Cc: eman mailing list
Subject: Re: [eman] EMAN-REQ: the notion of importance



Hi,

Brad - good precedent - because it makes the "importance"
machine readable (and therefore useful).

But since EMAN (and many other IETF WGs) have consistently backed



           away


             from any standard definition of "role" (w/ behavior
semantics that



           are


             predictable), a text string of "role" is useless (except
in
a
vendor- or site-specific manner - out-of-scope IMHO).

And I suggest that the "universe of things" is too diverse to lend
itself to an IANA registry of standard "role" keywords.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect) Chair - Linux
Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working
Group Co-Chair
- IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG
Chair
- TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP &
Printer MIB Blue Roof Music/High North Inc
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/blueroofmusic<<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/
b
l
ueroofmusic>
<<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/blueroofmusic><http://sites.google.com/site>http://sites.google.com/site
/
h
ighnorthinc<<http://sites.google.com/site/highnorthinc>http://sites.google.com/site/highnorthinc>
<<http://sites.google.com/site/highnorthinc>http://sites.google.com/site/highnorthinc><mailto:[e-mail]>mailto:[e-mail]
m
Winter  579 Park Place  Saline, MI  48176  734-944-0094 Summer  PO



           Box


             221  Grand Marais, MI 49839  906-494-2434





On Mon, Feb 27, 2012 at 12:10 PM, Brad Schoening <<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>>
<<mailto:[e-mail]>mailto:[e-mail]>
wrote:

Benoit,



There is a precedence for doing this on the device in the PoE MIB,
rfc3621 which defines pethPsePortPowerPriority:

  pethPsePortPowerPriority OBJECT-TYPE
   SYNTAX INTEGER   {
              critical(1),
              high(2),
              low(3)
    }
   MAX-ACCESS read-write
   STATUS current
   DESCRIPTION
       "This object controls the priority of the port from the





         point



                      of view of a power management algorithm.  The
priority





         that



                      is set by this variable could be used by a
control





         mechanism



                      that prevents over current situations by
disconnecting





         first



                      ports with lower power priority.  Ports that
connect





         devices



                      critical to the operation of the network - like
the E911
        telephones ports - should be set to higher priority."
   ::= { pethPsePortEntry 7 }





Brad Schoening
e: <mailto:[e-mail]> [e-mail]<mailto:[e-mail]> ⟐ m: 917-304-7190











             Redefining Storage Economics





From: Benoit Claise <<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>> <<mailto:[e-mail]>mailto:[e-mail]>
Date: Mon, 27 Feb 2012 05:17:24 -0600
To: eman mailing list <<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>> <<mailto:[e-mail]>mailto:[e-mail]>
Subject: [eman] EMAN-REQ: the notion of importance



Dear all,

There is a discussion amongst the "EMAN requirements" authors right
now about the notion of importance.
We're trying to evaluate the requirements related to the





         "importance".



             The current draft version
<<http://tools.ietf.org/html/draft-ietf-eman-requirements-05>http://tools.ietf.org/html/draft-ietf-



           eman-


             requirements-05>  only mentions:


5.1.2.  Context information on powered entities

  The energy management standard must provide means for retrieving



           and


                reporting context information on powered entities, for
example,



           tags


                associated with a powered entity that indicate the
powered



           entity's


                role, or importance.


So there are no justifications why the importance is required.
The people who want this, please provide some more



           text/justifications


             Some extra questions:
- Is this importance specific to EMAN or is this generic also for
non Energy Objects?
- Importance is important related to ...?

Regards, Benoit (as a contributor for the EMAN-REQ)





_______________________________________________
eman mailing list
[e-mail]://www.ietf.org/mailman/listinfo/eman<mailto:[e-mail]://www.ietf.org/mailman/listinfo/eman>




         _______________________________________________
eman mailing list
[e-mail]://www.ietf.org/mailman/listinfo/eman<mailto:[e-mail]://www.ietf.org/mailman/listinfo/eman>


       _______________________________________________
eman mailing list
[e-mail]://www.ietf.org/mailman/listinfo/eman<mailto:[e-mail]://www.ietf.org/mailman/listinfo/eman>


     _______________________________________________
eman mailing list
[e-mail]://www.ietf.org/mailman/listinfo/eman<mailto:[e-mail]://www.ietf.org/mailman/listinfo/eman>