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

[Benoit Claise <[e-mail]>]

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"<[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"<[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"<[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"<[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]]
>>>> 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: [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]]
>>>> 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]]
>>>> 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: [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: [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/
>>>> b
>>>> l
>>>> ueroofmusic>
>>>> <http://sites.google.com/site/blueroofmusic>http://sites.google.com/site
>>>> /
>>>> h
>>>> ighnorthinc<http://sites.google.com/site/highnorthinc>
>>>> <http://sites.google.com/site/highnorthinc>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<[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: [e-mail] ⟐ m: 917-304-7190
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>               Redefining Storage Economics
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: Benoit Claise<[e-mail]>  <mailto:[e-mail]>
>>>> Date: Mon, 27 Feb 2012 05:17:24 -0600
>>>> To: eman mailing list<[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>   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
>>>>
>>>>
>>>>
>>>>
>>>>           _______________________________________________
>>>> eman mailing list
>>>> [e-mail]://www.ietf.org/mailman/listinfo/eman
>>>>
>>>>
>>>>         _______________________________________________
>>>> eman mailing list
>>>> [e-mail]://www.ietf.org/mailman/listinfo/eman
>>>>
>>>>
>>>>       _______________________________________________
>>>> eman mailing list
>>>> [e-mail]://www.ietf.org/mailman/listinfo/eman
>>>>
>>>>
>>>>
>>>>
>>>>
>
>