C-0001.htm

<html> <head> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 10 (filtered)"> <style>  </style> </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> Jerry,   Thanks for the comments, but please indicate if these are your comments, comments made during the face-to-face, or comments sent to you.   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.   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.   My comments follow:   <ol start=1 type=1> <li class=MsoNormal style='color:navy'>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?</li> <li class=MsoNormal style='color:navy'> </li> <ol start=1 type=a> <li class=MsoNormal style='color:navy'>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.</li> <li class=MsoNormal style='color:navy'>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.</li> </ol> <li class=MsoNormal style='color:navy'> </li> <ol start=1 type=a> <li class=MsoNormal style='color:navy'>Line 405: OK</li> <li class=MsoNormal style='color:navy'>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.”</li> </ol> <li class=MsoNormal style='color:navy'>OK</li> <li class=MsoNormal style='color:navy'>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. </li> <li class=MsoNormal style='color:navy'>OK</li> <li class=MsoNormal style='color:navy'>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.</li> <li class=MsoNormal style='color:navy'>Ira had argued that Messages should go under “Monitoring” rather than “Job”. So he may want to change the MIB.</li> <li class=MsoNormal style='color:navy'>OK</li> <li class=MsoNormal style='color:navy'>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. </li> </ol>   Bill Wagner           -----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   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.) 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....??? 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.... 4. Counter Spec. Page 17, grammer error in first sentence of Datastream.BlankImpressions, FCImpressions and HCImpressions definitions.....(use not uses). 5. Counter Spec. or MIB. Page 22 Monitoring table: Monitoring.Alerts.....The MIB named it  Monitoring.TotalAlerts.....seems more accurate. 6. Counter Spec. Page 14, Line 436, word miss-spelled in sentence (should be "sum" not "sub"). 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. 8. Counter Spec./MIB...The counter MIB defines TrafficJobInputMessages and TrafficJobOutputMessages..the Counter Spec. does not, but does define Monitoring.InputMessages and Monitoring.Outputs. 9. Counter Spec. lists JobInputMessages and JobOutputMessages in 5.3, 5.4, 5.5, 5.6, 5,7 and 5.8. (should be MonitoringInputMessages). 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. </div> </body> </html>