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
----------------------------------------------
"McDonald, Ira" <imcdonald at sharplabs.com>
Sent by: owner-wims at pwg.org
04/20/2005 09:43 AM
To
"'thrasher at lexmark.com'" <thrasher at lexmark.com>, wims at pwg.org
cc
Subject
RE: RE: WIMS> Counter MIB Last Call Comments
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 at sharplabs.com
-----Original Message-----
From: owner-wims at pwg.org [mailto:owner-wims at pwg.org]On Behalf Of
thrasher at lexmark.com
Sent: Wednesday, April 20, 2005 11:24 AM
To: wims at 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>
"William A Wagner" <wamwagner at comcast.net>
04/18/2005 07:37 PM
To: <thrasher at lexmark.com>, <wims at pwg.org>
cc:
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?
<JT>
The problem I see is that the MIB defies a group for Subunit
counters and there is not companion specification that defines the counts
(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.
any privite subunit counter groups could be included in a private MIB.
<JT>
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.
<JT>
As a way of also addressing the name mapping issue (comment 10), the
description
section of each MIB counter definition could include:
"See [Counter Spec. ref] definition for [Counter Spec Section 4 name]."
<JT>
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.
<JT>
If SNMP and WIMS were the only two Imaging System management protocols,
this
might be an acceptable way to look at, although that creates a very
uncomfortable
dependency of the XML Schema on the MIB. There "may" be other mappings
of these counter definitions to other "legacy" managment protocols that a
WIMS
proxy might need to deal with. As these other mappings are created it
doesn't
make much sense to have to refer to the MIB mapping (because it's first)
to
get the exact detailed counter specification. Either that, or the WIMS
proxy
would have to keep state-type information on each managed device.
<JT>
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.
<JT>
The first "total" being for all services, the second for all alerts...
<JT>
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.
<JT>
But the current description in the MIB does include the sense of channels,
which is the correct (more accurate) definition. We don't want to be
including inter or intra-service data cummunication or transfer
(that's not specifically job related) in these byte counts.
The question about "channels" correct comes in because a channel is
defined
as a subunit, one might want to measure the number of Koctets that
flow in or out of a channel (or through, depending on what's considered
a channel) but these counters get somewhat circular if you try to apply
them.
<JT>
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.
<JT>
see the comment 2 response
<JT>
-----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/20050420/15064422/attachment-0001.html