Well... I feel the scope was ever constrained to "leasing and service"
although I agree this is included. An intranet capable solution does not
necessarily exclude service probes across the firewall! Don't know why the
effort will be "horrendous". We have SNMP and CIM models to begin with and
experienced parties offering requirements to guide the effort (such as
Cathy's suggestion that data be modeled according to application use vs
device implementation). Perhaps, in this recommendation, lies the
crossroad between what you are articulating (remote service applications)
and others (full fledged device management).
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"Wagner,William" <WWagner at NetSilicon.com>
01/31/2003 12:28 PM
To: Harry Lewis/Boulder/IBM at IBMUS
cc: "MARKLE,CATHY (HP-Boise,ex1)" <cathy_markle at hp.com>,
<wbmm at pwg.org>
Subject: RE: WBMM> WBMM Requirements
I guess the truncation was only with Microsoft Outlook.
Harry,
My ...surprise rather than frustration... is because several of the recent
"requirements" have increased the scope of this effort (and apparently
changed the purpose) to an extreme level. I recognize the fact that
presentations at Plenary and postings to the web site may not get much
attention... indeed it is apparent that the plenary minutes aren't looked
at either. But over the past four months, I identified a very specific
problem, I provided examples of that problem and required characteristics
of a solution. This problem was communicating management information over
the internet. I have given examples, real examples not fabricated
scenarios, of how this is a problem to manufacturers and to leasing
companies. This is a very real need; and multiple companies are addressing
the need in different and sometimes incompatible ways.
I agree that it may be reasonable to consider a requirement that the
solution be applicable to intranet management as well. But to impose the
perceived requirements of full capability intra-enterprise device and
service management on the much different characteristics of
extra-enterprise monitoring and management is to create a horrendous
task. Intra-enterprise wants detailed control to the last nit; it is
probably intended for human consumption. Extra enterprise is typically
interested in a much smaller setof management capability, it needs to
contend with firewalls and proxies, and the consumer is probably a data
base program. There can and should be commonality, but the main thrust is
different.
It seemed to me that PWG member companies doing leasing and service would
like an effective, consistent internet access solution. It seemed that
companies selling equipment might consider a feature making their
equipment more attractive to large purchasers a good selling point. If
that is not the case, I am sure that NetSilicon (as a random example)
would be just as happy offering proprietary solutions.
As you suggest, we need to see where the interest is, if there is any in
either area.
William A. Wagner (Bill Wagner)
Director of Technology
Imaging Division
NETsilicon, Inc.
781-398-4588
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Friday, January 31, 2003 12:57 PM
To: Wagner,William
Cc: MARKLE,CATHY (HP-Boise,ex1); wbmm at pwg.org
Subject: RE: WBMM> WBMM Requirements
Bill, actually the PWG process shows Brainstorming, Chartering and
Requirements gathering all occurring simultaneously at the beginning of a
new project (see chart at end of process doc). In the prose they are (of
natural consequence) ordered. We do seem to be "butting heads" somewhat
and I sense your frustration with what seems to you like a late response
but I think any standards process must acknowledge inherent drag,
especially at the start up phase. Everyone doesn't always come "off the
blocks" exactly when the gun is fired and not at the same pace. Or...
maybe we're all still gathering at the blocks and warming up?
I commend you, Bill, for taking the initiative to actually issue the first
documents to get the ball rolling. But, until recently, there was not a
whole lot of discussion. At this stage, if the discussion that (finally)
issues... seems to be shaping the charter and requirements differently
than you first imagined... I don't think it's appropriate to point to the
initial documents as De fide. I suggest the discussion is the valuable
part at this stage.
Yes, discussion need to ultimately map back to clarifications, mods etc.
to your initial charter and reqs docs. I'm eager to help with that.
Honestly, everything you cite these docs as contrary to the recent
threads... I can never see your point. I review the discussion and review
your docs and I see alignment (albeit further endeavor to describe and
quantify).
Example, w.r.t. my suggested requirement that we be more expressive than
SNMP you ask what is the problem being addressed and I tried to make that
clear along with my request by giving the example of the "magic decoder
ring" relationship between MIB-II, HRMIB and Printer MIB!
We agree totally on the desire to have more participation from a wider
audience.
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"Wagner,William" <WWagner at NetSilicon.com>
Sent by: owner-wbmm at pwg.org
01/31/2003 10:09 AM
To: <wbmm at pwg.org>
cc: "MARKLE,CATHY (HP-Boise,ex1)" <cathy_markle at hp.com>,
Harry Lewis/Boulder/IBM at IBMUS
Subject: RE: WBMM> WBMM Requirements
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&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/9a8876f3/attachment-0001.html