RE: smidiff diagnostics fordraft-ietf-ipcdn-device-mibv2-09.txt (part 1)

Comments inline, marked with [RW].

-- Rich

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Randy Presuhn
Sent: Tuesday, June 28, 2005 12:09 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] smidiff diagnostics
fordraft-ietf-ipcdn-device-mibv2-09.txt (part 1)


Hi -

I ran smidiff to check the changes from RFC 2669 in
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt
Below are the diagnostics it produced, with my comments interspersed.
Since there were numerous messages, I'm breaking this into multiple
postings.

rfc2669.txt:1573: subtyping not allowed in SEQUENCE
rfc2669.txt:1574: subtyping not allowed in SEQUENCE
   --> not an issue here

draft-ietf-ipcdn-device-mibv2-09.txt:939: warning: object identifier
name `docsDevServerConfigTftpAddressType' longer than 32 characters
draft-ietf-ipcdn-device-mibv2-09.txt:1446: warning: object identifier
name `docsDevEvThrottleThresholdExceeded' longer than 32 characters
   --> these are OK, in line with section 4.2 of MIB review guidelines

draft-ietf-ipcdn-device-mibv2-09.txt:2489: warning: index of row
`docsDevCpeInetEntry' can exceed OID size limit by 141
subidentifier(s)
   --> OK, docsDevCpeInetAddr has appropriate warnings for implementors

draft-ietf-ipcdn-device-mibv2-09.txt:2873: warning: current compliance
statement `docsDevCmCompliance' includes deprecated group
`docsDevNmAccessGroup'
draft-ietf-ipcdn-device-mibv2-09.txt:2873: warning: current compliance
statement `docsDevCmCompliance' includes deprecated group
`docsDevNmAccessExtGroup'
draft-ietf-ipcdn-device-mibv2-09.txt:2873: warning: current compliance
statement `docsDevCmCompliance' includes deprecated group
`docsDevFilterGroup'
draft-ietf-ipcdn-device-mibv2-09.txt:3163: warning: current compliance
statement `docsDevCmtsCompliance' includes deprecated group
`docsDevNmAccessGroup'
draft-ietf-ipcdn-device-mibv2-09.txt:3163: warning: current compliance
statement `docsDevCmtsCompliance' includes deprecated group
`docsDevNmAccessExtGroup'
draft-ietf-ipcdn-device-mibv2-09.txt:3163: warning: current compliance
statement `docsDevCmtsCompliance' includes deprecated group
`docsDevFilterGroup'
draft-ietf-ipcdn-device-mibv2-09.txt:3163: warning: current compliance
statement `docsDevCmtsCompliance' includes deprecated group
`docsDevCpeGroup'
   --> addressed in another thread

draft-ietf-ipcdn-device-mibv2-09.txt:40 [3] {organization-changed}
organization of `DOCS-CABLE-DEVICE-MIB' changed
draft-ietf-ipcdn-device-mibv2-09.txt:40 [3] {contact-changed} contact of
`DOCS-CABLE-DEVICE-MIB' changed draft-ietf-ipcdn-device-mibv2-09.txt:40
[5] {description-changed} description of `DOCS-CABLE-DEVICE-MIB' changed
draft-ietf-ipcdn-device-mibv2-09.txt:197 [3] {revision-changed} revision
`1999-08-19 00:00' changed rfc2669.txt:46 [6] {previous-definition}
previous definition of `1999-08-19 00:00'
draft-ietf-ipcdn-device-mibv2-09.txt:84 [5] {revision-added} revision
`2005-06-10 00:00' added rfc2669.txt:27 [6] {previous-definition}
previous definition of `DOCS-CABLE-DEVICE-MIB'
   -->  these changes look OK

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

draft-ietf-ipcdn-device-mibv2-09.txt:243 [5] {description-changed}
description of `docsDevDateTime' changed rfc2669.txt:87 [6]
{previous-definition} previous definition of `docsDevDateTime'
   -->  The changed DESCRIPTION has some problems.  It reads:
               "The current date and time, with optional time zone
                information.  This value is initialized on boot
                from the time server.
                If it is impossible to set this from boot, this shall
                represent elapsed time from boot relative to the
                standard epoch (e.g. 1 Jan 1970 0000Z).  In other
                words, if this agent has been up for 3 minutes, and
                has been unable to set this object from the time
                server, this object will return 1 Jan 1970 0003Z."
   (1) RFC 2579's definition of DateAndTime doesn't make the time zone
   information "optional".  Rather, its absence indicates that the time
zone
   isn't known.
    (2) saying "This value is initialized on boot from the time server"
   is serious over-specification, and should be removed.
    (3) "If it is impossible to set this from boot" should be replaced
with
    something like "If the real data and time cannot be determined"
   (4) Likewise, "been unable to set this object from the time server"
   should be replaced with something like "not been able to determine
   what the actual date and time are"
   (5) the value format "1 Jan 1970 0000Z" doesn't map well onto the
   actual syntax of the underlying textual convention.  It lacks the
seconds
   and deci-seconds fields.  Its elements are in a different order.
   (6)  The "Z" would normally be understood as the fields for hours and
   minutes from UTC    being zero, rather than absent, in the case of
   "1 Jan 1970 0003Z".  RFC 2579 requires that the offset be absent
   if the time is "local", as it surely would be in this case.

   This MUST be fixed.

[RW] Here is the modified object definition:

docsDevDateTime OBJECT-TYPE
        SYNTAX      DateAndTime
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION
            "The current date and time, with time zone information
             (if known).

             If the real data and time cannot be determined, this
             shall represent elapsed time from boot relative to
             the standard epoch '1970-1-1,0:0:0.0'.  In other
             words, if this agent has been up for 3 minutes, and
             not been able to determine what the actual date and
             time are, this object will return the value
             '1970-1-1,0:03:0.0'."
        ::= { docsDevBase 2 }

draft-ietf-ipcdn-device-mibv2-09.txt:280 [3] {defval-added} default
value added to `docsDevSTPControl'
draft-ietf-ipcdn-device-mibv2-09.txt:359 [5] {status-change} legal
status change from `current' to `deprecated' for `docsDevNmAccessTable'
   --> ok.

draft-ietf-ipcdn-device-mibv2-09.txt:359 [5] {description-changed}
description of `docsDevNmAccessTable' changed rfc2669.txt:151 [6]
{previous-definition} previous definition of `docsDevNmAccessTable'
   --> The changed DESCRIPTION has some problems that SHOULD be fixed.
It reads:
               "This table controls access to SNMP objects by network
                management stations.  If the table is empty, access to
                SNMP objects is unrestricted.  The objects in this table
                do not persist across reboots.  The objects in this
                table are only accessible from cable devices which are
                not operating in SNMP Coexistence mode (RFC 3584) nor in
                SNMPv3 mode (RFC 3410).  See the conformance section for
                details.  Note that some devices are required by other
                specifications, e.g. the DOCSIS OSSIv1.1 specification,
                to support the legacy SNMPv1/v2c docsDevNmAccess mode
                for backward compatibility.

                This table is deprecated.  Instead, use the SNMP
                coexistence MIBs from RFC 3584, the TARGET and
                NOTIFICATION MIBs from the SNMP Applications RFC, and
                the View-Based Access Control Model (VACM) MIBs for
                SNMPv1 and V2C access."

   (1)  I think instead of "which are not operating" you mean "which are
          not capable of operating".
   (2)  Add appropriate references to RFCs 3413 and 3415
   (3) replace "SNMPv1 and V2C access" with "all SNMP protocol
versions."

[RW] Here is the modified object definition:

docsDevNmAccessTable OBJECT-TYPE
        SYNTAX      SEQUENCE OF DocsDevNmAccessEntry
        MAX-ACCESS  not-accessible
        STATUS      deprecated
        DESCRIPTION
            "This table controls access to SNMP objects by network
             management stations.  If the table is empty, access to
             SNMP objects is unrestricted.  The objects in this table
             do not persist across reboots.  The objects in this
             table are only accessible from cable devices which are
             not capable of operating in SNMP Coexistence mode
             (RFC 3584) nor in SNMPv3 mode (RFC 3410).
             See the conformance section for
             details.  Note that some devices are required by other
             specifications, e.g. the DOCSIS OSSIv1.1 specification,
             to support the legacy SNMPv1/v2c docsDevNmAccess mode
             for backward compatibility.

             This table is deprecated.  Instead, use the SNMP
             coexistence MIBs from RFC 3584, the TARGET and
             NOTIFICATION MIBs from RFC 3413, and
             the View-Based Access Control Model (VACM) MIBs for
             all SNMP protocol versions from RFC 3415."
        ::= { docsDevMIBObjects 2 }

draft-ietf-ipcdn-device-mibv2-09.txt:388 [5] {status-change} legal
status change from `current' to `deprecated' for `docsDevNmAccessEntry'
rfc2669.txt:165 [6] {previous-definition} previous definition of
`docsDevNmAccessEntry' draft-ietf-ipcdn-device-mibv2-09.txt:415 [5]
{status-change} legal status change from `current' to `deprecated' for
`docsDevNmAccessIndex' rfc2669.txt:191 [6] {previous-definition}
previous definition of `docsDevNmAccessIndex'
draft-ietf-ipcdn-device-mibv2-09.txt:429 [5] {status-change} legal
status change from `current' to `deprecated' for `docsDevNmAccessIp'
draft-ietf-ipcdn-device-mibv2-09.txt:429 [3] {defval-changed} default
value of `docsDevNmAccessIp' changed rfc2669.txt:205 [6]
{previous-definition} previous definition of `docsDevNmAccessIp'
   --> all ok

draft-ietf-ipcdn-device-mibv2-09.txt:429 [5] {description-changed}
description of `docsDevNmAccessIp' changed rfc2669.txt:205 [6]
{previous-definition} previous definition of `docsDevNmAccessIp'
   ---> The change to the object's semantics doesn't fit within the
guidelines of RFC 2578
   section 10.2.  However, the conformance material gives a hint at a
solution where it says:
               "It is compliant to recognize the IP address
                255.255.255.255 as referring to any NMS."
    So, I suggest replacing
               "The IP address (or subnet) of the network management
                station.  The address 0.0.0.0 is defined to mean
                any Network Management Station (NMS).  If traps are
                enabled for this entry, then the value must be the
                address of a specific device."
   with that preserves the original semantics, e.g.:
               "The IP address (or subnet) of the network management
                station.  The address 0.0.0.0 is defined to mean
                any Network Management Station (NMS).  If traps are
                enabled for this entry, then the value must be the
                address of a specific device.  Implementations MAY
                recognize 255.255.255.255 as equivalent to 0.0.0.0"

   Something MUST be done here.

[RW] Here is the modified object definition:

docsDevNmAccessIp OBJECT-TYPE
        SYNTAX      IpAddress
        MAX-ACCESS  read-create
        STATUS      deprecated
        DESCRIPTION
            "The IP address (or subnet) of the network management
             station.  The address 0.0.0.0 is defined to mean
             any Network Management Station (NMS).  If traps are
             enabled for this entry, then the value must be the
             address of a specific device.  Implementations MAY
             recognize 255.255.255.255 as equivalent to 0.0.0.0."
        DEFVAL { '00000000'h }
        ::= { docsDevNmAccessEntry 2 }

draft-ietf-ipcdn-device-mibv2-09.txt:442 [5] {status-change} legal
status change from `current' to `deprecated' for `docsDevNmAccessIpMask'
   --> ok

draft-ietf-ipcdn-device-mibv2-09.txt:442 [3] {defval-changed} default
value of `docsDevNmAccessIpMask' changed
draft-ietf-ipcdn-device-mibv2-09.txt:442 [5] {description-changed}
description of `docsDevNmAccessIpMask' changed rfc2669.txt:217 [6]
{previous-definition} previous definition of `docsDevNmAccessIpMask'
    --> Similar to the problems with docsDevNmAccessIp, except this one
doesn't have
    any language in the conformance material permitting the old value.
(I assume this was
    an oversight, that you'd want implementations to be able to honor
both 0.0.0.0 and
    255.255.255.255.)  This MUST be fixed.

[RW] Here is the modified object definition:

docsDevNmAccessIpMask OBJECT-TYPE
        SYNTAX      IpAddress
        MAX-ACCESS  read-create
        STATUS      deprecated
        DESCRIPTION
            "The IP subnet mask of the network management stations.
             If traps are enabled for this entry, then the value must
             be 0.0.0.0.  Implementations MAY recognize
             255.255.255.255 as equivalent to 0.0.0.0."
        DEFVAL { '00000000'h }
        ::= { docsDevNmAccessEntry 3 }

draft-ietf-ipcdn-device-mibv2-09.txt:453 [5] {status-change} legal
status change from `current' to `deprecated' for
`docsDevNmAccessCommunity' rfc2669.txt:228 [6] {previous-definition}
previous definition of `docsDevNmAccessCommunity'
draft-ietf-ipcdn-device-mibv2-09.txt:465 [5] {status-change} legal
status change from `current' to `deprecated' for
`docsDevNmAccessControl' rfc2669.txt:240 [6] {previous-definition}
previous definition of `docsDevNmAccessControl'
   --> ok

draft-ietf-ipcdn-device-mibv2-09.txt:495 [3] {to-implicit} implicit type
for `docsDevNmAccessInterfaces' replaces type `OctetString'
rfc2669.txt:270 [6] {previous-definition} previous definition of
`docsDevNmAccessInterfaces' draft-ietf-ipcdn-device-mibv2-09.txt:495 [3]
{range-added} size `(1..32)' added to type used in
`docsDevNmAccessInterfaces' draft-ietf-ipcdn-device-mibv2-09.txt:495 [5]
{status-change} legal status change from `current' to `deprecated' for
`docsDevNmAccessInterfaces'
   --> ok

draft-ietf-ipcdn-device-mibv2-09.txt:495 [3] {defval-added} default
value added to `docsDevNmAccessInterfaces'
   --> The default value given here looks odd.  Do you *really* intend
for the
         default value to be four bytes long, and, according to the
DESCRIPTION
         clause, to refer to interface number thirty-two?

[RW] We changed the DEFVAL to { '80000000'h }, thanks!

draft-ietf-ipcdn-device-mibv2-09.txt:495 [5] {description-changed}
description of `docsDevNmAccessInterfaces' changed rfc2669.txt:270 [6]
{previous-definition} previous definition of `docsDevNmAccessInterfaces'
   -> In the DESCRIPTION, where it says:
                Note that entries in this table apply only to link-layer
                interfaces (e.g., Ethernet and CATV MAC).  Upstream and
                downstream channel interfaces must not be specified.
       Is the "must not" intended to be "MUST NOT"?  Does "specified"
mean
       "the corresponding bit set to one" if an interface number exists
for that
       interface?
       When it says "The size of this object is the minimum required to
       represent all configured interfaces for this device", several
questions come
       to mind.  What happens if a management system attempts to set it
to a larger
       or smaller size?  When the row is being created, how does a
management
       system know what size to use?  What value is used for bits
corresponding
       to interfaces that do not exist?  As interfaces are added to or
removed from
       the device, do these objects' sizes adjust automatically?  A lot
of questions
      for a deprecated object....

[RW] We are still working this issue.

draft-ietf-ipcdn-device-mibv2-09.txt:532 [5] {status-change} legal
status change from `current' to `deprecated' for `docsDevNmAccessStatus'
rfc2669.txt:293 [6] {previous-definition} previous definition of
`docsDevNmAccessStatus' draft-ietf-ipcdn-device-mibv2-09.txt:569 [5]
{status-change} legal status change from `current' to `deprecated' for
`docsDevSwServer' draft-ietf-ipcdn-device-mibv2-09.txt:569 [5]
{description-changed} description of `docsDevSwServer' changed
rfc2669.txt:317 [6] {previous-definition} previous definition of
`docsDevSwServer'
   --> ok

draft-ietf-ipcdn-device-mibv2-09.txt:588 [5] {description-changed}
description of `docsDevSwFilename' changed rfc2669.txt:326 [6]
{previous-definition} previous definition of `docsDevSwFilename'
   --> I suggest replacing "empty" with "zero-length" to remove any
ambiguity.

[RW] Here is the modified object definition:

docsDevSwFilename OBJECT-TYPE
        SYNTAX      SnmpAdminString (SIZE (0..64))
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION
            "The filename of the software image to be downloaded via
             TFTP, or the abs_path (as defined in RFC 2616) of the
             software image to be downloaded via HTTP.

             Unless set via SNMP, this is the filename or abs_path
             specified by the provisioning server during the boot
             process, that corresponds to the software version that
             is desired for this device.

             If unknown, the value of this object is the zero-length
             string."
        ::= { docsDevSoftware 2 }

draft-ietf-ipcdn-device-mibv2-09.txt:606 [3] {defval-added} default
value added to `docsDevSwAdminStatus'
draft-ietf-ipcdn-device-mibv2-09.txt:606 [5] {description-changed}
description of `docsDevSwAdminStatus' changed rfc2669.txt:338 [6]
{previous-definition} previous definition of `docsDevSwAdminStatus'
   --> ok, though the text
                If the download process is interrupted by a reset or
                power failure, the device will load the previous image
                and, after re-initialization, continue to attempt
                loading the image specified in docsDevSwFilename.
   makes me wonder what is supposed to happen if the download process
   is interrupted by something else.

[RW] Change the text to say

             If the download process is interrupted (e.g. by a reset
             or power failure, the device will load the previous
             image and, after re-initialization, continue to attempt
             loading the image specified in docsDevSwFilename.

I guess I forgot to close the parenthesis. :^(

draft-ietf-ipcdn-device-mibv2-09.txt:645 [5] {description-changed}
description of `docsDevSwOperStatus' changed
draft-ietf-ipcdn-device-mibv2-09.txt:645 [5] {ref-changed} reference of
`docsDevSwOperStatus' changed rfc2669.txt:379 [6] {previous-definition}
previous definition of `docsDevSwOperStatus'
draft-ietf-ipcdn-device-mibv2-09.txt:775 [5] {description-changed}
description of `docsDevServerBootState' changed
draft-ietf-ipcdn-device-mibv2-09.txt:775 [5] {ref-changed} reference of
`docsDevServerBootState' changed rfc2669.txt:434 [6]
{previous-definition} previous definition of `docsDevServerBootState'
draft-ietf-ipcdn-device-mibv2-09.txt:837 [5] {status-change} legal
status change from `current' to `deprecated' for `docsDevServerDhcp'
draft-ietf-ipcdn-device-mibv2-09.txt:837 [5] {description-changed}
description of `docsDevServerDhcp' changed rfc2669.txt:479 [6]
{previous-definition} previous definition of `docsDevServerDhcp'
draft-ietf-ipcdn-device-mibv2-09.txt:856 [5] {status-change} legal
status change from `current' to `deprecated' for `docsDevServerTime'
draft-ietf-ipcdn-device-mibv2-09.txt:856 [5] {description-changed}
description of `docsDevServerTime' changed rfc2669.txt:489 [6]
{previous-definition} previous definition of `docsDevServerTime'
draft-ietf-ipcdn-device-mibv2-09.txt:869 [5] {status-change} legal
status change from `current' to `deprecated' for `docsDevServerTftp'
draft-ietf-ipcdn-device-mibv2-09.txt:869 [5] {description-changed}
description of `docsDevServerTftp' changed rfc2669.txt:498 [6]
{previous-definition} previous definition of `docsDevServerTftp'
draft-ietf-ipcdn-device-mibv2-09.txt:990 [5] {status-change} legal
status change from `current' to `deprecated' for `docsDevEvSyslog'
draft-ietf-ipcdn-device-mibv2-09.txt:990 [5] {description-changed}
description of `docsDevEvSyslog' changed rfc2669.txt:545 [6]
{previous-definition} previous definition of `docsDevEvSyslog'
  --> all ok

More to come...

Randy




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