Hi,
Fair warning to those who haven't opened Bill's note yet.
By the way, Nancy and I are moving home to the northwoods next week,
so there's a fair chance I won't be able to make this telecon - I'll do my
best.
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 at sharplabs.com
-----Original Message-----
From: owner-wims at pwg.org [mailto:owner-wims at pwg.org]On Behalf Of William A
Wagner
Sent: Monday, April 18, 2005 7:37 PM
To: thrasher at lexmark.com; wims at pwg.org
Subject: RE: WIMS> Counter MIB Last Call Comments
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:
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?
2.
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.
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.
3.
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."
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.
6. OK
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.
8. Ira had argued that Messages should go under "Monitoring" rather
than "Job". So he may want to change the MIB.
9. OK
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.
Bill Wagner
-----Original Message-----
From: owner-wims at pwg.org [mailto:owner-wims at pwg.org] On Behalf Of
thrasher at lexmark.com
Sent: Monday, April 18, 2005 3:57 PM
To: wims at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20050419/f76bfc21/attachment-0001.html