From: Ira McDonald (blueroofmusic@gmail.com)
Date: Wed Jan 16 2008 - 14:24:27 EST
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@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>
------------------------------------------------------------------------
This archive was generated by hypermail 2.1.4 : Wed Jan 16 2008 - 14:31:34 EST