attachment-0001
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4923.2500" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=876212801-27022003><FONT face="Courier New" color=#0000ff
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=876212801-27022003><FONT face="Courier New" color=#0000ff
size=2>1.b: I agree with Harry's comments.</FONT></SPAN></DIV>
<DIV><SPAN class=876212801-27022003><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=876212801-27022003><FONT face="Courier New" color=#0000ff
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=876212801-27022003><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=876212801-27022003><FONT face="Courier New" color=#0000ff
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=876212801-27022003><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=876212801-27022003><FONT face="Courier New" color=#0000ff
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=876212801-27022003><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=876212801-27022003><FONT face="Courier New" color=#0000ff
size=2>thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=876212801-27022003><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=876212801-27022003><FONT face="Courier New" color=#0000ff
size=2>bt</FONT></SPAN></DIV>
<DIV><SPAN class=876212801-27022003><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=876212801-27022003>
<P><FONT size=2>---------------------------------------------------<BR>Bob
Taylor <BR>Senior
Architect <BR>IPG
Strategic Technology Development <BR>Hewlett-Packard
Co. <BR><A
href="mailto:robertt@vcd.hp.com">mailto:robertt@vcd.hp.com</A> <BR>phone:
360.212.2625/T212.2625 <BR>fax:
208.730-5111 <BR>---------------------------------------------------
</FONT></P></SPAN></DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Harry Lewis
[mailto:harryl@us.ibm.com]<BR><B>Sent:</B> Saturday, February 22, 2003 9:57
PM<BR><B>To:</B> Wagner,William<BR><B>Cc:</B> 'Wbmm
(E-mail)<BR><B>Subject:</B> RE: WBMM> RE: Scope and Starting
Point<BR><BR></FONT></DIV><BR><FONT face=sans-serif size=2>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...".?</FONT> <BR><FONT
face=sans-serif size=2>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" ).</FONT>
<BR><BR><FONT face=sans-serif size=2>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). </FONT><BR><BR><FONT face=sans-serif size=2>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. </FONT><BR><BR><FONT face=sans-serif size=2>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.
</FONT><BR><BR><FONT face=sans-serif
size=2>---------------------------------------------- <BR>Harry Lewis <BR>IBM
Printing Systems <BR>----------------------------------------------
</FONT><BR><BR><BR>
<TABLE width="100%">
<TBODY>
<TR vAlign=top>
<TD>
<TD><FONT face=sans-serif size=1><B>"Wagner,William"
<WWagner@NetSilicon.com></B></FONT> <BR><FONT face=sans-serif
size=1>Sent by: owner-wbmm@pwg.org</FONT>
<P><FONT face=sans-serif size=1>02/20/2003 03:03 PM</FONT> </P>
<TD><FONT face=Arial size=1> </FONT><BR><FONT
face=sans-serif size=1> To:
"'Wbmm (E-mail)" <wbmm@pwg.org></FONT> <BR><FONT
face=sans-serif size=1> cc:
</FONT> <BR><FONT face=sans-serif size=1>
Subject: RE: WBMM> RE: Scope
and Starting Point</FONT></TR></TBODY></TABLE><BR><BR><BR><FONT
size=2><TT><BR><BR>Bob Tailor had a very good suggestion. "..try to
identify the issues before [the conference call]<BR>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."<BR><BR>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.<BR><BR>Please
forward your issues to the list!<BR><BR>Lets start with a few that I
see.<BR><BR>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.<BR> a.
Do we have agreement on this?<BR>
b. Is there a strong feeing that the scope must be expanded, and
if so, how?<BR><BR>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?<BR> My
contention is:<BR> a.
as overall approaches, all seem to lack the concept of finessing
firewalls<BR> 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.<BR>
c. we may however, want to consider some other aspects of the other
approaches. Perhaps the coding or the notion of XML coded RPCs.<BR><BR>3. Is
there general agreement on the use of HTTP clients operating in a Browser-like
mode as the mechanism to finesse firewall?<BR><BR>Please feel free to add
issues!<BR><BR>Many thanks,<BR><BR>Bill
Wagner/NetSilicon<BR><BR><BR><BR>-----Original Message-----<BR>From:
TAYLOR,BOB (HP-Vancouver,ex1) [mailto:bobt@hp.com]<BR>Sent: Thursday, February
20, 2003 3:49 PM<BR>To: Wagner,William<BR>Subject: FW: WBMM> RE: Scope and
Starting Point<BR><BR><BR>3/4 4-5 EST works for me. One suggestion:
Given that you only are<BR>allocating one hour, it might be good to try to
identify the issues before<BR>then, so you might ask that everyone post them
to WBMM before the meeting.<BR>For "simple" issues, we may be able to knock
them off in email, saving our<BR>phone time for the more
significant/contentious issues.<BR><BR>bt<BR><BR>-----Original
Message-----<BR>From: Wagner,William [mailto:WWagner@NetSilicon.com]<BR>Sent:
Wednesday, February 19, 2003 6:11 PM<BR>To: wbmm@pwg.org<BR>Subject: WBMM>
RE: Scope and Starting Point<BR><BR><BR><BR><BR>Greetings:<BR><BR>I have
attached some thoughts on the use cases the WBMM should be<BR>addressing, and
taken a cut at defining a starting point. The document is<BR>posted
to:<BR>ftp://ftp.pwg.org/pub/pwg/wbmm/white/wbmm_Scope&Start.pdf<BR><BR>I
would appreciate some feedback with the objective of finding common
ground<BR>within the working group. Would a conference call on 4 March,
4-5 PM EST be<BR>agreeable?<BR><BR><BR><BR>Bill
Wagner<BR></TT></FONT><BR></BLOCKQUOTE></BODY></HTML>