attachment


<br><font size=2 face="sans-serif">Interop has been our key goal, but efficiency
is also a legitimate concern. I'm not sure the focus should be limited
to SNMP... as we have put a great deal of effort into evolving a common
semantic model and new, web-services based approaches to imaging service
and device management. In either case, an Implementer's Guide would be
helpful and I'm happy to see you volunteer to play a role. </font>
<br>
<br><font size=2 face="sans-serif">Paul, I recommend you structure a short
presentation outlining the problem space and potential solutions and plan
to present at the April (5/6) PWG meeting which will be hosted by Oki in
Mt. Laurel, NJ. If you cannot be there in person, Ron or I will be happy
to deliver the presentation. I will arrange a time slot for a BOF as part
of the PWG Plenary (or separately). </font>
<br><font size=2 face="sans-serif">----------------------------------------------
<br>
Harry Lewis <br>
IBM STSM<br>
Chairman - IEEE-ISTO Printer Working Group<br>
http://www.pwg.org<br>
IBM Printing Systems <br>
http://www.ibm.com/printers<br>
303-924-5337<br>
---------------------------------------------- </font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>&quot;Paul Tykodi&quot;
&lt;ptykodi@tykodi.com&gt;</b> </font>
<br><font size=1 face="sans-serif">Sent by: pmp-owner@pwg.org</font>
<p><font size=1 face="sans-serif">02/15/2006 07:13 AM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
&lt;ptykodi@tykodi.com&gt;</font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">&lt;pmp@pwg.org&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">RE: Feedback - PMP&gt; Minutes of the
MFP Teleconference 20060214</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Hi Ira,<br>
<br>
I am willing to be a co-editor for such a project. Is this something the
PWG<br>
would likely want to pursue in the near term future?<br>
<br>
Thanks.<br>
<br>
Best Regards,<br>
<br>
/Paul<br>
--<br>
Paul Tykodi<br>
Principal Consultant<br>
TCS - Tykodi Consulting Services LLC<br>
<br>
Tel/Fax: 603-343-1820<br>
Mobile: &nbsp;603-866-0712<br>
E-mail: &nbsp;ptykodi@tykodi.com<br>
WWW: &nbsp; &nbsp; http://www.tykodi.com<br>
<br>
-----Original Message-----<br>
From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org] On Behalf Of McDonald,<br>
Ira<br>
Sent: Wednesday, February 15, 2006 1:06 AM<br>
To: 'ptykodi@tykodi.com'; pmp@pwg.org<br>
Subject: RE: Feedback - PMP&gt; Minutes of the MFP Teleconference 20060214<br>
<br>
Hi Paul,<br>
<br>
Harry Lewis (IBM, chair of PWG) has repeatedly suggested that a<br>
good project would be a PWG standard &quot;Printer MIB Implementor's<br>
Guide&quot; - similar in purpose and scope to the IETF Proposed Std<br>
&quot;IPP/1.1 Implementor's Guide&quot; (RFC 3196, November 2001).<br>
<br>
Volunteer PWG editor bandwidth is the problem - that and the very<br>
complicated problem space of SNMP optimization biased by MIB<br>
optimization biased by the fact that printers (and spoolers) are<br>
supposed to &quot;print first and bother me later&quot;.<br>
<br>
A first step was that Printer MIB v2 (RFC 3805) contained a great<br>
many improved DESCRIPTION clauses that clarified and recommended<br>
implementation choices for many of the columnar objects.<br>
<br>
But the problem you've identified is a whole system problem, not<br>
just a Printer MIB implementation problem.<br>
<br>
Cheers,<br>
- Ira (co-editor of Printer MIB v2)<br>
<br>
Ira McDonald (Musician / Software Architect)<br>
Blue Roof Music / High North Inc<br>
PO Box 221 &nbsp;Grand Marais, MI &nbsp;49839<br>
phone: +1-906-494-2434<br>
email: imcdonald@sharplabs.com<br>
 <br>
-----Original Message-----<br>
From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf Of Paul Tykodi<br>
Sent: Tuesday, February 14, 2006 10:50 PM<br>
To: pmp@pwg.org<br>
Subject: RE: Feedback - PMP&gt; Minutes of the MFP Teleconference 20060214<br>
<br>
<br>
Dear Bill,<br>
 <br>
The host I was most recently analyzing was an IBM iSeries - AS/400 host.
The<br>
MIB itself worked flawlessly. I am not suggesting that it was somehow the<br>
culprit for the slow printing or that it did not work correctly. The<br>
communication started OK and then the host was concerned that a response<br>
packet was not received in a timely fashion. It began a significant SNMP<br>
based questioning process to determine the current hardware status of the<br>
device and interspersed with the SNMP questions about whether the device
was<br>
in error or not came a re-transmission of a potentially lost packet just
to<br>
be safe.<br>
 <br>
Pretty soon the majority of the communication on the wire revolved around<br>
SNMP discussions as to the device's status and data packet re-transmissions<br>
and confirmations from the printing device that it had indeed received
the<br>
packet re-transmissions. As you mention, the whole idea of printing<br>
information had become unfortunately a secondary concern.<br>
 <br>
In the end, all of the data was printed and no errors were reported by
the<br>
host. Unfortunately the method utilized to determine that everything was<br>
actually fine was so intrusive on the printing process that I feel<br>
comfortable saying I believe that a typical customer (having paid a fee
for<br>
their printing device related to its rated engine performance) would<br>
probably not have accepted the result as commercially viable.<br>
 <br>
So my previous comment is directed more towards device managing software<br>
product's use of MIB capabilities (especially if more interesting things
to<br>
check are added into future MIB's) and the impact that significant device<br>
status verifications can have on the actual process (in this case printing),<br>
which is being monitored.<br>
 <br>
Thus in the future if some type of RFC or other standards document were
to<br>
be produced, my suggestion would be to include some examples that tried
to<br>
help steer software developers implementing use of MIB data away from<br>
creating the issue you outline in point b. below.<br>
 <br>
Thanks.<br>
 <br>
Best Regards,<br>
 <br>
/Paul<br>
--<br>
Paul Tykodi<br>
Principal Consultant<br>
TCS - Tykodi Consulting Services LLC<br>
<br>
Tel/Fax: 603-343-1820<br>
Mobile: &nbsp;603-866-0712<br>
E-mail: &nbsp;ptykodi@tykodi.com<br>
WWW: &nbsp;http://www.tykodi.com<br>
<br>
<br>
<br>
From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org] On Behalf Of<br>
wamwagner@comcast.net<br>
Sent: Tuesday, February 14, 2006 10:33 PM<br>
To: ptykodi@tykodi.com; pmp@pwg.org<br>
Cc: Paul Tykodi<br>
Subject: RE: Feedback - PMP&gt; Minutes of the MFP Teleconference 20060214<br>
 <br>
Paul,<br>
 <br>
Thanks for sending in your observation. I have worked with printers and
SNMP<br>
management for many years and have not seen anything like the sort of<br>
slowdown that you cite. Perhaps this is because I have worked with slower<br>
machines and printers/MFPs with separate NICs. At any rate, a basic SNMP<br>
tenet is that servicing of SNMP is secondary to the main purpose of the<br>
device. Indeed, reflecting this, I have seen missed or late SNMP responses<br>
during periods of high print activity.<br>
 <br>
Of course, it is desirable to have efficient MIBs, something that sometimes<br>
gets lost in this era of &quot;human readability&quot;. Although you may
have<br>
contradicting data, I would suggest that the current public MIBs are not
in<br>
themselves inefficient and that the problem you observed may be due to
other<br>
factors such as:<br>
a. &nbsp; &nbsp; &nbsp; certain private MIBS use an indirect addressing
approach,<br>
particularly for writes, which may make for some elegance but does<br>
complicate interaction<br>
b. &nbsp; &nbsp; &nbsp;many management applications are terribly inefficient,
repeatedly<br>
querying the same (sometimes status) variable, and often unnecessarily<br>
dumping blocks of data.<br>
c. &nbsp; &nbsp; &nbsp; Drastically underpowered controllers and/or poor
handling of<br>
priorities<br>
 <br>
Although I understand that it may be difficult to release such information,<br>
it would be useful to have some information on the specifics of the<br>
slow-down... the condition the management station was querying, the objects<br>
being queried, etc.<br>
 <br>
Bill Wagner, TIC<br>
 <br>
-------------- Original message -------------- <br>
From: &quot;Paul Tykodi&quot; &lt;ptykodi@tykodi.com&gt; <br>
Dear List,<br>
 <br>
During the last year, I have been involved in some network analysis looking<br>
at how certain hosts use the current printer MIB to determine device status<br>
(including that of MFP's) and what effect a significant number of SNMP<br>
queries and responses can have on effective printing throughput (at times<br>
rather dramatic reduction in achievable throughput).<br>
 <br>
In looking at the minutes from today's meeting, I would suggest that it<br>
might be a good idea to consider whether MIB optimization should be a<br>
category for an MFP alerts project. The idea would be to at least minimally<br>
describe some best practices for MIB usage, which would result in the host<br>
obtaining the required information using the smallest SNMP query and<br>
response packet transmission overhead possible.<br>
 <br>
In case people are wondering how dramatic a reduction in PPM I have observed<br>
when SNMP traffic is significant (host trying to determine whether device
is<br>
in error or not - multiple queries are sent asking more and more specific<br>
questions of the printer MIB), I have seen printers and MFP's with rated<br>
speeds in the 75 - 125 PPM range reduced to achieving actual throughput
in<br>
the 10 to 20 PPM range.<br>
 <br>
HTH<br>
 <br>
Best Regards,<br>
 <br>
/Paul<br>
--<br>
Paul Tykodi<br>
Principal Consultant<br>
TCS - Tykodi Consulting Services LLC<br>
<br>
Tel/Fax: 603-343-1820<br>
Mobile: &nbsp;603-866-0712<br>
E-mail: &nbsp;ptykodi@tykodi.com<br>
WWW: &nbsp;http://www.tykodi.com<br>
<br>
<br>
<br>
From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org] On Behalf Of Bergman,
Ron<br>
Sent: Tuesday, February 14, 2006 7:02 PM<br>
To: pmp@pwg.org<br>
Subject: PMP&gt; Minutes of the MFP Teleconference 20060214<br>
 <br>
The minutes can be found at: <br>
 &nbsp; &nbsp; &nbsp; &nbsp;ftp://ftp.pwg.org/pub/pwg/pmp/minutes/mfp/MFP_Minutes_20060214.pdf
<br>
Ron Bergman <br>
Chairman, Printer MIBs Working Group <br>
<br>
</font></tt>
<br>