Re: smidiff diagnosticsfordraft-ietf-ipcdn-device-mibv2-09.txt (part 2)

Hi -

I'm happy with your proposed resolutions to my comments,
of course subject to agreement on the open issues you noted.

Randy

----- Original Message ----- 
From: "Woundy, Richard" <[email protected]>
To: "Ipcdn (E-mail)" <[email protected]>
Cc: "Randy Presuhn" <[email protected]>; "Marez Kevin-MGI1375" <[email protected]>; "Woundy,Richard"
<[email protected]>
Sent: Sunday, July 24, 2005 7:32 PM
Subject: RE: [ipcdn] smidiff diagnosticsfordraft-ietf-ipcdn-device-mibv2-09.txt (part 2)


Comments inline, marked with [RW].

-- Rich

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Randy Presuhn
Sent: Tuesday, June 28, 2005 2:26 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] smidiff diagnostics
fordraft-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."

[RW] Here is the modified object definition:

docsDevEvThrottleThreshold OBJECT-TYPE
        SYNTAX      Unsigned32
        UNITS       "events"
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION
            "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.  For example, 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."
        DEFVAL { 0 }
        ::= { docsDevEvent 5 }

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"

[RW] Here is the modified object definition:

docsDevEvThrottleInterval OBJECT-TYPE
        SYNTAX      Integer32 (1..2147483647)
        UNITS       "seconds"
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION
            "The interval over which docsDevEvThrottleThreshold
             applies."
        DEFVAL { 1 }
        ::= { docsDevEvent 6 }

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?

[RW] We are still working this issue.

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.

[RW] It has been removed.

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."

[RW] Here is the modified object definition:

docsDevEvLastTime OBJECT-TYPE
        SYNTAX      DateAndTime
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "When an entry reports only one event, this object will
             have the same value as the corresponding instance of
             docsDevEvFirstTime.  When an entry reports multiple
             events, this object will record the value that
             docsDevDateTime had when the most recent event for this
             entry occurred."
        ::= { docsDevEventEntry 3 }

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

[RW] Good question, but we left this one alone.

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.)

[RW] We are still working this issue.

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




_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn