Hi folks, Wednesday (16 January 2008)
[For review tomorrow at our regular WIMS-CIM telecon]
Below are: (a) updated DESCRIPTIONS for several Counter MIB objects; and
(b) Bill Wagner's comments that led to these updates, with my replies.
ACTION:
All - please read every DESCRIPTION in the Counter MIB carefully (not
just the handful revised in January) - this document will shortly enter
PWG Last Call to span the PWG face-to-face meeting in February.
Cheers,
- Ira
--
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
------------------------------------------------------------------------
[updated MIB objects]
(1) sysUpTime versus hrSystemUptime - multiple mappings?
- correct spelling of hrSystemUptime throughout MIB
icTimeTotalSeconds
- correct spelling of hrSystemUptime in Usage
- replace Usage paragraph in DESCRIPTION clause with:
Usage: Total time may be mapped from values of hrSystemUptime
in Host Resources MIB (RFC2790) or sysUpTime in MIB-II
(RFC 1213), but these 32-bit tick (1/100th second) counters can
roll over in 15 months, so an agent MUST account for roll over.
If implemented, hrSystemUptime (main system running time) SHOULD
be used instead of sysUpTime (SNMP Agent running time), to avoid
undetected roll over or restart discontinuities.
icTimeDownSeconds
- correct spelling of hrSystemUptime in Usage
- append to end of Usage paragraph in DESCRIPTION clause:
If implemented, hrSystemUptime (main system running time) SHOULD
be used instead of sysUpTime (SNMP Agent running time), to avoid
undetected roll over or restart discontinuities.
icTimeMaintenanceSeconds
- correct spelling of hrSystemUptime in Usage
- append to end of Usage paragraph in DESCRIPTION clause:
If implemented, hrSystemUptime (main system running time) SHOULD
be used instead of sysUpTime (SNMP Agent running time), to avoid
undetected roll over or restart discontinuities.
icTimeProcessingSeconds
- correct spelling of hrSystemUptime in Usage
- append to end of Usage paragraph in DESCRIPTION clause:
If implemented, hrSystemUptime (main system running time) SHOULD
be used instead of sysUpTime (SNMP Agent running time), to avoid
undetected roll over or restart discontinuities.
(2) Memory allocation warnings - misuse of Usage - not a mapping
icMonitorMemoryAllocWarnings
- replace erroneous Usage paragraph in DESCRIPTION clause with:
Note: This counter is intended to support increasing available
memory on an Imaging System before job failures occur. At this
time, there is no support for detection of memory allocation
warnings (as opposed to errors) in any IETF standards-track MIB,
except for the generic 'subunitRecoverableFailure(29)' value
of PrtAlertCodeTC defined in the IANA Printer MIB (originally
published in RFC 3805)."
(3) Storage allocation warnings - misuse of Usage - not a mapping
icMonitorStorageAllocWarnings
- replace erroneous Usage paragraph in DESCRIPTION clause with:
Note: This counter is intended to support increasing available
storage on an Imaging System before job failures occur. At this
time, there is no support for detection of storage allocation
warnings (as opposed to errors) in any IETF standards-track MIB,
except for the generic 'subunitRecoverableFailure(29)' value
of PrtAlertCodeTC defined in the IANA Printer MIB (originally
published in RFC 3805)."
(4) Packets and Messages - not equivalent
icTrafficInputMessages
- delete erroneous REFERENCE clause entirely
- replace erroneous Usage paragraph in DESCRIPTION clause with:
Note: At this time, there is no support for counting input
messages (instead of packets) in any IETF standards-track MIB.
A single application protocol request or response message may be
composed of one or more network protocol packets."
icTrafficOutputMessages
- delete erroneous REFERENCE clause entirely
- replace erroneous Usage paragraph in DESCRIPTION clause with:
Note: At this time, there is no support for counting output
messages (instead of packets) in any IETF standards-track MIB.
A single application protocol request or response message may be
composed of one or more network protocol packets."
------------------------------------------------------------------------
[Bill Wagner's comments on Wednesday 9 January]
I have a few comments on Ira's changes, and some questions. It appears
that the change marking of items in the MIB itself were lost, so my
comments are on the text of the changed items rather than the changes
per se.
1. Usage information for all times gives three possible derivation
sources. I would be happier if just sysUpTime were referenced because I
expect any networked device will include this object, and it would be
better to have a consistent correlation.
<ira>
Discussed during telecon Thursday 10 January - in fact, sysUpTime is a
bad choice for service monitoring - see new DESCRIPTION clause above.
</ira>
2. The usage description for icMonitorMemoryAllocWarnings, taken cold,
seems a bit off.
"Usage: This counter is intended to support increasing available
memory on an Imaging System before job failures occur."
If a usage comment is needed at all, I would suggest something like:
"Usage: This counter provides a measure the safety margin in
memory capacity, to indicate that inadequate Imaging System memory
capacity should be increased before job failures occur."
<ira>
Discussed during telecon Thursday 10 January - for both warnings, term
"Usage" will be replaced by "Note" (as elsewhere in MIB) - there are NO
standard public MIB mappings for source of these two counters.
</ira>
3. A similar comment with regard to icMonitorStorageAllocWarnings
<ira>
Discussed during telecon Thursday 10 January - see (2) above.
</ira>
4. I think I have a problem with the usage information in
icTrafficInputMessages and icTrafficOutputMessages.
"System input messages may be mapped from ifInUcastPkts"
In the Counter Spec, we defined
"Message - A single application protocol request or response (that may
consist of multiple application protocol data units) received or sent by
Service such as EmailIn or FaxOut."
Even neglecting the question of how one associates ifInUcastPkts to a
specific protocol, it does not strike me that there is a clear
correlation between message and unicast packets.
<ira>
Discussed during telecon Thursday 10 January - mapping to ifInUcastPkts
is spurious (and not associated with any application, as Bill observes).
</ira>
5. Line 3876: two section breaks?
<ira>
Discussed during telecon Thursday 10 January - will be fixed.
</ira>
------------------------------------------------------------------------