[WIMS] Draft of Charter of WIMS Power Mgmt Project

[WIMS] Draft of Charter of WIMS Power Mgmt Project

[WIMS] Draft of Charter of WIMS Power Mgmt Project

Ira McDonald blueroofmusic at gmail.com
Mon May 11 23:11:20 UTC 2009


Hi Bill,

Important distinction about the "charter process" here:

(a) Project charters are approved directly by PWG SC
      (by recent years' tradition)

(b) WG charters are approved by PWG Members
      via a Formal Vote (much longer time)

The charter for WIMS Power Project will not involve
extra time over the SC "approving" an informal
Project Outline - we have to cover these topics
anyway.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
 579 Park Place  Saline, MI  48176
 734-944-0094
summer:
 PO Box 221  Grand Marais, MI 49839
 906-494-2434


On Mon, May 11, 2009 at 6:36 PM, Ira McDonald <blueroofmusic at gmail.com>wrote:

> Hi Bill,
>
> The PWG SC *has* required a charter for every project or WG
> in the last four years (including CIM) - that's what our Process
> says - and the PWG SC has required a project charter for all
> new projects of existing working groups because they CHANGE
> the scope of the base WG charter.
>
> An important advantage is to get solid Out-of-Scope statements.
> An open-ended WIMS Power Management project is a sure
> formula for failure.
>
> There is no harm in following our existing process (charters)
> and a good deal of possible harm to skipping our process.
>
> Two specific comments:
>
> (1) The abstract spec should be called Power Managerment Model
>       (not Elements spec or whatever) - we have a well-known name
>       for these specs - let's use it please.
>
> (2) As early as possible, requirements gathered should be part
>       of Section 3 Requirements in a working draft of the PWG Power
>       Management Model spec, not just informal stuff in .../wims/power
>
> Cheers,
> - Ira
>
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music/High North Inc
> email: blueroofmusic at gmail.com
> winter:
>  579 Park Place  Saline, MI  48176
>  734-944-0094
> summer:
>  PO Box 221  Grand Marais, MI 49839
>  906-494-2434
>
>
> On Mon, May 11, 2009 at 6:15 PM, William Wagner <wamwagner at comcast.net>wrote:
>
>>  Ira et al,
>>
>>
>>
>> Thank you for your suggestions. My thoughts on the subject:
>>
>>
>>
>> 1.     Although a project statement is necessary for with Power
>> Management effort, I do not think that a charter is. My plan was to pass a
>> project statement past the working group and the SC for comment, but not to
>> go through a charter process.
>>
>> 2.     Similar to what was done for other projects, I will create a new
>> subdirectory under WIMS, but no new mailing list. I intend to place the
>> existing power management information and the project statement in this
>> directory, as well as non-specification draft documents. Working Draft
>> documents for this effort will go under the WIMS/WD directory. But quite
>> frankly, I foresee most of the immediate term effort being in gathering and
>> documenting information of requirements and constraints rather than coming
>> out with spec drafts.
>>
>> 3.     Addressing Harry’s question, I will try to make the “out of scope”
>> area clearer and less restrictive.  At this point, I do not want to
>>  prejudge what we want to do without better understanding of both
>> user/administrator and manufacturer viewpoints.
>>
>> a.     In general, adding power state definitions beyond what is in ACPI
>> is out of scope, although I would not immediately preclude providing for
>> manufacturer defined sub-states. That is, the state must be one of the
>> standard ones; but we may want to allow for a manufacturer to provide more
>> details so he could effectively identify  more detailed sub states to an
>> application which understands them.
>>
>> b.    Regardless, we certainly need to address how the standard states
>> apply to  imaging devices in such a way that an identified state has a
>> consistent meaning across all products. Determining just what this meaning
>> is will be a major task. It is not immediately clear to me that there is an
>> absolute power-range  level associate with each state rather than a relative
>> level or other aspects such as the ACPI Global state definitions include;
>> e.g., , the latency from external events to application response,  reboot
>> require, safe to disassemble  etc.
>>
>> c.     We touched upon whether we will identify power states for just
>> systems, or subunits or a services or some combination. Ira suggested that
>> we start with systems (which I am included to agree with)) and absolutely
>> avoid Services (which I am not so definite about). If at all possible, we
>> need to get user/administrator input, and we may find that although users
>> think in terms Devices (Fax, Scanner, Printer), when dealing with an MFD,
>> they are really concerned with Services. At this point, I think we need to
>> listen more than dictate.
>>
>> d.    Although it may be obvious, developing a protocol is out of scope
>> and tying the elements to a specific protocol is to be avoided. We recognize
>> that defining a working binding is necessary for prototype, and the obvious
>> choice at this point is SNMP. Nor do I believe that just mapping to a
>> binding is a valid prototype of the elements spec.  But the Power Management
>> Elements Spec should be protocol agnostic.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Bill Wagner
>>
>>
>>
>>
>>
>>
>>
>> *From:* Ira McDonald [mailto:blueroofmusic at gmail.com]
>> *Sent:* Monday, May 11, 2009 5:01 PM
>> *To:* Harry Lewis; Ira McDonald
>> *Cc:* William Wagner; wims at pwg.org
>> *Subject:* Re: [WIMS] Draft of Charter of WIMS Power Mgmt Project
>>
>>
>>
>> Hi Harry,
>>
>> Thanks for the comments - my replies are inline below.
>>
>> Cheers,
>> - Ira
>>
>> Ira McDonald (Musician / Software Architect)
>> Chair - Linux Foundation Open Printing WG
>> Blue Roof Music/High North Inc
>> email: blueroofmusic at gmail.com
>> winter:
>>  579 Park Place  Saline, MI  48176
>>  734-944-0094
>> summer:
>>  PO Box 221  Grand Marais, MI 49839
>>  906-494-2434
>>
>>  On Mon, May 11, 2009 at 4:44 PM, Harry Lewis <harry.lewis at infoprint.com>
>> wrote:
>>
>>
>> Ira, great start! Couple observations.
>>
>> 1. As written, adding or changing power state definitions is out of scope.
>> Should the objectives include "interpretation" or mapping of defined power
>> states as they relate to imaging devices?
>>   - For example - are we going to standardize which "power level" relates
>> to fuser or scanner lamp readiness etc?
>>
>>
>> <ira>
>> My two cents.
>>
>> There was strong concensus at the last two face-to-face BOFs
>> NOT to allow any but standard (CIM/ACPI) or vendor-defined
>> power states - no site-defined power states - however, each
>> power state should have an attribute for power consumption
>> (in watts) - ACPI and CIM do NOT manage the absolute
>> power level - they manage a *small* set of standard power
>> states.
>>
>> Therefore, the power *state* that relates to fuser or scanner
>> lamp readiness is in-scope for WIMS Power, but the exact
>> power consumption should NOT be changeable by the site.
>>
>> Site-defined Power Policy (when to go to sleep after idle
>> or a time-of-day) that can be changed is in-scope.
>> </ira>
>>
>>
>>
>> 2. Should the subtask have its own reflector? (we can't pass up the
>> opportunity for POW at PWG.ORG!)
>>
>>
>> <ira>
>> No - we should continue to use the single WIMS reflector
>> (as we have done for 4 years for CIM without problems).
>> </ira>
>>
>>
>>
>> Regards,
>> Harry
>> *
>> Harry Lewis*
>> Program Manager - Intellectual Property & Open Standards
>> Phone: 720-663-3456
>> e-mail: harry.lewis at infoprint.com
>> infoprint.com <http://www.infoprint.com/>
>>
>>
>> P Think before you print
>>
>>   *Ira McDonald <blueroofmusic at gmail.com>*
>> Sent by: wims-bounces at pwg.org
>>
>> 05/11/2009 12:54 PM
>>
>> To
>>
>> wims at pwg.org, William Wagner <wamwagner at comcast.net>, Ira McDonald <
>> blueroofmusic at gmail.com>
>>
>> cc
>>
>> Subject
>>
>> [WIMS] Draft of Charter of WIMS Power Mgmt Project
>>
>>
>>
>>
>>
>>
>> Hi Bill,
>>
>> Attempting to more constructively help out...
>>
>> I just posted a draft of a charter for WIMS Power Mgmt Project:
>>
>>   ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimspower-charter-20090511.htm
>>
>> I followed the format approved by the PWG in IPP PSX project
>> and more recently the MFD WG (basically the same idea).
>> Especially, it includes a specific Out-Of-Scope section.
>>
>> Please add a brief Problem Statement (replace <tbd>).
>>
>> The Milestones during Definition Phase (Initial draft, Prototype
>> draft, and PWG Last Call for each of Model and Binding specs)
>> are the ones the PWG Steering Committee agreed on for MFD
>> - the SC specifically do not want a milestone such as 'PWG CS',
>> because a WG can't project that.
>>
>> Comments?
>>
>> Cheers,
>> - Ira
>>
>> Ira McDonald (Musician / Software Architect)
>> Chair - Linux Foundation Open Printing WG
>> Blue Roof Music/High North Inc
>> email: blueroofmusic at gmail.com
>>
>>
>> winter:
>>  579 Park Place  Saline, MI  48176
>>  734-944-0094
>> summer:
>>  PO Box 221  Grand Marais, MI 49839
>>  906-494-2434
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
>>
>> believed to be clean. _______________________________________________
>> wims mailing list
>> wims at pwg.org
>> https://www.pwg.org/mailman/listinfo/wims
>>
>>
>>
>> _____________________________________________________________________________
>> "This message and any attachments are solely for the intended recipient
>> and may contain confidential or privileged information. If you are not the
>> intended recipient, any disclosure, copying, use, or distribution of the
>> information included in this message and any attachments is prohibited. If
>> you have received this communication in error, please notify us by reply
>> e-mail and immediately and permanently delete this message and any
>> attachments. Thank you."
>> _____________________________________________________________________________
>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
>>
>> believed to be clean.
>>
>> _______________________________________________
>> wims mailing list
>> wims at pwg.org
>> https://www.pwg.org/mailman/listinfo/wims
>>
>>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/wims/attachments/20090511/da69fb12/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 590 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/wims/attachments/20090511/da69fb12/attachment-0001.gif>


More information about the wims mailing list