Subject: [eman] iana powerstate tc proposal

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jul 2011 18:45:03 +0200

Hi,

here is a proposal for an IANA maintained power state textual
convention. There are of course other ways of doing this but I thought
a concrete proposal might help the discussion.

/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: Bruce Nordman <[email-masked]>
Date: Thu, 28 Jul 2011 13:01:19 -0400

I'm not a MIB person, but assuming this is the desired
structure, sets for ACPI and the Printer group should
be added, and EMAN dropped.

For 1621, it also defines "Unplugged" (today I would have
instead called it "Disconnected") to refer to a subset of
Off when not mains-connected (a battery powered device
could be On or in Sleep when unplugged).  This probably
worth adding.
Also, 1621 is specifically scoped to electronic devices,
and for non-electronic ones, "Ready" is a common power
state. It would be convenient to include Ready as an
expansion of 1621.  It is not defined, but is mentioned
in the text as a form of On, along with Active.

Thanks,

--Bruce

On Thu, Jul 28, 2011 at 12:45 PM, Juergen Schoenwaelder <
[email-masked]> wrote:

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

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

---

From: "John Parello (jparello)" <[email-masked]>
Date: Thu, 28 Jul 2011 10:26:12 -0700

Disconneted, Unplugged is more precisely defined as mechanical-off.

Once you add these and a ready state you get very close to the eman states we proposed.

I like keeping to the spirit of ou 1621 as three states and then setting up DMTF and EMAN with the full spectrum.

Jp

-----Original Message-----
From: [email-masked] on behalf of Bruce Nordman
Sent: Thu 7/28/2011 10:01 AM
To: Juergen Schoenwaelder; [email-masked]
Subject: Re: [eman] iana powerstate tc proposal

Thanks,

--Bruce

---

From: "John Parello (jparello)" <[email-masked]>
Date: Thu, 28 Jul 2011 10:28:57 -0700

There was a long discussion on having two indecies. One to represent the set and then numbering within the set.

I'd like to see a seperate index for the sets  then numbering withing the set as opposed to a single numbered array.

This way it's easy to determine the set you implement. I find this type of sparse array very arcane and cumbersome.

There was quite a discussion on that an IIRC a single array was not desirable.
Jp

-----Original Message-----
From: [email-masked] on behalf of Juergen Schoenwaelder
Sent: Thu 7/28/2011 9:45 AM
To: [email-masked]
Subject: [eman] iana powerstate tc proposal
 
Hi,

/js

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 28 Jul 2011 13:31:13 -0500

Hi Juergen S.

Thanks for your proposal. 

We as authors had debated 3 approaches. 

1.  One TC for PowerStateSet - which is a 2 byte octet - one byte for
Power State Set and one byte for the Power State within the Set  

Proposal one has an advantage of a single index which captures both
Power State Set and Power State within the set. 

2.  One TC for the PowerStateset which is a 1-byte octet and States
within the set is a simple enumeration - (consensus of authors) as it is
this version of the document. 

3. one  TCs for the PowerStateSet - simple enumeration and one TC for
the Power States with in the Set (another enumeration). 

We had discussed this extensively and felt design 2 was good. Your
comments welcome.

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Schoenwaelder
Sent: Thursday, July 28, 2011 12:45 PM
To: [email-masked]
Subject: [eman] iana powerstate tc proposal

Hi,

here is a proposal for an IANA maintained power state textual
convention. There are of course other ways of doing this but I thought a
concrete proposal might help the discussion.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jul 2011 20:42:35 +0200

> This way it's easy to determine the set you implement. I find this type of sparse array very arcane and cumbersome.

The code (value & 0xff) is not that complex. What I find complex is
the following:

- I always have to poll two OIDs to retrieve the power state. This
  adds runtime verbosity and overhead.

- I need to implement and enforce atomic sets with two varbinds in
  order to change from a value in one power state set to a value in a
  different power state set.

Compared to this, doing (value & 0xff) or (value >> 8) is rather
cheap. And in addition, with this this appraoch,

- I have _all_ IANA maintained power states defined in a machine
  readable format, something that can drive tools and automation.

So here are three technical arguments. Looking forward to the
technical arguments against this.

/js

---

From: "John Parello (jparello)" <[email-masked]>
Date: Thu, 28 Jul 2011 13:47:40 -0700

Hi JS,

Thanks for throwing out a strawman for it BTW but I think you need to review the discussions to see what the consensus was. 

See inline...

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thu 7/28/2011 11:42 AM
To: John Parello (jparello)
Cc: [email-masked]
Subject: Re: [eman] iana powerstate tc proposal

[jp] If you define a numeric value to each set then this is an index to a state series subtree so you don't have to poll twice It would be in a the tree. If you keep it the way you have it you have to poll the base number first remember the series and then know to avoid or use that range to find out what is supported. With a seperate power state set number it's implicit in the data.  You just traverse or get the entire table.

[jp] If you have an index for the set first you get the same ability

[jp] Having an index to the series first is still machine readable. Also BTW you are limiting power states to 256. There was lengthy discussions on not limiting it. I can see a series with 1000 as percentage increments.

Again all this was discussed. I think Mouli sent a summary.

Jp

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jul 2011 23:20:16 +0200

> [jp] If you define a numeric value to each set then this is an index to a state series subtree so you don't have to poll twice It would be in a the tree. If you keep it the way you have it you have…

But that particular table design I think you are refering to is
awkward in the first place since it indexes and thus duplicates
objects that are really not specific to the set. That said, once
stored, a single integer is simply self-contained (and you even get a
meaningful descriptor with typical generic SNMP tools).
 
> [jp] If you have an index for the set first you get the same ability

Well, not completely true. If you have dmtf off and you want to change
to eman on, how does set look like? I know that you assume magic
implementation specific translations between the power state sets,
which I find ugly. Too much magic if our goal is interoperability.

> [jp] Having an index to the series first is still machine
> readable. 

The value is machine readable. There is not machine readable
definition of the power state definitions themself.

> Also BTW you are limiting power states to 256. There was lengthy
> discussions on not limiting it. I can see a series with 1000 as
> percentage increments.

We have 32 bits to play with. If 8 bits are not enough, we pick
16. Gives you ~65000 power states. Still not enough? We are after all
talking about _states_.

/js

---

From: Brad Schoening <[email-masked]>
Date: Thu, 28 Jul 2011 22:07:54 +0000

ECMA has four power states:  Off, Sleep, Idle, Active.  This more adaptable than the three in 1621.

I agree with John that 'mechanically off' is the correct term.

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Parello (jparello)
Sent: Thursday, July 28, 2011 1:26 PM
To: Bruce Nordman; Juergen Schoenwaelder; [email-masked]
Subject: Re: [eman] iana powerstate tc proposal

Jp

-----Original Message-----
From: [email-masked] on behalf of Bruce Nordman
Sent: Thu 7/28/2011 10:01 AM
To: Juergen Schoenwaelder; [email-masked]
Subject: Re: [eman] iana powerstate tc proposal

Thanks,

--Bruce

---

From: Ira McDonald <[email-masked]>
Date: Thu, 28 Jul 2011 19:16:50 -0400

Hi,

I find Juergen Schoenwalder's single enumeration arguments
compelling.  And we do have 32 bits, so 16-bits for particular
state seems quite sufficient.

Also, I suggest that power state should *not* be an index
in any table, if possible - though I did this in two tables in the
IEEE-ISTO PWG Imaging System Power MIB (for printers
and MFDs), but we didn't have to support multiple power
state series.

Even a table that describes the nominal power consumption
and capabilities (can accept work, can process work, etc.)
for each power state can have a simple integer index - an
NMS only needs to read this table once.

BTW - powSupportTable in the PWG Power MIB, has a much
richer set of the capabilities for each supported power state:

PowSupportEntry ::= SEQUENCE {
        powSupportPowerState            PowPowerStateTC,
        powSupportPowerInactiveWatts    Integer32,
        powSupportPowerActiveWatts      Integer32,
        powSupportCanAcceptJobs         TruthValue,
        powSupportCanProcessJobs        TruthValue,
        powSupportCanRequestPowerState  TruthValue,
        powSupportCanUseInterfaces      DisplayString,
        powSupportPowerPeakWatts        Integer32
    }

In the printer industry, the terms active and inactive are
qualifiers of the *same* operational or power state and
are *not* separate states.

Cheers,
- Ira (Editor of IEEE-ISTO PWG Imaging System Power MIB)

-------------------------------------------

On Thu, Jul 28, 2011 at 6:07 PM, Brad Schoening <[email-masked]>wrote:

> ECMA has four power states:  Off, Sleep, Idle, Active.  This more adaptable than the three in 1621.   ****
>
> ** **
>
> I agree with John that ‘mechanically off’ is the correct term.****
>
>

---

From: "John Parello (jparello)" <[email-masked]>
Date: Fri, 29 Jul 2011 09:37:11 -0700

Hi Jeurgen,

Either design is reasonable. 

So I have some specific questions/use cases in your design that I am
concerned about:

1) How would a mgt station determine which power state sets are
supported?
This would be for a discovery stage inquiry. I want to determine the
power state sets supported by a device. I don't want to set any, just
determine which is supported

2) Can you ensure that if a device supports a particular power state set
it is valid to get or set a state in the series?
I don't mean valid from the point of the device ack or nack the set but
I mean not an error in syntax.

By that I mean with the two byte values you propose I can imagine
someone choosing to do DMTF(3) and DMTF(5) and then say IEEE(2)?  What
I'd like to have is a clear way of having these sets be like and
interface that an device supports. That's natural to the mgt stations
when presenting controls.

So I'm not concerned with the encoding but more about how to announce
and discover the power state sets a device supports.

I'd like one get with values of the power state sets supported. Then
assurance that if I try to decode to a specific set in that series is a
valid request (other than operational ack or nack)

Can your design cover that?

Jp

PS go for the 64K states right now versus the 255 so we don't have to
come back to this point in our lifetimes ;)

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 2:20 PM
To: John Parello (jparello)
Cc: [email-masked]
Subject: Re: [eman] iana powerstate tc proposal

On Thu, Jul 28, 2011 at 10:47:40PM +0200, John Parello (jparello) wrote:

> [jp] If you define a numeric value to each set then this is an index
to a state series subtree so you don't have to poll twice It would be in
a the tree. If you keep it the way you have it you have to poll the base
number first remember the series and then know to avoid or use that
range to find out what is supported. With a seperate power state set
number it's implicit in the data.  You just traverse or get the entire
table.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Jul 2011 19:02:09 +0200

> determine which is supported

I can imagine different ways of doing this but this also depends how
the tables in general look like for devices that claim to support
multiple power state sets. Is a device always in exactly one state or
can a device be in multiple states of different sets simultaneously?
If the later, what is the mapping and what happens if there is not
suitable mapping?
 
> when presenting controls.

I am not sure I understand your question. You set the state to
dmtfSleepDeep or dmtfOffSoft or ieee1621Sleep. The device will either
do as requested or return an error. If your NMS wants to present
things in a different way (because you believe DMTF(3) is more user
friendly than dmtfSleep), this can be easily be done. The encoding on
the wire is not the user interface.

> valid request (other than operational ack or nack)

If the device is correct and the power state set did not get augmented
(seems to have happened in the past), you can make this assumption. In
the real world, you know that a set succeeds when it got carried out.
(But this is generally independent of the encoding.) The main point
here is that power state sets do not seem to be static and with
additions over time and implementations improving over time, you
simply will never be fully sure. This is a versioning issues and
independent of the encoding on the wire - you will always face this.

/js

---

From: "John Parello (jparello)" <[email-masked]>
Date: Fri, 29 Jul 2011 10:26:28 -0700

Hi Jeurgen,

Ok, I guess maybe my questions are in the mib design then not the IANA
registry.

I want to ask what are the power sets you support. After that I want to
make sure that if I ask  to go to a state in a set that was not
supported - that is a different error than if I ask to set to a state
and the device can/cannot do that right now.

So I'm looking for validity of request versus execution of request.

For your question on multiple states and sets at the same time I think
we converged (see Bills email) on two power sets can be supported at the
same time.

Jp

-----Original Message-----
Sent: Friday, July 29, 2011 10:02 AM

 

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Jul 2011 21:51:26 +0200

> So I'm looking for validity of request versus execution of request.

This is an SNMP question since error codes are SNMP specific, not data
model specific. Fortunately, SNMP distinquishes between 'wrongValue',
'inconsistentValue', and 'resourceUnavailable' (see section 4.2.5 of
RFC 3416 for the details).

/js