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

[Benoit Claise <[e-mail]>]

Hi Juergen,

Me not anglish talker also ;-)

In light of the latest new emails on the topic,
I would still prefer "importance". However, if a compromise is required, 
what about "energy object ranking"?

Regards, Benoit.
> 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"<[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"<[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"<[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"<[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]]
>>>>>> 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]>  [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]>  [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]>  [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]>>
>>>>>> <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]  <mailto:[e-mail]>  ⟐ m: 917-304-7190
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>               Redefining Storage Economics
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Benoit Claise<[e-mail]  <mailto:[e-mail]>>  <mailto:[e-mail]>
>>>>>> Date: Mon, 27 Feb 2012 05:17:24 -0600
>>>>>> To: eman mailing list<[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>   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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>