[ipcdn] Review comments on draft 09 of cable device MIB

["Randy Presuhn" <[e-mail]>]

Hi -

Here are the last of my review comments (I hope!) on
draft-ietf-ipcdn-device-mibv2-09.txt.  This message has three
sections.  The first has the MUST fix issues; the second is
has the SHOULD fix issues.  The third, "Conditional" are things
where the intent was not clear, and, depending on the intent, we
may have a MUST fix issue.  These are in addition to my
previous comments posted to this mailing list.  The guidelines
version I used for this is in
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-04.txt


MUST fix issues:

For docsDevNmAccessStatus, docsDevFilterLLCStatus, docsDevFilterIpStatus,
docsDevFilterPolicyStatus, docsDevFilterTosStatus,
docsDevCpeInetRowStatus, review guidelines page 23 requires:
     - The DESCRIPTION clause of the status column MUST specify which
       columnar objects (if any) have to be set to valid values before
       the row can be activated.  If any objects in cascading tables
       have to be populated with related data before the row can be
       activated, then this MUST also be specified.


SHOULD fix issues:

ZeroBasedCounter32 would be more appropriate for docsDevFilterIpMatches
than the current Counter32.  This would result in no on-wire changes.

docsDevEvThrottleInhibited: currently, part of DESCRIPTION reads:
               "If true(1), trap and syslog transmission is currently
                inhibited due to thresholds and/or the current setting
                of docsDevEvThrottleAdminStatus.  In addition, this is
                set to true(1) if transmission is inhibited due to no
                syslog (docsDevEvSyslog) or trap (docsDevNmAccessEntry)
                destinations having been set.
The phrase "is set to true(1) if" should be "is true(1) when"

docsDevFilterIpContinue: currently, the DESCRIPTION reads, in its entirety:
               "If this value is set to true, and docsDevFilterIpControl
                is anything but discard (1), continue scanning and
                applying policies."
This reads like a fragment of some larger procedure.  Just what that procedure
is is not clear; I'm assuming it has something to do with section 3.3.3
I realize this is inherited from RFC 2669, and that's the
only reason I'm not calling this a MUST fix.

docsDevSwCurrentVers: currently, the DESCRIPTION reads:
               "The software version currently operating in this device.
                This object should be in the syntax used by the
                individual vendor to identify software versions.  Any
                CM MUST return a string descriptive of the current
                software load.  For a CMTS, this object SHOULD contain
                either a human readable representation of the vendor
                specific designation of the software for the chassis,
                or of the software for the control processor.  If
                neither of these is applicable, this MUST contain an
                empty string."
The first "MUST" is rather vacuous, since the object's SYNTAX guarantees
a string, and the previous sentence only gives "should be" guidance.  I suggest
tightening this up to something like:
               "The software version currently operating in this device.
                This string's syntax is that used by the
                individual vendor to identify software versions.
                For a CM, this string will describe the current
                software load.  For a CMTS, this object SHOULD contain
                either a human readable representation of the vendor
                specific designation of the software for the chassis,
                or of the software for the control processor.  If
                neither of these is applicable, the value MUST be a
                zero-length string."

docsDevSwServerAddressType and docsDevSwServerTransportProtocol:
replace "setting" with "attempting to set" in both DESCRIPTIONS

docsDevServerConfigFile: replace "empty" with "zero-length"

docsDevEvThrottleInterval: it's not clear what the phrase "all
system notifications" is supposed to mean.

-------------
Conditional:
docsDevNmAccessStatus, docsDevFilterLLCStatus, docsDevFilterIpStatus,
docsDevFilterPolicyStatus, docsDevFilterTosStatus, docsDevCpeStatus,
docsDevCpeInetRowStatus,
do not mention whether the agent can create or destroy rows on its own.
page 23 of the guidelines says:
     - If the agent itself may also create and/or delete rows, then the
       conditions under which this can occur MUST be clearly documented
       in the row object DESCRIPTION clause.
consequently, this MIB may be read as not permitting an agent to create
or delete rows on its own in these tables.  The text in section 3.3.2.1
that says "the policy for automatically creating filters in those
tables is controlled by docsDevCpeEnroll and docsDevMaxCpe as well
as the network management agent." makes me think that that is not your
intent, in at least some cases.  If so, this is a MUST fix.


Randy




_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn