RE: WIMS> CIM> There is one podssible candidate for EnabledLogicalElement

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Wed Apr 25 2007 - 16:02:51 EDT

Next message: McDonald, Ira: "WIMS> CIM - Posted OutputTray (25 April 2007)"

Previous message: Richard_Landau@Dell.com: "RE: WIMS> OutputTray - Next Steps"
In reply to: wamwagner@comcast.net: "RE: WIMS> CIM> There is one podssible candidate for EnabledLogicalElement"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Hi Bill,

Thanks for your good feedback about console locking!

About DMTF interest - single digit numbers of votes _typically_ pass
new or revised CIM classes - like I said to Lee, vigilante justice is
just their modus operandi - no reflection on interest in printing.

And we've steadily received considerable help from Jon Hass (Dell,
CIM Core WG co-chair), who works closely with Rick Landau, so
we're better off than most alliance partners!

Actually, CIM Core WG has tentatively _approved_ OutputTray, after
we make the status updates in collaboration with Jon Hass - see
the new version I'll post in a few minutes - after CIM Core quick
review, Rick and I expect OutputTray to be forwarded to the DMTF
Technical Committee for final approval quite soon.

We don't lose this functionality (lock/unlock Console) - we just
build it (at some point in the future) as CIM operations (along with
all the other state changing operations for print devices and print
services).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

-----Original Message-----
From: wamwagner@comcast.net [mailto:wamwagner@comcast.net]
Sent: Monday, April 23, 2007 9:37 PM
To: McDonald, Ira; Richard_Landau@Dell.com; wims@pwg.org
Subject: RE: WIMS> CIM> There is one podssible candidate for EnabledLogicalElement

Ira,

I provided my observations for information only. But this brings up the significant question of at what point do we sacrifice too much of the managability capability to deal with the cumbersomeness of the CIM route. And a related question of whether there is sufficient concern in the industry of how this effort, which is conceived as the basis for Web Services management, comes out to either help in the effort or put some pressure on DMTF. Four votes our of 2xx from DMTF does not indicate any interest there.

Bill Wagner

-------------- Original message --------------
From: "McDonald, Ira" <imcdonald@sharplabs.com>

Hi Bill,

My point is that this status property, when added to our CIM_Printer
(from prtGeneralEntry), will probably generate a lot of discussion
and pushback from CIM Core, but what-the-heck, we can spare a
decade to model Print Device, right?

And Rick's suggesting that we'll probably have to move this boolean
out to a new (otherwise empty) class CIM_PrintConsole that contains
the state property and accepts two methods (enable and disable).

Cheers,
- Ira

-----Original Message-----
From: wamwagner@comcast.net [mailto:wamwagner@comcast.net]
Sent: Monday, April 23, 2007 3:49 PM
To: Richard_Landau@Dell.com; McDonald, Ira; wims@pwg.org
Subject: RE: WIMS> CIM> There is one podssible candidate for EnabledLogicalElement

Some general comments.

1. I am aware of printers that support write for both prtGeneralReset and prtConsoleDisable. Granted that these are dangerous from a security viewpoint, there are many MIB writeable objects that are so. SNMP security must be provided by SNMPv3, shutting off SNMP (or just SNMP write) or by other methods.

2. I thought that we had agreed that CIM printing MOFs would be read only, with CIM operations handling the write functionality.

Bill Wagner

-------------- Original message --------------
From: <Richard_Landau@Dell.com>

Subject still ConsoleDisable.

BTW, I know that the DEC PostScript/SNMP printers of my generation, that is, until early 2000, did implement this feature. Don't know if customers used it. But that is not the point.

Believe it or not, the equivalent of ConsoleDisable for desktop monitors is among the most-requested features from large businesses these days. They call it ConsoleLock, but it's the same thing: don't let the user futz with the buttons. Yes, it does require that one re-enable the console for a service call, but apparently it also makes service calls less frequent. Go figure.

In any case, if there is a secure method to invoke this, it is a useful and desirable feature, and I think we should carry it forward in future standards.

rick

_____

From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
Sent: Friday, April 20, 2007 12:25
To: Landau, Richard; wims@pwg.org
Subject: RE: WIMS> CIM> There is one podssible candidate for EnabledLogicalElement

Hi Rick,

Well, hypothetical capability today in Printer MIB... The conformance
macro allows 'read-only'. And I have personally never encountered
a printer that allows remote disable of the console (think about this - it
breaks service scenarios entirely). This is an edge condition.

Now, remote reset of the printer actually does make sense (via a CIM
operation of course). Although, again I don't think there are current
printers that allow remote reset via SNMP (for security reasons).

Cheers,
- Ira

-----Original Message-----
From: Richard_Landau@Dell.com [mailto:Richard_Landau@Dell.com]
Sent: Thursday, April 19, 2007 4:08 PM
To: McDonald, Ira; wims@pwg.org
Subject: RE: WIMS> CIM> There is one podssible candidate for EnabledLogicalElement

I was not proposing any analogous property at all, but an empty class with only the method to change the state. What I intend is having a class to represent the function of the property we don't like. And the class has a RequestStateChange() method to effect the function. And the enabled-disabled state of the class shows up in the existing EnabledState property.

This is the *last* thing I would do to the new model, after adding all the other stuff as read-only as we agreed. Or rather, the first thing of the new writable model, the pipe cleaner for putting write functions on various properties.

We have the capability (pardon the expression) today, at least in the model if not in many implementations, to disable console input. If we can model the capability in another way that does not expose a dangerous writable property, that seems like a good thing.

rick

_____

From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
Sent: Thursday, April 19, 2007 15:39
To: Landau, Richard; wims@pwg.org
Subject: RE: WIMS> CIM> There is one podssible candidate for EnabledLogicalElement

Hi,

My two cents - NO - no writable properties at all - no state changing methods
defined in any Phase 2 modelling activity - drop this property entirely or show
it as a read-only boolean in CIM_Printer.

Cheers,
- Ira

-----Original Message-----
From: owner-wims@pwg.org [mailto:owner-wims@pwg.org]On Behalf Of Richard_Landau@Dell.com
Sent: Thursday, April 19, 2007 1:51 PM
To: Richard_Landau@Dell.com; wims@pwg.org
Subject: RE: WIMS> CIM> There is one podssible candidate for EnabledLogicalElement

Actually, I would propose calling the class ConsoleButtons or ConsoleInput. The existing function does not disable the lights or text display, only input from the buttons.

rick

_____

From: owner-wims@pwg.org [mailto:owner-wims@pwg.org] On Behalf Of Richard_Landau@Dell.com
Sent: Thursday, April 19, 2007 13:42
To: wims@pwg.org
Subject: WIMS> CIM> There is one possible candidate for EnabledLogicalElement

Console. Not ConsoleLights or ConsoleDisplayBuffer, but a class with no properties other than state so that it can be enabled and disabled. In the voting spreadsheet from eons ago, we all voted prtGeneralConsoleDisable as priority A. And there is a comment on it that says, "must be implemented as CIM state accessible by RequestStateChange() method." Who would have guessed that we had such foresight way back then.

Proposal: When we get to it, we can use this as a pipe cleaner for CIM modeling of this writable property. I think it results in an otherwise empty class derived directly from EnabledLogicalElement. No new properties, just the state properties and RequestStateChange() method inherited from the parent.

Comments?

rick

----------------------
Richard_Landau(at)dell(dot)com, Stds & System Mgt Architecture, CTO Office
+1-512-728-9023, One Dell Way, RR5-3, MS RR5-09, Round Rock, TX 78682

-- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.5.4/768 - Release Date: 4/19/2007 5:32 AM

-- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.5.5/769 - Release Date: 4/19/2007 5:56 PM

No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.463 / Virus Database: 269.5.9/773 - Release Date: 4/22/2007 8:18 PM

No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.463 / Virus Database: 269.6.1/776 - Release Date: 4/25/2007 12:19 PM

Next message: McDonald, Ira: "WIMS> CIM - Posted OutputTray (25 April 2007)"
Previous message: Richard_Landau@Dell.com: "RE: WIMS> OutputTray - Next Steps"
In reply to: wamwagner@comcast.net: "RE: WIMS> CIM> There is one podssible candidate for EnabledLogicalElement"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

This archive was generated by hypermail 2.1.4 : Wed Apr 25 2007 - 16:03:02 EDT