attachment

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"> <META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD> <BODY> <DIV> </DIV> <DIV>I guess the truncation was only with Microsoft Outlook.</DIV> <DIV> </DIV> <DIV>Harry, </DIV> <DIV> </DIV> <DIV>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. </DIV> <DIV> </DIV> <DIV>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. </DIV> <DIV> </DIV> <DIV> </DIV> <DIV>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.</DIV> <DIV> </DIV> <DIV>As you suggest, we need to see where the interest is, if there is any in either area.</DIV> <DIV> </DIV> William A. Wagner (Bill Wagner) Director of Technology Imaging Division NETsilicon, Inc. 781-398-4588 <BLOCKQUOTE> <DIV class=OutlookMessageHeader dir=ltr align=left>-----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, January 31, 2003 12:57 PM To: Wagner,William Cc: MARKLE,CATHY (HP-Boise,ex1); wbmm@pwg.org Subject: RE: WBMM> WBMM Requirements </DIV> 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 ---------------------------------------------- <TABLE width="100%"> <TBODY> <TR vAlign=top> <TD> <TD>"Wagner,William" <WWagner@NetSilicon.com> Sent by: owner-wbmm@pwg.org 01/31/2003 10:09 AM <TD>                To:        <wbmm@pwg.org>         cc:        "MARKLE,CATHY (HP-Boise,ex1)" <cathy_markle@hp.com>, Harry Lewis/Boulder/IBM@IBMUS         Subject:        RE: WBMM> WBMM Requirements</TR></TBODY></TABLE> 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 <A href="ftp://ftp.pwg.org/pub/pwg/wbmm/R&A.ppt">ftp://ftp.pwg.org/pub/pwg/wbmm/R&A.ppt</A>)    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@hp.com] Sent: Thursday, January 30, 2003 7:53 PM To: 'Harry Lewis'; wbmm@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@us.ibm.com] Sent: Thursday, January 30, 2003 5:25 PM To: wbmm@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 ---------------------------------------------- </BLOCKQUOTE></BODY></HTML>