Replies inline below.
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
579 Park Place Saline, MI 48176
PO Box 221 Grand Marais, MI 49839
On Sun, Nov 29, 2009 at 2:14 PM, William Wagner <wamwagner at comcast.net> wrote:
> Hi Ira,
>>>> A few questions from looking though the MIB.
>> 1. The Abstract document identified five stable power states. The MIB
> appears to identify six, with the difference being that there are two OFF
> states in the MIB and one in the abstract document.
>> offHard(60), -- Off Hard - mechanical unplug
>> off(80), -- Off - soft off w/ flea power
>>>> It is unclear how the MIB OFF states correlate with the Abstract Document
> OFF state, although my inclination is that the abstract OFF correlates best
> to offHard. Do we need to include the two “off’s” in the abstract document?
> A better explanation of what is involved in “flea power” would be desirable
> (enough for turn on by network, Bluetooth or IR, illuminate the power
> switch, just reactive leakage, ?)
The MIB *exactly* follows the authoritative states listed in Table 2 on page 34
of the Power Management Model - it came via cut-and-paste.
Yes - we have an issue to address about distinguished OffHard from Off(Soft)
in the Model (and then the MIB).
>>> 2. Because powMonitorIndex is used throughout the MIB, would not some
> statement that an index assignment cannot be changed except on hard reset
> (or whatever) be desirable?
<ira> I would say that powMonitorIndex MUST be preserved across all
reboots and MUST NOT change with reboots (because it breaks the
integrity of the Power Log and all other groups).
>>> 3. Perhaps some mention of the power-cycle persistence of the LogTable
> might be desirable.
<ira> Yes - although the main persistence discussion belongs in
the front matter of the eventual Power MIB spec, I think.
>>> 4. I have put it though the MG-SOFT compiler without problem.
>>> Bill Wagner
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.