attachment-0001

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