Elliot,
1. At this point, we have not had much participation. I will put a message out on announce.
2. I have not heard of other problems with the Acrobat file.
3. Certainly, we tend to consider our preconceived solutions to a problem as "requirements". I have been trying to avoid this, to allow perhaps novel solutions to not be eliminated from consideration by the definition of the problem. That being said, I think the likely approach is to parallel PSI, using a similar approach, but designing it for the specific requirements of remote management. Again, my thoughts are that it is much simpler since an enterprise will have arraigned with a particularly facility to do remote management. So general issues of discovery, detailed attribute exchange, data formats, etc, do not need to be addressed. Similarly, the items being managed are not at the same level of detail or completeness as for inter-enterprise management.
As Bob Tailor has just observed, some participants will have are other requirements (e.g., alignment with the new round of IT & management technologies). These need to be identified, considered and either stated as requirements or not. Such requirements will tend to dictate certain solutions.
4. You may be correct about my distinction between the needs of intra- and extra enterprise management not being so clear. I identified the scenarios that I was considering. Things like identification, usage, perhaps more detailed accounting information, low consumables, problem warnings and alerts are important. At this point, I do not wee where detailed printing characteristics and capabilities, default values, etc are important. Although I certainly had no intention of the structure preventing access to such management capability, I do not see where creating a new management model to ease local management is a prerequisite to solving the remote management problem.
5. I fully agree that we need to identify the use cases. And further, that my primary concern with remote management may be just one aspect of an activity that will seek to revamp the entire management approach. And so I again solicit use cases, scenarios, or whatever illustration of what we are trying to define seems appropriate. And perhaps we will need to partition the activity.
I will start with a very simple but real one, names changed to protect the innocent.
Ika, an office equipment leasing company, leases and services printers and copiers from several manufacturers to a wide range of customers. One specific customer is an insurance company, American Casualty Ensurence (ACE). ACE is very concerned with security but also is demanding no more that 0.5% downtime for the equipment. Under different circumstances, Ika would have resident service people checking the equipment, keeping usage figures for billing, and ready to react if a user reported a problem. But because of the security issues, ACE will give service people access only when there is a problem. Security also prevents Ika from access to the ACE network to use standard equipment monitoring programs. Indeed, between traffic and security concerns, ACE does not allow programs using broadcast SNMP to be on its network.
ACE does allow its employees internet access though an HTTP proxy. However, ACE does not allow any other internet access including FTP. ACE will allow Ika to communicate status and usage information using the WEB access structure in place, provided that ACE MIS has the ability to monitor the communication. Nothing that reflects anything about the network or the business can be communicated: this includes IP addresses, device names, and of course, any job information.
Bill Wagner
-----Original Message-----
From: ElliottBradshaw at oaktech.com [mailto:ElliottBradshaw at oaktech.com]
Sent: Friday, February 07, 2003 2:56 PM
To: wbmm at pwg.org
Subject: WBMM> WBMM requirements
I got around to subscribing, and I read the history. (Bill, how many
people have joined? It might be worth a reminder announcement to prod
people who, like me, are interested but haven't got around to it.)
Bill, when I try to read the posted charter I get a complaint from Acrobat
about a missing or corrupted encoding (CMap). Does anyone else have this?
Writing requirements is hard...one man's requirement is another's design.
Based on Bill's original notes, there seem to be end-user use-cases covered
by the "requirements" section and more internal, technology needs covered
in the "objectives" section. This seems to me like a good division. Using
this approach, the discussion of SNMP seems to be mostly in the latter
category.
One reason why some of us gravitate toward thinking about SNMP is that
there is so much overlap in the nature of the technical problem to be
solved (encoding, transport, who-calls-whom), and in the end it would be
very useful to limit the number of schemes that a device needs to support.
Could SNMP be extended to cover the use cases Bill mentions? In some
cases, yes, but the firewall is a big problem. Most of the technical
challenges for connecting clients, servers, services, and devices seem to
me to be parallel to what PSI has already worked through. Could PSI be
extended to handle WBMM use cases? My guess is that it could.
Before we jump into the transport-layer issues for WBMM I'd be intersted in
understanding the use cases better...specifically who calls whom when, and
when do we need intermediate servers. Some sort of message-passing
pseudocode might be worthwhile for the key scenarios. If there is interest
in the group I'll help work this out.
I'm not as convinced as Bill is that there is a black-and-white division
between what internal IT people want (traditionally users of SNMP) vs. what
external service companies would want (target of WBMM). Specifically, it
may be that different vendors will want to draw this line differently. So
again it could be useful to have one infrastructure that can be applied to
both of these situations.
I think we should understand the WBMM use cases in more detail. As a
parallel (and probably separate) effort we should work out a long-term
roadmap that would let SNMP be replaced by one or more XML-based protocols,
perhaps with PSI as a framework. Hopefully these will converge at some
point, but we don't really know yet.
E.
------------------------------------------
Elliott Bradshaw
Director, Software Engineering
Oak Technology Imaging Group
781 638-7534