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

Hi -

Reponses to Richard's proposed changes in response to me comments...
Most are fine with me, though a couple might need a little discussion.

> From: "Woundy, Richard" <[email protected]>
...
> Sent: Sunday, July 24, 2005 7:24 PM
> Subject: RE: [ipcdn] smidiff diagnostics fordraft-ietf-ipcdn-device-mibv2-09.txt (part 1)
...
> >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 }

This addresses my concerns.

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

Ok, though on re-reading the sentence "If the table is empty, access to
SNMP objects is unrestricted" gives me a little heartburn; more accurate
(I hope!) would be "If this table is empty, it imposes no restrictions on
access to SNMP objects."  (Since in protocol there is no way to tell
the difference between an empty table and one which does not exist,
the current wording permits some interesting misreadings.)

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

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 }

Looking at this more closely, do we really want to change the DESCRIPTION
in this way?  It looks like there have been some cut-and-paste problems between
docsDevNmAccessIp and docsDevNmAccessIpMask, and it's not clear to
me that the new DEFVAL for this one is right.

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

This still leaves me wondering why the default is four bytes long, when
the one-byte '80'h would do just as well.

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

Ack.  I hate to see too much time go into it, but trying to put myself in
an implementor's place I see a lot of potential interoperability problems.
I guess it boils down to just how much we deprecate this object.  :-)

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

Ok.

> > 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. :^(

At the first comma?  That would be fine with me.  The change
addresses my concern.

...

Randy