Hi,
All of the changes below were approved at today's WIMS WG meeting,
so next steps are:
(1) Ira - Post new Word/PDF/ASN.1 version
(2) Bill - Announce PWG Last Call to span February face-to-face
The relevant quote from PWG Process/2.0 is:
"The Working Group Chair announces a Last Call on a document with
rough consensus of the Working Group. Last Calls are posted to all
members of the PWG via the PWG-ANNOUNCE mailing list. The Last Call
period may vary, based upon the content, complexity, holidays or other
circumstances, but must be at least 16 full working days (minimum 22
calendar days)."
Cheers,
- Ira
On Jan 16, 2008 2:24 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
> 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>
>> ------------------------------------------------------------------------
>
--
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