Re: [ipcdn] Review comments on draft 09 of cable device MIB
"Randy Presuhn" <randy_presuhn@mindspring.com> Wed, 27 July 2005 06:06 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxf3u-000080-Op; Wed, 27 Jul 2005 02:06:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxf3r-00007o-S7 for ipcdn@megatron.ietf.org; Wed, 27 Jul 2005 02:06:37 -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 CAA00337 for <ipcdn@ietf.org>; Wed, 27 Jul 2005 02:06:33 -0400 (EDT)
Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxfZ4-0007gd-43 for ipcdn@ietf.org; Wed, 27 Jul 2005 02:38:50 -0400
Received: from h-68-166-189-173.snvacaid.dynamic.covad.net ([68.166.189.173] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dxf3q-0000at-00 for ipcdn@ietf.org; Wed, 27 Jul 2005 02:06:34 -0400
Message-ID: <018d01c59271$6c983000$7f1afea9@oemcomputer>
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: "Ipcdn (E-mail)" <ipcdn@ietf.org>
References: <6EEEACD9D7F52940BEE26F5467C02C73807491@PACDCEXCMB01.cable.comcast.com>
Subject: Re: [ipcdn] Review comments on draft 09 of cable device MIB
Date: Tue, 26 Jul 2005 23:07:09 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df
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
Hi - Richard's proposed changes in response to my comments in this thread look ok to me. That just leaves the open items he noted below. Randy ----- Original Message ----- From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com> To: "Ipcdn (E-mail)" <ipcdn@ietf.org> Cc: "Randy Presuhn" <randy_presuhn@mindspring.com>; "Marez Kevin-MGI1375" <Kevin.Marez@motorola.com>; "Woundy,Richard" <Richard_Woundy@cable.comcast.com> Sent: Sunday, July 24, 2005 8:26 PM Subject: RE: [ipcdn] Review comments on draft 09 of cable device MIB 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 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn
- [ipcdn] Review comments on draft 09 of cable devi… Randy Presuhn
- RE: [ipcdn] Review comments on draft 09 of cable … Wijnen, Bert (Bert)
- RE: [ipcdn] Review comments on draft 09 of cable … Woundy, Richard
- Re: [ipcdn] Review comments on draft 09 of cable … Randy Presuhn