smidiff diagnostics for draft-ietf-ipcdn-device-mibv2-09.txt (part 2)

Hi -

Here's the second part of the smidiff diagnostics, with my comments interspersed.

draft-ietf-ipcdn-device-mibv2-09.txt:1008 [3] {defval-added} default value added to `docsDevEvThrottleAdminStatus'
draft-ietf-ipcdn-device-mibv2-09.txt:1008 [5] {description-changed} description of `docsDevEvThrottleAdminStatus' changed
rfc2669.txt:554 [6] {previous-definition} previous definition of `docsDevEvThrottleAdminStatus'
   -> ok

draft-ietf-ipcdn-device-mibv2-09.txt:1043 [5] {status-change} legal status change from `current' to `deprecated' for
`docsDevEvThrottleInhibited'
draft-ietf-ipcdn-device-mibv2-09.txt:1043 [5] {description-changed} description of `docsDevEvThrottleInhibited' changed
rfc2669.txt:591 [6] {previous-definition} previous definition of `docsDevEvThrottleInhibited'
   -> ok

draft-ietf-ipcdn-device-mibv2-09.txt:1064 [3] {defval-added} default value added to `docsDevEvThrottleThreshold'
draft-ietf-ipcdn-device-mibv2-09.txt:1064 [5] {units-added} units added to `docsDevEvThrottleThreshold'
draft-ietf-ipcdn-device-mibv2-09.txt:1064 [5] {description-changed} description of `docsDevEvThrottleThreshold' changed
rfc2669.txt:604 [6] {previous-definition} previous definition of `docsDevEvThrottleThreshold'
   --> the changes are ok, but the object itself gives me heartburn.  If it were formulated only
        in terms of internal events that could result in notifications being sent, it wouldn't bother me.
        As it is, it requires the subagent/component implementing this MIB to know about
        what has happened in two other subsystems: the SNMP engine and the syslog engine.
        Something more like the following DESCRIPTION would make me happy, if it
        isn't contrary to your intent:
               "Number of events per docsDevEvThrottleInterval
                permitted before throttling is to occur.

                A single event, whether the notification could result in
                messages transmitted using syslog, SNMP, or both
                protocols, and regardless of the number of destinations,
                (including zero) is always treated as a single event for
                threshold counting.  That is, an event causing both a
                trap and a syslog message is still treated as a single
                event.

                All system notifications that occur within the device
                should be taken into consideration when calculating
                and monitoring the threshold."

draft-ietf-ipcdn-device-mibv2-09.txt:1085 [3] {defval-added} default value added to `docsDevEvThrottleInterval'
draft-ietf-ipcdn-device-mibv2-09.txt:1085 [5] {description-changed} description of `docsDevEvThrottleInterval' changed
rfc2669.txt:619 [6] {previous-definition} previous definition of `docsDevEvThrottleInterval'
   --> changes ok, but replace "the trap threshold" with "docsDevEvThrottleThreshold"

draft-ietf-ipcdn-device-mibv2-09.txt:1104 [5] {description-changed} description of `docsDevEvControlTable' changed
rfc2669.txt:640 [6] {previous-definition} previous definition of `docsDevEvControlTable'
   --> ok

draft-ietf-ipcdn-device-mibv2-09.txt:1141 [5] {description-changed} description of `docsDevEvPriority' changed
rfc2669.txt:669 [6] {previous-definition} previous definition of `docsDevEvPriority'
   --> ok

draft-ietf-ipcdn-device-mibv2-09.txt:1197 [5] {named-number-added} named number `localVolatile' added to type used in
`docsDevEvReporting'
draft-ietf-ipcdn-device-mibv2-09.txt:1197 [5] {named-number-added} named number `stdInterface' added to type used in
`docsDevEvReporting'
draft-ietf-ipcdn-device-mibv2-09.txt:1197 [5] {description-changed} description of `docsDevEvReporting' changed
   --> minor formatting problem in DESCRIPTION (check indentation)
        I'm puzzled by this addition:
                   Any attempt to SET the traps(1) or syslog(2) bits
                   without setting the local(0) or localVolatile(8)
                   bits MUST result in an error being generated."
        Where did this come from?

draft-ietf-ipcdn-device-mibv2-09.txt:1197 [5] {ref-added} reference added to `docsDevEvReporting'
rfc2669.txt:699 [6] {previous-definition} previous definition of `docsDevEvReporting'
   --> this reference doesn't explain what this object does, so I suggest removing it.

draft-ietf-ipcdn-device-mibv2-09.txt:1240 [5] {description-changed} description of `docsDevEventTable' changed
rfc2669.txt:718 [6] {previous-definition} previous definition of `docsDevEventTable'
   --> ok

draft-ietf-ipcdn-device-mibv2-09.txt:1251 [5] {description-changed} description of `docsDevEventEntry' changed
rfc2669.txt:732 [6] {previous-definition} previous definition of `docsDevEventEntry'
   --> ok

draft-ietf-ipcdn-device-mibv2-09.txt:1298 [5] {description-changed} description of `docsDevEvFirstTime' changed
rfc2669.txt:774 [6] {previous-definition} previous definition of `docsDevEvFirstTime'
   --> ok

draft-ietf-ipcdn-device-mibv2-09.txt:1307 [5] {description-changed} description of `docsDevEvLastTime' changed
rfc2669.txt:787 [6] {previous-definition} previous definition of `docsDevEvLastTime'
   --> change ok, but the DESCRIPTION has some problems.  It reads:
               "If multiple events are reported via the same entry, the
                value of docsDevDateTime that the last event for this
                entry occurred, otherwise this should have the same
                value as docsDevEvFirstTime. "
   To get rid of the "should", I suggest something like:
               "When an entry reports only one event, this object will
                have the same value as the corresponding instance of
               docsDecEvFirstTime.  When an entry reports multiple
               events, this object will record the value that docsDevDateTime
               had when the most recent event for this entry occurred."

draft-ietf-ipcdn-device-mibv2-09.txt:1325 [5] {units-added} units added to `docsDevEvCounts'
   --> ok

draft-ietf-ipcdn-device-mibv2-09.txt:1337 [5] {description-changed} description of `docsDevEvLevel' changed
rfc2669.txt:811 [6] {previous-definition} previous definition of `docsDevEvLevel'
   --> ok, though I'm tempted to ask why there isn't a TC for this and docsDevEvPriority

draft-ietf-ipcdn-device-mibv2-09.txt:1396 [5] {ref-added} reference added to `docsDevEvId'
   --> ok

draft-ietf-ipcdn-device-mibv2-09.txt:1462 [3] {defval-added} default value added to `docsDevFilterLLCUnmatchedAction'
draft-ietf-ipcdn-device-mibv2-09.txt:1462 [5] {description-changed} description of `docsDevFilterLLCUnmatchedAction' changed
rfc2669.txt:869 [6] {previous-definition} previous definition of `docsDevFilterLLCUnmatchedAction'
   --> ok

draft-ietf-ipcdn-device-mibv2-09.txt:1494 [5] {description-changed} description of `docsDevFilterLLCTable' changed
rfc2669.txt:898 [6] {previous-definition} previous definition of `docsDevFilterLLCTable'
   --> the added text "Table entries are not required to persist across reboots for any device."
   is a little odd.  More RFC 2119-like would be something like "Table entries MAY
   persist across reboots for any device" or "Persistance of table entries across reboots
   is OPTIONAL for all devices."  (Whether this optionality would be a good thing is a
   separate discussion.)

draft-ietf-ipcdn-device-mibv2-09.txt:1554 [5] {description-changed} description of `docsDevFilterLLCIfIndex' changed
draft-ietf-ipcdn-device-mibv2-09.txt:1554 [5] {ref-added} reference added to `docsDevFilterLLCIfIndex'
rfc2669.txt:956 [6] {previous-definition} previous definition of `docsDevFilterLLCIfIndex'
   --> ok

Randy