WIMS> Counter MIB - fixed Usage paragraphs

WIMS> Counter MIB - fixed Usage paragraphs

WIMS> Counter MIB - fixed Usage paragraphs

Ira McDonald blueroofmusic at gmail.com
Wed Jan 16 14:24:27 EST 2008


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>

------------------------------------------------------------------------



More information about the Wims mailing list