attachment-0001


<br><font size=2 face="sans-serif">I'm glad to see a semi-consensus forming
which seems to say </font>
<br><font size=2 face="sans-serif">1. It would be good to address some
of the scars remaining with the printer MIB as we define a new protocol,
data format etc.</font>
<br><font size=2 face="sans-serif">2. External service agent is a viable
(and very important) target but not the only target (internal is a valid
topic)</font>
<br><font size=2 face="sans-serif">3. We should force ourselves to take
a client view this time around... whereas Printer MIB development was MOSTLY
or completely a device centric view</font>
<br>
<br><font size=2 face="sans-serif">As far as the tail waging the dog...
I agree with Ira... we're not going to have much (any) influence in that
direction. But I also agree with Bob Taylor that we could harm our effort
if we insist on alignment with some external emerging management standard.
Basically I think our xx years of experience with the Printer MIB have
proven there has not been much of a connection between the dog and tail.
I think the alignment should be driven, again, from a client perspective
as appropriate. In otherwords... let's not just try and find a dog to stick
our tail on... but, as we evaluate the solution space, data model, semantics
and protocols in terms of client requirements... if the same big dog is
always in the picture... that would be a good signal to align. </font>
<br><font size=2 face="sans-serif">----------------------------------------------
<br>
Harry Lewis <br>
IBM Printing Systems <br>
---------------------------------------------- </font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;McDonald, Ira&quot; &lt;imcdonald@sharplabs.com&gt;</b></font>
<p><font size=1 face="sans-serif">02/27/2003 08:18 AM</font>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To:
&nbsp; &nbsp; &nbsp; &nbsp;&quot;'TAYLOR,BOB (HP-Vancouver,ex1)'&quot;
&lt;bobt@hp.com&gt;, Harry Lewis/Boulder/IBM@IBMUS, &quot;Wagner,William&quot;
&lt;WWagner@NetSilicon.com&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc:
&nbsp; &nbsp; &nbsp; &nbsp;&quot;'Wbmm (E-mail)&quot; &lt;wbmm@pwg.org&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:
&nbsp; &nbsp; &nbsp; &nbsp;RE: WBMM&gt; RE: Scope and Starting
Point</font></table>
<br>
<br>
<br><font size=2><tt>Hi,<br>
<br>
I agree with all of Bob Taylor's and Harry Lewis's comments<br>
below, except for Bob's comment at (2). &nbsp;I think it's wildly<br>
unlikely that this tail (the printer industry) is going to<br>
wag that dog (the systems management industry).<br>
<br>
I especially like Bob's observation that the &quot;external<br>
service agent&quot; model should NOT be the only design center<br>
for WBMM.<br>
<br>
Please note that the assumption that SNMP is only &quot;internal&quot;<br>
is far out-of-date. &nbsp;SNMPv3 with strong security has been<br>
used by service providers for several years now to manage<br>
routers in their clients' enterprise networks. &nbsp;Now that<br>
SNMPv3 is full Internet Standard and SNMPv1 has been dropped<br>
from the Internet 'standards track' (it's status Historic),<br>
there will be an increasing number of peripheral devices<br>
(like printers) that follow the lead of the infrastructure<br>
devices (because of pressure from customers), I suspect.<br>
<br>
Cheers,<br>
- Ira McDonald<br>
 &nbsp;High North Inc<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: TAYLOR,BOB (HP-Vancouver,ex1) [mailto:bobt@hp.com]<br>
Sent: Wednesday, February 26, 2003 7:39 PM<br>
To: 'Harry Lewis'; Wagner,William<br>
Cc: 'Wbmm (E-mail)<br>
Subject: RE: WBMM&gt; RE: Scope and Starting Point<br>
<br>
<br>
1.a: I don't think we have alignment yet on whether this is for &quot;external&quot;<br>
agents only, or for internal &amp; external. &nbsp;IMHO, if we're going
to the<br>
trouble to define a new protocol/model for &quot;external&quot; that is
going to<br>
eventually cover most of what we use SNMP for internally, I want to be
able<br>
to use it internally as well. &nbsp;We want to be able to leverage, scale
&amp;<br>
distribute tools for management - forcing a completely different protocol<br>
when you cross the firewall makes this really difficult.<br>
1.b: I agree with Harry's comments.<br>
<br>
2: We should at the least be aware of these efforts - and where possible<br>
leverage off of them. &nbsp;I wouldn't, though, delay our progress to align
with<br>
them - and in fact if we make good progress, we may want to push some of
our<br>
ideas into these forums.<br>
<br>
3: I think we need to talk about the kinds of clients that we expect to
use<br>
this. &nbsp;While some may be &quot;browsers&quot;, I certainly expect
this protocol to be<br>
used by dedicated management tools (e.g., WebJetAdmin, etc.) and by<br>
automated systems. &nbsp;If it's just external &quot;browsers&quot; talking
across<br>
firewalls, I'm not sure we need to define any &quot;protocol&quot; at all
- in effect,<br>
your &quot;protocol&quot; is just HTML/Javascript, and an application inside
the<br>
firewall is serving up web content over an HTTPS: connection. &nbsp;It's
only<br>
when you're doing more &quot;programmatic&quot; tools that you really need
a robust<br>
protocol - and though these tools may be accessed through a browser (e.g.,<br>
something running on an app server), the protocols used in these cases
may<br>
not be very browser like - though they may use HTTPS, etc. to get through<br>
firewalls.<br>
<br>
I'll be sending a separate message with an explanation of how I'm thinking<br>
about the problem - as I write this up, I may find more issues and will<br>
bring them up then.<br>
<br>
thanks,<br>
<br>
bt<br>
<br>
---------------------------------------------------<br>
Bob Taylor &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
Senior Architect &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
IPG Strategic Technology Development <br>
Hewlett-Packard Co. &nbsp; &nbsp; &nbsp;<br>
mailto:robertt@vcd.hp.com &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; <br>
phone: 360.212.2625/T212.2625 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; <br>
fax: 208.730-5111 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
--------------------------------------------------- &nbsp; <br>
-----Original Message-----<br>
From: Harry Lewis [mailto:harryl@us.ibm.com]<br>
Sent: Saturday, February 22, 2003 9:57 PM<br>
To: Wagner,William<br>
Cc: 'Wbmm (E-mail)<br>
Subject: RE: WBMM&gt; RE: Scope and Starting Point<br>
<br>
<br>
<br>
1.a. - I agree... but I have a feeling I'm reading more into (&quot;etc.&quot;)
than<br>
you may. You've listed usage, alerts, diagnostics, configuration,<br>
downloading resources, downloading executables (presumably diagnostic or<br>
interrogative in nature) and upgrading (remotely)... there seems to be
very<br>
little remaining that is done via SNMP today... so why not include &quot;the<br>
rest&quot; ... like taking the device off-line, reading or writing the
OpPanel,<br>
... &quot;ETC...&quot;.? <br>
1. b. - Yes, I've expressed several times that I believe we should address<br>
the semantics for device management - just as we've recently done for job<br>
submission and &nbsp;management and we should specifically try to clean
up some<br>
of the toxic waste we spilled in the status area during the early MIB days<br>
(&quot;magic decoder ring&quot;, &quot;agent orange&quot; ). <br>
<br>
2. I think we should make ourselves aware of existing or emerging standards<br>
in the area. I don't think we should force alignment or compliance unless
we<br>
can clearly articulate the benefit and honestly feel there is a very good<br>
chance that alignment will result in adoption. While the Printer MIB is<br>
probably one of the most useful standards ever in terms of heterogeneous<br>
printer management, most of the pretzel twists we encountered to align
with<br>
a larger cause never really achieved the hoped for result (my opinion).
<br>
<br>
I feel we should leverage our own positive model and experience with the<br>
semantic model. No one questions whether SM is the right thing to do. The
SM<br>
springboards from our most recent job protocol... IPP into the web<br>
environment and does facilitate firewall scenarios I view WBMM as doing
the<br>
same thing... springboard off Printer, Finisher MIBs onto web protocols
via<br>
a common (device) semantic model. <br>
<br>
3. We need to nail this firewall discussion early. I do agree that we want<br>
to facilitate solutions that can cross the firewall... similar to the way<br>
we've done PSI. I hear others reacting to this requirement as if it is
an<br>
inappropriate goal. This will drag on and haunt us later if not put to
rest.<br>
<br>
<br>
---------------------------------------------- <br>
Harry Lewis <br>
IBM Printing Systems <br>
---------------------------------------------- <br>
<br>
<br>
&quot;Wagner,William&quot; &lt;WWagner@NetSilicon.com&gt; <br>
Sent by: owner-wbmm@pwg.org <br>
02/20/2003 03:03 PM &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp;To: &nbsp; &nbsp; &nbsp; &nbsp;&quot;'Wbmm
(E-mail)&quot; &lt;wbmm@pwg.org&gt; <br>
 &nbsp; &nbsp; &nbsp; &nbsp;cc: &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp;Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: WBMM&gt;
RE: Scope and Starting Point<br>
<br>
<br>
<br>
<br>
<br>
Bob Tailor had a very good suggestion. &nbsp;&quot;..try to identify the
issues before<br>
[the conference call]<br>
so you might ask that everyone post them to WBMM before the meeting. For<br>
&quot;simple&quot; issues, we may be able to knock them off in email, saving
our phone<br>
time for the more significant/contentious issues.&quot;<br>
<br>
I had intended that sort of thing in asking for comments on the write-up
(or<br>
any other comments that were felt to be germane). But an explicit request<br>
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<br>
imaging devices on an enterprise network, for the purpose of monitoring<br>
usage and alerts, perhaps for doing maintenance tests and general<br>
configuration, and perhaps for downloading files including executables,<br>
fonts, upgrades, etc.<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;a. Do we have agreement
on this?<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;b. Is there a strong
feeing that the scope must be expanded,<br>
and if so, how?<br>
<br>
2. Consideration of the approaches in the documents referenced by Ira,
Lee<br>
and Don (thank you all). Should we embrace, ignore, or possibly extract
some<br>
aspects from which ones?<br>
 My contention is:<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;a. as overall approaches,
all seem to lack the concept of<br>
finessing firewalls<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;b. approaches intended
for managing/configuring networks<br>
miss the problems of an external agent trying to manage devices on the<br>
network. The MIS people want some inherent restrictions on what the external<br>
site can do, and in many cases, want to be able to monitor messages being<br>
sent out to make sure that there is nothing untoward.<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;c. we may however,
want to consider some other aspects of<br>
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<br>
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&gt; RE: Scope and Starting Point<br>
<br>
<br>
3/4 4-5 EST works for me. &nbsp;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 &quot;simple&quot; 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&gt; 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. &nbsp;The document
is<br>
posted to:<br>
ftp://ftp.pwg.org/pub/pwg/wbmm/white/wbmm_Scope&amp;Start.pdf<br>
<br>
I would appreciate some feedback with the objective of finding common ground<br>
within the working group. Would a conference &nbsp;call on 4 March, 4-5
PM EST be<br>
agreeable?<br>
<br>
<br>
<br>
Bill Wagner<br>
</tt></font>
<br>