WBMM> RE: Scope and Starting Point

WBMM> RE: Scope and Starting Point

Wagner,William WWagner at NetSilicon.com
Thu Feb 27 12:01:36 EST 2003


We are getting the input that the "external service agent" model should NOT be the only design center
for WBMM.

I request that those taking this position be more specific, to come up with use cases and requirements. Certainly, if we can define what is desired in a more positive way and there is consensus, that can be added to the WBMM objectives. But, as I have observed, the requirements and constraints for the internal and external model are very different, and in many cases contradictory. If indeed, these two models can be accommodated by a single solution, there must be a firm 'constraint' capability defined, as well as (possible) different transports identified. 

Bob comments "While some [clients} may be "browsers", I certainly expect this protocol to be used by dedicated management tools (e.g., WebJetAdmin, etc.) and by automated systems." Again, I appear to have failed in my description, because my contention is that;
	a. the imaging devices or their proxies appear as browsers (and I understand that Ira objects to this)
	b. the data collection entity (which I termed the monitor) is a server, and is a dedicated, automated data collection machine

Under this, WBMM would not be concerned with direct human interface at any point. The human interface, if there is one, is provided as a application taking information from the monitor and making it available to users. This could be via a web site, via email messages, via invoices for equipment utilization, or whatever...but it is out of scope of the WBMM effort.

Again, if others in the group see a different requirement, please be more specific.

Many thanks.

Bill Wagner

-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Thursday, February 27, 2003 10:18 AM
To: 'TAYLOR,BOB (HP-Vancouver,ex1)'; 'Harry Lewis'; Wagner,William
Cc: 'Wbmm (E-mail)
Subject: RE: WBMM> RE: Scope and Starting Point


Hi,

I agree with all of Bob Taylor's and Harry Lewis's comments
below, except for Bob's comment at (2).  I think it's wildly
unlikely that this tail (the printer industry) is going to
wag that dog (the systems management industry).

I especially like Bob's observation that the "external
service agent" model should NOT be the only design center
for WBMM.

Please note that the assumption that SNMP is only "internal"
is far out-of-date.  SNMPv3 with strong security has been
used by service providers for several years now to manage
routers in their clients' enterprise networks.  Now that
SNMPv3 is full Internet Standard and SNMPv1 has been dropped
from the Internet 'standards track' (it's status Historic),
there will be an increasing number of peripheral devices
(like printers) that follow the lead of the infrastructure
devices (because of pressure from customers), I suspect.

Cheers,
- Ira McDonald
  High North Inc



-----Original Message-----
From: TAYLOR,BOB (HP-Vancouver,ex1) [mailto:bobt at hp.com]
Sent: Wednesday, February 26, 2003 7:39 PM
To: 'Harry Lewis'; Wagner,William
Cc: 'Wbmm (E-mail)
Subject: RE: WBMM> RE: Scope and Starting Point


1.a: I don't think we have alignment yet on whether this is for "external"
agents only, or for internal & external.  IMHO, if we're going to the
trouble to define a new protocol/model for "external" that is going to
eventually cover most of what we use SNMP for internally, I want to be able
to use it internally as well.  We want to be able to leverage, scale &
distribute tools for management - forcing a completely different protocol
when you cross the firewall makes this really difficult.
1.b: I agree with Harry's comments.

2: We should at the least be aware of these efforts - and where possible
leverage off of them.  I wouldn't, though, delay our progress to align with
them - and in fact if we make good progress, we may want to push some of our
ideas into these forums.

3: I think we need to talk about the kinds of clients that we expect to use
this.  While some may be "browsers", I certainly expect this protocol to be
used by dedicated management tools (e.g., WebJetAdmin, etc.) and by
automated systems.  If it's just external "browsers" talking across
firewalls, I'm not sure we need to define any "protocol" at all - in effect,
your "protocol" is just HTML/Javascript, and an application inside the
firewall is serving up web content over an HTTPS: connection.  It's only
when you're doing more "programmatic" tools that you really need a robust
protocol - and though these tools may be accessed through a browser (e.g.,
something running on an app server), the protocols used in these cases may
not be very browser like - though they may use HTTPS, etc. to get through
firewalls.

I'll be sending a separate message with an explanation of how I'm thinking
about the problem - as I write this up, I may find more issues and will
bring them up then.

thanks,

bt

---------------------------------------------------
Bob Taylor                                       
Senior Architect                           
IPG Strategic Technology Development 
Hewlett-Packard Co.      
mailto:robertt at vcd.hp.com                       
phone: 360.212.2625/T212.2625                   
fax: 208.730-5111                
---------------------------------------------------   
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Saturday, February 22, 2003 9:57 PM
To: Wagner,William
Cc: 'Wbmm (E-mail)
Subject: RE: WBMM> RE: Scope and Starting Point



1.a. - I agree... but I have a feeling I'm reading more into ("etc.") than
you may. You've listed usage, alerts, diagnostics, configuration,
downloading resources, downloading executables (presumably diagnostic or
interrogative in nature) and upgrading (remotely)... there seems to be very
little remaining that is done via SNMP today... so why not include "the
rest" ... like taking the device off-line, reading or writing the OpPanel,
... "ETC...".? 
1. b. - Yes, I've expressed several times that I believe we should address
the semantics for device management - just as we've recently done for job
submission and  management and we should specifically try to clean up some
of the toxic waste we spilled in the status area during the early MIB days
("magic decoder ring", "agent orange" ). 

2. I think we should make ourselves aware of existing or emerging standards
in the area. I don't think we should force alignment or compliance unless we
can clearly articulate the benefit and honestly feel there is a very good
chance that alignment will result in adoption. While the Printer MIB is
probably one of the most useful standards ever in terms of heterogeneous
printer management, most of the pretzel twists we encountered to align with
a larger cause never really achieved the hoped for result (my opinion). 

I feel we should leverage our own positive model and experience with the
semantic model. No one questions whether SM is the right thing to do. The SM
springboards from our most recent job protocol... IPP into the web
environment and does facilitate firewall scenarios I view WBMM as doing the
same thing... springboard off Printer, Finisher MIBs onto web protocols via
a common (device) semantic model. 

3. We need to nail this firewall discussion early. I do agree that we want
to facilitate solutions that can cross the firewall... similar to the way
we've done PSI. I hear others reacting to this requirement as if it is an
inappropriate goal. This will drag on and haunt us later if not put to rest.


---------------------------------------------- 
Harry Lewis 
IBM Printing Systems 
---------------------------------------------- 


"Wagner,William" <WWagner at NetSilicon.com> 
Sent by: owner-wbmm at pwg.org 
02/20/2003 03:03 PM         
        To:        "'Wbmm (E-mail)" <wbmm at pwg.org> 
        cc:         
        Subject:        RE: WBMM> RE: Scope and Starting Point





Bob Tailor had a very good suggestion.  "..try to identify the issues before
[the conference call]
so you might ask that everyone post them to WBMM before the meeting. For
"simple" issues, we may be able to knock them off in email, saving our phone
time for the more significant/contentious issues."

I had intended that sort of thing in asking for comments on the write-up (or
any other comments that were felt to be germane). But an explicit request
may be more fruitful.

Please forward your issues to the list!

Lets start with a few that I see.

1. Basic purpose: I have defined it as access by an external agent to
imaging devices on an enterprise network, for the purpose of monitoring
usage and alerts, perhaps for doing maintenance tests and general
configuration, and perhaps for downloading files including executables,
fonts, upgrades, etc.
                a. Do we have agreement on this?
                b. Is there a strong feeing that the scope must be expanded,
and if so, how?

2. Consideration of the approaches in the documents referenced by Ira, Lee
and Don (thank you all). Should we embrace, ignore, or possibly extract some
aspects from which ones?
 My contention is:
                a. as overall approaches, all seem to lack the concept of
finessing firewalls
                b. approaches intended for managing/configuring networks
miss the problems of an external agent trying to manage devices on the
network. The MIS people want some inherent restrictions on what the external
site can do, and in many cases, want to be able to monitor messages being
sent out to make sure that there is nothing untoward.
                c. we may however, want to consider some other aspects of
the other approaches. Perhaps the coding or the notion of XML coded RPCs.

3. Is there general agreement on the use of HTTP clients operating in a
Browser-like mode as the mechanism to finesse firewall?

Please feel free to add issues!

Many thanks,

Bill Wagner/NetSilicon



-----Original Message-----
From: TAYLOR,BOB (HP-Vancouver,ex1) [mailto:bobt at hp.com]
Sent: Thursday, February 20, 2003 3:49 PM
To: Wagner,William
Subject: FW: WBMM> RE: Scope and Starting Point


3/4 4-5 EST works for me.  One suggestion: Given that you only are
allocating one hour, it might be good to try to identify the issues before
then, so you might ask that everyone post them to WBMM before the meeting.
For "simple" issues, we may be able to knock them off in email, saving our
phone time for the more significant/contentious issues.

bt

-----Original Message-----
From: Wagner,William [mailto:WWagner at NetSilicon.com]
Sent: Wednesday, February 19, 2003 6:11 PM
To: wbmm at pwg.org
Subject: WBMM> RE: Scope and Starting Point




Greetings:

I have attached some thoughts on the use cases the WBMM should be
addressing, and taken a cut at defining a starting point.  The document is
posted to:
ftp://ftp.pwg.org/pub/pwg/wbmm/white/wbmm_Scope&Start.pdf

I would appreciate some feedback with the objective of finding common ground
within the working group. Would a conference  call on 4 March, 4-5 PM EST be
agreeable?



Bill Wagner



More information about the Wims mailing list