smidiff diagnostics for draft-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.

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

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.

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.

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?

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

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.

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.

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