attachment

<!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 6.00.2800.1491" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=359394415-20042005><FONT face=Arial color=#0000ff 
size=4>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=359394415-20042005><FONT face=Arial color=#0000ff 
size=4></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=359394415-20042005><FONT face=Arial color=#0000ff size=4>I 
someone who was at the meeting going to write up 
minutes/comments?</FONT></SPAN></DIV>
<DIV><SPAN class=359394415-20042005><FONT face=Arial color=#0000ff 
size=4></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=359394415-20042005><FONT face=Arial color=#0000ff 
size=4>Otherwise, it's going to be hard to respond to them.</FONT></SPAN></DIV>
<DIV><SPAN class=359394415-20042005><FONT face=Arial color=#0000ff 
size=4></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=359394415-20042005><FONT face=Arial color=#0000ff size=4>I'm 
gone for the rest of today.&nbsp; Talk to you folks 
tomorrow.</FONT></SPAN></DIV>
<DIV><SPAN class=359394415-20042005><FONT face=Arial color=#0000ff 
size=4></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=359394415-20042005><FONT face=Arial color=#0000ff 
size=4>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=359394415-20042005><FONT face=Arial color=#0000ff size=4>- 
Ira</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT size=2>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</FONT> </P>
<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> owner-wims@pwg.org 
  [mailto:owner-wims@pwg.org]<B>On Behalf Of 
  </B>thrasher@lexmark.com<BR><B>Sent:</B> Wednesday, April 20, 2005 11:24 
  AM<BR><B>To:</B> wims@pwg.org<BR><B>Subject:</B> RE:RE: WIMS&gt; Counter MIB 
  Last Call Comments<BR><BR></FONT></DIV><BR><FONT face=sans-serif 
  size=2>&lt;JT&gt;</FONT> <BR><FONT face=sans-serif size=2>The comments are not 
  a summary of the F2F meeting, althought there may be some overlap 
  between</FONT> <BR><FONT face=sans-serif size=2>these and comments I made at 
  the F2F that got recorded..</FONT> <BR><BR><FONT face=sans-serif 
  size=2>Responses Inline: </FONT><BR><FONT face=sans-serif size=2>&lt;JT&gt; 
  </FONT><BR><BR><BR>
  <TABLE width="100%">
    <TBODY>
    <TR vAlign=top>
      <TD>
      <TD><FONT face=sans-serif size=1><B>"William A Wagner" 
        &lt;wamwagner@comcast.net&gt;</B></FONT> 
        <P><FONT face=sans-serif size=1>04/18/2005 07:37 PM</FONT> <BR></P>
      <TD><FONT face=Arial size=1>&nbsp; &nbsp; &nbsp; &nbsp; </FONT><BR><FONT 
        face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; 
        &nbsp; &nbsp;&lt;thrasher@lexmark.com&gt;, &lt;wims@pwg.org&gt;</FONT> 
        <BR><FONT face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; 
        &nbsp; &nbsp; &nbsp;</FONT> <BR><FONT face=sans-serif size=1>&nbsp; 
        &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: WIMS&gt; 
        Counter MIB Last Call Comments</FONT></TR></TBODY></TABLE><BR><BR><BR><FONT 
  size=2><TT>Jerry,<BR></TT></FONT><BR><BR><BR><FONT size=2><TT>Thanks for the 
  comments, but please indicate if these are your comments,<BR>comments made 
  during the face-to-face, or comments sent to 
  you.<BR></TT></FONT><BR><BR><BR><FONT size=2><TT>I agree with Ira that most of 
  these comments refer to the Counter Spec,<BR>especially considering his 
  decision to remove any definitions from the<BR>Counter MIB and just reference 
  the Counter Spec. I also I suspect that most<BR>users will assume that they 
  understand the terminology and will not look at<BR>the 
  spec.<BR></TT></FONT><BR><BR><BR><FONT size=2><TT>I solicit comments on the 
  comments. &nbsp;The intent is to have a conference call<BR>on Wednesday, 27 
  April, at 12 noon Eastern Daylight Time to discuss these<BR>issues and any 
  others that come up relative to the Counter MIB and the<BR>Counter 
  Spec.<BR></TT></FONT><BR><BR><BR><FONT size=2><TT>My comments 
  follow:<BR></TT></FONT><BR><BR><BR><FONT size=2><TT>1. &nbsp; &nbsp; &nbsp; 
  &nbsp;It has been stated that the Counter MIB is intended to address in 
  an<BR>ASN.1 context the abstract counters defined in the Counter Spec. 
  Thgerefore<BR>any counter not specified in the Counter Spec can not be 
  included in the<BR>Counter MIB. The solutions are therefore either to 
  eliminate such counters<BR>from the MIB, or to allow the MIB to define 
  counters that are not explicitly<BR>defined in the Counter Spec. However, the 
  counter Spec essentially defines<BR>types of counters in Section 4 rather than 
  explicit counters. Section 5<BR>indicates which counter types are applicable 
  to which service. Therefore,<BR>one could maintain that &nbsp;the MIB could 
  include a counter type as defined in<BR>the Counter Spec, but applied to a 
  physical division (e.g., device or<BR>subunit) defined by some other document. 
  Discussion?</TT></FONT> <BR><BR><BR><FONT size=2><TT>&lt;JT&gt;</TT></FONT> 
  <BR><FONT size=2><TT>The problem I see is that the MIB defies a group for 
  Subunit</TT></FONT> <BR><FONT size=2><TT>counters and there is not companion 
  specification that defines the counts</TT></FONT> <BR><FONT size=2><TT>(from 
  the Counter Spec. or other) that are applicable or required. 
  </TT></FONT><BR><FONT size=2><TT>If/when there is a "Standard for Imaging 
  System Subunit Counters" defined, </TT></FONT><BR><FONT size=2><TT>then the 
  MIB would include this group. Until there is a subunit spec.</TT></FONT> 
  <BR><FONT size=2><TT>any privite subunit counter groups could be included in a 
  private MIB.</TT></FONT> <BR><FONT size=2><TT>&lt;JT&gt;</TT></FONT> 
  <BR><BR><FONT size=2><TT><BR>2.<BR></TT></FONT><BR><FONT size=2><TT>a. &nbsp; 
  &nbsp; &nbsp; &nbsp;Ira has stated that counters will not be defined in both 
  the Counter<BR>Spec and the Counter MIB. &nbsp;The MIB will refer to the Spec 
  for the conceptual<BR>definition of any counter in the MIB which corresponds 
  to a counter defined<BR>in the Spec.</TT></FONT> <BR><BR><FONT 
  size=2><TT>&lt;JT&gt;</TT></FONT> <BR><FONT size=2><TT>As a way of also 
  addressing the name mapping issue (comment 10), the description</TT></FONT> 
  <BR><FONT size=2><TT>section of each MIB counter definition could 
  include:</TT></FONT> <BR><BR><FONT size=2><TT>"See [Counter Spec. ref] 
  definition for [Counter Spec Section 4 name]."</TT></FONT> <BR><FONT 
  size=2><TT>&lt;JT&gt;</TT></FONT> <BR><BR><FONT size=2><TT><BR>b. &nbsp; 
  &nbsp; &nbsp; &nbsp;Although the Counter Spec may explicitly define and state 
  the<BR>"units" of each counter, I question &nbsp;whether it should include the 
  "initial,<BR>reset value and it's "rollover" value (i.e. how many bits, signed 
  or<BR>unsigned)", &nbsp;these specifics being more appropriate to the MIB or 
  &nbsp;XML<BR>Schema "mapped" counters. The question of retaining consistent 
  precision and<BR>maximum value when a proxy translates between MIB objects and 
  Schema<BR>elements is a valid concern. However, note that counters are all 
  read-only.<BR>Therefore, &nbsp;if the XML &nbsp;schema does not define a 
  larger maximum vale than<BR>the MIB, there should be no problem.</TT></FONT> 
  <BR><BR><FONT size=2><TT>&lt;JT&gt;</TT></FONT> <BR><FONT size=2><TT>If SNMP 
  and WIMS were the only two Imaging System management protocols, 
  this</TT></FONT> <BR><FONT size=2><TT>might be an acceptable way to look at, 
  although that creates a very uncomfortable</TT></FONT> <BR><FONT 
  size=2><TT>dependency of the XML Schema on the MIB. &nbsp;There "may" be other 
  mappings</TT></FONT> <BR><FONT size=2><TT>of these counter definitions to 
  other "legacy" managment protocols that a WIMS</TT></FONT> <BR><FONT 
  size=2><TT>proxy might need to deal with. As these other mappings are created 
  it doesn't</TT></FONT> <BR><FONT size=2><TT>make much sense to have to refer 
  to the MIB mapping (because it's first) to</TT></FONT> <BR><FONT 
  size=2><TT>get the exact detailed counter specification. Either that, or the 
  WIMS proxy</TT></FONT> <BR><FONT size=2><TT>would have to keep state-type 
  information on each managed device.</TT></FONT> <BR><FONT 
  size=2><TT>&lt;JT&gt; <BR></TT></FONT><BR><FONT 
  size=2><TT>3.<BR></TT></FONT><BR><FONT size=2><TT>a. &nbsp; &nbsp; &nbsp; 
  &nbsp;Line 405: OK<BR>b. &nbsp; &nbsp; &nbsp; &nbsp;Line 417: "units" was used 
  here as a replacement for parameter<BR>(meaning a characteristic element, 
  according to Merriam-Webster), but Ira<BR>does not like the term. Obviously, 
  "units" is confusing, so we go back to<BR>"counters", which apparently is less 
  confusing. Thus it now &nbsp;reads "This<BR>element contains the system-wide 
  counters aggregate that total like counters<BR>in all supported 
  services."<BR></TT></FONT><BR><FONT size=2><TT>4. &nbsp; &nbsp; &nbsp; 
  &nbsp;OK<BR>5. &nbsp; &nbsp; &nbsp; &nbsp;OK. But it will result in a 
  SystemTotals.Monitoring.Total Alerts<BR>element. That is, "total" in 
  SystemTotals has the sense of summing over all<BR>services.</TT></FONT> 
  <BR><BR><FONT size=2><TT>&lt;JT&gt;</TT></FONT> <BR><FONT size=2><TT>The first 
  "total" being for all services, the second for all alerts...</TT></FONT> 
  <BR><FONT size=2><TT>&lt;JT&gt;</TT></FONT> <BR><BR><FONT size=2><TT>6. &nbsp; 
  &nbsp; &nbsp; &nbsp;OK</TT></FONT> <BR><FONT size=2><TT><BR>7. &nbsp; &nbsp; 
  &nbsp; &nbsp;I do not see the conflict. The Spec has no sense of 
  &nbsp;channels, but<BR>defines the KOctets counters as accumulating the "The 
  total amount of ..<BR>data in integral units of 1024 octets" &nbsp;That would 
  seem to include data over<BR>all channels.</TT></FONT> <BR><BR><FONT 
  size=2><TT>&lt;JT&gt;</TT></FONT> <BR><FONT size=2><TT>But the current 
  description in the MIB does include the sense of channels,</TT></FONT> 
  <BR><FONT size=2><TT>which is the correct (more accurate) definition. &nbsp;We 
  don't want to be</TT></FONT> <BR><FONT size=2><TT>including inter or 
  intra-service data cummunication or transfer </TT></FONT><BR><FONT 
  size=2><TT>(that's not specifically job related) in these byte 
  counts.</TT></FONT> <BR><BR><FONT size=2><TT>The question about "channels" 
  correct comes in because a channel is defined</TT></FONT> <BR><FONT 
  size=2><TT>as a subunit, one might want to measure the number of Koctets 
  that</TT></FONT> <BR><FONT size=2><TT>flow in or out of a channel (or through, 
  depending on what's considered</TT></FONT> <BR><FONT size=2><TT>a channel) but 
  these counters get somewhat circular if you try to apply them.</TT></FONT> 
  <BR><FONT size=2><TT>&lt;JT&gt;</TT></FONT> <BR><BR><BR><FONT 
  size=2><TT><BR>8. &nbsp; &nbsp; &nbsp; &nbsp;Ira had argued that Messages 
  should go under "Monitoring" rather<BR>than "Job". So he may want to change 
  the MIB.</TT></FONT> <BR><BR><FONT size=2><TT><BR>9. &nbsp; &nbsp; &nbsp; 
  &nbsp;OK</TT></FONT> <BR><FONT size=2><TT><BR>10. &nbsp; &nbsp; &nbsp; &nbsp;I 
  agree that following the mapping of counter names from the spec to<BR>the MIB 
  is open to confusion. There are two mechanisms: Ira indicated that<BR>the 
  additional terms in the MIB names &nbsp;(e.g., traffic) &nbsp; were needed 
  because<BR>of MIB &nbsp;format requirements. However, note that the counter 
  names in Section<BR>4 are not explicit in that they do not refer to actual 
  counters but rather<BR>types of counters. The actual counters need the service 
  name (or<BR>SystemTotals) prefix.<BR></TT></FONT><BR><FONT 
  size=2><TT>&lt;JT&gt;</TT></FONT> <BR><FONT size=2><TT>&nbsp;see the comment 2 
  response</TT></FONT> <BR><FONT size=2><TT>&lt;JT&gt;</TT></FONT> <BR><BR><FONT 
  size=2><TT><BR></TT></FONT><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><FONT 
  size=2><TT>-----Original Message-----<BR>From: owner-wims@pwg.org 
  [mailto:owner-wims@pwg.org] On Behalf Of<BR>thrasher@lexmark.com<BR>Sent: 
  Monday, April 18, 2005 3:57 PM<BR>To: wims@pwg.org<BR>Subject: WIMS&gt; 
  Counter MIB Last Call Comments<BR></TT></FONT><BR><BR><BR><BR><FONT 
  size=2><TT>1. Counter MIB.<BR>Counter Spec. Page 11 Line 388,389. states that 
  usage counters for devices<BR>and subunits are NOT being addressed. &nbsp;This 
  being the case the MIB should<BR>not include subunit counter definition 
  language for subunits at this time<BR>until the counters can be reviewed as to 
  there applicability to the specific<BR>subunits that have been defined and new 
  counters defined, if needed, to<BR>address specific subunits.<BR>(e.g. how can 
  Monitoring.CompletedFinisherJobs apply to anything but a<BR>finisher subunit, 
  how does the concept of a Job apply to the channel<BR>subunit, the inputTray 
  subunit or any subunits other than possibly the<BR>interpreter and transformer 
  subunits.)<BR></TT></FONT><BR><FONT size=2><TT>2.Counter Spec.<BR>The 
  definitions for each counter should include definitions that are 
  one,<BR>consistent with any repeated language in the Counter MIB descriptions, 
  and<BR>two completely specify the attributes of the counter. The Counter 
  Spec.<BR>should explicitely define and state the "units" of each count as well 
  as the<BR>initial, reset value and it's "rollover" value (i.e. how many bits, 
  signed<BR>or unsigned).<BR>Example case of a WIMS proxy that's proxying two 
  agents, one implementing<BR>the Counter MIB (with mostly 32 bit counters) and 
  one with another<BR>management protocol binding that uses either 16 bit or 64 
  bit<BR>counters....does the WIMS proxy manage the rollover cases when 
  relaying<BR>information to the WIMS manager....???<BR></TT></FONT><BR><FONT 
  size=2><TT>3. Counter Spec. Page 12 Line 405, grammer error in sentence. 
  Line<BR>417,sentence should read that counters aggregate the totals of like 
  counters<BR>with like units....<BR></TT></FONT><BR><FONT size=2><TT>4. Counter 
  Spec. Page 17, grammer error in first sentence 
  of<BR>Datastream.BlankImpressions, FCImpressions and 
  HCImpressions<BR>definitions.....(use not uses).<BR></TT></FONT><BR><FONT 
  size=2><TT>5. Counter Spec. or MIB. Page 22 Monitoring table: 
  Monitoring.Alerts.....The<BR>MIB named it 
  &nbsp;Monitoring.TotalAlerts.....seems more accurate.<BR></TT></FONT><BR><FONT 
  size=2><TT>6. Counter Spec. Page 14, Line 436, word miss-spelled in sentence 
  (should be<BR>"sum" not "sub").<BR></TT></FONT><BR><FONT size=2><TT>7. Counter 
  Spec. Page 16, Definition of Job.InputKOctets and OutputKOctets<BR>does not 
  match that of the Counter MIB. &nbsp;The Counter 
  MIB's<BR>TrafficJobInputKOctets restricts the definition to data 
  &nbsp;recieved over ALL<BR>channels. (which is defined as a subunit)....not 
  sure either is correct.<BR></TT></FONT><BR><FONT size=2><TT>8. Counter 
  Spec./MIB...The counter MIB defines TrafficJobInputMessages 
  and<BR>TrafficJobOutputMessages..the Counter Spec. does not, but does 
  define<BR>Monitoring.InputMessages and 
  Monitoring.Outputs.<BR></TT></FONT><BR><FONT size=2><TT>9. Counter Spec. lists 
  JobInputMessages and JobOutputMessages in 5.3, 5.4,<BR>5.5, 5.6, 5,7 and 5.8. 
  (should be MonitoringInputMessages).<BR></TT></FONT><BR><FONT size=2><TT>10. 
  Counter MIB. The counter MIB needs to explicitly map its naming (or 
  name<BR>modification/shortening) of counters to the explicit names in 
  the<BR>definitions in Section 4 of the Counter Spec.</TT></FONT> 
  <BR><BR><BR><BR></BLOCKQUOTE></BODY></HTML>