WIMS> RE: Brief minutes from WIMS 8 June 2005

WIMS> RE: Brief minutes from WIMS 8 June 2005

Richard_Landau at Dell.com Richard_Landau at Dell.com
Mon Jun 13 12:18:13 EDT 2005


Bill, et al., 
 
Thanks again for more clarifications.  Glad to hear that we're all much
on the same page.  I look forward to contributing to making progress on
all these fronts.  
 
rick

  _____  

From: wamwagner at comcast.net [mailto:wamwagner at comcast.net] 
Sent: Friday, June 10, 2005 19:24
To: Landau, Richard; harryl at us.ibm.com
Cc: imcdonald at sharplabs.com; thrasher at lexmark.com; wims at pwg.org
Subject: Re: WIMS> RE: Brief minutes from WIMS 8 June 2005


Rick,
 
Your comments are very valuable, not just because of your extensive
knowledge of the industry but because a prospective user can see
problems that those of us close to the project do not see.
 
As Ira has pointed out, the ExecuteAction operation in the Manager
Interface does allow for a manager to initiate an immediate action,
without a schedule. Although the same thing can be done with a
SetSchedule operation with the execute timing set to immediate, the
ExecuteAction operation was considered simpler.
 We do need to do a major cleanup on the
ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wims10-20050322rev.doc draft, but
it does include  use models and interaction diagrams. Some more specific
help on where these fail would be appreciated.
 
We too understand that Web Services has advanced greatly since we
started WIMS. We had spent some looking at what was being worked on
before we started, and it seemed that WEB Based enterprise management ,
in general, was indeed being addressed.  We felt that an activity that
addressed fleet management in combination with the development of a
management model for multifunction devices expressible in XML, which was
necessary for any Web based management, would be useful. I think that
remains true, although we may be not satisfactorily addressing this.
 
And we certainly agree with you comment on proxies.
 
I would like to try and wrap up the counter spec as soon as possible so
that we can get on with WIMS protocol, and perhaps an extension to WIMS
protocol. I hope you, and others, will continue to contribute to this
effort.
 
Bill Wagner, WIMS Chariman
 
-------------- Original message -------------- 


	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.com 
cc
wims at pwg.org 
Subject
Re: 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
<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 
	> ---------------------------------------------- 
	

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20050613/f9201e6e/attachment-0001.html


More information about the Wims mailing list