WBMM> WBMM Requirements

WBMM> WBMM Requirements

WBMM> WBMM Requirements

Harry Lewis harryl at us.ibm.com
Fri Jan 31 12:56:36 EST 2003


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/7e24792b/attachment-0001.html


More information about the Wims mailing list