Hi Rick,
Umm...just so you know, event notification (the SendAlerts operation in the
Agent
Interface and the SubscribeForEvents action in SetSchedule and Execute
Action
in the Manager Interface) has always been part of the current WIMS protocol.
Unlike IPP or PSI, event notification works fine in WIMS.
And WIMS SendReports behaves like SNMPv2/v3 Inform (not an exception, can
carry
lots of data elements).
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
-----Original Message-----
From: Richard_Landau at Dell.com [mailto:Richard_Landau at Dell.com]
Sent: Thursday, June 09, 2005 4:18 PM
To: harryl at us.ibm.com; wamwagner at comcast.net
Cc: imcdonald at sharplabs.com; thrasher at lexmark.com; wims at pwg.org
Subject: RE: Brief minutes from WIMS 8 June 2005
Bill, thanks for the historical perspective. I appreciate that, having been
away from this business for a few (apparently interesting) years.
My questions really stemmed from two fundamental concerns. (I will write
real requirements later at some length.)
1. I found it very difficult to grasp the document as it stands. I came
away with the impression that only scheduled operations are supported, and I
think that anyone but the most serious reader would make similar mistakes.
Introductory information that describes usage models and message exchange
sequences would be very helpful in this regard.
2. I appreciate the need for a fleet management protocol, but not to the
exclusion of other, simpler models. Two years ago when WIMS was conceived
and written, web services were exotic and heavyweight. No longer true. Web
services will be the new SNMP, eventually, in endpoint devices. They will
be just another transport mechanism for the same management information in
the device.
Didn't early SNMP specs talk about proxy implementations? I haven't seen
any new SNMP proxy implementations lately. Web services will follow the
same path: there will be early proxy implementations to front for legacy
devices, but they will migrate into endpoint devices -- and much more
quickly than SNMP did.
I would like to see the WIMS model *extended*, not changed, to embrace
modest groups of printers/MFDs managed from within, which is still a much
more common deployment in our experience. To support that model, I think we
need to consider extensions such as polled management, event notification,
service advertising, and resource discovery. Scheduled,
reverse-communications (benign Trojan horse) operations suitable for fleet
management can be entirely layered on top of such a simpler model, I
believe.
Enough tirade for one day. I apologize for its length.
I cannot make the call this coming Wed., 6/15, sorry; out of town.
rick
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Wednesday, June 08, 2005 22:59
To: wamwagner at comcast.net
Cc: McDonald, Ira; Landau, Richard; thrasher at lexmark.com; wims at pwg.org
Subject: Re: Brief minutes from WIMS 8 June 2005
Excellent response, Bill. I agree with getting the current Counter Spec (and
WIMS... if possible) to CS w/o too much perturbation and building (into
Enterprise mgt) from there... UNLESS... someone has some powerhouse
recommendations that generate a great deal of new interest.
----------------------------------------------
Harry Lewis
IBM STSM
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems
http://www.ibm.com/printers
303-924-5337
----------------------------------------------
wamwagner at comcast.net
06/08/2005 05:46 PM To"McDonald, Ira" <imcdonald at sharplabs.com>, Harry
Lewis/Boulder/IBM at IBMUS, "McDonald, Ira" <imcdonald at sharplabs.com>,
thrasher at lexmark.com, Richard_Landau at Dell.comccwims at pwg.org
SubjectRe: Brief minutes from WIMS 8 June 2005
Rick's questions are interesting, and to an extent reflect the sort of
capability that HP wanted to include in WIMS, before they withdrew.
The answers to the questions are quite simply that WIMS was intended for
fleet management, and was specifically aimed at increasing the efficiency
and potential market of companies like Danka and Ikon (and the service arms
of several MFD manufacturers), which account for a vast number of
multifuntion products in place today. Indeed, it appears that most small and
midsized companies and indeed many large enterprises do not buy or maintain
MFD products with internal resources.
It was recognized that some of the capabilities included in WIMS would be
useful for enterprise level management as well, and some features were added
to support this application. With HPs sudden withdrawal from what had been
active participation, the remaining members of the WG decided to concentrate
on the original scope.
If Dell or any other companies would like to expand the WIMS scope, I am
sure the WG would be happy to support this. However, I want to follow
through with the objective of getting the basic WIMS ideas in some
recoverable form, probably a candidate specification. The additional
features could be addressed by a subsequent document.
It has turned out that, for whatever reason, we have been unable to get
active participation from those companies that would most directly benifit
from WIMS. On the other hand, manufacturers appear more interested in
pursuing private solutions with the intent of locking customers into using
their products. It would seem that a company that sold products OEM'ed from
multiple manufacturers would prefer a standard solution. At any rate, it is
with the belief that a standard means of facilitating third-party fleet
management is needed and that this need will be recognized eventually that
we wanted to document the fleed-management WIMS.
Because third-party fleet management concerns are not generally trusted
with anything except the minimum information necessary to bill and maintain
their equipment, many of the features that an enterprise management
capability would want would need to be disabled for third-party fleet
management.
In direct answer to Rick's questions:
(1) Why is the WIMS Protocol only explained in terms of the
> Schedule and fleet management / firewall traversal?
- In facilitating third party management, particularly for small sites,
the intent was to utilize the existing network facilities and require a
minimum installation activity. The approach taken was to use existing web
access capability (with whatever protection the site normally provides for).
- The schedule approach reflects the premise that all communication is to be
initiated by from the site. This supports both the use of an unaltered web
access facility at the side, and the requirement that the site retains
control over what what the manager has access to.
>> (2) Why isn't there a second top-level diagram showing the use
> of WIMS _within_ an enterprise, specifically _without_ a
> proxy (i.e., small network of WIMS-capable imaging systems)?
-This was one of the scenarios that was proposed by HP. See
ftp://ftp.pwg.org/pub/pwg/wbmm/white/Use_Cases_7.pdf, the basis for a
requirements document, but now almost two years old. In refocusing the spec
to the original intent, the operations that might be desirable to support
this mode were dropped. Perhaps we should also have dropped any reference to
the use of WIMS for internal management, but it was felt that WIMS does
include features useful for this mode as well.
>> (3) For WIMS within an enterprise, the model of direct admin
> preconfiguration of lots of WIMS Agents doesn't work.
- WIMS specifically did not include either service advertizing or discovery.
The third party fleet model, such capabilities would be a security risk. The
intent was that the right to obtain information from a service must be
initiated at the site; indeed, all communication must be initiated from the
site. For internal management, other protocols exist to allow discovery. SLP
and LDAP might be good choices. UPNP would seem to be inapplicable.
>> (3a) What protocols for service advertising (SLP, UPnP)
> should a WIMS Agent use?
>> (3b) What protocols for service discovery (SNMP Ping, LDAP,
> DNS-SD, UDDI) should a WIMS Manager use?
>> (4) How can a WIMS Manager immediately begin management of a
> WIMS Agent (i.e., where is the Management Interface operation
> 'BeginManagement')?
- Again, the premise is that a manager cannot begin management of a device
until that device has directly or indirectly (through a proxy) granted the
manager that right.
Bill Wagner, Chairman, WIMS
-------------- Original message --------------
> Hi,
>> [This just _bounced_ from 'wims at pwg.org' - huh?]
>> Only Rick Landau (Dell) and I called in today. While we waited
> for ephemeral others, Rick asked some questions about the WIMS
> Protocol itself:
>> (1) Why is the WIMS Protocol only explained in terms of the
> Schedule and fleet management / firewall traversal?
>> (2) Why isn't there a second top-level diagram showing the use
> of WIMS _within_ an enterprise, specifically _without_ a
> proxy (i.e., small network of WIMS-capable imaging systems)?
>> (3) For WIMS within an enterprise, the model of direct admin
> preconfiguration of lots of WIMS Agents doesn't work.
>> (3a) What protocols for service advertising (SLP, UPnP)
> should a W! IMS Agent use?
>> (3b) What protocols for service discovery (SNMP Ping, LDAP,
> DNS-SD, UDDI) should a WIMS Manager use?
>> (4) How can a WIMS Manager immediately begin management of a
> WIMS Agent (i.e., where is the Management Interface operation
> 'BeginManagement')?
> (This assumes that an LDAP or Kerberos user identity (e.g.)
> already exists for both the WIMS Manager and WIMS Agent.)
>> Good questions that need clear answers in the spec.
>> I'd like to note that Rick feels that Dell wouldn't consider
> deployment of WIMS for enterprise service management based on
> the Schedule-centric fleet management operations sequences.
>> Rick volunteered to write paragraphs describing solutions to
> some of the above questions for addition to the spec. At present,
> Rick can't volunteer to be the principal editor of the WIMS spec.
> > In the interests of encouraging actual deployment of WIMS, I
> agree with Rick that the spec should support both models
> (enterprise and fleet management)?
>> Same time next week - Wednesday 15 June
>> Call-in US Toll-free: 1-866-365-4406
> Call-in International/Toll: 1-303-248-9655
> Participant Identification number: 2635888#
>> Cheers,
> - Ira
>>> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221 Grand Marais, MI 49839
> phone: +1-906-494-2434
> email: imcdonald at sharplabs.com>> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221 Grand Marais, MI 49839
> phone: +1-906-494-2434
> email: imcdonald at sharplabs.com>> -----Original Message-----
> From: Harry Lewis [mailto:harryl at us.ibm.com]
> Sent: Wednesday, June 08, 2005 3:33 PM
> To: imcdonald at shar! plabs.com; thrasher at lexmark.com;
wamwagner at comcast.net;
>Richard_Landau at Dell.com> Subject: Sorry I missed WIMS call today - will be available next week
>>>> Sorry, after posting my warning to you folks... I ended up in a strategic
> customer briefing that I just could not escape from.
> I have had to postpone my vacation for business reasons which should make
me
> available for a call on the 15th (I'd previously begged off that one).
> Was there a call today? Minutes?
> ----------------------------------------------
> Harry Lewis
> IBM STSM
> Chairman - IEEE-ISTO Printer Working Group
>http://www.pwg.org> IBM Printing Systems
>http://www.ibm.com/printers> 303-924-5337
> ----------------------------------------------