Harry is quite correct with regard to the PWG process; the outline of requirements is done before the charter. And it was done in November. Perhaps Harry and Cathy are suggesting starting up an associated but different working group than the WBMM; or perhaps a different activity of the group.
I had presented an outline of requirements at the November PWG meeting, and this presentation has been on the PWG site for several months ( ftp://ftp.pwg.org/pub/pwg/wsm/ R&A.ppt and now at ftp://ftp.pwg.org/pub/pwg/wbmm/R <ftp://ftp.pwg.org/pub/pwg/wbmm/R&A.ppt> &A.ppt) Following procedure, the charter draft reflected the objectives to address the expressed requirements. Indeed, the requirements presentation reflected problems statements that had been presented and documented in previous Plenary meetings. The expressed requirements are:
nMFD Web Management
Requirements:
Monitoring
Manufacturer:
n Product service - from central or distributed locations
n Product statistics - information to make product better
n Imaging support service (enterprise or external):
n Usage/costing - Meter reads
n Supplies - just-in-time supplies and maintenance
n Service - automatic alert of problems - keeps customer happy and machine running
n Management:
Manufacturer:
n Product update - send to new code
n Product upgrade - sell additional services and deliver directly to machine
n Imaging support service (enterprise or external):
n Setup change - defaults, server links, address lists
n Constrain usage - encourage timely bill payments, discourage abuse, change authorized users
n
Objectives;
nCompatible with enterprise environments
n Low network traffic impact
n security provisions and policies
n Scalable
n Large enterprise
n Support of many small offices
n Standard yet Flexible
n Transport and format standard
n Content customizable
Features:
n Identification of Device Characteristics
n Model, Manufacturer, Configuration
n Location, Contacts, Administrator
n Objects that can be monitored, current value
n Objects that can be managed, current value
n Date-Time
n Remote programmability (Instructions)
n Specify Objects to be monitored
n Rate of monitoring
n Rate/time of reporting
n Accommodate default sets of Status, Usage and Alert objects
n Reports
n Compatible with Data Base Management
n Human Readable?
Aspects to be Defined
Transport
n Report
n Instruction
n Message format
n Coding
n Compatibility with Data Base Management
n Contents
The document goes on to suggest XML coding, SOAP etc. not as requirements but as suggested parts of a solution. I think it is important to distinguish requirements from solutions. For example, one of Harry's requirements was:
1. More expressive than the Printer MIB
This may be a characteristic of a proposed solution. But what is the problem that is being addressed?
Indeed, my difficulty with Harry's and Cathy's "requirements" are that many seem to be addressing a different problem than Web Based Monitoring and Management of devices and services. They refer to a "new model" and to a MIB replacement, which at this point has not been established as a necessary part of the solution to previously stated requirements. And, quite frankly, requiring these items would be be contradictory to the idea be able to apply Web Based Monitoring and Management to the existing equipment base which is certainly one of my personal requirements. It is quite possible that, in looking at solutions to WBMM requirements, it may be established that the sort of thing that Harry and Cathy are referring to is desirable. But I do not agree that we must start off with the premise that a requirement is to come up with a replacement to MIBs.
I request:
a. comments from more potential participants on the objective of the working group ... is the intent to come up with
a. a MIB replacement and the restructuring of the device model or :
b. a solution to the much more immediate problem of communicating management data (derived from whatever source) over the internet, using the existing infrastructure of the Web?
b. that contributors look at previously stated requirements. It would be more fruitful for all of us to argue the stated requirements rather than to just propose conflicting ones, or to indicate proposed solutions to a requirement (which nominally comes later).
Many thanks.
Bill Wagner
-----Original Message-----
From: MARKLE,CATHY (HP-Boise,ex1) [mailto:cathy_markle at hp.com]
Sent: Thursday, January 30, 2003 7:53 PM
To: 'Harry Lewis'; wbmm at pwg.org
Subject: RE: WBMM> WBMM Requirements
Thanks for the start Harry. I would also like to add some ideas regarding the XML and MIB points you mention.
1. The new model should be structured around how the data is consumed by applications as opposed to how a device is physically built.
2. It should take advantage of XML's ability to describe (and enforce) structure
3. It should be extensible so that vendors can add their own extensions. We should provide a defined path for vendors to provide updates to the model as needed. (Maintenance?)
4. It should be organized in a manner that a group of related data can be accessed all at once.
5. It should take into account other efforts that are happening in other standards areas to leverage learnings in these areas where beneficial and to not cause conflict in overlapping areas whenever possible.
I also think we should address the access protocol.
1. Use SOAP
- SOAP supports both an RPC and document based model.
- Currently, use SOAP over HTTP but it is not limited to this
- WSDL exists to describe SOAP services
- Directory and discovery services exist to support the SOAP protocol (for example UDDI)
- SOAP is also usable by the wide variety of applications that Harry mentions below.
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Thursday, January 30, 2003 5:25 PM
To: wbmm at pwg.org
Subject: WBMM> WBMM Requiements
The PWG process (diagram) acknowlesd Brainstorming, Charter development and Requirments gathering as valid actiities at the origin of a new program. I'd like to begin a requirements thread. Here are requirements of WBMM that I would like to see addressed
1. More expressive than the Printer MIB
- While the Printer MIB is an EXCELLENT standard from the point of view of adoption and functionality... there is room for improvment
- Specifically, we could be more expressive and clearer regarding State, Status and Error reaaons.
- You who are smiling know what I'm talking about (i.e. nix the decoder ring...)
2. Expressed in XML
- More than a clique, XML will aid developers in designing and implementing compliant applicatins with modern tools
3 Usable by a wide variety of applications
- Experience with the Printer MIB has demonstrated that the range of interested applications includes
- Device Management
- Accounting
- Enterprise Managemtn
- Remote Serviceing and Help Desk
- Self configuring Drivers
4. Optomized for interoperatility
- Care should be given to the use of mandatory and optional
- Min/Max access to settable attributes should not be a mystery
- Consider a self describing data model vs. embedding definitions in the protocol
5. More... I'm sure. Please join in...
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20030131/15932ef9/attachment.html