Bill,
I disagree that things like discovery do not need to be addressed. Many
companies do not know how many printers exist in their environment. So a
discovery would be useful to a remote management company. I can see another
scenario where a rogue employee in company X buys a printer that the company
does not know about. I would expect that if company Y has been contracted
to manage all of the devices on the site that at least company X would want
to be made aware of the new device so that it can now be managed, gotten rid
of, etc.
Cathy
-----Original Message-----
From: Wagner,William [mailto:WWagner@NetSilicon.com]
Sent: Monday, February 10, 2003 1:18 PM
To: ElliottBradshaw@oaktech.com; wbmm@pwg.org
Subject: RE: WBMM> WBMM requirements
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@oaktech.com [mailto:ElliottBradshaw@oaktech.com]
Sent: Friday, February 07, 2003 2:56 PM
To: wbmm@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
This archive was generated by hypermail 2b29 : Mon Feb 10 2003 - 15:43:42 EST