Subject: [eman] MIB-friendly proposal for flexible power states

From: Juergen Quittek <[email-masked]>
Date: Wed, 16 Mar 2011 00:56:55 +0100

Dear all,

here is a proposal for our power state discussion.
It is not new and has been discussed in different flavors already.
I just try to promote it by showing that it is flexible and 
at the same time simple concerning its definition in a MIB module.

It looks like people on this list want to be able to use different 
sets of power states in order to support different energy management
interfaces. An example for a set would be the set of DMTF power states.

A way to support this and still allowing very simple implementations
would be the following:

We can be open to any set of power states by having them registered 
at IANA. For each set we would register
  - an ID (number) for identifying the set
  - a number for each power state in this set

For example:
EMAN:
set ID: 0
states IDs: off(0). sleep(1). on(2)

DMTF: 
set ID: 1
states:  powerOn(2), sleepLight(3), sleepDeep(4), etc.

ACPI:
setID: 2
states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc.

Then we can define power state tables such that they have two indices:
First the setID and then the stateID. 

In such a table you could implement several sets (interfaces) at the same time.
a device can support three basic power states with setID 0 as first index,
but as well show all DMTF power states with setID 1 as first index. And another
index could be used for ACPI and other power state sets. Simple implementations
would just implement a single (simple) set, but device makers would have the 
chance to provide support for multiple interfaces (sets).

A small disadvantage is that for identifying a power state we need two numbers.
We can solve this at MIB level by a textual convention for power state index objects
that defines the index as a string consisting of two numbers separated by a dot,
for example, "0.2" or "4.12". The first number would identify the set and the second
one the state within the set.

Any organization that specifies or builds devices can then define sets of power 
states, for example, for light bulbs or for UPS systems, and register them at IANA.
This mechanism is still simple but provides openness to future developments
without need to modify or extend the MIB module.

    Juergen

---

From: "John Parello (jparello)" <[email-masked]>
Date: Tue, 15 Mar 2011 17:07:18 -0700

+1 on this! 

-----Original Message-----
From: [email-masked] on behalf of Juergen Quittek
Sent: Tue 3/15/2011 4:56 PM
To: eman mailing list
Subject: [eman] MIB-friendly proposal for flexible power states
 
Dear all,

For example:
EMAN:
set ID: 0

DMTF: 
set ID: 1

ACPI:
setID: 2

    Juergen

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

---

From: Ted Ghose <[email-masked]>
Date: Tue, 15 Mar 2011 20:22:36 -0700

Hi Juergen

This is a great start, why can't we take all and have one unified standard

this is the standard body, isn't it?

If you lead to one unified standard, like SI and we publish a
conversation, everyone across the world will have one thing to refer to.

thanks

-tg-

*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,.
                     Save time... see it my way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,.

On Tue, Mar 15, 2011 at 5:07 PM, John Parello (jparello) <[email-masked]
> wrote:

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Mar 2011 06:28:54 +0100

> without need to modify or extend the MIB module.

I am likely confused what the goal is. If every power state set needs
to be registered with IANA, then why not simply use an enumeration?

simple-off(0), simple-sleep(1), simple-on(2),
dmtf-powerOn(100), dmtf-sleepLight(101), dmtf-sleepDeep(102), ...
acpi-offHard(200), acpi-offSoft(201), hibernate(202), sleepDeep(203), ...

You can add whatever text is needed to tell implementors they should
just use the values of one set only. If you want to support non-IANA
registered power states, the normal thing to do in MIB land is to use
OBJECT-IDENTITIES, that is defined object identifier constants. This
is how we identify say crypto-algorithms. We also have numeric TCs
that define a set of well known values and that partition some of the
integer number space for private use, in case a small number of well
known power states with vendor extensibility is the way to go.

I think it is crucial to figure out how much flexibility is needed and
desirable and once that question has been answered, I think we should
talk about the encoding (and I prefer encodings that are already known
in MIB land over new creations).

/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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 16 Mar 2011 11:22:37 +0100

Hi, 

+1 to what JuergenS said. 

Thanks and Regards,

Dan 
(speaking as contributor) 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Wednesday, March 16, 2011 7:29 AM
> To: Juergen Quittek
> Cc: eman mailing list
> Subject: Re: [eman] MIB-friendly proposal for flexible power states
> 
> > I just try to promote it by showing that it is flexible and at the 
> > same time simple concerning its definition in a MIB module.
> > 
> > We can be open to any set of power states by having them 
> registered at 
> > IANA. For each set we would register
> > a device can support three basic power states with setID 0 as first 
> > index, but as well show all DMTF power states with setID 1 as first 
> > index. And another index could be used for ACPI and other 
> power state 
> > sets. Simple implementations would just implement a single (simple) 
> > set, but device makers would have the chance to provide 
> support for multiple interfaces (sets).
> > 
> > We can solve this at MIB level by a textual convention for 
> power state 
> > index objects that defines the index as a string consisting of two 
> > numbers separated by a dot, for example, "0.2" or "4.12". The first 
> > number would identify the set and the second one the state 
> within the set.
> > 
> > Any organization that specifies or builds devices can then 
> define sets 
> > of power states, for example, for light bulbs or for UPS 
> systems, and register them at IANA.
> > This mechanism is still simple but provides openness to future 
> > developments without need to modify or extend the MIB module.
> 
> I am likely confused what the goal is. If every power state 
> set needs to be registered with IANA, then why not simply use 
> an enumeration?
> 
> You can add whatever text is needed to tell implementors they 
> should just use the values of one set only. If you want to 
> support non-IANA registered power states, the normal thing to 
> do in MIB land is to use OBJECT-IDENTITIES, that is defined 
> object identifier constants. This is how we identify say 
> crypto-algorithms. We also have numeric TCs that define a set 
> of well known values and that partition some of the integer 
> number space for private use, in case a small number of well 
> I think it is crucial to figure out how much flexibility is 
> needed and desirable and once that question has been 
> answered, I think we should talk about the encoding (and I 
> prefer encodings that are already known in MIB land over new 
> creations).
> 
> /js
> 
> --

---

From: Rolf Winter <[email-masked]>
Date: Wed, 16 Mar 2011 10:34:00 +0000

This looks very good to me. +1

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
> Juergen Quittek
> Sent: Mittwoch, 16. März 2011 00:57
> To: eman mailing list
> index,
> developments

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 16 Mar 2011 08:25:44 -0500

Juergen S,

Would it be useful to know the capability of the device on which power
state model is supported by the device - ENTITY-STATE, DMTF, ACPI or
...? 
A device can also support multiple power state models. 

In that sense, the model Juergen Q proposed - the vector model (x1, x2)
- where x1 - is the power state type and x2 is the power state seems
more natural ?

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Schoenwaelder
Sent: Wednesday, March 16, 2011 10:59 AM
To: Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] MIB-friendly proposal for flexible power states

index,
developments

simple-off(0), simple-sleep(1), simple-on(2),
dmtf-powerOn(100), dmtf-sleepLight(101), dmtf-sleepDeep(102), ...
acpi-offHard(200), acpi-offSoft(201), hibernate(202), sleepDeep(203),
...

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Mar 2011 14:54:00 +0100

> - where x1 - is the power state type and x2 is the power state seems

I do not think Juergen Q proposed a vector. Juergen, correct me if I
am wrong. This is actually different design issue, independent of the
encoding. I was commenting on the encoding only.

/js

---

From: Russ White <[email-masked]>
Date: Wed, 16 Mar 2011 12:53:59 -0400

>   - a number for each power state in this set

I really like this idea... The only thing I would do is have it split
into two "spaces," perhaps. All devices should support "on" and "off,"
so those should be in the "primary space." Then you could have an
"extended state" that is defined as below. You could also actually
support multiple "extended spaces." For instance, you could have one
space for batteries, and another for various ranges of device states.

I would support this idea.

:-)

Russ

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Mar 2011 18:42:46 +0100

> space for batteries, and another for various ranges of device states.

What is a management application going to do with "multiple extended
spaces"? What is going to happen if the "multiple extended spaces"
turn out to be inconsistent? The more bloat people want to add, the
more I start liking a minimal three state model. ;-)

/js

---

From: Russ White <[email-masked]>
Date: Wed, 16 Mar 2011 13:48:02 -0400

> more I start liking a minimal three state model. ;-)

Don't most management applications already support a "plug in"
architecture for various devices? IE, if I buy a switch from some
vendor, don't I have the option of downloading the MIB for the switch
and putting it into the management application so I get finer grained
control/understanding of what the switch supports?

In this case, you'd have one space for the power state, depending on the
sort of power state the device supports, like DMTP, an EMAN standard, or
something else.

And if the device has a battery, you could pull in the battery state as
well.

This makes more sense than having power states tied to battery states.
You could have a laptop that provides some set of standard PC power
states, and then some set of standard battery power states. A desktop
would provide the PC levels, while not the battery ones. A wired video
camera might provide the right power states for that sort of device, and
add on some standard set of states for batteries if it happens to be
battery powered.

This allows the flexibility of different sets of states for devices that
would fall under different standards, and additional power states where
that information might be useful.

Flexibility seems like it would be a good thing, given the past
conversations on what to support and how to support it.

:-)

Russ

---

From: "John Parello (jparello)" <[email-masked]>
Date: Wed, 16 Mar 2011 11:23:13 -0700

Hi Juergen,

You could have one long list as you suggest but then if someone added a
state they are not grouped. So in your example if the dmtf adds a state
foo you would have to add dmtf-foo to the end?

It seems clearer to have these groups in sets and those sets are
interfaces.

Also there will be a question of parity on states. If I set to EMAN-OFF
does that imply I am in DMTF-OFF and HAL-HARD-OFF as well?

>From a strict interface implementation split such a distinction would
make sense.

Jp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Schoenwaelder
Sent: Tuesday, March 15, 2011 10:29 PM
To: Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] MIB-friendly proposal for flexible power states

index,
developments

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Mar 2011 08:18:28 +0100

> conversations on what to support and how to support it.

Reporting different states for different components of the system
makes sense to me. Reporting a vector of states for a single component
does not make much sense to me.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Mar 2011 08:22:47 +0100

> foo you would have to add dmtf-foo to the end?

I tried to group the numbers but screwd up at the end. But at the end,
it does not matter. A management system either understands what a
particular number _means_ so that it can do something meaningful with
the information or all it can do is just displaying the label. In both
cases, what the number is is not really of importance.
 
> It seems clearer to have these groups in sets and those sets are

Explain "interfaces".

> does that imply I am in DMTF-OFF and HAL-HARD-OFF as well?

This is what I was pointing to. I heard some people arguing for a
small and simple set of states. Others were arguing for exporting the
component's native state. I can see value in both and have no clear
opinion. However, the direction of reporting a vector of states for a
component seems to be wrong and not at all helpful to me.

> From a strict interface implementation split such a distinction would

Please explain "interface".

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 17 Mar 2011 11:45:48 +0100

Hi John, 

This grouping that you are talking about seems to me to be a matter of
document readability by humans. It does not have any application
significance, as the management application just gets an integer value.
Am I wrong? 

We can do a few things to improve human readability - for example
similar prefixing of enumerated value names that belong to the same
group, or sparse grouping that leaves room for definition of new
enumerated values in the same group for the foreseeing future. 

Regards,

Dan 

> Behalf Of John Parello (jparello)
> Sent: Wednesday, March 16, 2011 8:23 PM
> To: Juergen Schoenwaelder; Juergen Quittek
> Cc: eman mailing list
> You could have one long list as you suggest but then if 
> someone added a state they are not grouped. So in your 
> example if the dmtf adds a state foo you would have to add 
> dmtf-foo to the end?
> 
> It seems clearer to have these groups in sets and those sets 
> are interfaces.
> 
> Also there will be a question of parity on states. If I set 
> to EMAN-OFF does that imply I am in DMTF-OFF and HAL-HARD-OFF as well?
> 
> From a strict interface implementation split such a 
> distinction would make sense.
> 
> Jp
> 
> > A small disadvantage is that for identifying a power state 
> we need two
> numbers.
> index objects
> > that defines the index as a string consisting of two 
> numbers separated
> by a dot,
> > for example, "0.2" or "4.12". The first number would 
> identify the set
> and the second
> of power 
> > states, for example, for light bulbs or for UPS systems, 
> and register
> them at IANA.

---

From: Russ White <[email-masked]>
Date: Thu, 17 Mar 2011 07:57:20 -0400

> does not make much sense to me.

Agreed --what I think would make sense is something like this:

energy
    +--common states
    |     +--on
    |     +--off
    |     +--low power mode
    |
    +--standard low power states
    |     +--whatever makes sense here (DMTF/etc)
    |
    +--standard battery states
          +--whatever makes sense here

In other words, restricted to three branches, a set of common states, a
set of standard states, and a set of battery states. The device should
be required to implement at least the common states, and always set
them. If the device contains a battery, then it would implement some
form of battery state (maybe there should only be one battery state,
time remaining on charge, or something). And then based on the class of
device, it may implement one of the other standard states.

A system that knows how to read various more detailed information would
know to look for those, and make use of them. Otherwise, ignore and use
the common states.

Anyway, just an idea for discussion on how to structure this.

:-)

Russ

---

From: "John Parello (jparello)" <[email-masked]>
Date: Thu, 17 Mar 2011 08:58:54 -0700

Hi Dan,

True a registry with long list with a name space is equivalent. So how
about giving a dns like name to the state. It would also clear up the
ownership and the registry would be human readable.

Thinking out loud here how about....

org.dmtf.off  17
org.dmtf.sleep 42
:
.
org.ietf.eman.off  93
:
.
com.hal.off 102
com.hal.drowsey 117
etc...

would allow for sorting and then perhaps a set by name without a cryptic
indexing 

setStatebyName('com.hal.off')
setState(102)

That may also handle the issue of subcomponents? Although I'm not sure
of the implications of this as yet...

com.hal.battery.off  73

One different issue I'd like to see addressed is whether or not setting
a state in one name space implies a setting to an equivalent state in
another name space. 

Jp

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Thursday, March 17, 2011 3:46 AM
To: John Parello (jparello); Juergen Schoenwaelder; Juergen Quittek
Cc: eman mailing list
Subject: RE: [eman] MIB-friendly proposal for flexible power states

Hi John, 

Regards,

Dan

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Thu, 17 Mar 2011 11:24:09 -0500

> Juergen Quittek wrote:

I have been tied up with non-IETF duties of late so have not been able to respond before now.  I see that this thread is gaining some momentum which is good because I (personally) favor either (a) a minimalist set of states as Bruce has been arguing, or (b) a more flexible approach which can be extened over time as things evolve without requiring changes to the core EMAN approach to power states.

While I favor incorporating more flexibility I am not tied to any particular approach to achieving that flexibility.  This approach seems to be a nice middle ground approach but allow me to play devil's advocate and ask a few questions to explore what we achieve with this approach.  I ask only to increase my understanding of the proposal not because I have any opinion pro or con.

This approach appears to give us the ability to have multiple sets of power states where each set is effectively an enumerated type.  I see this as a good thing, in general, because I argue that having a meaningful set of states will have some element of a technology specific dependency.  We are seeing that in some of the later replies in this thread where the subject of battery states comes up vs. PC states vs. perahps camera states, etc.

Now one element of your proposal is to have these sets of power states (each effectively an enumerated type) be "standardized" by having them registered at IANA.  One advantage of requiring IANA registration is that the resulting states would at least be well defined and relatively stable while allowing for evolution in the face of changing technologies and vendor implementation choices.

Now let me ask you a more fundamental question.  Once we open the door to having an extensible set of enumerated types as your proposal does, from the perspective of "enabling more effect management" of a given device does registering those enumerated types with IANA actually add anything over the alternative of having those enumerated types being dynamically discoverable through the MIB?  I am not arguing this point one way or the other, but I would be interested in hearing your thoughts on the topic.

The main difference that I can see from an implementation perspective is that with your proposal the vendors of management applications could then write code which is "hard coded" to one or more specific sets of states and possibly have logic which is "hard bound" to the semantics associated with the states being registered with IANA.

This then raises a follow-up question.  When these sets of states are registered with IANA are there also specific definitions of the semantics that are tied to the states being so registered, or is IANA only managing the set of integer values that are associated each of the enumerated power states?  In other words, is the interpretation of what those states actually mean in practice still an implementation specific detail decide at the whim of each vendor?

One final question, given that you envision different sets of power states what are the core variabilities at play that you believe would drive the definition of a new power state set?  Over time would these sets be driven by technology specific differences, vender specific differences, both, or something entirely different?  I think gaining more clarity on why we would even want a new set of states may shed light on how best to organize things to support that type of evolution over time.

Some food for thought.

Thanks,

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [email-masked]
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Thu, 17 Mar 2011 11:48:20 -0500

> Juergen Schoenwaelder wrote:
> 

+1 on the observation that power states are actually tied to the components of a system and not the system as a whole (although that too may have a power state).

+1 on the observation that different components will need to have different states to make those states "meaningful" depending on the type of the component.

Regading your vector comment I think that you have misinterpreted Mouli's comment.  When he said "vector" another way of saying what he meant would be "tuple", because he was talking about the fundamental idea in JourgenQ's proposal where the "state" of a component is actually a tuple (i.e. a vector) which is composed of "(x1,y1)" where x1 actually specifies the state type (i.e. which set or enumeration applies) and y1 specifies the actual state (i.e. which value within the corresponding set or enumeration has been selected).  Please correct me, Mouli, if this was not your meaning.

In this context you seem to be using the term "vector" to mean "a list of such states" for each component which I don't think anyone has proposed.  I think that there is a simply a miscommunication here based on the use of the term "vector".

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Thu, 17 Mar 2011 12:37:18 -0500

> Russ White wrote:
> time remaining on charge, or something). And then based on 
> the class of device, it may implement one of the other standard states.

I am curious as to why you believe that batteries are important enough to be called out explicitly within your hierarchy?  What is special about batteries that makes them not suitable to simply use the common or standard power states?

If we generalize from where this is heading, might there not be other equally important types of components which need to have similarly specialized states?

I generally like your idea of a hierarchy of states as long as we could apply a meaningful structure to it.  I would actually take this idea and morph it into a 2 level hierachy as follows:

energy
    +--common power state
    |     +--on
    |     +--off
    |     +--low power mode -> See domain specific states for more details.
    |
    +--domain specific power states
          +--whatever makes sense here.  --> Details specified per JuergenQ's 
                                             IANA proposal or similar.

At the top is the most abstract view possible: on, off, or low power mode.  That makes for a nice high level, reasonably universal set of states that gives the management application a general sense of the state of the entity.

I would then merge your last two levels into one with the concept being that these are "domain specific" power states.  I have thus far argued that these domains are likely to be aligned with the underlying technology involved but they need not be restricted to that dimension.  They could be literally anything.

Within this "domain specific level" of the hierarchy the concept of the states being tuples, as proposed by JuergenQ, can come into play.  What I am calling "domain specific power states" maps cleanly one-to-one with the power sets or enumerated types JuergenQ proposes to have registered at IANA.  Each such set forms the set of states which are meaningful to a particular "domain".  Thus things like ACPI and DMTF are simply specialized domains.  For components where those states make sense, by all means utilize them.  For components where they don't, use a different set.  If there are no existing sets of states already registered at IANA which are meaningful for a given component then propose and register a meaningful set unique to that component's domain.

Operationally the management applications would start by simply reporting the common state for each component.  In the case where that state is "low power mode" the software could then use the "set type identifier" from JuergenQ's proposal to then lookup and and invoke the proper "domain specific plugin" that you alluded to earlier.  This would then be able to report and manage things based on the domain specific states actually defined for that specific grouping.

I think an implication of this approach is that each component/entity would actually have two power states associated with it in the MIB.  The first is universal and defined as part of the eman standard and corresponds to your "common power states".  The second is actually tied to domain specific power states which are registered and maintained within IANA and could be implemented as suggested by JuergenQ's proposal or somthing similar.

Thoughts from others?

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

---

From: "John Parello (jparello)" <[email-masked]>
Date: Thu, 17 Mar 2011 10:44:12 -0700

Hi William,

I'm curious on one point you called out as well regarding battery. At
some management level does the administrator care about whether the
battery is charging or if the devices is charging.

Think from a use point of view. I charge my phone, my ipod, my car. Do I
charge the battery?

So from a device object point of view no - you probably charge the
device. Is the device sleeping and the battery charging or is the device
simply charging.

It's a tricky relationship that needs to be modeled.

Jp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mielke, William F (Bill)
Sent: Thursday, March 17, 2011 10:37 AM
To: russ (mailer list); Juergen Quittek; emanmailing list
Subject: Re: [eman] MIB-friendly proposal for flexible power states

> Agreed --what I 
> the class of device, it may implement one of the other standard
states.

I am curious as to why you believe that batteries are important enough
to be called out explicitly within your hierarchy?  What is special
about batteries that makes them not suitable to simply use the common or
standard power states?

If we generalize from where this is heading, might there not be other
equally important types of components which need to have similarly
specialized states?

I generally like your idea of a hierarchy of states as long as we could
apply a meaningful structure to it.  I would actually take this idea and
morph it into a 2 level hierachy as follows:

energy
    +--common power state
    |     +--on
    |     +--off
    |     +--low power mode -> See domain specific states for more
details.
    |
    +--domain specific power states
          +--whatever makes sense here.  --> Details specified per
JuergenQ's 
                                             IANA proposal or similar.

At the top is the most abstract view possible: on, off, or low power
mode.  That makes for a nice high level, reasonably universal set of
states that gives the management application a general sense of the
state of the entity.

I would then merge your last two levels into one with the concept being
that these are "domain specific" power states.  I have thus far argued
that these domains are likely to be aligned with the underlying
technology involved but they need not be restricted to that dimension.
They could be literally anything.

Within this "domain specific level" of the hierarchy the concept of the
states being tuples, as proposed by JuergenQ, can come into play.  What
I am calling "domain specific power states" maps cleanly one-to-one with
the power sets or enumerated types JuergenQ proposes to have registered
at IANA.  Each such set forms the set of states which are meaningful to
a particular "domain".  Thus things like ACPI and DMTF are simply
specialized domains.  For components where those states make sense, by
all means utilize them.  For components where they don't, use a
different set.  If there are no existing sets of states already
registered at IANA which are meaningful for a given component then
propose and register a meaningful set unique to that component's domain.

Operationally the management applications would start by simply
reporting the common state for each component.  In the case where that
state is "low power mode" the software could then use the "set type
identifier" from JuergenQ's proposal to then lookup and and invoke the
proper "domain specific plugin" that you alluded to earlier.  This would
then be able to report and manage things based on the domain specific
states actually defined for that specific grouping.

I think an implication of this approach is that each component/entity
would actually have two power states associated with it in the MIB.  The
first is universal and defined as part of the eman standard and
corresponds to your "common power states".  The second is actually tied
to domain specific power states which are registered and maintained
within IANA and could be implemented as suggested by JuergenQ's proposal
or somthing similar.

Thoughts from others?

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

---

From: Russ White <[email-masked]>
Date: Thu, 17 Mar 2011 13:57:30 -0400

> device. Is the device sleeping and the battery charging or is the device

Well, there was a discussion a while back on the list about including
battery state for various reasons... I was just thinking that batteries
exist on some devices and not on others that are otherwise identical.

So, if we _wanted_ to include battery, this seems like a good way to do
it. If we don't, then... I'm fine with dropping it, and going to two
sections. I know that in the MANET world battery power is really
important --you actually base routing on battery power remaining, for
instance. But I wouldn't want to have one model for a wireless AP
without a battery, and another with a battery...

:-)

Russ

-- 
[email-masked] :: CCIE :: CCDE :: <>< Grace Alone

If the whole universe has no meaning, we should never have found out
that it has no meaning: just as, if there were no light in the universe
and therefore no creatures with eyes, we should never know it was dark.
Dark would be without meaning. -C. S. Lewis

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Thu, 17 Mar 2011 13:25:03 -0500

> John Parello wrote:

I agree that it is tricky.

I think that the answer is tied to how the device is modeled.  If we present the device as an entity in its own right, as I think most people would argue we should, then at that level your point makes sense to me.  If we also model not only the device but also it's contained hierachy of components wherein the battery becomes a unique entity then at that level I would argue that the domain specific set of "battery states" applies only at the battery level.

Given this your question starts to lead me down the path of thinking about parent/child relationships and containment hierachies.  Along with that discussion will also come the inevitable question of whether and how things like power states "aggregate" up the containment hierachy.  I can imagine coming up with rules for how things like the common states (on, off, low power mode) might aggregate up the hierachy in a meaningful sense, but the device specific states not as much.

At the abstract level of an "iPhone" I would argue that a state like "charging" doesn't make sense even though you point out that in common language usage it would.  Literally speaking, to say that your iPhone is charging means that it contains a battery that is charging.  The term "charging" only applies to the specific domain of the battery and to the specific contained entity that is the battery.

In my view of things, and I am open to other perspectives, the way that a human operator would identify that the iPhone is "charging" is that they would have to specifically drill down into the iPhone entity, discover that it contained a battery, and observe that the battery is in the charging state.  It is less clear to me how one takes what I just described and codifies it into an application, but obviously it can be done so long as the code in question knows to explicitly look for this relationship.

Now, one possible approach if we actually feel that aggegrating device specific component states up the containment hierarchy is important is to introduce the concept of a power state vector similar to what JuergenS was talking about (but in a separate context).  Abstract entities which are themselves composites of simple entities could report a vector of all the contained domain specific states of all of it's simple "leaf components".  In practice I would expect this to become quite large and unwieldly and so I would argue against such an approach, but it is certainly possible.  Thus the domain specific state of a composite entity is actually the union of the domain specific state of the composite entity itself along with the domain specific states of all of its constituent components.

Does that make sense?

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 17 Mar 2011 13:26:50 -0500

Hi William,

Exactly, this is what I had intended. (x1, y1), where x1 is the power
state type and y1 is the specific power state within that model. 

I thought there is value when an NMS queries an end-device, it would be
useful to know what is the power state model implemented in the device.

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mielke, William F (Bill)
Sent: Thursday, March 17, 2011 10:18 PM
To: Juergen Schoenwaelder; russ (mailer list)
Cc: eman mailing list
Subject: Re: [eman] MIB-friendly proposal for flexible power states

> does not make much sense to me.

+1 on the observation that power states are actually tied to the
components of a system and not the system as a whole (although that too
may have a power state).

+1 on the observation that different components will need to have
different states to make those states "meaningful" depending on the type
of the component.

Regading your vector comment I think that you have misinterpreted
Mouli's comment.  When he said "vector" another way of saying what he
meant would be "tuple", because he was talking about the fundamental
idea in JourgenQ's proposal where the "state" of a component is actually
a tuple (i.e. a vector) which is composed of "(x1,y1)" where x1 actually
specifies the state type (i.e. which set or enumeration applies) and y1
specifies the actual state (i.e. which value within the corresponding
set or enumeration has been selected).  Please correct me, Mouli, if
this was not your meaning.

In this context you seem to be using the term "vector" to mean "a list
of such states" for each component which I don't think anyone has
proposed.  I think that there is a simply a miscommunication here based
on the use of the term "vector".

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

---

From: Ted Ghose <[email-masked]>
Date: Thu, 17 Mar 2011 11:29:19 -0700

Hi Juergen

If the proposal here to display any collection of any states that people
will go and register in IANA, are we not loosing the main focus of
standardizing, and what that means.

You were arguing else where "what's the state of the 'device off battery
charging' be", and I agree with you.

But without standardizing some basic EMAN states, but
displaying wide varieties of state of overlapping and even conflicting
meaning registered in IANA, what will be a real value add.

Different devices some how or other does shows different states they
have implemented, anyway.

I'd urge the WG to bring some standard and avoid the explosion of power
states in IANA.

thanks

-tg-

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 17 Mar 2011 23:21:18 +0100

Am 16.03.2011 um 06:28 schrieb Juergen Schoenwaelder:
> acpi-offHard(200), acpi-offSoft(201), hibernate(202), sleepDeep(203), ..

Yes, this is a good alternative.
It is cleaner in the MIB because it uses just one index level.
The other alternative was cleaner because it separates the set index from the state index.

Thanks,

  Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 17 Mar 2011 23:21:25 +0100

Dear John, Bill, and all,

I agree, that it does not make sense to combine states of a battery with state of a PC. Imaging you would also consider a fan. The fan may be still running while the PC is already off or sleeping until the temperature is low enough.

If we combined states, we would end up with something like
 - off
 - off-charging
 - off-fan-on
 - off-charging-fan-on
 - sleep
 - sleep-charging
 - sleep-charging-fan-on
etc.

And there may be more then just fan and battery to be considered.

Thus, we should be able to report on components of a device separately,
 - PC
 - fan
 - battery
 - etc.

The ENTITY MIB gives us means for indicating that all in contained in the same physical device. It also gives us the list of contained entities. And reporting of power states should be independent for each entity.

Thanks,

   Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 17 Mar 2011 23:21:27 +0100

Hi Russ,

I think there is more devices than just batteries which need different power states.
For example fans, lamps, air conditionings, etc.

So, I would like to not have the number of sets of power states be limited.

Thanks,

   Juergen

---

From: [email-masked]
Date: Thu, 17 Mar 2011 16:35:39 -0700

> The other alternative was cleaner because it separates the set index

RFC 2578, Section 7.1.1.  Integer32 and INTEGER

   Finally, a label for a named-number enumeration must consist of one
   or more letters or digits, up to a maximum of 64 characters, and the
   initial character must be a lower-case letter.  (However, labels
   longer than 32 characters are not recommended.)  Note that hyphens
   are not allowed by this specification (except for use by information
   modules converted from SMIv1 which did allow hyphens).

Just hoping you're not relying on the "-" character to help with this.

I'm still not quite following how this is supposed to work.  Is the plan
to have a single object that can take in all of these enumerated values?

If so, how would an entity report its state using multiple
representations (simple-off, dmtf-powerOff, and acpi-offHard all being
equivalent) from the same OID interface?  It seems like you still need
multiple interfaces, one for each representation, otherwise the various
representations start clobbering each other.

Chris

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Mar 2011 10:08:48 +0100

> In this context you seem to be using the term "vector" to mean "a list of such states" for each component which I don't think anyone has proposed.  I think that there is a simply a miscommunication…

If I misunderstood something, I apologize. However, as mentioned
before, I think (x1,y1) can simply be z = (x1*100+y1) or something
like that, making MIB design, IANA allocations, and SNMP on the wire
more efficient. That is what I meant with "encoding".

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Mar 2011 10:14:39 +0100

> of the implications of this as yet...

A state is per component. If a component has subcomponents, they can
report their own state.

> One different issue I'd like to see addressed is whether or not
> setting a state in one name space implies a setting to an equivalent
> state in another name space.

The idea is that a component supports a set of states. If you set a
state it does not support, you will get an inconsistentValue error
or something close to that.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Mar 2011 10:15:52 +0100

>    I'd urge the WG to bring some standard and avoid the explosion of power

Every IANA registry has defined rules how something can be added. The
WG would have to define the rules and they can be restrictive. IANA
control does not imply explosion of power states.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Mar 2011 10:17:38 +0100

> The other alternative was cleaner because it separates the set index

But this separation does not add any real value since a state value is
only meaningful together with the set index. Hence, by making them one
thing, you make a number of errors simply impossible and you gain
efficiency.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Mar 2011 10:19:51 +0100

> representations start clobbering each other.

A component of a device reports one possible value, the value that is
in the set of states it supports natively.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Mar 2011 10:31:55 +0100

> Now let me ask you a more fundamental question.  Once we open the door to having an extensible set of enumerated types as your proposal does, from the perspective of "enabling more effect managemen…

The registration procedure needs to be spelled out and this will
regulate how easy or painful it is to register new states. If we allow
arbitrary registrations, then all we have is a central registry to
lookup what the value 42 means (which is still better than having
nothing). I personally would argue for more restrictive IANA rules.
 
> This then raises a follow-up question.  When these sets of states are registered with IANA are there also specific definitions of the semantics that are tied to the states being so registered, or i…

It all depends on the rules given to IANA. I would expect some
controlled procedure for new registrations and I would assume that the
procedure requires to document what a new state means. The WG can even
create templates for this purpose, a common way to deal with such IANA
things.

> One final question, given that you envision different sets of power states what are the core variabilities at play that you believe would drive the definition of a new power state set?  Over time w…

As far as I understand things, we do have defined power states coming
from other organizations/consortiums, e.g. ACPI. It might well be that
in 5 or 10 years ACPI is replaced by something else that is gaining
widespread support. In that case, one might extend the IANA registry
to cover these new states.  We also have power states that are
specific to component types, the common case today are batteries. I do
not know what types of components we will have in 5 or 10 years, but I
would not be surprised if at some point new power states might be
needed for specific new component types, e.g. components that generate
energy. A controlled IANA registry allows to deal with all this in a
sensible way.

/js

---

From: Russ White <[email-masked]>
Date: Wed, 16 Mar 2011 12:51:09 -0400

:-)

Russ

---

From: [email-masked]
Date: Fri, 18 Mar 2011 08:05:58 -0700

> in the set of states it supports natively.

But an entity (i.e. "a component of a device") cannot support more than
one set of states natively?  It must choose only one paradigm?

Chris

---

From: Benoit Claise <[email-masked]>
Date: Fri, 18 Mar 2011 16:34:28 +0100

Hi John,

We can go with a single series like this.
However, I have some concerns because there is actually a data modelling 
behind this IANA registry.
What if I decide to request "org.dmtf.ietf.com.sleep"? What are the 
consequences?
I mean, we would need a really good IANA section to:
     1. explain the data modelling behind the naming conventions
     2. block the proliferation of power states
... to effectively try to model power state _series_.

Regards, Benoit.
>> Fax:   +49 421 200 3103<http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Mar 2011 16:41:08 +0100

> one set of states natively?  It must choose only one paradigm?

Such an assumption likely makes things tremendously simpler. Why
does a component of a device have to be in several states at the
same time? What is the set of meaningful combinations and how is
a management system going to do anything useful with N concurrent
power states of a component?

/js

---

From: Benoit Claise <[email-masked]>
Date: Fri, 18 Mar 2011 16:27:44 +0100

Hi Juergen,

I like this proposal, because only the time will tell us which power 
states will be accepted by the industry. Trying to impose a single one 
might not work. It might happen that different industry segments will 
have different series.
Let me answer to some possible optimization later in the email thread.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 18 Mar 2011 16:40:24 +0100

Dear all,
> thing, you make a number of errors simply impossible and you gain
I agree with your argument on reducing the error by combining two 
indexes into one.
However, isn't it interesting to discover which power state series 
(EMAN, ACPI, manufacturer, etc...) a device support? And then within 
that series, which states are supported?

Regards, Benoit.

---

From: [email-masked]
Date: Fri, 18 Mar 2011 09:04:17 -0700

On Fri, Mar 18, 2011 at 04:41:08PM +0100, Juergen Schoenwaelder wrote:
> > > A component of a device reports one possible value, the value that
> > > is in the set of states it supports natively.
> >
> > But an entity (i.e. "a component of a device") cannot support more
> > than one set of states natively?  It must choose only one paradigm?
>

The entity is in one state, but it may be described by different
paradigms in totally equivalent ways.

Some users may understand ACPI better than DMTF for whatever reason.  In
that case, let's say that they purchase a server whose manufacturer, for
no reason other than personal preference, sets DMTF as its "native"
language.  We're saying that the user can speak ACPI to the server, but
the server responds back in DMTF?

Doesn't this seem asinine?

Philosophically, I think you've hit on a key point that "simple-off" and
"acpi-off" and "dmtf-off" are all the same operational state.  However,
how you represent "off" changes based on the language you speak.
English: "off."  Spanish: "apagado."  Russian: "OT."  We don't want to
force Russians to speak English.  :-)

Similarly, we're talking about developing a "Tower of Babel" style
language here in EMAN to reflect power states.  Such is an enormous
undertaking, and prone to error as concepts are mistranslated or
misunderstood.

Wouldn't it be better to put together an interface like a Rosetta stone?
Let each user access the system in whatever ways make sense for that
user, and then have the agent provide the equivalent translation of
power states that makes sense for that agent?

Chris

P.S.  Google Translate pulled the "OT" for Russian, so no clue if it's
right.

---

From: Ted Ghose <[email-masked]>
Date: Fri, 18 Mar 2011 09:22:08 -0700

This approach will then be similarly useless that what we have today,
without a MIB!

If the charter of the WG is to publish an yellow book of all existing
practices and just open a registration forum in IANA, can we think for a
moment how does it going to help end users?

Device manufactures will have a easy task, yes. But I belief WG authors MIB
to help end users.

If that is not the case, I belief I'm wasting my time over here.

thanks

-tg-

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Mar 2011 17:23:58 +0100

> that series, which states are supported?

If you report the set type and the set value in separate objects, I
think you still have the same question. In other words, the question
whether there is a function to discover supported sets of power states
seems to be independent of the encoding.

I many (if no most) MIB modules, there are no objects that let you
discover which values you may write. There are likely three reasons:

a) Originally, the idea was that SNMP implementations were providing
   AGENT-CAPABILITIES that would provide this information out of band.

b) Providing this information in band takes a lot of extra work since
   you end up needing additional objects.

c) Even if you have an object that tells you that a device supports a
   certain value, there is still no guarantee that you can
   successfully write it. Hence, it is often easier for a management
   system to simply try the desired value and to fallback to some
   fallback value if the desired value did not work.

Perhaps it helps to answer the question how many different sets of
power states we will likely have first (that is how restrictive IANA
rules would be) and based on that whether a discovery mechanism is
necessary for the first version of the MIB module.

/js

---

From: Ted Ghose <[email-masked]>
Date: Fri, 18 Mar 2011 09:24:13 -0700

+1

-tg-

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Fri, 18 Mar 2011 11:27:42 -0500

> Benoit Claise wrote:

My $0.02 on this is that I can accept either approach as each has its own benefits.

If I got to pick I would argue that the benefit (intuitive clarity from a modeling perspective for lack of a better description) of the 2 index approach proposed by JuergenQ outweighs the efficiency argument of JuergenS to combine the two into a single index.  But this is just my personal opinion.  YMMV.

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Mar 2011 17:32:59 +0100

> If that is not the case, I belief I'm wasting my time over here.

Once again, the WG specifies the IANA rules. And they can be as strict
as requiring a standards action to make changes. The implication "IANA
controlled" => "yellow book of all existing practices" is wrong.

For more details, I suggest reading RFC 5226.

/js

---

From: "John Parello (jparello)" <[email-masked]>
Date: Fri, 18 Mar 2011 09:44:28 -0700

+1

If we must support interfaces of states then the two index is clearer.

Next best is list with domain name style names spaces IMO

Jp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mielke, William F (Bill)
Sent: Friday, March 18, 2011 9:28 AM
To: eman mailing list
Subject: Re: [eman] MIB-friendly proposal for flexible power states

> that series, which states are supported?

My $0.02 on this is that I can accept either approach as each has its
own benefits.

If I got to pick I would argue that the benefit (intuitive clarity from
a modeling perspective for lack of a better description) of the 2 index
approach proposed by JuergenQ outweighs the efficiency argument of
JuergenS to combine the two into a single index.  But this is just my
personal opinion.  YMMV.

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

---

From: Ted Ghose <[email-masked]>
Date: Fri, 18 Mar 2011 09:46:59 -0700

Hi  Juergen

> For more details, I suggest reading RFC 5226.

according to RFC 5226:

5.  Registering New Values in an Existing Registry

so, anyone can come and register a new set of states. WG will not allow
that? why? why APCI and DMTF got a differential treatment?

I do not see why you are saying  "yellow book of all existing practices" is
wrong.

I clearly see that where you are taking this to, anyway! Its a mute point if
u use one index or two.

-tg-

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Mar 2011 18:14:46 +0100

On Fri, Mar 18, 2011 at 09:46:59AM -0700, Ted Ghose wrote:
> so, anyone can come and register a new set of states.

It might help to read the whole document.

> WG will not allow

Standards are about interoperability. An open ended set of states is
likely a failure from this point of view. Not recognizing widely
implemented states such as ACPI is likely a failure as well. An IANA
registry allows to have controlled extensibility. The WG needs to
decide what the initial content of the registry should be.

/js

---

From: Ted Ghose <[email-masked]>
Date: Fri, 18 Mar 2011 10:42:16 -0700

> It might help to read the whole document.

whats your point?

> decide what the initial content of the registry should be.

I have a great respect for standard and WG.  I belief people in WG will lead
and define (not open ended) a set of states.

There is no question of not recognizing an implemented state like ACPI, but
to give them guidance in future what IETF's state it will align to.

we had miles/lb system, and it was recognized! we globally adopted SI system
scientifically. We do not define a superset of different standard saying it
will be flexible!

My appeal to you and the WG is to define "a standard" not an yellow page of
existing standards.

thanks

-tg-

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Fri, 18 Mar 2011 13:11:20 -0500

> [email-masked] wrote:
> 

I think that this would be a nice thing to do but I also think that it is not achievable.

This notion of defining an equivalence of states between the sets is the source of much of our angst here.  Defining such an "eqivalency map" between disparate sets of states is the essence of why it is difficult to create a single common set of states in the first place.

If it were possible to bucket the various states from all of these different sets into "equivalence classes" then the "equivalence classes" would BE the universal set of states that we seek.  I argue that this is not really possible to do, at least not to the level people seem to want.  It may be easy for some states like the various "off" states, or the "on" states, but beyond that the underlying semantics associated with the more specialized states are inherently NOT equivalent so they cannot be so cleanly grouped.  You will quickly degenerate down to the point where each equivalence class is mapped one-to-one with a single state from a single set.  So in the end you have what is essentially the complete union of all the states from all the sets combined into one big set and I question the utility of having one big set.

For this reason I favor an approach which defines meaningful sets of states that map cleanly to the semantics associated with the capabilities of the device in question.  The IANA proposals enable us to have state definitions which do that while still offering some benefit to the management applications from having a constrained process for the creation of new power state sets.

The device vendors will still be constrained to using IANA registered sets and thus they will have a reasonable incentive to reuse those sets before embarking down the path of defining a whole new set.  And even in the course of defining a new set they will, presumably, be challenged to justify why they need a whole new set instead of utilizing or extending an existing one.

Note this is likely to lead to an overall reduction in the number of unique sets (which is what the management applications want) but in a way that does not require EMAN as a working group to try to be omniscient about where things will move in the future.  The list of sets will grow only as needed and based on legitimate reasons for creating them rather than on the simple whim of every vendor.

So what does this all mean for your reference to a Rosetta Stone approach?

Personally I believe that it means, or should be constrained by us to mean, that a particular device gets to decide which state set makes sense for IT given its capabilities and that the operators and management applications need to talk to that device using the set IT says it understands.  If a particular device (or component) feels that the ACPI set best matches its needs then it should adopt and use that set and the management applications should be constrained to talking to it using that set.

A device which adopts ACPI should not be in the position of trying to guess what a management application means when it subsequently tries to set it to some DMTF state.  Or worse, try to guess what two different management applications mean when one is speaking ACPI and the other is speaking DMTF.  If a device that adopts ACPI receives a request to set itself to a particular DMTF state the response should simply be, IMHO, "No hablo DMTF.  Hablo ACPI."  At least that is the case if we want to foster clear and unambiguous communications between the management applications and the devices.

Allowing the management applications to ASSUME the equivalence of states between the various sets is likely to lead to the old canard about assuming things (i.e. never ASSUME anything because it makes an ...).  Conversely, trying to force an equivalence by standards body fiat is only going to lead to a situation where the standard is not well adopted because it doesn't map cleanly to the underlying reality of a given device's capabilities.

I would love to be proven wrong here but thus far I remain unconvinced that we (or anyone) can define a reasonable equivalence map between the meaningful power states of all possible devices.  If some people here (and this is not directed specifically at Chris or anyone else) want us to achieve a single set of such states then let's see some proposals for how to make that actually work in real life scenarios.  I certainly agree that this is a worthy goal, I just don't believe that it is an attainable one.

So, unless and until such a unified state proposal is put forth I personally favor an approach which seeks to at least acknowledge the inherent real life complexity we are dealing with and thus far I think that the IANA based proposals are a pragmatic step in that direction.

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

---

From: Rolf Winter <[email-masked]>
Date: Mon, 21 Mar 2011 12:25:16 +0000

Hi,

I guess the real underlying question is whether one actually can come up with one set of states that is applicable to _all_ devices out there and for future devices yet to come. My personal take on this is that that's probably not the case as the set of industry standards out there seems to imply. Assuming it is possible, the question arises whether the IETF folks are indeed the right crowd to define such a set. I have serious doubts that they are. An attempt of protocol engineers to define them will likely do more harm than good.

Best,

Rolf

> Ted Ghose
> Sent: Freitag, 18. März 2011 18:42
> To: Juergen Schoenwaelder; Ted Ghose; Juergen Quittek; eman mailing
> list
> I have a great respect for standard and WG.  I belief people in WG will
> lead and define (not open ended) a set of states.
> 
> There is no question of not recognizing an implemented state like ACPI,
> but to give them guidance in future what IETF's state it will align to.
> 
> we had miles/lb system, and it was recognized! we globally adopted SI
> system scientifically. We do not define a superset of different
> standard saying it will be flexible!
> 
> My appeal to you and the WG is to define "a standard" not an yellow
> page of existing standards.
> 
> thanks
> 
> -tg-

---

From: Ted Ghose <[email-masked]>
Date: Mon, 21 Mar 2011 08:06:28 -0700

Hi Rolf

This is a great observation, and I'm in total agreement with you.

Can we take a lead to defining a broad class of devices, and seek engagement
of people from these industries? I refuse to call quits even without trying.

Once we have a broad classification of devices, I'll reach out to people in
various industry so that we have a fair representation while defining one
set of power states.

Thanks

-tg-

On Mon, Mar 21, 2011 at 5:25 AM, Rolf Winter <[email-masked]> wrote:

> Hi,
>
> I guess the real underlying question is whether one actually can come up
> with one set of states that is applicable to _all_ devices out there and for
> future devices yet to come. My personal take on this is that that's probably
> not the case as the set of industry standards out there seems to imply.
> Assuming it is possible, the question arises whether the IETF folks are
> indeed the right crowd to define such a set. I have serious doubts that they
> are. An attempt of protocol engineers to define them will likely do more
> harm than good.
>
> Best,
>
> Rolf
>
>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 22 Mar 2011 11:08:16 +0100

Hi William,

I like your analysis, and I arrive to the same conclusion in 
http://www.ietf.org/mail-archive/web/eman/current/msg00221.html

Based on the recent conclusions, I would complement my analysis

    What I believe the solution is in terms of EMAN:
    - we must be ready to support multiple power states series
    - we must be ready to support a new power states series.
    - the device must report which power states series it supports

With
           - lock the IANA process so that we don't have an explosion of 
new power states (series)

Regards, Benoit.

---

From: Ted Ghose <[email-masked]>
Date: Tue, 22 Mar 2011 07:52:51 -0700

hi Benoit

I see a great value to define one standard power state set.

supporting multiple power state series will bring more confusion

thanks

-tg-

On Tue, Mar 22, 2011 at 3:08 AM, Benoit Claise <[email-masked]> wrote:

>           - lock the IANA process so that we don't have an explosion of new
> power states (series)
>
> Regards, Benoit.
>
> eman mailing [email-masked]://www.ietf.org/mailman/listinfo/eman
>
>
>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 22 Mar 2011 16:01:52 +0100

Hi Ted,

Which one then? An existing one? A new one?

Regards, Benoit.
> On Tue, Mar 22, 2011 at 3:08 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi William,
>
>               - lock the IANA process so that we don't have an
>     explosion of new power states (series)
>
>     Regards, Benoit.
>
>>>     [email-masked]  <mailto:[email-masked]>  wrote:
>>>
>>     Email:[email-masked]  <mailto:[email-masked]>
>>     Phone:614 367 5628  <tel:614%20367%205628>
>>     Fax:614 367 5965  <tel:614%20367%205965>
>>
>>     [email-masked]  <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Mon, 28 Mar 2011 12:34:56 -0500

I am only now in the process of catching up with the latest EMAN emails.  I agree with Benoit on the following points.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [email-masked]<mailto:[email-masked]>
Phone: 614 367 5628
Fax: 614 367 5965

    - Albert Einstein

________________________________
From: Benoit Claise [mailto:[email-masked]]
Sent: Tuesday, March 22, 2011 6:08 AM
To: Mielke, William F (Bill)
Cc: eman mailing list
Subject: Re: [eman] MIB-friendly proposal for flexible power states

Hi William,

I like your analysis, and I arrive to the same conclusion in http://www.ietf.org/mail-archive/web/eman/current/msg00221.html

          - lock the IANA process so that we don't have an explosion of new power states (series)

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 29 Mar 2011 00:53:36 +0200

Hi Bill and Benoit,

I also agree.

This leads to another question: 
Do we want a device to be able to support more than one series at a time?

Thanks,

    Juergen