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

From: Benoit Claise <[email-masked]>
Date: Mon, 27 Feb 2012 12:17:24 +0100

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)

---

From: Ira McDonald <[email-masked]>
Date: Mon, 27 Feb 2012 08:29:20 -0500

Hi Benoit,

That quote equates "powered entity's role" with "importance".

This sounds largely useless and subjective.

There seems to be no interest in having standardized "role"
values in the EMAN community (and I'm not sure it's a
tractable problem, anyway).

How about dropping the "importance" terminology entirely
and sticking to "role as an energy consumer"?

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/highnorthinc
mailto:[email-masked]
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 6:17 AM, Benoit Claise <[email-masked]> wrote:

> 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
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>
>

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 27 Feb 2012 16:00:24 +0000

+1

Juergen

On 27.02.12 14:29, "Ira McDonald" <[email-masked]> wrote:

>    There is a discussion amongst the "EMAN requirements" authors right
>    now about the notion of importance.
>    The current
>      draft version
>    5.1.2.  Context information on powered entities   The energy
>management standard must provide means for retrieving and
>    - Is this importance specific to EMAN or is this generic also for
>    non Energy Objects?

---

From: Rolf Winter <[email-masked]>
Date: Mon, 27 Feb 2012 16:08:26 +0000

Hi,

I agree. I personally also think that importance can be removed. It is ill defined in the current document, if _really_ needed it seems like a more general concept and I wonder why it should be part of the MIB as opposed to something that is part of the management system. Regarding role, if it is to stay in the MIB (as opposed to the EnMS) then it also need a better definition and a good justification why it should be stored on the device itself.

Best,

Rolf

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ira McDonald
> Sent: Montag, 27. Februar 2012 14:29
> To: Benoit Claise; Ira McDonald
> Cc: eman mailing list
> Subject: Re: [eman] EMAN-REQ: the notion of importance
> 
> Hi Benoit,
> 
> values in the EMAN community (and I'm not sure it's a tractable problem,
> anyway).
> 
> How about dropping the "importance" terminology entirely and sticking
> to "role as an energy consumer"?
> 
> 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
> Winter  579 Park Place  Saline, MI  48176  734-944-0094 Summer  PO Box
> 221  Grand Marais, MI 49839  906-494-2434
> 
> 
> 
> 	There is a discussion amongst the "EMAN requirements" authors
> right now about the notion of importance.
> 	The current draft version <http://tools.ietf.org/html/draft-ietf-
> eman-requirements-05>  only mentions:
> 
> 
> 
>

---

From: "John Parello (jparello)" <[email-masked]>
Date: Mon, 27 Feb 2012 08:42:40 -0800

-1

If you remove context variables such as role: what a device is use for,
and a way to compare devices (importance) how will you determine which
ones you can shed power usage from in times of peak.

I agree this is something that should be in general network management.
Fault correlation and problem tracking would be easier. For power
management of a system the notion of context becomes more critical. For
example if during a peak demand time you want to shed power from you
lighting system and you have no notion of context how would you
determine which lights were decorative, emergency, task, or ambient
lights? 

The argument that this should be in the management system can be said
for any attribute, it becomes more useful if the devices have these
attributes in them. 

For example compare this to location attributes. You could argue that a
device need not have  a location attribute and this is part of the NMS -
but look at the usefulness of systems that have been developed when a
standardized location is put in the devices themselves versus a central
NMS.

If you remove context you remove any notion of being able to have
devices work on their own or in concert to control power. You relegate
it to a central system which will become proprietary an intractable with
the IoT.

So if you remove this you remove the core usefulness of the system.
Jp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rolf Winter
Sent: Monday, February 27, 2012 8:08 AM
To: Ira McDonald; Benoit Claise (bclaise)
Cc: eman mailing list
Subject: Re: [eman] EMAN-REQ: the notion of importance

Hi,

I agree. I personally also think that importance can be removed. It is
ill defined in the current document, if _really_ needed it seems like a
more general concept and I wonder why it should be part of the MIB as
opposed to something that is part of the management system. Regarding
role, if it is to stay in the MIB (as opposed to the EnMS) then it also
need a better definition and a good justification why it should be
stored on the device itself.

Best,

Rolf

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

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Ira McDonald
> values in the EMAN community (and I'm not sure it's a tractable 
> problem, anyway).
> 
> Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair 
> - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG 
> Chair
right 
> 	The current draft version
<http://tools.ietf.org/html/draft-ietf-
> 	   The energy management standard must provide means for
retrieving 
> and
> 	   reporting context information on powered entities, for
example, 
> tags

---

From: Brad Schoening <[email-masked]>
Date: Mon, 27 Feb 2012 11:10:00 -0600

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: [email-masked] ⟐ m: 917-304-7190

<http://www.coraid.com/> Redefining Storage Economics

From: Benoit Claise <[email-masked]<mailto:[email-masked]>>
Date: Mon, 27 Feb 2012 05:17:24 -0600
To: eman mailing list <[email-masked]<mailto:[email-masked]>>
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:

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

---

From: Ira McDonald <[email-masked]>
Date: Mon, 27 Feb 2012 12:44:42 -0500

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

On Mon, Feb 27, 2012 at 12:10 PM, Brad Schoening <[email-masked]> wrote:

>  <http://www.coraid.com/> Redefining
> Storage Economics****
>
> ** **
>
> From: Benoit Claise <[email-masked]>
> To: eman mailing list <[email-masked]>

---

From: "John Parello (jparello)" <[email-masked]>
Date: Mon, 27 Feb 2012 10:02:20 -0800

-1 on removing  Role

+1 on importance precedence

We haven’t had consensus yet on role in EMAN so you can’t say EMAN WG has backed away as yet. Considering it’s already in the drafts I think you’re speaking too soon. After a call sure.

Which WG groups have backed away for a role string? There are plenty of attributes defined in IETF RFC’s that hold a value where the value is not IANA registered. 

Look at location CAType 22 LOC  Additional Location information or CAtypre 21 LMK Vanity address. Very useful attributes without a registry for values defined as unstructured strings.

An unstructured vendor or site specific value for context is very useful and even without a registry having the attribute is extremely useful. I have vendors using such a field already for energy management. So whether or not this group makes a standard of the values the need for the attribute already exists and is deployed -  that seems useful to me.

Jp

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ira McDonald
Sent: Monday, February 27, 2012 9:45 AM
To: Brad Schoening; Ira McDonald
Cc: eman mailing list
Subject: Re: [eman] EMAN-REQ: the notion of importance

Hi,

Cheers,
- Ira

http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic> 
http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc> 

Benoit,

 

Brad Schoening

 

Dear all, 

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

Some extra questions:

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 27 Feb 2012 19:22:27 +0000

Hi Brad,

"Power priority" seems to be a much clearer concept than "importance".

Thanks,
    Juergen

On 27.02.12 18:10, "Brad Schoening" <[email-masked]> wrote:

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

---

From: "John Parello (jparello)" <[email-masked]>
Date: Mon, 27 Feb 2012 15:30:23 -0800

Let's be precise in our terms please. Priority describes precedence while importance describes significance.

Those are two different concepts. So a power priority is describing the power granting, while importance as defined in the framework describes the context of the device. So one is rating the powering order while the other the devices context or use.

For example I could order three devices based on how important they are to my organization as (A,B,C).  For providing power the priority could be (B,A,C) if B is required to be supplied power before A on say start up.

The order in which you are served does not equal the importance in a steady running state.

Importance as defined is for context not ordering.

Jp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Quittek
Sent: Monday, February 27, 2012 11:22 AM
To: Brad Schoening; Benoit Claise (bclaise); emanmailing list
Subject: Re: [eman] EMAN-REQ: the notion of importance

Hi Brad,

Thanks,
    Juergen

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Mon, 27 Feb 2012 23:57:21 -0600

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: [email-masked] [mailto:[email-masked]] 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,

Cheers,
- Ira

Benoit,

 

Brad Schoening

 

Dear all, 

Some extra questions:

---

From: Rolf Winter <[email-masked]>
Date: Tue, 28 Feb 2012 08:35:02 +0000

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

> Mouli Chandramouli (moulchan)
> Sent: Dienstag, 28. Februar 2012 06:57
> To: Ira McDonald; Brad Schoening
> Cc: eman mailing list
> 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
> 
> 
> 
> 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).
> 
> <http://sites.google.com/site/blueroofmusic>
> <http://sites.google.com/site/highnorthinc>
> Description: Coraid+Logo_reallysmall <http://www.coraid.com/>
> Redefining Storage Economics
> 
> 
> 
> 
>

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 28 Feb 2012 03:01:38 -0600

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:[email-masked]] 
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,

Best,

Rolf

---

From: Rolf Winter <[email-masked]>
Date: Tue, 28 Feb 2012 09:16:05 +0000

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

> From: Mouli Chandramouli (moulchan) [mailto:[email-masked]]
> Sent: Dienstag, 28. Februar 2012 10:02
> To: Rolf Winter; Ira McDonald; Brad Schoening
> Cc: eman mailing list
> 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
> 
> 
> 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
> 
> 
> > Of Mouli Chandramouli (moulchan)
> > Given the precedence of use of priority in other IETF MIBs, I think
> > the value of importance is clearly illustrated.
> >
> >
> >
> > concept is already used by deployments.  Should not be dismissed as
> > not useful.
> >
> >
> >

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 28 Feb 2012 09:34:22 +0000

Yes, I would also like to be precise.

For me, 'power priority' is a clear concept,
while 'importance' is a fuzzy concept.
Of course this implies that they are different concepts.

Thanks,
    Juergen

On 28.02.12 00:30, "John Parello (jparello)" <[email-masked]> wrote:

>Those are two different concepts. So a power priority is describing the
>power granting, while importance as defined in the framework describes
>the context of the device. So one is rating the powering order while the
>other the devices context or use.
>
>For example I could order three devices based on how important they are
>to my organization as (A,B,C).  For providing power the priority could be
>(B,A,C) if B is required to be supplied power before A on say start up.
>
>Juergen Quittek

---

From: "John Parello (jparello)" <[email-masked]>
Date: Tue, 28 Feb 2012 11:04:51 -0800

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: [email-masked] [mailto:[email-masked]] 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

Best,

Rolf

> 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
> 
> 
> > predictable), a text string of "role" is useless (except in a 
> > vendor- or site-specific manner - out-of-scope IMHO).
> >
> > Ira McDonald (Musician / Software Architect) Chair - Linux 
> > Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working 
> > Group Co-Chair

---

From: Rolf Winter <[email-masked]>
Date: Wed, 29 Feb 2012 09:02:55 +0000

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:

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

> From: John Parello (jparello) [mailto:[email-masked]]
> Sent: Dienstag, 28. Februar 2012 20:05
> To: Rolf Winter; Mouli Chandramouli (moulchan); Ira McDonald; Brad
> Schoening
> Cc: eman mailing list
> 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.
> 
> 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
> 
> 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.
> 
> 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
> 
> 
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Feb 2012 11:41:54 +0100

On Wed, Feb 29, 2012 at 09:02:55AM +0000, Rolf Winter wrote:
 
> 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:

[...]

I also understood priority to be different from "power up order" but
this might all be just different interpretations of words. 

That said, experience tells me that knowing the proper power up order
is practically extremely useful and I would not mind being able to
tell a power distribution unit in which sequence and in which timing
order to power things up. I am not sure whether this is in any
requirements or other documents so I thought I write this message with
a new subject line.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Rolf Winter <[email-masked]>
Date: Wed, 29 Feb 2012 12:30:56 +0000

... and power down priorities do make a lot of sense too. I personally think they make enough sense to have a separate requirement on it. But I would rather not have the respective object potentially overloaded with other uses. So why do we not add a requirement on a power down priority analogous to the PoE case and see what's potentially left in "importance" to judge whether it is worth another requirement? Does that make sense?

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Mittwoch, 29. Februar 2012 11:42
> To: Rolf Winter
> Cc: eman mailing list
> Subject: Re: [eman] EMAN-REQ: power up order
> 
> need
> > to be powered up. It certainly doesn’t mean that in the PoE
> > context:
> 
> [...]
> 
> is practically extremely useful and I would not mind being able to tell
> a power distribution unit in which sequence and in which timing order
> to power things up. I am not sure whether this is in any requirements
> or other documents so I thought I write this message with a new subject
> line.
> 
> /js
> 
> --

---

From: "John Parello (jparello)" <[email-masked]>
Date: Wed, 29 Feb 2012 10:26:24 -0800

Great we're making progress.

So you can understand that a bring up order and shut down order of devices is necessary. Now let's realize that an entire shut down or bring up of a site happens very infrequently.

What happens every day is that peak power demands cause sites to be billed 10-100 times their normal rate during very short periods mid day.

So what is a much more frequent case is a site will want to turn off things that are not importance. 

The bring up order and shut down order doesn't tell you that. So can we have a requirement  for a way to determine what this  since we have this already in dozens of systems and a use case that happens daily.

Jp

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Feb 2012 19:53:47 +0100

> The bring up order and shut down order doesn't tell you that. So can we have a requirement  for a way to determine what this  since we have this already in dozens of systems and a use case that hap…

So are you now talking about priority or importance or yet something
else? And are you in the right subject given the subject line? 

I think we are largely talking past each other here and we should
simply accept that words can often be understood in different ways and
hence it is important to be as clear as possible.

/js

---

From: Bruce Nordman <[email-masked]>
Date: Wed, 29 Feb 2012 11:06:58 -0800

This ordering of powering up and down seems more about functionality than
energy management
to me, but I'll put that aside for the following questions.

-Are we talking about components or only entire devices?  I would think
entire devices, but I
 have learned to not assume such things. :)
-Are we speaking to setting the power state of the device, or to cut off
power and re-initiate power   supply?
  -Some PCs and Servers can be turned on remotely with a WOL packet or by
communication
    with a service processor out-of-band from the main system.
  -For devices with internal batteries, removing external power does not
itself change power state,
   another reason why power supply and power state are different.
-Is power-up order necessarily the reverse of power-down order?  Also,
timing would seem to be different.

--Bruce (as contributor)

On Wed, Feb 29, 2012 at 10:53 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > So you can understand that a bring up order and shut down order of
> devices is necessary. Now let's realize that an entire shut down or bring
> up of a site happens very infrequently.
> >
> > What happens every day is that peak power demands cause sites to be
> billed 10-100 times their normal rate during very short periods mid day.
> >
> > The bring up order and shut down order doesn't tell you that. So can we
> have a requirement  for a way to determine what this  since we have this
> already in dozens of systems and a use case that happens daily.
> >
>

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Feb 2012 20:57:32 +0100

On Wed, Feb 29, 2012 at 11:06:58AM -0800, Bruce Nordman wrote:

> -Are we talking about components or only entire devices?  I would
> think entire devices, but I have learned to not assume such
> things. :)

Not sure what a component is either. ;-)

>    another reason why power supply and power state are different.

My use case is a "smart power box" (not sure how to properly call
this) with (I hope to get this right) multiple power outlets that are
controlled by the smart power box. Assume the outlets supply power to
several different servers. If this "smart power box" powers up, I like
to be able to tell the box in which order and timing the servers start
to receive power. The power down case is for me less important since I
can tell the servers to shutdown and then power down the outlets of
the "smart power box". For the power-up scenario, unless there is a
magic third communication channel, I can't really control in which
order the servers boot up.

Perhaps this is something EMAN does not want to provide. But since the
term power-up order was brought up, I thought I make this an explicit
design decision to make.

> -Is power-up order necessarily the reverse of power-down order?
> Also, timing would seem to be different.

As explained above, I do not care much about the power-down in _my_
use case since I assume I can talk to device before powering them off.
For powering them up, this requires extra investments and complexities
so it would just be nice if a "smart power box" could provide the
needed functionality for me (and that increases my incentive to buy
one).

/js