Subject: Re: [eman] Please add PWG power states to EMAN Framework

From: Nevil Brownlee <[email-masked]>
Date: Wed, 12 Jun 2013 10:11:54 +1200

Hi Ira:

Following up on your email dated 29 May, we've discussed the
PWG power states, and are happy to add them into the EMAN Framework's
Power State Sets.

However, looking at the PWG states, we feel it's not a good idea
to have little subsets for particular vendors as part of the PWG
state set.  That's mostly because it won't scale to a large number
of vendors.  From an IANA point of view, it would be better to
have a separate IANA registry for Vendor-specific power states -
that way, when a new vendor needs particular states they could
simply ask IANA to add them to that registry.

For now, we see three possible ways forward:
1. Add PWG's power states, leaving out its vendor-specific
    states.
2. Leave the PWG states out of the EMAN power states for now;
    they could be added later by asking IANA to register them
    (they'd probably be subject to Expert review at that point).
3. Discuss having a Vendor-specific Power States Registry with IANA.

Would you please consider these possibilities, and let me know
which you'd like us to proceed with.  Speaking only for myself,
I suggest that the question is "how important is it for PWG to
have vendor-specific power states?"

Cheers, Nevil (EMAN co-chair)

On 29/05/13 10:31 AM, Ira McDonald wrote:
> Hi,
>
> I understand that the EMAN Framework document
> will request IANA to create some initial sets of power
> states.  We would like this to include the PWG's power
> state set for imaging devices.  That can be found at
> the following link and the states (and numeric codes)
> from that are listed below.
>
> The stable reference for IEEE-ISTO PWG power state
> names and numeric values is the PWG Imaging System
> Power MIB (PWG 5106.5-2011) archived at:
>
> ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.mib
>
> On line 50 is the PowPowerStateTC definition, which uses
> the DMTF CIM power states multiplied by 10 w/ inserted
> vendor sub-states for a few stable (non-transient) states,
> as follows:
>
> PowPowerStateTC ::= TEXTUAL-CONVENTION
>      STATUS      current
>      DESCRIPTION
>          "The power state of this component (System or Subunit).
>
>          Usage:  Vendor extensions allowed ONLY for primary power states
>          (on, standby, suspend, hibernate, and offSoft).  Vendor
>          extensions are intentionally not defined for reset or
>          interrupts."
>      REFERENCE
>          "Table 3 in section 7.3 in DMTF CIM Power Profile (DSP 1027)."
>      SYNTAX      INTEGER {
>          other(1),
>    -- DO NOT USE
>          unknown(2),                     -- initial default ONLY
>          on(20),                         -- On - fully operational
>          onVendor1(21),
>          onVendor2(22),
>          onVendor3(23),
>          onVendor4(24),
>          onVendor5(25),
>          standby(30),                    -- Standby - light sleep
>          standbyVendor1(31),
>          standbyVendor2(32),
>          standbyVendor3(33),
>          standbyVendor4(34),
>          standbyVendor5(35),
>          suspend(40),                    -- Suspend - deep sleep
>          suspendVendor1(41),
>          suspendVendor2(42),
>          suspendVendor3(43),
>          suspendVendor4(44),
>          suspendVendor5(45),
>          resetSoft(50),                  -- Reset - soft reset
>          offHard(60),                    -- Off Hard - no power consumed
>          hibernate(70),                  -- Hibernate - context save, off
>          hibernateVendor1(71),
>          hibernateVendor2(72),
>          hibernateVendor3(73),
>          hibernateVendor4(74),
>          hibernateVendor5(75),
>          offSoft(80),                    -- Off Soft - w/ auxiliary power
>          offSoftVendor1(81),
>          offSoftVendor2(82),
>          offSoftVendor3(83),
>          offSoftVendor4(84),
>          offSoftVendor5(85),
>          resetHard(90),                  -- hard off, power on
>          resetMBR(100),                  -- Master Bus Reset
>          resetNMI(110),                  -- Non-Maskable Interrupt
>          offSoftGraceful(120),           -- orderley shutdown, soft off
>          offHardGraceful(130),           -- orderly shutdown, hard off
>          resetMBRGraceful(140),          -- orderly shutdown, MBR reset
>          resetSoftGraceful(150),         -- orderly shutdown, soft reset
>          resetHardGraceful(160),         -- orderly shutdown, hard reset
>          resetINIT(170),                 -- Diagnostic Interrupt (INIT)
>          notApplicable(180),
>          noChange(190)
>      }
>
> Thanks,
> - Ira (editor of PWG Power MIB and PWG Secretary).
>
>
> 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
>
>
>
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>

-- 
---------------------------------------------------------------------
  Nevil Brownlee                          Computer Science Department
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

---

From: Ira McDonald <[email-masked]>
Date: Tue, 11 Jun 2013 20:17:48 -0400

Hi Nevil,

We added the standard-named vendor extension sub-states under pressure
from some of the printer vendors.

But it's unlikely that printer vendors will ever register their own
extension states
with IANA - most of them don't currently publicly disclose much at all
about their
SNMP implementations (even their list of IETF and PWG MIB modules).

I suggest not registering the PWG power states *at all* and just letting the
printer vendors use the standard DMTF power states - which they have to
do anyway for compatibility with DMTF CIM based management protocols
and we standardized on this "folding" in the PWG Power Model and MIB.

Cheers,
- Ira (editor of PWG Imaging System Power MIB)

On Tue, Jun 11, 2013 at 6:11 PM, Nevil Brownlee
<[email-masked]>wrote:

>> ftp://ftp.pwg.org/pub/pwg/**candidates/cs-wimspowermib10-**
>> 20110214-5106.5.mib<ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.mib>
>>
>> http://sites.google.com/site/**blueroofmusic<http://sites.google.com/site/blueroofmusic>
>> http://sites.google.com/site/**highnorthinc<http://sites.google.com/site/highnorthinc>
>> ______________________________**_________________
>> eman mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/eman<https://www.ietf.org/mailman/listinfo/eman>
>>
>>
>
> --
> ------------------------------**------------------------------**---------

---

From: Benoit Claise <[email-masked]>
Date: Thu, 13 Jun 2013 20:52:21 +0200

Hi Ira,

That makes sense.
Btw, they could still do later on. The EMAN framework IANA 
considerations section will contain the guidelines on how to do it.

Regards, Benoit
> mailto:[email-masked] <mailto:[email-masked]>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Hi Ira:
>
>         mailto:[email-masked] <mailto:[email-masked]>
>         <tel:734-944-0094>
>         <tel:906-494-2434>
>         [email-masked] <mailto:[email-masked]>
>      Phone: +64 9 373 7599 x88941
>     <tel:%2B64%209%20373%207599%20x88941>             The University
>     of Auckland
>      FAX: +64 9 373 7453 <tel:%2B64%209%20373%207453>   Private Bag
>     92019, Auckland 1142, New Zealand
>
>
>
>