[WIMS] Re: Hints about simpler Power conformance?

[WIMS] Re: Hints about simpler Power conformance?

Ira McDonald blueroofmusic at gmail.com
Mon Sep 21 22:35:22 UTC 2009


Hi Bill,

[oops - deleted the duplicate line below PowerRequest,
copied from PowerPolicy - doubled the model size -:) ]

By Wednesday next week (30 September), I have to
publish some ASN.1 sketch of PWG Power Mgmt MIB,
per our project charter.

I plan to delete from the Power Model these properties:

- PowerMonitor.MonitorID (redundant, only 1 allowed)
- PowerMonitor.LastLogID (not useful, per Mike Fenelon)
- PowerRequest.RequestID (redundant, only 1 allowed)

I now suggest 3 Power conformance packages (not levels,
because they are orthogonal packages):

Status (REQUIRED)
- PowerMonitor group
 (3 read-only properties)
- PowerLog group
 (1 key, 4 read-only properties, minimum 2 rows)

Capabilities (OPTIONAL)
- PowerMode group (supported states)
 (1 key, 5 read-only properties)
- PowerTransition group (supported transitions)
 (2 keys, 1 read-only property)

Settings (OPTIONAL)
- PowerPolicy group
 (1 key, 13 min-access read-only properties)
- PowerRequest group (state change)
 (1 read-write property, 4 read-only properties)

Apart from simplifying (?) PowerPolicy group,
does this approach seem better to you?

I'd like to update my Model draft before our next
Monday WIMS WG, if we can come any closer
to a common vision.

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, Sep 21, 2009 at 6:26 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
> Hi Bill,
>
> By Wednesday next week (30 September), I have to
> publish some ASN.1 sketch of PWG Power Mgmt MIB,
> per our project charter.
>
> I plan to delete from the Power Model these properties:
>
> - PowerMonitor.MonitorID (redundant, only 1 allowed)
> - PowerMonitor.LastLogID (not useful, per Mike Fenelon)
> - PowerRequest.RequestID (redundant, only 1 allowed)
>
> I now suggest 3 Power conformance packages (not levels,
> because they are orthogonal packages):
>
> Status (REQUIRED)
> - PowerMonitor group
>  (3 read-only properties)
> - PowerLog group
>  (1 key, 4 read-only properties, minimum 2 rows)
>
> Capabilities (OPTIONAL)
> - PowerMode group (supported states)
>  (1 key, 5 read-only properties)
> - PowerTransition group (supported transitions)
>  (2 keys, 1 read-only property)
>
> Settings (OPTIONAL)
> - PowerPolicy group
>  (1 key, 13 min-access read-only properties)
> - PowerRequest group (state change)
>  (1 read-write property, 4 read-only properties)
>  (1 key, 13 properties, min-access read-only)
>
> Apart from simplifying (?) PowerPolicy group,
> does this approach seem better to you?
>
> I'd like to update my Model draft before our next
> Monday WIMS WG, if we can come any closer
> to a common vision.
>
> 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, and is
believed to be clean.




More information about the wims mailing list