WBMM> WBMM Requirements

WBMM> WBMM Requirements

WBMM> WBMM Requirements

Harry Lewis harryl at us.ibm.com
Fri Jan 31 14:53:31 EST 2003


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


More information about the Wims mailing list