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

"Woundy, Richard" <Richard_Woundy@cable.comcast.com> Mon, 25 July 2005 03:30 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtfX-0008IE-NA; Sun, 24 Jul 2005 23:30:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtfV-0008I9-86 for ipcdn@megatron.ietf.org; Sun, 24 Jul 2005 23:30:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17994 for <ipcdn@ietf.org>; Sun, 24 Jul 2005 23:30:14 -0400 (EDT)
Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwuAH-000834-3L for ipcdn@ietf.org; Mon, 25 Jul 2005 00:02:05 -0400
Received: from ([10.20.62.13]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.12446487; Sun, 24 Jul 2005 23:29:45 -0400
Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 24 Jul 2005 23:29:45 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ipcdn] Review comments on draft 09 of cable device MIB
Date: Sun, 24 Jul 2005 23:26:19 -0400
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73807491@PACDCEXCMB01.cable.comcast.com>
Thread-Topic: [ipcdn] Review comments on draft 09 of cable device MIB
Thread-Index: AcWJz5cVE6JjQEvlTIeNC6m2zmJU7gG96+UQ
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: "Ipcdn (E-mail)" <ipcdn@ietf.org>
X-OriginalArrivalTime: 25 Jul 2005 03:29:45.0610 (UTC) FILETIME=[1A6CEEA0:01C590C9]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964
Content-Transfer-Encoding: quoted-printable
Cc: Randy Presuhn <randy_presuhn@mindspring.com>, Marez Kevin-MGI1375 <Kevin.Marez@motorola.com>, "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=subscribe>
Sender: ipcdn-bounces@ietf.org
Errors-To: ipcdn-bounces@ietf.org

Comments inline, marked with [RW].

-- Rich

-----Original Message-----
From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf
Of Randy Presuhn
Sent: Saturday, July 16, 2005 2:27 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] Review comments on draft 09 of cable device MIB


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.

[RW] I think this has been addressed, but for now it is part of the four
open issues against this draft (see previous email).

SHOULD fix issues:

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

[RW] Done.

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"

[RW] Done. The revised paragraph 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
                true(1) when transmission is inhibited due to no
                syslog (docsDevEvSyslog) or trap (docsDevNmAccessEntry)
                destinations having been set.

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.

[RW] There are also further details in the DESCRIPTION of
docsDevFilterIpTable. The definition of docsDevFilterIpContinue has been
modified as follows:

   docsDevFilterIpContinue OBJECT-TYPE
           SYNTAX      TruthValue
           MAX-ACCESS  read-create
           STATUS      deprecated
           DESCRIPTION
               "If this value is set to true, and docsDevFilterIpControl
                is anything but discard (1), continue scanning and
                applying policies.  See section 3.3.3 for more
                details."
           DEFVAL { false }
           ::= { docsDevFilterIpEntry 19 }

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

[RW] Here is the modified object definition:

   docsDevSwCurrentVers OBJECT-TYPE
           SYNTAX      SnmpAdminString
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
               "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."
           ::= { docsDevSoftware 5 }


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

[RW] Here are the modified object definitions:

   docsDevSwServerAddressType OBJECT-TYPE
           SYNTAX      InetAddressType
           MAX-ACCESS  read-write
           STATUS      current
           DESCRIPTION
               "The type of address of the TFTP or HTTP server used for
                software upgrades.

                If docsDevSwServerTransportProtocol is currently set to
                tftp(1), attempting to set this object to dns(16) MUST
                result in an error."
           ::= { docsDevSoftware 6 }

   docsDevSwServerTransportProtocol OBJECT-TYPE
           SYNTAX INTEGER {
               tftp(1),
               http(2)
           }
           MAX-ACCESS  read-write
           STATUS      current
           DESCRIPTION
               "This object specifies the transport protocol (TFTP or
                HTTP) to be used for software upgrades.

                If the value of this object is tftp(1), then the cable
                device uses TFTP (RFC 1350) read request packets to
                download the docsDevSwFilename from the
                docsDevSwServerAddress in octet mode.

                If the value of this object is http(2), then the cable
                device uses HTTP 1.0 (RFC 1945) or HTTP 1.1 (RFC 2616)
                GET requests sent to host docsDevSwServerAddress to
                download the software image from path docsDevSwFilename.

                If docsDevSwServerAddressType is currently set to
                dns(16), attempting to set this object to tftp(1) MUST
                result in an error."
           DEFVAL { tftp }
           ::= { docsDevSoftware 8 }

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

[RW] Done.

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

[RW] The offending sentence is removed; the reference to
docsDevEvThrottleThreshold should be sufficient to understand the
context. 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 }


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

[RW] This is part of the four open issues against this draft (see
previous email).

Randy




_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn