From ipcdn-bounces@ietf.org Wed Jul 06 05:15:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq5zj-0008AK-9f; Wed, 06 Jul 2005 05:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq5zg-000877-Mt for ipcdn@megatron.ietf.org; Wed, 06 Jul 2005 05:15:00 -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 FAA29577 for ; Wed, 6 Jul 2005 05:14:58 -0400 (EDT) Received: from go4.ext.ti.com ([192.91.75.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq6Qa-0001ag-Rh for ipcdn@ietf.org; Wed, 06 Jul 2005 05:42:52 -0400 Received: from dlep52.itg.ti.com ([157.170.170.57]) by go4.ext.ti.com (8.13.1/8.13.1) with ESMTP id j669EjHM026734 for ; Wed, 6 Jul 2005 04:14:46 -0500 (CDT) Received: from dlep90.itg.ti.com (localhost [127.0.0.1]) by dlep52.itg.ti.com (8.12.11/8.12.11) with ESMTP id j669EjWI002057 for ; Wed, 6 Jul 2005 04:14:45 -0500 (CDT) Received: from dbde01.ent.ti.com (localhost [127.0.0.1]) by dlep90.itg.ti.com (8.12.11/8.12.11) with ESMTP id j669DWrK018768 for ; Wed, 6 Jul 2005 04:14:44 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Jul 2005 14:44:19 +0530 Message-ID: Thread-Topic: Tone Generation Proposal Thread-Index: AcWCCxcIGgapqaiOTpyL1r2RROc6nw== From: "T, Shivakumar" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Subject: [ipcdn] Tone Generation Proposal X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0774497194==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============0774497194== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5820B.1798263A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5820B.1798263A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If we can make the following 2 assumptions, I am proposing a modified version of the existing tone table. 1) There is no tone which uses more than 4 frequencies. 2) There is no tone which has to be generated by modulating a multi-freq tone with another tone. =20 With these assumptions we can modify the existing tone table without adding any extra tables. =20 Instead of PriComp and SecComp, we'll have freq1, freq2, freq3 and freq4 in the multi-freq tone table. If modulation is selected, freq1 will be modulated with freq2. =20 Shiva =20 ------_=_NextPart_001_01C5820B.1798263A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If we can make the following 2 assumptions, I am = proposing a modified version of the existing tone = table.

1)       = There is no tone which uses more than 4 frequencies.

2)       = There is no tone which has to be generated by modulating a multi-freq tone with = another tone.

 

With these assumptions we can modify the existing = tone table without adding any extra tables.

 

Instead of PriComp and SecComp, we’ll have = freq1, freq2, freq3 and freq4 in the multi-freq tone = table.

If modulation is selected, freq1 will be modulated = with freq2.

 

Shiva

 

------_=_NextPart_001_01C5820B.1798263A-- --===============0774497194== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0774497194==-- From ipcdn-bounces@ietf.org Wed Jul 06 17:26:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqHPM-00025G-46; Wed, 06 Jul 2005 17:26:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqHPK-000214-CQ for ipcdn@megatron.ietf.org; Wed, 06 Jul 2005 17:26:14 -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 RAA00271 for ; Wed, 6 Jul 2005 17:26:12 -0400 (EDT) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqHqN-0006ox-TQ for ipcdn@ietf.org; Wed, 06 Jul 2005 17:54:12 -0400 Received: from ([10.20.9.174]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.11989345; Wed, 06 Jul 2005 17:25:52 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 17:25:51 -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] Problems in XML source of Cable Device MIB, Draft 09 Date: Wed, 6 Jul 2005 17:25:51 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73807325@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [ipcdn] Problems in XML source of Cable Device MIB, Draft 09 Thread-Index: AcV5RRg16zTj90DAThaLfqdedj3OTQJJ2CHg From: "Woundy, Richard" To: "Randy Presuhn" , "Marez Kevin-MGI1375" X-OriginalArrivalTime: 06 Jul 2005 21:25:51.0637 (UTC) FILETIME=[48ED8C50:01C58271] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 Content-Transfer-Encoding: quoted-printable Cc: ipcdn@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Randy, The comments in your six emails (below is the first one I received) look very reasonable. I would like to post a revised draft that addresses all of your comments before the July 18th cut-off. Kevin, can we talk about how we would do this in an offline discussion? I think the WG needs to discuss which deprecated groups should be included in the docsDevCmCompliance and docsDevCmtsCompliance statement (if any). In my opinion, some (if not all) of the deprecated groups need to be implemented on CMs and CMTSs for backwards compatibility with various cable OSS systems... but maybe cable operators are ready to drop support for some of these deprecated groups, and this draft should reflect that. I have oonly a few minor reactions to your other comments, that I will address over the next few days. For example, with respect to docsDevNmAccessTable, according to DOCSIS a cable modem may boot in a mode where SNMP Coexistence mode is disabled, but the same cable modem may boot in a mode where SNMP Coexistance mode or SNMPv3 management is enabled, depending on the boot parameters received. -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Saturday, June 25, 2005 1:15 AM To: Ipcdn (E-mail) Subject: [ipcdn] Problems in XML source of Cable Device MIB, Draft 09 Hi Rich - > From: "Woundy, Richard" > To: "Randy Presuhn" > Sent: Friday, June 24, 2005 11:51 AM > Subject: RE: [ipcdn] Cable Device MIB, Draft 09 released > > Thanks! I attached the XML version, which might help slightly. ... I tried Bill Fenner's tool on it, and got quite a few diagnostics. Background by Bill: Another tool that is worth running on the xml source before using xml2rfc on it is at http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ ; it will check that the source is well-formed and valid according to the DTD (XML generated outside of a validating editor is often not valid, and sometimes even not well-formed, even though xml2rfc creates a fine-looking document from it), and also checks for various other errors including the IPR requested. The warnings are mostly due to inappropriate characters (like spaces or periods) in things like xref targets and anchors. Clear those up, and you'll know whether the complaints about unreferenced references are real. These aren't terribly critical, as far as I'm concerned, but it's probably good housekeeping to take care of them now, since it would be one less potential source of error during final RFC editing. The messages I received were: Validation results for C:\My Documents\draft-ietf-ipcdn-device-mibv2-09.xml Processing... Validating document... 193: element xref: validity error : Syntax of value for attribute target of xref is not valid 192: "Data-Over-Cable Service Interface Specification". A term referring to the 193: ITU-T J.112 194: Annex B standard for cable modem systems. 212: element section: validity error : Syntax of value for attribute anchor of section is not valid 211: 212:
213: 4061: element reference: validity error : Syntax of value for attribute anchor of reference is not valid 4060: 4061: 4062: ...validation failed Performing additional checks... 142: fyi: anchor framework not referenced 141: 142:
143: 159: fyi: anchor glossary not referenced 158: 159:
160: 165: fyi: anchor catv not referenced 164: 165:
166: 173: fyi: anchor cm not referenced 172: 173:
174: 180: fyi: anchor cmts not referenced 179: 180:
181: 190: fyi: anchor docsis not referenced 189: 190:
191: 199: fyi: anchor downstream not referenced 198: 199:
200: 205: fyi: anchor head-end not referenced 204: 205:
206: 212: fyi: anchor mac packet not referenced 211: 212:
213: 218: fyi: anchor rf not referenced 217: 218:
219: 224: fyi: anchor snmp not referenced 223: 224:
225: 232: fyi: anchor upstream not referenced 231: 232:
233: 240: fyi: anchor introduction not referenced 239: 240:
241: 263: fyi: anchor mibstructure not referenced 262: 263:
264: 308: fyi: anchor ipv4 not referenced 307: 308:
309: 321: fyi: anchor management not referenced 320: 321:
322: 323: fyi: anchor upgrades not referenced 322: 323:
324: 366: fyi: anchor events not referenced 365: 366:
367: 380: fyi: anchor throttling not referenced 379: 380:
381: 388: fyi: anchor ratethrottling not referenced 387: 388:
389: 409: fyi: anchor limitingrate not referenced 408: 409:
410: 430: fyi: anchor protocolfilters not referenced 429: 430:
431: 451: error:
inside is deprecated by rfc2629bis 450: filters. 451:
452: 491: fyi: anchor inboundllcfilters not referenced 490: 491:
492: 506: fyi: anchor specialfilters not referenced 505: 506:
507: 513: fyi: anchor spoofingfilters not referenced 512: 513:
514: 540: fyi: anchor snmpfilters not referenced 539: 540:
541: 559: fyi: anchor ipfilters not referenced 558: 559:
560: 609: fyi: anchor outboundllcfilters not referenced 608: 609:
610: 624: fyi: anchor definitions not referenced 623: 624:
625: 626: error:
inside is deprecated by rfc2629bis 625: 626:
627: 3777: 3790: fyi: anchor revisions not referenced 3789: 3790:
3791: 3829: fyi: anchor securityconsiderations not referenced 3828: 3829:
3830: 3: warning: anchor RFC2863 not referenced 2: 3: 4: 3: fyi: anchor RFC3014 referred to in plain text as [RFC3014] 2: 3: 4: 3: warning: anchor RFC3411 not referenced 2: 3: 4: 3: fyi: anchor RFC3413 referred to in plain text as [RFC3413] 2: 3: 4: 3: warning: anchor RFC3617 not referenced 2: 3: 4: 4084: warning: anchor OSSI1.1 not referenced 4083: 4084: 4085: 4095: warning: anchor OSSI2.0 not referenced 4094: 4095: 4096: ...done 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 From ipcdn-bounces@ietf.org Wed Jul 06 17:53:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqHpb-0008M2-8n; Wed, 06 Jul 2005 17:53:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqHpZ-0008Kq-3t for ipcdn@megatron.ietf.org; Wed, 06 Jul 2005 17:53:21 -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 RAA01914 for ; Wed, 6 Jul 2005 17:53:18 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqIGb-0003er-10 for ipcdn@ietf.org; Wed, 06 Jul 2005 18:21:19 -0400 Received: from h-64-105-136-184.snvacaid.dynamic.covad.net ([64.105.136.184] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DqHpN-00024u-00 for ipcdn@ietf.org; Wed, 06 Jul 2005 17:53:09 -0400 Message-ID: <001001c58275$ac403240$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6EEEACD9D7F52940BEE26F5467C02C73807325@PACDCEXCMB01.cable.comcast.com> Subject: Re: [ipcdn] Problems in XML source of Cable Device MIB, Draft 09 Date: Wed, 6 Jul 2005 14:57:14 -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: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi - > From: "Woundy, Richard" > To: "Randy Presuhn" ; "Marez Kevin-MGI1375" > Cc: > Sent: Wednesday, July 06, 2005 2:25 PM > Subject: RE: [ipcdn] Problems in XML source of Cable Device MIB, Draft 09 ... > The comments in your six emails (below is the first one I received) look > very reasonable. Thanks. :-) Keep in mind that these are really just commentary on the diagnostics generated by tools. I still need to plow through the document "manually" for the stuff that programs don't catch (yet). Those are the comments that are more likely to need discussion. > I would like to post a revised draft that addresses all of your comments > before the July 18th cut-off. Kevin, can we talk about how we would do > this in an offline discussion? Fine with me, just keep in mind my comment above. > I think the WG needs to discuss which deprecated groups should be > included in the docsDevCmCompliance and docsDevCmtsCompliance statement > (if any). In my opinion, some (if not all) of the deprecated groups need > to be implemented on CMs and CMTSs for backwards compatibility with > various cable OSS systems... but maybe cable operators are ready to drop > support for some of these deprecated groups, and this draft should > reflect that. As long as the WG is able to agree on what it wants to say, we can make sure the MIB module conformance material reflects that intent. > I have oonly a few minor reactions to your other comments, that I will > address over the next few days. For example, with respect to > docsDevNmAccessTable, according to DOCSIS a cable modem may boot in a > mode where SNMP Coexistence mode is disabled, but the same cable modem > may boot in a mode where SNMP Coexistance mode or SNMPv3 management is > enabled, depending on the boot parameters received. ... Understood. Two points I'll offer in reply: 1) A more common way of modeling this kind of a situation in a MIB module would for the tables to always be available, independent of the "mode" in use at the moment, with a separate object indicating the current mode. However, I recognize that changing this aspect of this MIB module does not seem to make sense at this stage. 2) As this draft's own security considerations section states, "deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED". Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sat Jul 16 02:26:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtg8J-0006TZ-Mk; Sat, 16 Jul 2005 02:26:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtg8F-0006TQ-1I for ipcdn@megatron.ietf.org; Sat, 16 Jul 2005 02:26:41 -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 CAA27839 for ; Sat, 16 Jul 2005 02:26:37 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtgbC-0004cX-0i for ipcdn@ietf.org; Sat, 16 Jul 2005 02:56:35 -0400 Received: from h-68-165-6-174.snvacaid.dynamic.covad.net ([68.165.6.174] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dtg88-00042T-00 for ipcdn@ietf.org; Sat, 16 Jul 2005 02:26:32 -0400 Message-ID: <000d01c589cf$5170a6e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" Date: Fri, 15 Jul 2005 23:26:35 -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: a8a20a483a84f747e56475e290ee868e Subject: [ipcdn] Review comments on draft 09 of cable device MIB X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org 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 IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sat Jul 16 14:17:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrDs-0006qP-7k; Sat, 16 Jul 2005 14:17:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrDq-0006ps-Jz for ipcdn@megatron.ietf.org; Sat, 16 Jul 2005 14:17:10 -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 OAA19956 for ; Sat, 16 Jul 2005 14:17:08 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtp3e-0008IQ-6W for ipcdn@ietf.org; Sat, 16 Jul 2005 11:58:31 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j6GFSICE029698; Sat, 16 Jul 2005 10:28:18 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 16 Jul 2005 17:28:17 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507986417@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Randy Presuhn , "Ipcdn (E-mail)" Subject: RE: [ipcdn] Review comments on draft 09 of cable device MIB Date: Sat, 16 Jul 2005 17:28:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Thanks Randy! Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jul 20 10:33:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvFe2-0005ix-63; Wed, 20 Jul 2005 10:33:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvFe0-0005i5-1k for ipcdn@megatron.ietf.org; Wed, 20 Jul 2005 10:33:56 -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 KAA21732 for ; Wed, 20 Jul 2005 10:33:53 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvG7p-0006jW-L0 for ipcdn@ietf.org; Wed, 20 Jul 2005 11:04:47 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j6KEXVdV019651; Wed, 20 Jul 2005 08:33:31 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Agenda for the IETF#63 IPCDN meeting, Mon 8/1/2005 in Paris Date: Wed, 20 Jul 2005 08:33:33 -0600 Message-ID: Thread-Topic: [ipcdn] Agenda for the IETF#63 IPCDN meeting, Mon 8/1/2005 in Paris Thread-Index: AcWNOBVZCR63P7O9TZGRiirLXFOlsw== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: "Richard Woundy @ Comcast" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org The ipcdn wg has a scheduled working session at next IETF on MONDAY, August 1, 2005, from 9-10am. See http://www.ietf.org/meetings/agenda_63.txt We have about 5 documents left in our WG charter and we will use the 1 hour time as a working session to discuss open issues. There will be no slides for this meeting (we will use text from emails summarizing open issues in the working session). Below is a proposed agenda, let us know if you have any comments. I will wait until Friday 9am MT to send the final agenda out for posting. IP over Cable Data Network WG (ipcdn) IETF #63 =20 MONDAY, August 1, 2005, from 0900-1000 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Chairs: Richard Woundy Jean-Francois Mule =20 AGENDA: =20 I. Agenda Bashing II. Administration =20 III. IPCDN DOCSIS mibs =20 o DOCSIS Cable Device MIB version 2 draft-ietf-ipcdn-device-mibv2-09.txt Editors: Kevin Marez & Rich Woundy http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt o RF MIB v2 draft-ietf-ipcdn-docs-rfmibv2-13.txt Editor: Eduardo Cardona http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-13.txt IV. IPCablecom/PacketCable Submissions o MTA MIB draft-ietf-ipcdn-pktc-mtamib-06.txt http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-06.txt o Signaling MIB draft-ietf-ipcdn-pktc-signaling-08.txt=20 =20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-08.t xt=20 o Management Event MIB draft-ietf-ipcdn-pktc-eventmess-04.txt =20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-04.t xt V. Next steps -- Richard Woundy and Jean-Francois Mule, IPCDN co-chairs _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sun Jul 24 21:41:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwryO-0000HS-CY; Sun, 24 Jul 2005 21:41:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwryM-0000HI-9V for ipcdn@megatron.ietf.org; Sun, 24 Jul 2005 21:41:38 -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 VAA11082 for ; Sun, 24 Jul 2005 21:41:35 -0400 (EDT) Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwsT6-0004jt-V6 for ipcdn@ietf.org; Sun, 24 Jul 2005 22:13:25 -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 Date: Sun, 24 Jul 2005 21:38:19 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73807486@PACDCEXCMB01.cable.comcast.com> Thread-Topic: Cable Device MIB -10 text for discussion Thread-Index: AcWKM4VZiMGB5kSgSNu1Yl52r9N2xAGhGvsA From: "Woundy, Richard" To: "Ipcdn \(E-mail\)" X-OriginalArrivalTime: 25 Jul 2005 01:40:55.0344 (UTC) FILETIME=[E6156B00:01C590B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Content-Transfer-Encoding: quoted-printable Cc: Randy Presuhn , "Wijnen, Bert \(Bert\)" , Marez Kevin-MGI1375 , "Woundy, Richard" , Jean-Francois Mule Subject: [ipcdn] Cable Device MIB -10 text for discussion X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Folks, Kevin Marez and I have been working on an update to the Cable Device MIB. We were unable to make the July 18th draft submission cut-off, but we are posting a "-10" version on the www.ipcdn.org for review by the working group, our MIB doctor (Randy Presuhn), and our Area Director/Advisor (Bert Wijnen). Below are links to the XML version, TXT version, and diffs, respectively: There are four significant discussion points remaining in this draft, based on our understanding of the last MIB doctor review. Below are the key MIB objects followed by MIB doctor comments and author comments. 1. docsDevNmAccessInterfaces OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..32)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Specifies the set of interfaces from which requests from this NMS will be accepted. Each octet within the value of this object specifies a set of eight interfaces, with the first octet specifying ports 1 through 8, the second octet specifying interfaces 9 through 16, etc. Within each octet, the most significant bit represents the lowest numbered interface, and the least significant bit represents the highest numbered interface. Thus, each interface is represented by a single bit within the value of this object. If that bit has a value of '1' then that interface is included in the set. Note that entries in this table apply only to link-layer interfaces (e.g., Ethernet and CATV MAC). Bits representing upstream and downstream channel interfaces MUST NOT be set to '1'. Note that according to the DOCSIS OSSIv1.1 specification, when ifIndex '1' is included in the set, then this row applies to all CPE (customer-facing) interfaces. The size of this object is the minimum required to represent all configured interfaces for this device." DEFVAL { '80000000'h } ::=3D { docsDevNmAccessEntry 6 } -- Randy comments: --> 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? --> 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.... -- [KMarez] Yes, a lot of questions. Since the object is -- deprecated, can we just let this one go? I think it might be -- reasonable to address two things though: -- * Clarify which octet is the 'first' one. From left or -- right? While this might be implicit, it's probably good -- to state it. -- * Clarify what to do with bits that correspond to -- non-existent interfaces. -- [RWoundy] I am sure that the wrong bit was set in the DEFVAL -- (fixed). -- I don't know how to make the DESCRIPTION any clearer. -- I'm not sure how to do the wording for the "non-existent -- interfaces". The general intent is that if an octet is -- missing from the value of this object, then that octet -- implicitly has the value '0' for all bits. 2. docsDevNmAccessStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Controls and reflects the status of rows in this table. Rows in this table may be created by either the create-and-go or create-and-wait paradigms. There is no restriction on changing values in a row of this table while the row is active. The following objects MUST have valid values before this object can be set to active: docsDevNmAccessIp, docsDevNmAccessStatus, docsDevNmAccessIpMask, docsDevNmAccessCommunity, docsDevNmAccessControl and docsDevNmAccessInterfaces." ::=3D { docsDevNmAccessEntry 7 } -- Randy comments: -- 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. -- 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. -- [KMarez] I added text to address specifying which columnar -- objects have to be set before the the row can be activated. It -- appears that docsDevFilterIpStatus and -- docsDevFilterTosStatus actually covered that MUST. -- You may want to confirm the others. -- [RWoundy] My presumption is that docsDevEvControlTable rows with -- local(0) reporting MUST persist across reboots on cable -- modems, and all other tables on cable modems (e.g. -- docsDevNmAccess, docsDevFilterLLC, docsDevFilterIp, -- docsDevFilterPolicy, docsDevFilterTos, docsDevCpeInet) MUST NOT -- persist across reboots on cable modems. Probably should be -- discussed in the WG. -- Also, we should change the DESCRIPTION of docsDevCpeStatus -- and docsDevCpeInetRowStatus to document how the agent adds rows. 3. docsDevEvReporting OBJECT-TYPE SYNTAX BITS { local(0), traps(1), syslog(2), localVolatile(8), stdInterface(9) } MAX-ACCESS read-write STATUS current DESCRIPTION "Defines the action to be taken on occurrence of this event class. Implementations may not necessarily support all options for all event classes, but at minimum must allow traps and syslogging to be disabled. If the local(0) bit is set, then log to the internal log and update non-volatile store, for backward compatibility with the original RFC 2669 definition. If the traps(1) bit is set, then generate an SNMP trap, and if the syslog(2) bit is set, then send a syslog message (assuming the syslog address is set). If the localVolatile(8) bit is set, then log to the internal log without updating non-volatile store. If the stdInterface(9) bit is set, then the agent ignores all other bits except the local(0), syslog(2) and localVolatile(8) bits. Setting the stdInterface(9) bit indicates that RFC3413 and RFC3014 are being used to control event reporting mechanisms. =20 Any attempt to SET the traps(1) or syslog(2) bits without setting the local(0) or localVolatile(8) bits MUST result in an error being generated." ::=3D { docsDevEvControlEntry 2 } -- Randy comments: --> I'm puzzled by this addition: -- Any attempt to SET the traps(1) or syslog(2) bits -- without setting the local(0) or localVolatile(8) -- bits MUST result in an error being generated." -- Where did this come from? -- [KMarez] I've no idea where this came from either. I cleaned -- up the wording a bit on it, but the text was there in the -- -06 version that I got from Rich. -- [RWoundy] I don't remember exactly where this came from, -- either. I think the concern was that there is information -- captured in the docsDevEventTable that may not be -- reflected in either SNMP PDUs or SYSLOG messages, and -- that with the advent of localVolatile(8) logging -- there is no implementation barrier to capturing all -- events in docsDevEventTable. 4. docsDevFilterLLCTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevFilterLLCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of filters to apply to (bridged) LLC traffic. The filters in this table are applied to incoming traffic on the appropriate interface(s) prior to any further processing (e.g. before handing the packet off for level 3 processing, or for bridging). The specific action taken when no filter is matched is controlled by docsDevFilterLLCUnmatchedAction. Table entries MAY persist across reboots for any device." ::=3D { docsDevFilter 2 } -- Randy comments: --> the added text "Table entries are not required to persist -- across reboots for any device." is a little odd. More RFC -- 2119-like would be something like "Table entries MAY persist -- across reboots for any device" or "Persistance of table entries -- across reboots is OPTIONAL for all devices." (Whether this -- optionality would be a good thing is a separate discussion.) -- [KMarez] Done. -- [RWoundy] --> My presumption is we should say here, "Table entries MUST NOT -- persist across reboots for cable modems." I think this requirement -- needs to be applied to NmAccess, FilterLLC, FilterIp, Policy, Tos, -- Cpe and InetCpe tables. This may require more discussion. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sun Jul 24 21:51:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dws8A-0001eG-7Y; Sun, 24 Jul 2005 21:51:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dws89-0001eB-Mi for ipcdn@megatron.ietf.org; Sun, 24 Jul 2005 21:51:45 -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 VAA11695 for ; Sun, 24 Jul 2005 21:51:43 -0400 (EDT) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwscs-000519-I8 for ipcdn@ietf.org; Sun, 24 Jul 2005 22:23:33 -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] Problems in XML source of Cable Device MIB, Draft 09 Date: Sun, 24 Jul 2005 21:48:34 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73807487@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [ipcdn] Problems in XML source of Cable Device MIB, Draft 09 Thread-Index: AcV5RRg16zTj90DAThaLfqdedj3OTQXdIoOg From: "Woundy, Richard" To: "Ipcdn \(E-mail\)" X-OriginalArrivalTime: 25 Jul 2005 01:51:12.0499 (UTC) FILETIME=[55EFCC30:01C590BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 Content-Transfer-Encoding: quoted-printable Cc: Randy Presuhn , "Woundy, Richard" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Randy, I used the tool to clean up most of the XML formatting errors in . I removed the unreferenced anchors, removed spaces from reference targets (e.g. "ITU-T J.112" became "ITU-T_J.112"), and removed "
inside ". I was unable to avoid the following errors from the tool. All of these normative references are either from the IMPORTS clause, or from one or more REFERENCE clauses. Validation results for C:\Documents and Settings\rwound00\Desktop\ipcdn resources\cable device mib\draft-ietf-ipcdn-device-mibv2-10-discussion.xml Processing... Validating document... Validation succeeded Performing additional checks... 3: warning: anchor RFC2021 not referenced 2: 3: 4: 3: warning: anchor RFC2863 not referenced 2: 3: 4: 3: warning: anchor RFC3411 not referenced 2: 3: 4: 3: warning: anchor RFC3617 not referenced 2: 3: 4: 4150: warning: anchor OSSI1.1 not referenced 4149:=20 4150: 4151: 4161: warning: anchor OSSI2.0 not referenced 4160:=20 4161: 4162: ...done=20 -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Saturday, June 25, 2005 1:15 AM To: Ipcdn (E-mail) Subject: [ipcdn] Problems in XML source of Cable Device MIB, Draft 09 Hi Rich - > From: "Woundy, Richard" > To: "Randy Presuhn" > Sent: Friday, June 24, 2005 11:51 AM > Subject: RE: [ipcdn] Cable Device MIB, Draft 09 released > > Thanks! I attached the XML version, which might help slightly. ... I tried Bill Fenner's tool on it, and got quite a few diagnostics. Background by Bill: Another tool that is worth running on the xml source before using xml2rfc on it is at http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ ; it will check that the source is well-formed and valid according to the DTD (XML generated outside of a validating editor is often not valid, and sometimes even not well-formed, even though xml2rfc creates a fine-looking document from it), and also checks for various other errors including the IPR requested. The warnings are mostly due to inappropriate characters (like spaces or periods) in things like xref targets and anchors. Clear those up, and you'll know whether the complaints about unreferenced references are real. These aren't terribly critical, as far as I'm concerned, but it's probably good housekeeping to take care of them now, since it would be one less potential source of error during final RFC editing. The messages I received were: Validation results for C:\My Documents\draft-ietf-ipcdn-device-mibv2-09.xml Processing... Validating document... 193: element xref: validity error : Syntax of value for attribute target of xref is not valid 192: "Data-Over-Cable Service Interface Specification". A term referring to the 193: ITU-T J.112 194: Annex B standard for cable modem systems. 212: element section: validity error : Syntax of value for attribute anchor of section is not valid 211: 212:
213: 4061: element reference: validity error : Syntax of value for attribute anchor of reference is not valid 4060: 4061: 4062: ...validation failed Performing additional checks... 142: fyi: anchor framework not referenced 141: 142:
143: 159: fyi: anchor glossary not referenced 158: 159:
160: 165: fyi: anchor catv not referenced 164: 165:
166: 173: fyi: anchor cm not referenced 172: 173:
174: 180: fyi: anchor cmts not referenced 179: 180:
181: 190: fyi: anchor docsis not referenced 189: 190:
191: 199: fyi: anchor downstream not referenced 198: 199:
200: 205: fyi: anchor head-end not referenced 204: 205:
206: 212: fyi: anchor mac packet not referenced 211: 212:
213: 218: fyi: anchor rf not referenced 217: 218:
219: 224: fyi: anchor snmp not referenced 223: 224:
225: 232: fyi: anchor upstream not referenced 231: 232:
233: 240: fyi: anchor introduction not referenced 239: 240:
241: 263: fyi: anchor mibstructure not referenced 262: 263:
264: 308: fyi: anchor ipv4 not referenced 307: 308:
309: 321: fyi: anchor management not referenced 320: 321:
322: 323: fyi: anchor upgrades not referenced 322: 323:
324: 366: fyi: anchor events not referenced 365: 366:
367: 380: fyi: anchor throttling not referenced 379: 380:
381: 388: fyi: anchor ratethrottling not referenced 387: 388:
389: 409: fyi: anchor limitingrate not referenced 408: 409:
410: 430: fyi: anchor protocolfilters not referenced 429: 430:
431: 451: error:
inside is deprecated by rfc2629bis 450: filters. 451:
452: 491: fyi: anchor inboundllcfilters not referenced 490: 491:
492: 506: fyi: anchor specialfilters not referenced 505: 506:
507: 513: fyi: anchor spoofingfilters not referenced 512: 513:
514: 540: fyi: anchor snmpfilters not referenced 539: 540:
541: 559: fyi: anchor ipfilters not referenced 558: 559:
560: 609: fyi: anchor outboundllcfilters not referenced 608: 609:
610: 624: fyi: anchor definitions not referenced 623: 624:
625: 626: error:
inside is deprecated by rfc2629bis 625: 626:
627: 3777: 3790: fyi: anchor revisions not referenced 3789: 3790:
3791: 3829: fyi: anchor securityconsiderations not referenced 3828: 3829:
3830: 3: warning: anchor RFC2863 not referenced 2: 3: 4: 3: fyi: anchor RFC3014 referred to in plain text as [RFC3014] 2: 3: 4: 3: warning: anchor RFC3411 not referenced 2: 3: 4: 3: fyi: anchor RFC3413 referred to in plain text as [RFC3413] 2: 3: 4: 3: warning: anchor RFC3617 not referenced 2: 3: 4: 4084: warning: anchor OSSI1.1 not referenced 4083: 4084: 4085: 4095: warning: anchor OSSI2.0 not referenced 4094: 4095: 4096: ...done 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 From ipcdn-bounces@ietf.org Sun Jul 24 22:15:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwsTd-0005IR-PB; Sun, 24 Jul 2005 22:13:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwsTb-0005ID-UX for ipcdn@megatron.ietf.org; Sun, 24 Jul 2005 22:13:56 -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 WAA12944 for ; Sun, 24 Jul 2005 22:13:53 -0400 (EDT) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwsyN-0005ca-8d for ipcdn@ietf.org; Sun, 24 Jul 2005 22:45:43 -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] idnits and smilint on Cable Device MIB Draft 09 Date: Sun, 24 Jul 2005 22:12:08 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73807489@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [ipcdn] idnits and smilint on Cable Device MIB Draft 09 Thread-Index: AcV5SaeI8hUEv9OZQ2qt7ch4yoTpYAXcYA7w From: "Woundy, Richard" To: "Ipcdn \(E-mail\)" X-OriginalArrivalTime: 25 Jul 2005 02:13:21.0294 (UTC) FILETIME=[6DF5D2E0:01C590BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable Cc: Randy Presuhn , "Woundy, Richard" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Folks, With respect to the discussion version of the Cable Device MIB -10: I get the same clean output from idnits, and now much better output from smilint. The significant MIB compilation problem with version -09 was the inclusion of deprecated groups in the current compliance statements 'docsDevCmCompliance' and 'docsDevCmtsCompliance'. After further discussion among the authors, we decided that we should remove the deprecated groups from the current compliance statement. The key realization is that if a particular version of DOCSIS requires implementation of a deprecated group, then that requirement can be captured in a CableLabs specification, not in this internet-draft/RFC. This internet-draft/RFC should be agnostic with regards to DOCSIS versions and their (evolving) requirements. The unfortunate consequence is that the group 'docsDevNmAccessExtGroup' is no longer referenced by any compliance statement. This group consists of a single MIB object that was invented by CableLabs after publication of RFC 2669. We still include this MIB object (and group) for future reference -- although it is immediately deprecated. Note that we post-dated the MIB to August 8, hence the "future date" warnings. --- Here is the latest smilint output: This is an automatically generated mail message in response to a mail message you (or someone else who used your address) sent to . If you want to learn more about this mail service, send a mail message with the "Subject: help" to . The program smilint 0.4.3, as of Thu Jun 23 10:41:27 2005 has been used to process your request as follows: smilint -m -s -e -l 6 mailbody mailbody:43: [4] {date-in-future} warning: date specification `200508080000Z' is in the future mailbody:81: [4] {date-in-future} warning: date specification `200508080000Z' is in the future mailbody:2394: [5] {index-exceeds-too-large} warning: index of row `docsDevCpeInetEntry' can exceed OID size limit by 141 subidentifier(s) mailbody:3100: [5] {group-unref} warning: deprecated group `docsDevNmAccessExtGroup' is not referenced in this module -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Saturday, June 25, 2005 1:51 AM To: Ipcdn (E-mail) Subject: [ipcdn] idnits and smilint on Cable Device MIB Draft 09=20 Hi - Good news and not-so-good news. On ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt, I ran http://ietf.levkowetz.com/tools/idnits/idnits.pyht, and it gave the -09 a clean bill of health: idnits 1.74 tmp/draft-ietf-ipcdn-device-mibv2-09.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. No nits found. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. No nits found. When I ran smilint 0.4.3, things were a bit more interesting. (I used the smilint@ibr.cs.tu-bs.de service) It identified two issues. mailbody:2489: [5] {index-exceeds-too-large} warning: index of row `docsDevCpeInetEntry' can exceed OID size limit by 141 subidentifier(s) This is OK, the DESCRIPTION of docsDevCpeInetAddr explains the situation in the spirit of the MBI review guidelines section 4.6.6 mailbody:3013: [4] {compliance-group-status} warning: current compliance statement `docsDevCmCompliance' includes deprecated group `docsDevNmAccessGroup' mailbody:3031: [4] {compliance-group-status} warning: current compliance statement `docsDevCmCompliance' includes deprecated group `docsDevNmAccessExtGroup' mailbody:3044: [4] {compliance-group-status} warning: current compliance statement `docsDevCmCompliance' includes deprecated group `docsDevFilterGroup' mailbody:3195: [4] {compliance-group-status} warning: current compliance statement `docsDevCmtsCompliance' includes deprecated group `docsDevNmAccessGroup' mailbody:3206: [4] {compliance-group-status} warning: current compliance statement `docsDevCmtsCompliance' includes deprecated group `docsDevNmAccessExtGroup' mailbody:3235: [4] {compliance-group-status} warning: current compliance statement `docsDevCmtsCompliance' includes deprecated group `docsDevFilterGroup' mailbody:3247: [4] {compliance-group-status} warning: current compliance statement `docsDevCmtsCompliance' includes deprecated group `docsDevCpeGroup' This doesn't look OK. I think what you wanted to say was that the old docsDevCmCompliance should be deprecated, and that there will be a docDevCmComplianceRev1 (or whatever a good name would be) that has only the "current" stuff from docsDevCmCompliance. Alternatively, you could keep the old compliance stuff as-is, and just add a docDevCmComplianceRev1. It depends on the message you want to send. I'll look at the smidiff output separately. 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 From ipcdn-bounces@ietf.org Sun Jul 24 22:18:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwsXu-0005yH-T7; Sun, 24 Jul 2005 22:18:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwsXt-0005yC-4v for ipcdn@megatron.ietf.org; Sun, 24 Jul 2005 22:18:21 -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 WAA13284 for ; Sun, 24 Jul 2005 22:18:18 -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 1Dwt2e-0005mo-KA for ipcdn@ietf.org; Sun, 24 Jul 2005 22:50:09 -0400 Received: from ([10.52.116.10]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.12446205; Sun, 24 Jul 2005 22:17:50 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 24 Jul 2005 22:17:50 -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] idnits and smilint on Cable Device MIB Draft 09 Date: Sun, 24 Jul 2005 22:15:37 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7380748A@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [ipcdn] idnits and smilint on Cable Device MIB Draft 09 Thread-Index: AcV7XA46Y7j9edL0RrqAVVDy4rB7oAVYlgKw From: "Woundy, Richard" To: "Randy Presuhn" X-OriginalArrivalTime: 25 Jul 2005 02:17:50.0214 (UTC) FILETIME=[0E3FC260:01C590BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: "Ipcdn \(E-mail\)" , "Woundy, Richard" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Randy, Kevin Marez and I had an offline discussion about these deprecated groups. We concluded that if CableLabs needs to specify the implementation of these deprecated groups for interim compliance testing, then that can be handled outside of the IETF standardization process. So we have modified the current compliance statements so that they do not include deprecated groups. -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Monday, June 27, 2005 5:07 PM To: Ipcdn (E-mail) Subject: Re: [ipcdn] idnits and smilint on Cable Device MIB Draft 09=20 Hi - > From: "Marez Kevin-MGI1375" > To: "Randy Presuhn" ; "Ipcdn \(E-mail\)" > > Sent: Monday, June 27, 2005 12:26 PM > Subject: RE: [ipcdn] idnits and smilint on Cable Device MIB Draft 09 ... > Randy, > > Thanks very much for the speedy review! Regarding your 'not-so-good=20 > news', > > I think what you wanted to say was that the old docsDevCmCompliance > should be deprecated, and that there will be a docDevCmComplianceRev1 > (or whatever a good name would be) that has only the "current"=20 > stuff from docsDevCmCompliance. Alternatively, you could keep the old compliance > stuff as-is, and just add a docDevCmComplianceRev1. It depends on the > message you want to send. > > we had actually discussed this previously and reached the following=20 > conclusion (this was per an "internal" discussion with Rich Woundy and others in response to the question of having compliance statements contain deprecated objects): > > Hopefully the MIB doctors are OK with these compliance statements=20 > as-is. Note the following text from the MIB guidelines, page 30 of=20 > nes-03 > .txt>: > > - The status of a compliance statement is independent of the status > of its members. Thus, a current compliance statement MAY refer to > deprecated object groups or notification groups. This may be > desirable in certain cases, e.g., a set of widely-deployed object > or notification groups may be deprecated when they are replaced by > a more up-to-date set of definitions, but compliance statements > that refer to them may remain current in order to encourage > continued implementation of the deprecated groups. > > Please let me know if this is acceptable. Thanks very much, ... It's ok with me if it's really the case that the WG wants to "encourage continued implementation of the deprecated groups". When I look at what has actaully been deprecated, it's seems to me that that is not the intent. 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 From ipcdn-bounces@ietf.org Sun Jul 24 22:26:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwsfU-00077z-FP; Sun, 24 Jul 2005 22:26:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwsfT-00077r-0Z for ipcdn@megatron.ietf.org; Sun, 24 Jul 2005 22:26:11 -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 WAA14037 for ; Sun, 24 Jul 2005 22:26:08 -0400 (EDT) Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwtAD-00065H-7i for ipcdn@ietf.org; Sun, 24 Jul 2005 22:57:58 -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] smidiff diagnostics fordraft-ietf-ipcdn-device-mibv2-09.txt (part 1) Date: Sun, 24 Jul 2005 22:24:06 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7380748B@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [ipcdn] smidiff diagnostics fordraft-ietf-ipcdn-device-mibv2-09.txt (part 1) Thread-Index: AcV7lrtMHbDM6p+/SzewZ6Arazr+CwVKBnSg From: "Woundy, Richard" To: "Randy Presuhn" X-OriginalArrivalTime: 25 Jul 2005 02:25:30.0135 (UTC) FILETIME=[20622270:01C590C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: f560cc438c8be83d0aa5c816c29b481c Content-Transfer-Encoding: quoted-printable Cc: "Ipcdn \(E-mail\)" , "Woundy, Richard" , Marez Kevin-MGI1375 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-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: Tuesday, June 28, 2005 12:09 AM To: Ipcdn (E-mail) Subject: [ipcdn] smidiff diagnostics fordraft-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. [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'." ::=3D { docsDevBase 2 } 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." [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." ::=3D { docsDevMIBObjects 2 } 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. [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 } ::=3D { docsDevNmAccessEntry 2 } 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. [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 } ::=3D { docsDevNmAccessEntry 3 } 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? [RW] We changed the DEFVAL to { '80000000'h }, thanks! 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. 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. [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." ::=3D { docsDevSoftware 2 } 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. :^( 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 _______________________________________________ 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 From ipcdn-bounces@ietf.org Sun Jul 24 22:34:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwsne-0000hz-Kj; Sun, 24 Jul 2005 22:34:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwsnb-0000hh-CB for ipcdn@megatron.ietf.org; Sun, 24 Jul 2005 22:34:36 -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 WAA14812 for ; Sun, 24 Jul 2005 22:34:32 -0400 (EDT) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwtIM-0006Ph-OH for ipcdn@ietf.org; Sun, 24 Jul 2005 23:06:23 -0400 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.12357857; Sun, 24 Jul 2005 22:34:22 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 24 Jul 2005 22:34:22 -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] smidiff diagnostics fordraft-ietf-ipcdn-device-mibv2-09.txt (part 2) Date: Sun, 24 Jul 2005 22:32:08 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7380748C@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [ipcdn] smidiff diagnostics fordraft-ietf-ipcdn-device-mibv2-09.txt (part 2) Thread-Index: AcV7qi01lR6JkID+R+2yeNWRw3U3ZAVFcXhQ From: "Woundy, Richard" To: "Ipcdn \(E-mail\)" X-OriginalArrivalTime: 25 Jul 2005 02:34:22.0002 (UTC) FILETIME=[5D669920:01C590C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Content-Transfer-Encoding: quoted-printable Cc: Randy Presuhn , Marez Kevin-MGI1375 , "Woundy, Richard" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-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: Tuesday, June 28, 2005 2:26 AM To: Ipcdn (E-mail) Subject: [ipcdn] smidiff diagnostics fordraft-ietf-ipcdn-device-mibv2-09.txt (part 2) Hi - Here's the second part of the smidiff diagnostics, with my comments interspersed. draft-ietf-ipcdn-device-mibv2-09.txt:1008 [3] {defval-added} default value added to `docsDevEvThrottleAdminStatus' draft-ietf-ipcdn-device-mibv2-09.txt:1008 [5] {description-changed} description of `docsDevEvThrottleAdminStatus' changed rfc2669.txt:554 [6] {previous-definition} previous definition of `docsDevEvThrottleAdminStatus' -> ok draft-ietf-ipcdn-device-mibv2-09.txt:1043 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevEvThrottleInhibited' draft-ietf-ipcdn-device-mibv2-09.txt:1043 [5] {description-changed} description of `docsDevEvThrottleInhibited' changed rfc2669.txt:591 [6] {previous-definition} previous definition of `docsDevEvThrottleInhibited' -> ok draft-ietf-ipcdn-device-mibv2-09.txt:1064 [3] {defval-added} default value added to `docsDevEvThrottleThreshold' draft-ietf-ipcdn-device-mibv2-09.txt:1064 [5] {units-added} units added to `docsDevEvThrottleThreshold' draft-ietf-ipcdn-device-mibv2-09.txt:1064 [5] {description-changed} description of `docsDevEvThrottleThreshold' changed rfc2669.txt:604 [6] {previous-definition} previous definition of `docsDevEvThrottleThreshold' --> the changes are ok, but the object itself gives me heartburn. If it were formulated only in terms of internal events that could result in notifications being sent, it wouldn't bother me. As it is, it requires the subagent/component implementing this MIB to know about what has happened in two other subsystems: the SNMP engine and the syslog engine. Something more like the following DESCRIPTION would make me happy, if it isn't contrary to your intent: "Number of events per docsDevEvThrottleInterval permitted before throttling is to occur. A single event, whether the notification could result in messages transmitted using syslog, SNMP, or both protocols, and regardless of the number of destinations, (including zero) is always treated as a single event for threshold counting. That is, an event causing both a trap and a syslog message is still treated as a single event. All system notifications that occur within the device should be taken into consideration when calculating and monitoring the threshold." [RW] Here is the modified object definition: docsDevEvThrottleThreshold OBJECT-TYPE SYNTAX Unsigned32 UNITS "events" MAX-ACCESS read-write STATUS current DESCRIPTION "Number of events per docsDevEvThrottleInterval permitted before throttling is to occur. A single event, whether the notification could result in messages transmitted using syslog, SNMP, or both protocols, and regardless of the number of destinations, (including zero) is always treated as a single event for threshold counting. For example, an event causing both a trap and a syslog message is still treated as a single event. All system notifications that occur within the device should be taken into consideration when calculating and monitoring the threshold." DEFVAL { 0 } ::=3D { docsDevEvent 5 } draft-ietf-ipcdn-device-mibv2-09.txt:1085 [3] {defval-added} default value added to `docsDevEvThrottleInterval' draft-ietf-ipcdn-device-mibv2-09.txt:1085 [5] {description-changed} description of `docsDevEvThrottleInterval' changed rfc2669.txt:619 [6] {previous-definition} previous definition of `docsDevEvThrottleInterval' --> changes ok, but replace "the trap threshold" with "docsDevEvThrottleThreshold" [RW] 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 } ::=3D { docsDevEvent 6 } draft-ietf-ipcdn-device-mibv2-09.txt:1104 [5] {description-changed} description of `docsDevEvControlTable' changed rfc2669.txt:640 [6] {previous-definition} previous definition of `docsDevEvControlTable' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1141 [5] {description-changed} description of `docsDevEvPriority' changed rfc2669.txt:669 [6] {previous-definition} previous definition of `docsDevEvPriority' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1197 [5] {named-number-added} named number `localVolatile' added to type used in `docsDevEvReporting' draft-ietf-ipcdn-device-mibv2-09.txt:1197 [5] {named-number-added} named number `stdInterface' added to type used in `docsDevEvReporting' draft-ietf-ipcdn-device-mibv2-09.txt:1197 [5] {description-changed} description of `docsDevEvReporting' changed --> minor formatting problem in DESCRIPTION (check indentation) I'm puzzled by this addition: Any attempt to SET the traps(1) or syslog(2) bits without setting the local(0) or localVolatile(8) bits MUST result in an error being generated." Where did this come from? [RW] We are still working this issue. draft-ietf-ipcdn-device-mibv2-09.txt:1197 [5] {ref-added} reference added to `docsDevEvReporting' rfc2669.txt:699 [6] {previous-definition} previous definition of `docsDevEvReporting' --> this reference doesn't explain what this object does, so I suggest removing it. [RW] It has been removed. draft-ietf-ipcdn-device-mibv2-09.txt:1240 [5] {description-changed} description of `docsDevEventTable' changed rfc2669.txt:718 [6] {previous-definition} previous definition of `docsDevEventTable' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1251 [5] {description-changed} description of `docsDevEventEntry' changed rfc2669.txt:732 [6] {previous-definition} previous definition of `docsDevEventEntry' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1298 [5] {description-changed} description of `docsDevEvFirstTime' changed rfc2669.txt:774 [6] {previous-definition} previous definition of `docsDevEvFirstTime' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1307 [5] {description-changed} description of `docsDevEvLastTime' changed rfc2669.txt:787 [6] {previous-definition} previous definition of `docsDevEvLastTime' --> change ok, but the DESCRIPTION has some problems. It reads: "If multiple events are reported via the same entry, the value of docsDevDateTime that the last event for this entry occurred, otherwise this should have the same value as docsDevEvFirstTime. " To get rid of the "should", I suggest something like: "When an entry reports only one event, this object will have the same value as the corresponding instance of docsDecEvFirstTime. When an entry reports multiple events, this object will record the value that docsDevDateTime had when the most recent event for this entry occurred." [RW] Here is the modified object definition: docsDevEvLastTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "When an entry reports only one event, this object will have the same value as the corresponding instance of docsDevEvFirstTime. When an entry reports multiple events, this object will record the value that docsDevDateTime had when the most recent event for this entry occurred." ::=3D { docsDevEventEntry 3 } draft-ietf-ipcdn-device-mibv2-09.txt:1325 [5] {units-added} units added to `docsDevEvCounts' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1337 [5] {description-changed} description of `docsDevEvLevel' changed rfc2669.txt:811 [6] {previous-definition} previous definition of `docsDevEvLevel' --> ok, though I'm tempted to ask why there isn't a TC for this and docsDevEvPriority [RW] Good question, but we left this one alone. draft-ietf-ipcdn-device-mibv2-09.txt:1396 [5] {ref-added} reference added to `docsDevEvId' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1462 [3] {defval-added} default value added to `docsDevFilterLLCUnmatchedAction' draft-ietf-ipcdn-device-mibv2-09.txt:1462 [5] {description-changed} description of `docsDevFilterLLCUnmatchedAction' changed rfc2669.txt:869 [6] {previous-definition} previous definition of `docsDevFilterLLCUnmatchedAction' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1494 [5] {description-changed} description of `docsDevFilterLLCTable' changed rfc2669.txt:898 [6] {previous-definition} previous definition of `docsDevFilterLLCTable' --> the added text "Table entries are not required to persist across reboots for any device." is a little odd. More RFC 2119-like would be something like "Table entries MAY persist across reboots for any device" or "Persistance of table entries across reboots is OPTIONAL for all devices." (Whether this optionality would be a good thing is a separate discussion.) [RW] We are still working this issue. draft-ietf-ipcdn-device-mibv2-09.txt:1554 [5] {description-changed} description of `docsDevFilterLLCIfIndex' changed draft-ietf-ipcdn-device-mibv2-09.txt:1554 [5] {ref-added} reference added to `docsDevFilterLLCIfIndex' rfc2669.txt:956 [6] {previous-definition} previous definition of `docsDevFilterLLCIfIndex' --> ok 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 From ipcdn-bounces@ietf.org Sun Jul 24 22:53:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwt6G-0003Qy-M6; Sun, 24 Jul 2005 22:53:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwt6F-0003Qt-IQ for ipcdn@megatron.ietf.org; Sun, 24 Jul 2005 22:53:51 -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 WAA15889 for ; Sun, 24 Jul 2005 22:53:49 -0400 (EDT) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwtb0-0006vs-Fa for ipcdn@ietf.org; Sun, 24 Jul 2005 23:25:39 -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] smidiff diagnostics fordraft-ietf-ipcdn-device-mibv2-09.txt (part 3) Date: Sun, 24 Jul 2005 22:51:58 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7380748D@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [ipcdn] smidiff diagnostics fordraft-ietf-ipcdn-device-mibv2-09.txt (part 3) Thread-Index: AcV8dbE/eB0IPUiqSOOrDJNpLmFCcQUS2QUA From: "Woundy, Richard" To: "Ipcdn \(E-mail\)" X-OriginalArrivalTime: 25 Jul 2005 02:53:14.0885 (UTC) FILETIME=[00A6D350:01C590C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6852087d2a39b5d20c975154ae1cd415 Content-Transfer-Encoding: quoted-printable Cc: Randy Presuhn , Marez Kevin-MGI1375 , "Woundy, Richard" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-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: Wednesday, June 29, 2005 2:43 AM To: Ipcdn (E-mail) Subject: [ipcdn] smidiff diagnostics fordraft-ietf-ipcdn-device-mibv2-09.txt (part 3) Hi - Continuing with the smidiff diagnostics, with my comments interspered: draft-ietf-ipcdn-device-mibv2-09.txt:1576 [5] {description-changed} description of `docsDevFilterLLCProtocolType' changed rfc2669.txt:970 [6] {previous-definition} previous definition of `docsDevFilterLLCProtocolType' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1597 [5] {description-changed} description of `docsDevFilterLLCProtocol' changed rfc2669.txt:985 [6] {previous-definition} previous definition of `docsDevFilterLLCProtocol' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1610 [5] {units-added} units added to `docsDevFilterLLCMatches' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1623 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpDefault' draft-ietf-ipcdn-device-mibv2-09.txt:1623 [3] {defval-added} default value added to `docsDevFilterIpDefault' draft-ietf-ipcdn-device-mibv2-09.txt:1623 [5] {description-changed} description of `docsDevFilterIpDefault' changed rfc2669.txt:1014 [6] {previous-definition} previous definition of `docsDevFilterIpDefault' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1648 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpTable' draft-ietf-ipcdn-device-mibv2-09.txt:1648 [5] {description-changed} description of `docsDevFilterIpTable' changed rfc2669.txt:1029 [6] {previous-definition} previous definition of `docsDevFilterIpTable' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1713 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpEntry' rfc2669.txt:1079 [6] {previous-definition} previous definition of `docsDevFilterIpEntry' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1758 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpIndex' rfc2669.txt:1124 [6] {previous-definition} previous definition of `docsDevFilterIpIndex' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1768 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpStatus' rfc2669.txt:1134 [6] {previous-definition} previous definition of `docsDevFilterIpStatus' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1787 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpControl' draft-ietf-ipcdn-device-mibv2-09.txt:1787 [5] {description-changed} description of `docsDevFilterIpControl' changed rfc2669.txt:1158 [6] {previous-definition} previous definition of `docsDevFilterIpControl' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1817 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpIfIndex' draft-ietf-ipcdn-device-mibv2-09.txt:1817 [5] {description-changed} description of `docsDevFilterIpIfIndex' changed draft-ietf-ipcdn-device-mibv2-09.txt:1817 [5] {ref-added} reference added to `docsDevFilterIpIfIndex' rfc2669.txt:1182 [6] {previous-definition} previous definition of `docsDevFilterIpIfIndex' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1839 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpDirection' rfc2669.txt:1196 [6] {previous-definition} previous definition of `docsDevFilterIpDirection' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1859 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpBroadcast' rfc2669.txt:1216 [6] {previous-definition} previous definition of `docsDevFilterIpBroadcast' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1870 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpSaddr' rfc2669.txt:1227 [6] {previous-definition} previous definition of `docsDevFilterIpSaddr' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1883 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpSmask' rfc2669.txt:1240 [6] {previous-definition} previous definition of `docsDevFilterIpSmask' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1895 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpDaddr' draft-ietf-ipcdn-device-mibv2-09.txt:1895 [5] {description-changed} description of `docsDevFilterIpDaddr' changed rfc2669.txt:1252 [6] {previous-definition} previous definition of `docsDevFilterIpDaddr' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1914 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpDmask' rfc2669.txt:1270 [6] {previous-definition} previous definition of `docsDevFilterIpDmask' --> ok, but s/must/MUST/ in DESCRIPTION clause [RW] Here is the modified object definition: docsDevFilterIpDmask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "A bit mask that is to be applied to the destination address prior to matching. This mask is not necessarily the same as a subnet mask, but 1's bits MUST be leftmost and contiguous." DEFVAL { '00000000'h } ::=3D { docsDevFilterIpEntry 10 } draft-ietf-ipcdn-device-mibv2-09.txt:1926 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpProtocol' draft-ietf-ipcdn-device-mibv2-09.txt:1926 [5] {ref-added} reference added to `docsDevFilterIpProtocol' rfc2669.txt:1282 [6] {previous-definition} previous definition of `docsDevFilterIpProtocol' --> ok, but I think the REFERENCE is incorrect; the file at that URL covers values outside the 0..256 range permitted by this object-type's syntax. [RW] You are correct; the reference has been changed to: REFERENCE "www.iana.org/assignments/protocol-numbers" draft-ietf-ipcdn-device-mibv2-09.txt:1938 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpSourcePortLow' draft-ietf-ipcdn-device-mibv2-09.txt:1938 [5] {description-changed} description of `docsDevFilterIpSourcePortLow' changed rfc2669.txt:1293 [6] {previous-definition} previous definition of `docsDevFilterIpSourcePortLow' --> ok, but I think the REFERENCE that was put on docsDevFilterIpProtocol belongs here [RW] You are correct; this reference has been added: REFERENCE "www.iana.org/assignments/port-numbers" draft-ietf-ipcdn-device-mibv2-09.txt:1950 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpSourcePortHigh' draft-ietf-ipcdn-device-mibv2-09.txt:1950 [5] {description-changed} description of `docsDevFilterIpSourcePortHigh' changed rfc2669.txt:1305 [6] {previous-definition} previous definition of `docsDevFilterIpSourcePortHigh' --> ok, but I think the REFERENCE that was put on docsDevFilterIpProtocol belongs here [RW] You are correct; this reference has been added: REFERENCE "www.iana.org/assignments/port-numbers" draft-ietf-ipcdn-device-mibv2-09.txt:1967 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpDestPortLow' draft-ietf-ipcdn-device-mibv2-09.txt:1967 [5] {description-changed} description of `docsDevFilterIpDestPortLow' changed rfc2669.txt:1322 [6] {previous-definition} previous definition of `docsDevFilterIpDestPortLow' --> ok, but I think the REFERENCE that was put on docsDevFilterIpProtocol belongs here [RW] You are correct; this reference has been added: REFERENCE "www.iana.org/assignments/port-numbers" draft-ietf-ipcdn-device-mibv2-09.txt:1979 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpDestPortHigh' draft-ietf-ipcdn-device-mibv2-09.txt:1979 [5] {description-changed} description of `docsDevFilterIpDestPortHigh' changed rfc2669.txt:1334 [6] {previous-definition} previous definition of `docsDevFilterIpDestPortHigh' --> ok, but I think the REFERENCE that was put on docsDevFilterIpProtocol belongs here [RW] You are correct; this reference has been added: REFERENCE "www.iana.org/assignments/port-numbers" draft-ietf-ipcdn-device-mibv2-09.txt:1991 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpMatches' draft-ietf-ipcdn-device-mibv2-09.txt:1991 [5] {units-added} units added to `docsDevFilterIpMatches' rfc2669.txt:1346 [6] {previous-definition} previous definition of `docsDevFilterIpMatches' -> ok, but the SYNTAX needs to be ZeroBasedCounter32, per MIB review guidelines section 4.6.1.2. This doesn't change anything on the wire, so it's a permissible SYNTAX change. (This comment applies to ALL zero-based counters in the document.) [RW] Here is the modified object definition (note that ZeroBasedCounter32 also needed to be IMPORTED from RMON2-MIB): docsDevFilterIpMatches OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "matches" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Counts the number of times this filter was matched. This object is initialized to 0 at boot, or at row creation, and is reset only upon reboot." ::=3D { docsDevFilterIpEntry 16 } draft-ietf-ipcdn-device-mibv2-09.txt:2002 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpTos' rfc2669.txt:1356 [6] {previous-definition} previous definition of `docsDevFilterIpTos' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2019 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpTosMask' rfc2669.txt:1373 [6] {previous-definition} previous definition of `docsDevFilterIpTosMask' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2029 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpContinue' rfc2669.txt:1383 [6] {previous-definition} previous definition of `docsDevFilterIpContinue' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2040 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpPolicyId' rfc2669.txt:1394 [6] {previous-definition} previous definition of `docsDevFilterIpPolicyId' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2065 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterPolicyTable' draft-ietf-ipcdn-device-mibv2-09.txt:2065 [5] {description-changed} description of `docsDevFilterPolicyTable' changed rfc2669.txt:1413 [6] {previous-definition} previous definition of `docsDevFilterPolicyTable' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2103 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterPolicyEntry' draft-ietf-ipcdn-device-mibv2-09.txt:2103 [5] {description-changed} description of `docsDevFilterPolicyEntry' changed rfc2669.txt:1450 [6] {previous-definition} previous definition of `docsDevFilterPolicyEntry' --> ok, but s/must/MUST/ in DESCRIPTION [RW] Here is the modified object definition: docsDevFilterPolicyEntry OBJECT-TYPE SYNTAX DocsDevFilterPolicyEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry in the docsDevFilterPolicyTable. Entries are created by Network Management. To create an entry, docsDevFilterPolicyId MUST be specified." INDEX { docsDevFilterPolicyIndex } ::=3D { docsDevFilterPolicyTable 1 } draft-ietf-ipcdn-device-mibv2-09.txt:2127 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterPolicyIndex' rfc2669.txt:1476 [6] {previous-definition} previous definition of `docsDevFilterPolicyIndex' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2134 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterPolicyId' draft-ietf-ipcdn-device-mibv2-09.txt:2134 [5] {description-changed} description of `docsDevFilterPolicyId' changed rfc2669.txt:1483 [6] {previous-definition} previous definition of `docsDevFilterPolicyId' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2153 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterPolicyStatus' draft-ietf-ipcdn-device-mibv2-09.txt:2153 [5] {description-changed} description of `docsDevFilterPolicyStatus' changed rfc2669.txt:1499 [6] {previous-definition} previous definition of `docsDevFilterPolicyStatus' --> ok, but note from the MIB review guidelines page 23: - 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. This should be checked for any other RowStatus objects in the i-d. [RW] Here is the modified object definition: docsDevFilterPolicyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Object used to create an entry in this table. There is no restriction in changing any object in a row while this object is set to active. The following object MUST have a valid value before this object can be set to active: docsDevFilterPolicyPtr." ::=3D { docsDevFilterPolicyEntry 5 } draft-ietf-ipcdn-device-mibv2-09.txt:2163 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterPolicyPtr' draft-ietf-ipcdn-device-mibv2-09.txt:2163 [5] {description-changed} description of `docsDevFilterPolicyPtr' changed rfc2669.txt:1508 [6] {previous-definition} previous definition of `docsDevFilterPolicyPtr' --> ok, but the "must" seems a bit odd. Is MUST intended? It's not clear whether a statement that strong is needed. [RW] The offending statement was changed as follows: Vendors are recommended to adhere to the same convention when adding vendor specific policy table extensions. draft-ietf-ipcdn-device-mibv2-09.txt:2199 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterTosTable' draft-ietf-ipcdn-device-mibv2-09.txt:2199 [5] {description-changed} description of `docsDevFilterTosTable' changed rfc2669.txt:1538 [6] {previous-definition} previous definition of `docsDevFilterTosTable' --> ok, but what's "&" doing in the formatted text? [RW] This was an XML formatting error, which has been corrected to: Set the tosBits of the packet to (tosBits & docsDevFilterTosAndMask) | docsDevFilterTosOrMask draft-ietf-ipcdn-device-mibv2-09.txt:2234 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterTosEntry' rfc2669.txt:1561 [6] {previous-definition} previous definition of `docsDevFilterTosEntry' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2250 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterTosIndex' rfc2669.txt:1582 [6] {previous-definition} previous definition of `docsDevFilterTosIndex' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2260 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterTosStatus' rfc2669.txt:1592 [6] {previous-definition} previous definition of `docsDevFilterTosStatus' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2279 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterTosAndMask' rfc2669.txt:1606 [6] {previous-definition} previous definition of `docsDevFilterTosAndMask' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2289 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterTosOrMask' draft-ietf-ipcdn-device-mibv2-09.txt:2289 [5] {description-changed} description of `docsDevFilterTosOrMask' changed rfc2669.txt:1617 [6] {previous-definition} previous definition of `docsDevFilterTosOrMask' --> ok, but the changed DESCRIPTION is no more helpful than the original. Also, the representation of the bitwise operations is not consistent with the conventions used in the DESCRIPTION of docsDevFilterTosTable [RW] Here is the modified object definition: docsDevFilterTosOrMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This value is bitwise OR'd with the result from the AND procedure, (tosBits & docsDevFilterTosAndMask). The result then replaces the packet's TOS bits." DEFVAL { '00'h } ::=3D { docsDevFilterTosEntry 4 } draft-ietf-ipcdn-device-mibv2-09.txt:2308 [3] {defval-added} default value added to `docsDevCpeEnroll' draft-ietf-ipcdn-device-mibv2-09.txt:2308 [5] {description-changed} description of `docsDevCpeEnroll' changed rfc2669.txt:1640 [6] {previous-definition} previous definition of `docsDevCpeEnroll' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2333 [3] {defval-added} default value added to `docsDevCpeIpMax' draft-ietf-ipcdn-device-mibv2-09.txt:2333 [5] {description-changed} description of `docsDevCpeIpMax' changed rfc2669.txt:1657 [6] {previous-definition} previous definition of `docsDevCpeIpMax' --> Though adding a DEFVAL is ok, I'm concerned that the DEFVAL added is different from the default value given in the DESCRIPTION in RFC 2669. Was there an error? [RW] This is an intentional change. Operators that relied on default behavior tend not to want to impose a limit to the number of computers working behind a cable modem. Operators that want to restrict the number of computers tend to use the DOCSIS configuration file to set the number of computers (aka CPEs) explicitly. Hence the default value of this object was changed. draft-ietf-ipcdn-device-mibv2-09.txt:2350 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevCpeTable' draft-ietf-ipcdn-device-mibv2-09.txt:2350 [5] {description-changed} description of `docsDevCpeTable' changed rfc2669.txt:1673 [6] {previous-definition} previous definition of `docsDevCpeTable' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2373 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevCpeEntry' draft-ietf-ipcdn-device-mibv2-09.txt:2373 [5] {description-changed} description of `docsDevCpeEntry' changed rfc2669.txt:1690 [6] {previous-definition} previous definition of `docsDevCpeEntry' --> ok, though splitting the persistance behaviour between this and docsDevCpeTable makes things less clear than they otherwise might be, since this DESCRIPTION explicitly forbids behaviour permitted by the DESCRIPTION of docsDevCpeTable. [RW] The discussion of persistance behavior was removed from dosDevCpeEntry. Here is the modified object definition: docsDevCpeEntry OBJECT-TYPE SYNTAX DocsDevCpeEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry in the docsDevFilterCpeTable. There is one entry for each IPv4 CPE seen or provisioned. If docsDevCpeIpMax is set to -1, this table is ignored, otherwise: Upon receipt of an IP packet from the customer interface of the CM, the source IP address is checked against this table. If the address is in the table, packet processing continues. If the address is not in the table, but docsDevCpeEnroll is set to any and the sum of the table sizes of docsDevCpeTable and docsDevCpeInetTable is less than docsDevCpeIpMax, the address is added to the table and packet processing continues. Otherwise, the packet is dropped. The filtering actions specified by this table occur after any LLC filtering (docsDevFilterLLCTable), but prior to any IP filtering (docsDevFilterIpTable, docsDevNmAccessTable)." INDEX { docsDevCpeIp } ::=3D {docsDevCpeTable 1 } draft-ietf-ipcdn-device-mibv2-09.txt:2412 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevCpeIp' draft-ietf-ipcdn-device-mibv2-09.txt:2412 [5] {description-changed} description of `docsDevCpeIp' changed rfc2669.txt:1720 [6] {previous-definition} previous definition of `docsDevCpeIp' --> the added DESCRIPTION text needs to be put into 2119-speak, e.g., something like: Attempts to set all zeros or all ones address values MUST be rejected. [RW] Here is the modified object definition: docsDevCpeIp OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The IPv4 address to which this entry applies. N.B. Attempts to set all zeros or all ones address values MUST be rejected." ::=3D { docsDevCpeEntry 1 } draft-ietf-ipcdn-device-mibv2-09.txt:2423 [2] {named-number-removed} named number `other' removed from type used in `docsDevCpeSource' draft-ietf-ipcdn-device-mibv2-09.txt:2423 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevCpeSource' draft-ietf-ipcdn-device-mibv2-09.txt:2423 [5] {description-changed} description of `docsDevCpeSource' changed rfc2669.txt:1728 [6] {previous-definition} previous definition of `docsDevCpeSource' --> removing a value from an enumeration isn't one of the permitted changes, as far as I know. You can use conformance statements to say that the value other(1) need not be supported (using WRITE-SYNTAX and READ-SYNTAX). [RW] We added 'other(1)' back to the definition. Here is the modified object definition: docsDevCpeSource OBJECT-TYPE SYNTAX INTEGER { other(1), manual(2), learned(3) } MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object describes how this entry was created. If the value is manual(2), this row was created by a network management action (either configuration or SNMP set). If set to learned(3), then it was found via looking at the source IPv4 address of a received packet. The value other(1) is used for any entries that do not meet manual(2) or learned(3) criteria." ::=3D { docsDevCpeEntry 2 } draft-ietf-ipcdn-device-mibv2-09.txt:2444 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevCpeStatus' rfc2669.txt:1749 [6] {previous-definition} previous definition of `docsDevCpeStatus' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2588 [5] {node-added} node `docsDevNotifications' has been added draft-ietf-ipcdn-device-mibv2-09.txt:306 [5] {node-added} scalar `docsDevIgmpModeControl' has been added draft-ietf-ipcdn-device-mibv2-09.txt:334 [5] {node-added} scalar `docsDevMaxCpe' has been added draft-ietf-ipcdn-device-mibv2-09.txt:544 [5] {node-added} column `docsDevNmAccessTrapVersion' has been added draft-ietf-ipcdn-device-mibv2-09.txt:700 [5] {node-added} scalar `docsDevSwServerAddressType' has been added draft-ietf-ipcdn-device-mibv2-09.txt:713 [5] {node-added} scalar `docsDevSwServerAddress' has been added draft-ietf-ipcdn-device-mibv2-09.txt:740 [5] {node-added} scalar `docsDevSwServerTransportProtocol' has been added draft-ietf-ipcdn-device-mibv2-09.txt:893 [5] {node-added} scalar `docsDevServerDhcpAddressType' has been added draft-ietf-ipcdn-device-mibv2-09.txt:908 [5] {node-added} scalar `docsDevServerDhcpAddress' has been added draft-ietf-ipcdn-device-mibv2-09.txt:919 [5] {node-added} scalar `docsDevServerTimeAddressType' has been added draft-ietf-ipcdn-device-mibv2-09.txt:929 [5] {node-added} scalar `docsDevServerTimeAddress' has been added draft-ietf-ipcdn-device-mibv2-09.txt:939 [5] {node-added} scalar `docsDevServerConfigTftpAddressType' has been added draft-ietf-ipcdn-device-mibv2-09.txt:954 [5] {node-added} scalar `docsDevServerConfigTftpAddress' has been added draft-ietf-ipcdn-device-mibv2-09.txt:1418 [5] {node-added} scalar `docsDevEvSyslogAddressType' has been added draft-ietf-ipcdn-device-mibv2-09.txt:1434 [5] {node-added} scalar `docsDevEvSyslogAddress' has been added draft-ietf-ipcdn-device-mibv2-09.txt:1446 [5] {node-added} scalar `docsDevEvThrottleThresholdExceeded' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2460 [5] {node-added} table `docsDevCpeInetTable' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2489 [5] {node-added} row `docsDevCpeInetEntry' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2524 [5] {node-added} column `docsDevCpeInetType' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2532 [5] {node-added} column `docsDevCpeInetAddr' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2552 [5] {node-added} column `docsDevCpeInetSource' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2568 [5] {node-added} column `docsDevCpeInetRowStatus' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2870 [5] {node-added} node `docsDevGroupsV2' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2871 [5] {node-added} node `docsDevCompliancesV2' has been added --> additions are ok, will comment separately on any details draft-ietf-ipcdn-device-mibv2-09.txt:2692 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevNmAccessGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2692 [5] {description-changed} description of `docsDevNmAccessGroup' changed rfc2669.txt:1861 [6] {previous-definition} previous definition of `docsDevNmAccessGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2716 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevSoftwareGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2716 [5] {description-changed} description of `docsDevSoftwareGroup' changed rfc2669.txt:1876 [6] {previous-definition} previous definition of `docsDevSoftwareGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2737 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevServerGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2737 [5] {description-changed} description of `docsDevServerGroup' changed rfc2669.txt:1890 [6] {previous-definition} previous definition of `docsDevServerGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2764 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevEventGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2764 [5] {description-changed} description of `docsDevEventGroup' changed rfc2669.txt:1909 [6] {previous-definition} previous definition of `docsDevEventGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2793 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2793 [5] {description-changed} description of `docsDevFilterGroup' changed rfc2669.txt:1931 [6] {previous-definition} previous definition of `docsDevFilterGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2842 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevCpeGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2842 [5] {description-changed} description of `docsDevCpeGroup' changed rfc2669.txt:1977 [6] {previous-definition} previous definition of `docsDevCpeGroup' draft-ietf-ipcdn-device-mibv2-09.txt:3321 [5] {node-added} group `docsDevBaseIgmpGroup' has been added draft-ietf-ipcdn-device-mibv2-09.txt:3331 [5] {node-added} group `docsDevBaseMaxCpeGroup' has been added draft-ietf-ipcdn-device-mibv2-09.txt:3346 [5] {node-added} group `docsDevNmAccessExtGroup' has been added draft-ietf-ipcdn-device-mibv2-09.txt:3361 [5] {node-added} group `docsDevSoftwareGroupV2' has been added draft-ietf-ipcdn-device-mibv2-09.txt:3377 [5] {node-added} group `docsDevServerGroupV2' has been added draft-ietf-ipcdn-device-mibv2-09.txt:3399 [5] {node-added} group `docsDevEventGroupV2' has been added draft-ietf-ipcdn-device-mibv2-09.txt:3425 [5] {node-added} group `docsDevFilterLLCGroup' has been added draft-ietf-ipcdn-device-mibv2-09.txt:3443 [5] {node-added} group `docsDevInetCpeGroup' has been added --> ok, though some of the DESCRIPTIONs are a bit funky. (For example, the capitalized "Mandatory" seems like it's trying to do something like a 2119 keyword.) [RW] We left the "funky" wording alone, for the most part. :^) This is the end of the smidiff diagnostics. 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 From ipcdn-bounces@ietf.org Sun Jul 24 23:30:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtfR-0008HD-5b; Sun, 24 Jul 2005 23:30:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtfP-0008H8-5Z for ipcdn@megatron.ietf.org; Sun, 24 Jul 2005 23:30:11 -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 XAA17984 for ; Sun, 24 Jul 2005 23:30:08 -0400 (EDT) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwuAB-00082p-4G for ipcdn@ietf.org; Mon, 25 Jul 2005 00:01:59 -0400 Received: from ([10.20.9.174]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.12358071; Sun, 24 Jul 2005 23:29:45 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP02.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Cable Device MIB, Draft 09 released Date: Sun, 24 Jul 2005 23:28:33 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73807490@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [ipcdn] Cable Device MIB, Draft 09 released Thread-Index: AcV3cvGsHrBJ6VwkTwu5Ml0jonZsVgBUVCkwBgEeeDA= From: "Woundy, Richard" To: X-OriginalArrivalTime: 25 Jul 2005 03:29:45.0141 (UTC) FILETIME=[1A255E50:01C590C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Cc: bwijnen@lucent.com, Jean-Francois Mule , "Woundy, Richard" , Marez Kevin-MGI1375 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Jean-Francois, Here is the modified object definition for docsDevMaxCpe, which = hopefully addresses your concern below: docsDevMaxCpe OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "CPEs" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of CPEs that can be granted access through a CM during a CM epoch. This value can be obtained from the CM configuration file, however, it may be adjusted by the CM based on hardware or software limitations that have been imposed on the implementation." REFERENCE "DOCSIS RFI 1.0 Specification, Appendix C.7.20., and DOCSIS RFI 1.1 Specification, Appendix C.1.1.7. and DOCSIS RFI 2.0 Specification, Appendix C.1.1.7." ::=3D { docsDevBase 7 } -- Rich -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Friday, June 24, 2005 10:36 AM To: Marez Kevin-MGI1375; Woundy, Richard Cc: ipcdn@ietf.org; bwijnen@lucent.com Subject: RE: [ipcdn] Cable Device MIB, Draft 09 released Kevin and Rich, Thank you for the ID revision.=20 This email summarizes the status of the Internet Draft as I = understand it and proposes some next steps.=20 Let me know if you are ok with the proposal and if I missed anything. = Thanks, Jean-Fran=E7ois --- Draft status: The WGLC on the ipcdn cable device MIB draft 08 was initiated on 5/17 = and concluded on 6/1/2005. There was no comment sent to the list.=20 --- Changes from draft 08 to draft 09 Going through draft 09, and using the IETF diff tool, all the changes = from draft08 to draft09 seem editorial in nature. The list of changes = includes: - updated ID boilerplate - corrected typo for docsDevMaxCpe on page 11 (thanks to Fred Oko for = catching this one) - updated reference for RFC 4036 - modified description for docsDevMaxCpe --- WG chair note on the docsDevMaxCpe modification After reviewing the change on the docsDevMaxCpe modification, I find the = new text a bit confusing: + docsDevMaxCpe is a read-only object, + the description says: "This value can be obtained from the CM = configuration file, however, it may be modified based on = hardware/software limitations that have been imposed." The following text attempts to address the potential confusion and can = be considered an editorial change (which can be done in the later phase = of the IETF ID approval): --> "This value can be obtained from the CM configuration file, however, = --> it may be adjusted by the CM based on hardware or software = limitations that have been imposed implementation limitations." (Or something like that which means: value =3D=3D what's in the config = file unless the CM has to change it because of its limitations - but you = can't modify it via SNMP.) --- Next steps The next step is to Request Publication to the AD. To help expedite this = process, I will follow the new PROTO process = (http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shepher= ding-05.txt) and provide the write-up accompanying the document that is = forwarded to the IESG for publication. I will complete this by Friday = July 1st unless Bert tells us he does not need it for this ID. Jean-Fran=E7ois ipcdn co-chair. > -----Original Message----- > From: Marez Kevin-MGI1375 [mailto:Kevin.Marez@motorola.com] > Sent: Wednesday, June 22, 2005 3:37 PM > To: ipcdn@ietf.org > Subject: [ipcdn] Cable Device MIB, Draft 09 released >=20 > To all: >=20 >=20 >=20 > The following draft has been posted as draft-09 for the Cable Device=20 > MIB. >=20 >=20 >=20 > >=20 >=20 >=20 > The following highlights the differences between draft-08 and draft- > 09: >=20 >=20 >=20 > -Modified DESCRIPTION for docsDevMaxCpe >=20 >=20 >=20 > Additionally, a full listing of differences can be viewed at the=20 > following link: >=20 >=20 >=20 > http://tools.ietf.org/wg/ipcdn/draft-ietf-ipcdn-device-mibv2/draft- > ietf-ipcdn-device-mibv2-09-from-08.diff.html >=20 >=20 >=20 > Thank you very much, >=20 >=20 >=20 > Kevin Marez >=20 > Motorola _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sun Jul 24 23:30:19 2005 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 ; 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" To: "Ipcdn \(E-mail\)" 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 , Marez Kevin-MGI1375 , "Woundy, Richard" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-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 } ::=3D { 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." ::=3D { 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." ::=3D { 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 } ::=3D { 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 } ::=3D { 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 From ipcdn-bounces@ietf.org Mon Jul 25 10:23:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx3rb-0003jW-MO; Mon, 25 Jul 2005 10:23:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx3rZ-0003b8-Qd for ipcdn@megatron.ietf.org; Mon, 25 Jul 2005 10:23:26 -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 KAA24063 for ; Mon, 25 Jul 2005 10:23:24 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx4MN-0004C3-HL for ipcdn@ietf.org; Mon, 25 Jul 2005 10:55:16 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j6PEMwX6021832 for ; Mon, 25 Jul 2005 08:22:59 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2005 08:23:01 -0600 Message-ID: Thread-Topic: Proposed changes to draft-ipcdn-pktc-signaling-08 Thread-Index: AcWRJHAQGZNVoZcsQc6QiTx7E7oIbg== From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Proposed changes to draft-ipcdn-pktc-signaling-08: ------------------------------------------------- (ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-08.t xt) OPEN ISSUE (Need inputs): ---- -----=20 + Definition of the MIB Object 'pktcSigDevToneSteady'. This seems to allow for dual interpretation. =20 Strongly recommended changes (based on feedback received in the IPCDN WG): -------- ----------- ------- =20 Recommendation #1 (Reason: Technical): ------------------------------------- + pktcSigDevMultiFreqToneTable - Extend the MultiFrequency table to support 4, instead of 2 frequencies today (First, Second, Third, Fourth instead of Pri and Sec). i.e.=20 - pktcSigDevToneFirstFreqValue =20 - pktcSigDevToneSecondFreqValue =20 - pktcSigDevToneThirdFreqValue =20 - pktcSigDevToneFourthFreqValue =20 - Re-enumerate 'pktcSigDevToneNumber' to 1..8 (Reason: There is no need for anything more than 8 tones per tone type) - Make all the entries in this table to be 'read-only' (Reason: Will not require updating during run-time) - Update the DESCRIPTIONs appropriately (Reason: Addition of 4 frequencies changes the Modulation/Summation schemes) =20 =20 Recommendation #2: ----------------- + Deletion of MIB Objects - Delete the MIB Objects 'pktcNcsEndPntConfigTxGain' and 'pktcNcsEndPntConfigRxGain' (Reason: Proposal withdrawn) - Delete the MIB Object 'pktcSigDevToneNumFrequencies' (Reason: Redundant) =20 Editorial/Semantic Changes: ---------------------- ---------- - Rename 'pktcSigDevToneFrequencyNumber' as 'pktcSigDevToneNumber' (Reason: Semantics) - Move the MIB Object 'pktcSigDevToneType' to the Tone Table (Reason: MIB author guidelines) =20 Additional suggested changes: ---------- -------- -------- - 'pktcSigDevMultiFreqToneTable' could be indexed using only one MIB Object, easing implementation. Define FreqToneTable as being indexed only by pktcSigDevToneNumber (unique index for each entry) =20 pktcSigDevMultiFreqToneEntry OBJECT-TYPE =20 ............... INDEX {pktcSigDevToneNumber} =20 ::=3D { pktcSigDevMultiFreqToneTable 1 } =20 =20 PktcSigDevMultiFreqToneEntry ::=3D SEQUENCE { pktcSigDevToneNumber Unsigned32, pktcSigDevFreqToneType ToneType . . . } pktcSigDevToneNumber OBJECT-TYPE =20 SYNTAX Unsigned32(1..168)=20 MAX-ACCESS not-accessible STATUS current =20 DESCRIPTION =20 "This MIB Object is a unique number identifying each entry in ..." regards Sumanth _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jul 26 01:45:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxIFr-0002ds-7f; Tue, 26 Jul 2005 01:45:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxIFp-0002de-Nv for ipcdn@megatron.ietf.org; Tue, 26 Jul 2005 01:45:25 -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 BAA26512 for ; Tue, 26 Jul 2005 01:45:24 -0400 (EDT) Received: from go4.ext.ti.com ([192.91.75.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxIkn-0006Ua-FQ for ipcdn@ietf.org; Tue, 26 Jul 2005 02:17:27 -0400 Received: from dlep30.itg.ti.com ([157.170.139.157]) by go4.ext.ti.com (8.13.1/8.13.1) with ESMTP id j6Q5j6R6026206; Tue, 26 Jul 2005 00:45:06 -0500 (CDT) Received: from dlep90.itg.ti.com (localhost [127.0.0.1]) by dlep30.itg.ti.com (8.12.11/8.12.11) with ESMTP id j6Q5j6Yr001225; Tue, 26 Jul 2005 00:45:06 -0500 (CDT) Received: from dbde01.ent.ti.com (localhost [127.0.0.1]) by dlep90.itg.ti.com (8.12.11/8.12.11) with ESMTP id j6Q5giRW028455; Tue, 26 Jul 2005 00:45:05 -0500 (CDT) 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] Proposed changes to draft-ipcdn-pktc-signaling-08 Date: Tue, 26 Jul 2005 11:13:24 +0530 Message-ID: Thread-Topic: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08 Thread-Index: AcWRJHAQGZNVoZcsQc6QiTx7E7oIbgAe42+A From: "T, Shivakumar" To: "Sumanth Channabasappa" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Having a single index would really make things easier if a tonenumber can uniquely identify a tone type. Let's assume the following default entries are present in multifreq tone table: ToneNumber ToneType ------------------- 1 1 2 1 3 2 4 3 =20 5 3 6 3 7 4 8 4 9 5 =20 10 5 ------------------- Now tone type 2 has only one entry in the above table. In order to have say 2 entries for tone type 2, should we add an entry in the config file with index 4 or index 11. In either case the tonenumber can get changed for other tone types. One solution is to reserve the tonenumbers for a particular tone type. Since the tonenumber can range from 1-8, tonenumber 1-8 can be for tonetype 1, tonenumber 9-16 can be for tonetype 2 and so on. With this even the tonetype can be removed from the multifreq tone table. Shiva -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Sumanth Channabasappa Sent: Monday, July 25, 2005 7:53 PM To: ipcdn@ietf.org Subject: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08 Proposed changes to draft-ipcdn-pktc-signaling-08: ------------------------------------------------- (ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-08.t xt) OPEN ISSUE (Need inputs): ---- -----=20 + Definition of the MIB Object 'pktcSigDevToneSteady'. This seems to allow for dual interpretation. =20 Strongly recommended changes (based on feedback received in the IPCDN WG): -------- ----------- ------- =20 Recommendation #1 (Reason: Technical): ------------------------------------- + pktcSigDevMultiFreqToneTable - Extend the MultiFrequency table to support 4, instead of 2 frequencies today (First, Second, Third, Fourth instead of Pri and Sec). i.e.=20 - pktcSigDevToneFirstFreqValue =20 - pktcSigDevToneSecondFreqValue =20 - pktcSigDevToneThirdFreqValue =20 - pktcSigDevToneFourthFreqValue =20 - Re-enumerate 'pktcSigDevToneNumber' to 1..8 (Reason: There is no need for anything more than 8 tones per tone type) - Make all the entries in this table to be 'read-only' (Reason: Will not require updating during run-time) - Update the DESCRIPTIONs appropriately (Reason: Addition of 4 frequencies changes the Modulation/Summation schemes) =20 =20 Recommendation #2: ----------------- + Deletion of MIB Objects - Delete the MIB Objects 'pktcNcsEndPntConfigTxGain' and 'pktcNcsEndPntConfigRxGain' (Reason: Proposal withdrawn) - Delete the MIB Object 'pktcSigDevToneNumFrequencies' (Reason: Redundant) =20 Editorial/Semantic Changes: ---------------------- ---------- - Rename 'pktcSigDevToneFrequencyNumber' as 'pktcSigDevToneNumber' (Reason: Semantics) - Move the MIB Object 'pktcSigDevToneType' to the Tone Table (Reason: MIB author guidelines) =20 Additional suggested changes: ---------- -------- -------- - 'pktcSigDevMultiFreqToneTable' could be indexed using only one MIB Object, easing implementation. Define FreqToneTable as being indexed only by pktcSigDevToneNumber (unique index for each entry) =20 pktcSigDevMultiFreqToneEntry OBJECT-TYPE =20 ............... INDEX {pktcSigDevToneNumber} =20 ::=3D { pktcSigDevMultiFreqToneTable 1 } =20 =20 PktcSigDevMultiFreqToneEntry ::=3D SEQUENCE { pktcSigDevToneNumber Unsigned32, pktcSigDevFreqToneType ToneType . . . } pktcSigDevToneNumber OBJECT-TYPE =20 SYNTAX Unsigned32(1..168)=20 MAX-ACCESS not-accessible STATUS current =20 DESCRIPTION =20 "This MIB Object is a unique number identifying each entry in ..." regards Sumanth _______________________________________________ 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 From ipcdn-bounces@ietf.org Tue Jul 26 03:29:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxJsE-0006j1-10; Tue, 26 Jul 2005 03:29:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxJsC-0006it-7R for ipcdn@megatron.ietf.org; Tue, 26 Jul 2005 03:29:08 -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 DAA23544 for ; Tue, 26 Jul 2005 03:29:06 -0400 (EDT) Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxKNB-0000ek-NX for ipcdn@ietf.org; Tue, 26 Jul 2005 04:01:11 -0400 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 26 Jul 2005 00:28:41 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 26 Jul 2005 00:28:46 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BLS05553; Tue, 26 Jul 2005 00:28:45 -0700 (PDT) Received: from nt-sjca-0740.brcm.ad.broadcom.com ( nt-sjca-0740.sj.broadcom.com [10.16.192.49]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id AAA04766; Tue, 26 Jul 2005 00:28:45 -0700 (PDT) Received: from nt-sjca-0741.brcm.ad.broadcom.com ([10.16.192.42]) by nt-sjca-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 00:28:44 -0700 Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-sjca-0741.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 00:28:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08 Date: Tue, 26 Jul 2005 00:28:38 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B03122DC5@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08 Thread-Index: AcWRJHAQGZNVoZcsQc6QiTx7E7oIbgAe42+AAAPI/VA= From: "Eugene Nechamkin" To: "T, Shivakumar" , "Sumanth Channabasappa" , ipcdn@ietf.org X-OriginalArrivalTime: 26 Jul 2005 07:28:43.0813 (UTC) FILETIME=[A712D550:01C591B3] X-WSS-ID: 6EFB39A326K1815710-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org In case when pktcSigDevMultiFreqToneTable is indexed by one index (pktcSigDevToneNumber), particular values of the indexes and their assignments to the particular ToneTypes do not matter. The only = condition for indexes is to be unique for each row in the = pktcSigDevMultiFreqToneTable. This way the table does not have any restrictions on the number of rows = with the same value of the "ToneType".=20 In the example below, if additional entry of ToneType=3D2 is required it = should be introduced with the unique index value of pktcSigDevToneNumber=3D11. Eugene. -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf = Of T, Shivakumar Sent: Monday, July 25, 2005 10:43 PM To: Sumanth Channabasappa; ipcdn@ietf.org Subject: RE: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08 Having a single index would really make things easier if a tonenumber = can uniquely identify a tone type. Let's assume the following default entries are present in multifreq tone table: ToneNumber ToneType ------------------- 1 1 2 1 3 2 4 3 =20 5 3 6 3 7 4 8 4 9 5 =20 10 5 ------------------- Now tone type 2 has only one entry in the above table. In order to have = say 2 entries for tone type 2, should we add an entry in the config file with = index 4 or index 11. In either case the tonenumber can get changed for other = tone types. One solution is to reserve the tonenumbers for a particular tone type. Since the tonenumber can range from 1-8, tonenumber 1-8 can be for = tonetype 1, tonenumber 9-16 can be for tonetype 2 and so on. With this even the tonetype can be removed from the multifreq tone table. Shiva -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf = Of Sumanth Channabasappa Sent: Monday, July 25, 2005 7:53 PM To: ipcdn@ietf.org Subject: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08 Proposed changes to draft-ipcdn-pktc-signaling-08: ------------------------------------------------- (ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-08.t xt) OPEN ISSUE (Need inputs): ---- -----=20 + Definition of the MIB Object 'pktcSigDevToneSteady'. This seems to allow for dual interpretation. =20 Strongly recommended changes (based on feedback received in the IPCDN WG): -------- ----------- ------- =20 Recommendation #1 (Reason: Technical): ------------------------------------- + pktcSigDevMultiFreqToneTable - Extend the MultiFrequency table to support 4, instead of 2 frequencies today (First, Second, Third, Fourth instead of Pri and Sec). i.e.=20 - pktcSigDevToneFirstFreqValue =20 - pktcSigDevToneSecondFreqValue =20 - pktcSigDevToneThirdFreqValue =20 - pktcSigDevToneFourthFreqValue =20 - Re-enumerate 'pktcSigDevToneNumber' to 1..8 (Reason: There is no need = for anything more than 8 tones per tone type) - Make all the entries in this table to be 'read-only' (Reason: Will not require updating during run-time) - Update the DESCRIPTIONs appropriately (Reason: Addition of 4 = frequencies changes the Modulation/Summation schemes) =20 =20 Recommendation #2: ----------------- + Deletion of MIB Objects - Delete the MIB Objects 'pktcNcsEndPntConfigTxGain' and 'pktcNcsEndPntConfigRxGain' (Reason: Proposal withdrawn) - Delete the MIB Object 'pktcSigDevToneNumFrequencies' (Reason: Redundant) =20 Editorial/Semantic Changes: ---------------------- ---------- - Rename 'pktcSigDevToneFrequencyNumber' as 'pktcSigDevToneNumber' (Reason: Semantics) - Move the MIB Object 'pktcSigDevToneType' to the Tone Table (Reason: MIB author guidelines) =20 Additional suggested changes: ---------- -------- -------- - 'pktcSigDevMultiFreqToneTable' could be indexed using only one MIB = Object, easing implementation. Define FreqToneTable as being indexed only by pktcSigDevToneNumber = (unique index for each entry) =20 pktcSigDevMultiFreqToneEntry OBJECT-TYPE =20 ............... INDEX {pktcSigDevToneNumber} =20 ::=3D { pktcSigDevMultiFreqToneTable 1 } =20 =20 PktcSigDevMultiFreqToneEntry ::=3D SEQUENCE { pktcSigDevToneNumber Unsigned32, pktcSigDevFreqToneType ToneType . . . } pktcSigDevToneNumber OBJECT-TYPE =20 SYNTAX Unsigned32(1..168)=20 MAX-ACCESS not-accessible STATUS current =20 DESCRIPTION =20 "This MIB Object is a unique number identifying each entry in = ..." regards Sumanth _______________________________________________ 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 From ipcdn-bounces@ietf.org Tue Jul 26 03:48:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxKAY-000286-Hq; Tue, 26 Jul 2005 03:48:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxKAX-00027y-Eb for ipcdn@megatron.ietf.org; Tue, 26 Jul 2005 03:48:05 -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 DAA24919 for ; Tue, 26 Jul 2005 03:48:03 -0400 (EDT) Received: from go4.ext.ti.com ([192.91.75.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxKfW-0001Rc-7I for ipcdn@ietf.org; Tue, 26 Jul 2005 04:20:08 -0400 Received: from dlep31.itg.ti.com ([157.170.139.161]) by go4.ext.ti.com (8.13.1/8.13.1) with ESMTP id j6Q7lrmB022829; Tue, 26 Jul 2005 02:47:53 -0500 (CDT) Received: from dlep90.itg.ti.com (localhost [127.0.0.1]) by dlep31.itg.ti.com (8.12.11/8.12.11) with ESMTP id j6Q7lqKZ019916; Tue, 26 Jul 2005 02:47:52 -0500 (CDT) Received: from dbde01.ent.ti.com (localhost [127.0.0.1]) by dlep90.itg.ti.com (8.12.11/8.12.11) with ESMTP id j6Q7loPq025402; Tue, 26 Jul 2005 02:47:51 -0500 (CDT) 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] Proposed changes to draft-ipcdn-pktc-signaling-08 Date: Tue, 26 Jul 2005 13:17:49 +0530 Message-ID: Thread-Topic: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08 Thread-Index: AcWRJHAQGZNVoZcsQc6QiTx7E7oIbgAe42+AAAPI/VAAAYTkYA== From: "T, Shivakumar" To: "Eugene Nechamkin" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org The next available tonenumber may be different for various manufacturers or software images. It's an additional overhead for the operator to first find out the next tone number and accordingly generate config files for those entries. Shiva. -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com]=20 Sent: Tuesday, July 26, 2005 12:59 PM To: T, Shivakumar; Sumanth Channabasappa; ipcdn@ietf.org Subject: RE: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08 In case when pktcSigDevMultiFreqToneTable is indexed by one index (pktcSigDevToneNumber), particular values of the indexes and their assignments to the particular ToneTypes do not matter. The only condition for indexes is to be unique for each row in the pktcSigDevMultiFreqToneTable. This way the table does not have any restrictions on the number of rows with the same value of the "ToneType".=20 In the example below, if additional entry of ToneType=3D2 is required it should be introduced with the unique index value of pktcSigDevToneNumber=3D11. Eugene. -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of T, Shivakumar Sent: Monday, July 25, 2005 10:43 PM To: Sumanth Channabasappa; ipcdn@ietf.org Subject: RE: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08 Having a single index would really make things easier if a tonenumber can uniquely identify a tone type. Let's assume the following default entries are present in multifreq tone table: ToneNumber ToneType ------------------- 1 1 2 1 3 2 4 3 =20 5 3 6 3 7 4 8 4 9 5 =20 10 5 ------------------- Now tone type 2 has only one entry in the above table. In order to have say 2 entries for tone type 2, should we add an entry in the config file with index 4 or index 11. In either case the tonenumber can get changed for other tone types. One solution is to reserve the tonenumbers for a particular tone type. Since the tonenumber can range from 1-8, tonenumber 1-8 can be for tonetype 1, tonenumber 9-16 can be for tonetype 2 and so on. With this even the tonetype can be removed from the multifreq tone table. Shiva -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Sumanth Channabasappa Sent: Monday, July 25, 2005 7:53 PM To: ipcdn@ietf.org Subject: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08 Proposed changes to draft-ipcdn-pktc-signaling-08: ------------------------------------------------- (ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-08.t xt) OPEN ISSUE (Need inputs): ---- -----=20 + Definition of the MIB Object 'pktcSigDevToneSteady'. This seems to allow for dual interpretation. =20 Strongly recommended changes (based on feedback received in the IPCDN WG): -------- ----------- ------- =20 Recommendation #1 (Reason: Technical): ------------------------------------- + pktcSigDevMultiFreqToneTable - Extend the MultiFrequency table to support 4, instead of 2 frequencies today (First, Second, Third, Fourth instead of Pri and Sec). i.e.=20 - pktcSigDevToneFirstFreqValue =20 - pktcSigDevToneSecondFreqValue =20 - pktcSigDevToneThirdFreqValue =20 - pktcSigDevToneFourthFreqValue =20 - Re-enumerate 'pktcSigDevToneNumber' to 1..8 (Reason: There is no need for anything more than 8 tones per tone type) - Make all the entries in this table to be 'read-only' (Reason: Will not require updating during run-time) - Update the DESCRIPTIONs appropriately (Reason: Addition of 4 frequencies changes the Modulation/Summation schemes) =20 =20 Recommendation #2: ----------------- + Deletion of MIB Objects - Delete the MIB Objects 'pktcNcsEndPntConfigTxGain' and 'pktcNcsEndPntConfigRxGain' (Reason: Proposal withdrawn) - Delete the MIB Object 'pktcSigDevToneNumFrequencies' (Reason: Redundant) =20 Editorial/Semantic Changes: ---------------------- ---------- - Rename 'pktcSigDevToneFrequencyNumber' as 'pktcSigDevToneNumber' (Reason: Semantics) - Move the MIB Object 'pktcSigDevToneType' to the Tone Table (Reason: MIB author guidelines) =20 Additional suggested changes: ---------- -------- -------- - 'pktcSigDevMultiFreqToneTable' could be indexed using only one MIB Object, easing implementation. Define FreqToneTable as being indexed only by pktcSigDevToneNumber (unique index for each entry) =20 pktcSigDevMultiFreqToneEntry OBJECT-TYPE =20 ............... INDEX {pktcSigDevToneNumber} =20 ::=3D { pktcSigDevMultiFreqToneTable 1 } =20 =20 PktcSigDevMultiFreqToneEntry ::=3D SEQUENCE { pktcSigDevToneNumber Unsigned32, pktcSigDevFreqToneType ToneType . . . } pktcSigDevToneNumber OBJECT-TYPE =20 SYNTAX Unsigned32(1..168)=20 MAX-ACCESS not-accessible STATUS current =20 DESCRIPTION =20 "This MIB Object is a unique number identifying each entry in ..." regards Sumanth _______________________________________________ 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 From ipcdn-bounces@ietf.org Tue Jul 26 14:23:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxU5u-0004I7-PV; Tue, 26 Jul 2005 14:23:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxU5t-0004I2-8W for ipcdn@megatron.ietf.org; Tue, 26 Jul 2005 14:23:57 -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 OAA12279 for ; Tue, 26 Jul 2005 14:23:55 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxUay-0005oi-KG for ipcdn@ietf.org; Tue, 26 Jul 2005 14:56:05 -0400 Received: from h-68-166-189-173.snvacaid.dynamic.covad.net ([68.166.189.173] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DxU5q-0002bv-00 for ipcdn@ietf.org; Tue, 26 Jul 2005 14:23:54 -0400 Message-ID: <008e01c5920f$46a7e460$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" References: <6EEEACD9D7F52940BEE26F5467C02C73807486@PACDCEXCMB01.cable.comcast.com> Subject: Re: [ipcdn] Cable Device MIB -10 text for discussion Date: Tue, 26 Jul 2005 11:24:35 -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: 97adf591118a232206bdb5a27b217034 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi - > From: "Woundy, Richard" > To: "Ipcdn (E-mail)" ... > Sent: Sunday, July 24, 2005 6:38 PM > Subject: [ipcdn] Cable Device MIB -10 text for discussion ... > docsDevNmAccessInterfaces OBJECT-TYPE ... > -- [KMarez] Yes, a lot of questions. Since the object is > -- deprecated, can we just let this one go? I think it might be > -- reasonable to address two things though: > -- * Clarify which octet is the 'first' one. From left or > -- right? While this might be implicit, it's probably good > -- to state it. > -- * Clarify what to do with bits that correspond to > -- non-existent interfaces. ... This would help a lot. The 2119-stuff needs to be fixed. For all those other questions, my preference would be to find out how the various implementations have dealt with them. (Presumably there are at least a couple of implementors on this list.) If they've done so in a consistent manner, then the clarification is easy. If they have not, then the degree of flexibility should be made clearer, if possible. Another alternative might be to simply say that ambiguities in the original DESCRIPTION have resulted in a situation where implementations aren't necessarily interoperable, thus another motivation for deprecation. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jul 26 14:34:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxUGC-0006kd-7F; Tue, 26 Jul 2005 14:34:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxUGB-0006kN-AS for ipcdn@megatron.ietf.org; Tue, 26 Jul 2005 14:34:35 -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 OAA12995 for ; Tue, 26 Jul 2005 14:34:34 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxUlH-00067n-3Y for ipcdn@ietf.org; Tue, 26 Jul 2005 15:06:44 -0400 Received: from h-68-166-189-173.snvacaid.dynamic.covad.net ([68.166.189.173] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DxUG8-0005hV-00 for ipcdn@ietf.org; Tue, 26 Jul 2005 14:34:33 -0400 Message-ID: <009b01c59210$c35e5b00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" References: <6EEEACD9D7F52940BEE26F5467C02C73807487@PACDCEXCMB01.cable.comcast.com> Subject: Re: [ipcdn] Problems in XML source of Cable Device MIB, Draft 09 Date: Tue, 26 Jul 2005 11:35:13 -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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi - > From: "Woundy, Richard" > To: "Ipcdn (E-mail)" > Cc: "Randy Presuhn" ; "Woundy, Richard" > Sent: Sunday, July 24, 2005 6:48 PM > Subject: RE: [ipcdn] Problems in XML source of Cable Device MIB, Draft 09 ... > I was unable to avoid the following errors from the tool. All of these > normative references are either from the IMPORTS clause, or from one or > more REFERENCE clauses. ... See the top of page 10 in the MIB review guidelines http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-04.txt All you need to do is identify the sources of IMPORTed TCs and whatnot in your overview section. I'd suggest doing the same thing for the documents referenced from REFERENCE clauses. Something as simple as "The following documents are mentioned in REFERENCE clauses:..." would satisfy me. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jul 26 14:39:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxUL4-000890-Dq; Tue, 26 Jul 2005 14:39:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxUL3-00088U-R4 for ipcdn@megatron.ietf.org; Tue, 26 Jul 2005 14:39: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 OAA13397 for ; Tue, 26 Jul 2005 14:39:36 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxUq9-0006GQ-LZ for ipcdn@ietf.org; Tue, 26 Jul 2005 15:11:46 -0400 Received: from h-68-166-189-173.snvacaid.dynamic.covad.net ([68.166.189.173] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DxUL1-000792-00 for ipcdn@ietf.org; Tue, 26 Jul 2005 14:39:35 -0400 Message-ID: <00a201c59211$77b86640$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" References: <6EEEACD9D7F52940BEE26F5467C02C73807489@PACDCEXCMB01.cable.comcast.com> Subject: Re: [ipcdn] idnits and smilint on Cable Device MIB Draft 09 Date: Tue, 26 Jul 2005 11:40:16 -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: 52e1467c2184c31006318542db5614d5 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi - > From: "Woundy, Richard" > To: "Ipcdn (E-mail)" > Cc: "Randy Presuhn" ; "Woundy, Richard" > Sent: Sunday, July 24, 2005 7:12 PM > Subject: RE: [ipcdn] idnits and smilint on Cable Device MIB Draft 09 ... > The significant MIB compilation problem with version -09 was the > inclusion of deprecated groups in the current compliance statements > 'docsDevCmCompliance' and 'docsDevCmtsCompliance'. > > After further discussion among the authors, we decided that we should > remove the deprecated groups from the current compliance statement. The > key realization is that if a particular version of DOCSIS requires > implementation of a deprecated group, then that requirement can be > captured in a CableLabs specification, not in this internet-draft/RFC. > This internet-draft/RFC should be agnostic with regards to DOCSIS > versions and their (evolving) requirements. I think this is a very sensible solution. > The unfortunate consequence is that the group 'docsDevNmAccessExtGroup' > is no longer referenced by any compliance statement. This group consists > of a single MIB object that was invented by CableLabs after publication > of RFC 2669. We still include this MIB object (and group) for future > reference -- although it is immediately deprecated. ... Since the DESCRIPTION spells out why it is there, I think this is a satisfactory solution. even if it does trigger a warning message. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jul 26 14:40:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxUMN-0008QC-A6; Tue, 26 Jul 2005 14:40:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxUML-0008Q4-FX for ipcdn@megatron.ietf.org; Tue, 26 Jul 2005 14:40:57 -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 OAA13567 for ; Tue, 26 Jul 2005 14:40:56 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxUrS-0006Ki-8j for ipcdn@ietf.org; Tue, 26 Jul 2005 15:13:06 -0400 Received: from h-68-166-189-173.snvacaid.dynamic.covad.net ([68.166.189.173] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DxUMK-0007lE-00 for ipcdn@ietf.org; Tue, 26 Jul 2005 14:40:56 -0400 Message-ID: <00a901c59211$a81b7c00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" References: <6EEEACD9D7F52940BEE26F5467C02C7380748A@PACDCEXCMB01.cable.comcast.com> Subject: Re: [ipcdn] idnits and smilint on Cable Device MIB Draft 09 Date: Tue, 26 Jul 2005 11:41:37 -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: e1b0e72ff1bbd457ceef31828f216a86 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi - I'm happy with this approach. Randy ----- Original Message ----- From: "Woundy, Richard" To: "Randy Presuhn" Cc: "Ipcdn (E-mail)" ; "Woundy, Richard" Sent: Sunday, July 24, 2005 7:15 PM Subject: RE: [ipcdn] idnits and smilint on Cable Device MIB Draft 09 Randy, Kevin Marez and I had an offline discussion about these deprecated groups. We concluded that if CableLabs needs to specify the implementation of these deprecated groups for interim compliance testing, then that can be handled outside of the IETF standardization process. So we have modified the current compliance statements so that they do not include deprecated groups. -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Monday, June 27, 2005 5:07 PM To: Ipcdn (E-mail) Subject: Re: [ipcdn] idnits and smilint on Cable Device MIB Draft 09 Hi - > From: "Marez Kevin-MGI1375" > To: "Randy Presuhn" ; "Ipcdn \(E-mail\)" > > Sent: Monday, June 27, 2005 12:26 PM > Subject: RE: [ipcdn] idnits and smilint on Cable Device MIB Draft 09 ... > Randy, > > Thanks very much for the speedy review! Regarding your 'not-so-good > news', > > I think what you wanted to say was that the old docsDevCmCompliance > should be deprecated, and that there will be a docDevCmComplianceRev1 > (or whatever a good name would be) that has only the "current" > stuff from docsDevCmCompliance. Alternatively, you could keep the old compliance > stuff as-is, and just add a docDevCmComplianceRev1. It depends on the > message you want to send. > > we had actually discussed this previously and reached the following > conclusion (this was per an "internal" discussion with Rich Woundy and others in response to the question of having compliance statements contain deprecated objects): > > Hopefully the MIB doctors are OK with these compliance statements > as-is. Note the following text from the MIB guidelines, page 30 of > nes-03 > .txt>: > > - The status of a compliance statement is independent of the status > of its members. Thus, a current compliance statement MAY refer to > deprecated object groups or notification groups. This may be > desirable in certain cases, e.g., a set of widely-deployed object > or notification groups may be deprecated when they are replaced by > a more up-to-date set of definitions, but compliance statements > that refer to them may remain current in order to encourage > continued implementation of the deprecated groups. > > Please let me know if this is acceptable. Thanks very much, ... It's ok with me if it's really the case that the WG wants to "encourage continued implementation of the deprecated groups". When I look at what has actaully been deprecated, it's seems to me that that is not the intent. 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 From ipcdn-bounces@ietf.org Wed Jul 27 01:45:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxej0-0003xq-Ik; Wed, 27 Jul 2005 01:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxeiz-0003vR-1I for ipcdn@megatron.ietf.org; Wed, 27 Jul 2005 01:45:01 -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 BAA22894 for ; Wed, 27 Jul 2005 01:44:57 -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 1DxfE5-00078c-Kj for ipcdn@ietf.org; Wed, 27 Jul 2005 02:17:10 -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 1Dxein-00040v-00 for ipcdn@ietf.org; Wed, 27 Jul 2005 01:44:49 -0400 Message-ID: <012e01c5926e$62701e60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" References: <6EEEACD9D7F52940BEE26F5467C02C7380748B@PACDCEXCMB01.cable.comcast.com> Subject: Re: [ipcdn] smidiff diagnostics fordraft-ietf-ipcdn-device-mibv2-09.txt (part 1) Date: Tue, 26 Jul 2005 22:44:40 -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: 918f4bd8440e8de4700bcf6d658bc801 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org 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" ... > 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 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jul 27 01:56:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxeuS-0006fK-3E; Wed, 27 Jul 2005 01:56:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxeuP-0006f8-Pt for ipcdn@megatron.ietf.org; Wed, 27 Jul 2005 01:56:49 -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 BAA23459 for ; Wed, 27 Jul 2005 01:56:47 -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 1DxfPb-0007OB-Te for ipcdn@ietf.org; Wed, 27 Jul 2005 02:29:04 -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 1DxeuN-0006F8-00 for ipcdn@ietf.org; Wed, 27 Jul 2005 01:56:47 -0400 Message-ID: <017f01c59270$0f142ca0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" References: <6EEEACD9D7F52940BEE26F5467C02C7380748C@PACDCEXCMB01.cable.comcast.com> Subject: Re: [ipcdn] smidiff diagnosticsfordraft-ietf-ipcdn-device-mibv2-09.txt (part 2) Date: Tue, 26 Jul 2005 22:57:23 -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: f8184d7d4d1b986353eb58ea3e887935 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi - I'm happy with your proposed resolutions to my comments, of course subject to agreement on the open issues you noted. Randy ----- Original Message ----- From: "Woundy, Richard" To: "Ipcdn (E-mail)" Cc: "Randy Presuhn" ; "Marez Kevin-MGI1375" ; "Woundy,Richard" Sent: Sunday, July 24, 2005 7:32 PM Subject: RE: [ipcdn] smidiff diagnosticsfordraft-ietf-ipcdn-device-mibv2-09.txt (part 2) Comments inline, marked with [RW]. -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Tuesday, June 28, 2005 2:26 AM To: Ipcdn (E-mail) Subject: [ipcdn] smidiff diagnostics fordraft-ietf-ipcdn-device-mibv2-09.txt (part 2) Hi - Here's the second part of the smidiff diagnostics, with my comments interspersed. draft-ietf-ipcdn-device-mibv2-09.txt:1008 [3] {defval-added} default value added to `docsDevEvThrottleAdminStatus' draft-ietf-ipcdn-device-mibv2-09.txt:1008 [5] {description-changed} description of `docsDevEvThrottleAdminStatus' changed rfc2669.txt:554 [6] {previous-definition} previous definition of `docsDevEvThrottleAdminStatus' -> ok draft-ietf-ipcdn-device-mibv2-09.txt:1043 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevEvThrottleInhibited' draft-ietf-ipcdn-device-mibv2-09.txt:1043 [5] {description-changed} description of `docsDevEvThrottleInhibited' changed rfc2669.txt:591 [6] {previous-definition} previous definition of `docsDevEvThrottleInhibited' -> ok draft-ietf-ipcdn-device-mibv2-09.txt:1064 [3] {defval-added} default value added to `docsDevEvThrottleThreshold' draft-ietf-ipcdn-device-mibv2-09.txt:1064 [5] {units-added} units added to `docsDevEvThrottleThreshold' draft-ietf-ipcdn-device-mibv2-09.txt:1064 [5] {description-changed} description of `docsDevEvThrottleThreshold' changed rfc2669.txt:604 [6] {previous-definition} previous definition of `docsDevEvThrottleThreshold' --> the changes are ok, but the object itself gives me heartburn. If it were formulated only in terms of internal events that could result in notifications being sent, it wouldn't bother me. As it is, it requires the subagent/component implementing this MIB to know about what has happened in two other subsystems: the SNMP engine and the syslog engine. Something more like the following DESCRIPTION would make me happy, if it isn't contrary to your intent: "Number of events per docsDevEvThrottleInterval permitted before throttling is to occur. A single event, whether the notification could result in messages transmitted using syslog, SNMP, or both protocols, and regardless of the number of destinations, (including zero) is always treated as a single event for threshold counting. That is, an event causing both a trap and a syslog message is still treated as a single event. All system notifications that occur within the device should be taken into consideration when calculating and monitoring the threshold." [RW] Here is the modified object definition: docsDevEvThrottleThreshold OBJECT-TYPE SYNTAX Unsigned32 UNITS "events" MAX-ACCESS read-write STATUS current DESCRIPTION "Number of events per docsDevEvThrottleInterval permitted before throttling is to occur. A single event, whether the notification could result in messages transmitted using syslog, SNMP, or both protocols, and regardless of the number of destinations, (including zero) is always treated as a single event for threshold counting. For example, an event causing both a trap and a syslog message is still treated as a single event. All system notifications that occur within the device should be taken into consideration when calculating and monitoring the threshold." DEFVAL { 0 } ::= { docsDevEvent 5 } draft-ietf-ipcdn-device-mibv2-09.txt:1085 [3] {defval-added} default value added to `docsDevEvThrottleInterval' draft-ietf-ipcdn-device-mibv2-09.txt:1085 [5] {description-changed} description of `docsDevEvThrottleInterval' changed rfc2669.txt:619 [6] {previous-definition} previous definition of `docsDevEvThrottleInterval' --> changes ok, but replace "the trap threshold" with "docsDevEvThrottleThreshold" [RW] 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 } draft-ietf-ipcdn-device-mibv2-09.txt:1104 [5] {description-changed} description of `docsDevEvControlTable' changed rfc2669.txt:640 [6] {previous-definition} previous definition of `docsDevEvControlTable' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1141 [5] {description-changed} description of `docsDevEvPriority' changed rfc2669.txt:669 [6] {previous-definition} previous definition of `docsDevEvPriority' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1197 [5] {named-number-added} named number `localVolatile' added to type used in `docsDevEvReporting' draft-ietf-ipcdn-device-mibv2-09.txt:1197 [5] {named-number-added} named number `stdInterface' added to type used in `docsDevEvReporting' draft-ietf-ipcdn-device-mibv2-09.txt:1197 [5] {description-changed} description of `docsDevEvReporting' changed --> minor formatting problem in DESCRIPTION (check indentation) I'm puzzled by this addition: Any attempt to SET the traps(1) or syslog(2) bits without setting the local(0) or localVolatile(8) bits MUST result in an error being generated." Where did this come from? [RW] We are still working this issue. draft-ietf-ipcdn-device-mibv2-09.txt:1197 [5] {ref-added} reference added to `docsDevEvReporting' rfc2669.txt:699 [6] {previous-definition} previous definition of `docsDevEvReporting' --> this reference doesn't explain what this object does, so I suggest removing it. [RW] It has been removed. draft-ietf-ipcdn-device-mibv2-09.txt:1240 [5] {description-changed} description of `docsDevEventTable' changed rfc2669.txt:718 [6] {previous-definition} previous definition of `docsDevEventTable' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1251 [5] {description-changed} description of `docsDevEventEntry' changed rfc2669.txt:732 [6] {previous-definition} previous definition of `docsDevEventEntry' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1298 [5] {description-changed} description of `docsDevEvFirstTime' changed rfc2669.txt:774 [6] {previous-definition} previous definition of `docsDevEvFirstTime' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1307 [5] {description-changed} description of `docsDevEvLastTime' changed rfc2669.txt:787 [6] {previous-definition} previous definition of `docsDevEvLastTime' --> change ok, but the DESCRIPTION has some problems. It reads: "If multiple events are reported via the same entry, the value of docsDevDateTime that the last event for this entry occurred, otherwise this should have the same value as docsDevEvFirstTime. " To get rid of the "should", I suggest something like: "When an entry reports only one event, this object will have the same value as the corresponding instance of docsDecEvFirstTime. When an entry reports multiple events, this object will record the value that docsDevDateTime had when the most recent event for this entry occurred." [RW] Here is the modified object definition: docsDevEvLastTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "When an entry reports only one event, this object will have the same value as the corresponding instance of docsDevEvFirstTime. When an entry reports multiple events, this object will record the value that docsDevDateTime had when the most recent event for this entry occurred." ::= { docsDevEventEntry 3 } draft-ietf-ipcdn-device-mibv2-09.txt:1325 [5] {units-added} units added to `docsDevEvCounts' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1337 [5] {description-changed} description of `docsDevEvLevel' changed rfc2669.txt:811 [6] {previous-definition} previous definition of `docsDevEvLevel' --> ok, though I'm tempted to ask why there isn't a TC for this and docsDevEvPriority [RW] Good question, but we left this one alone. draft-ietf-ipcdn-device-mibv2-09.txt:1396 [5] {ref-added} reference added to `docsDevEvId' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1462 [3] {defval-added} default value added to `docsDevFilterLLCUnmatchedAction' draft-ietf-ipcdn-device-mibv2-09.txt:1462 [5] {description-changed} description of `docsDevFilterLLCUnmatchedAction' changed rfc2669.txt:869 [6] {previous-definition} previous definition of `docsDevFilterLLCUnmatchedAction' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1494 [5] {description-changed} description of `docsDevFilterLLCTable' changed rfc2669.txt:898 [6] {previous-definition} previous definition of `docsDevFilterLLCTable' --> the added text "Table entries are not required to persist across reboots for any device." is a little odd. More RFC 2119-like would be something like "Table entries MAY persist across reboots for any device" or "Persistance of table entries across reboots is OPTIONAL for all devices." (Whether this optionality would be a good thing is a separate discussion.) [RW] We are still working this issue. draft-ietf-ipcdn-device-mibv2-09.txt:1554 [5] {description-changed} description of `docsDevFilterLLCIfIndex' changed draft-ietf-ipcdn-device-mibv2-09.txt:1554 [5] {ref-added} reference added to `docsDevFilterLLCIfIndex' rfc2669.txt:956 [6] {previous-definition} previous definition of `docsDevFilterLLCIfIndex' --> ok 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 From ipcdn-bounces@ietf.org Wed Jul 27 02:02:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxf01-0007Zm-Or; Wed, 27 Jul 2005 02:02:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxezz-0007W8-LG for ipcdn@megatron.ietf.org; Wed, 27 Jul 2005 02:02:35 -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 CAA26146 for ; Wed, 27 Jul 2005 02:02:30 -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 1DxfV8-0007af-7w for ipcdn@ietf.org; Wed, 27 Jul 2005 02:34:47 -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 1Dxezt-0007Qx-00 for ipcdn@ietf.org; Wed, 27 Jul 2005 02:02:29 -0400 Message-ID: <018401c59270$da94bb60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" References: <6EEEACD9D7F52940BEE26F5467C02C7380748D@PACDCEXCMB01.cable.comcast.com> Subject: Re: [ipcdn] smidiff diagnosticsfordraft-ietf-ipcdn-device-mibv2-09.txt (part 3) Date: Tue, 26 Jul 2005 23:02:49 -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: a5514bacad4d93d5535dfe9fdc83bbb7 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi - I'm ok with Richard's proposed changes in repsonse to my comments in this thread. Randy ----- Original Message ----- From: "Woundy, Richard" To: "Ipcdn (E-mail)" Cc: "Randy Presuhn" ; "Marez Kevin-MGI1375" ; "Woundy,Richard" Sent: Sunday, July 24, 2005 7:51 PM Subject: RE: [ipcdn] smidiff diagnosticsfordraft-ietf-ipcdn-device-mibv2-09.txt (part 3) Comments inline, marked with [RW]. -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Wednesday, June 29, 2005 2:43 AM To: Ipcdn (E-mail) Subject: [ipcdn] smidiff diagnostics fordraft-ietf-ipcdn-device-mibv2-09.txt (part 3) Hi - Continuing with the smidiff diagnostics, with my comments interspered: draft-ietf-ipcdn-device-mibv2-09.txt:1576 [5] {description-changed} description of `docsDevFilterLLCProtocolType' changed rfc2669.txt:970 [6] {previous-definition} previous definition of `docsDevFilterLLCProtocolType' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1597 [5] {description-changed} description of `docsDevFilterLLCProtocol' changed rfc2669.txt:985 [6] {previous-definition} previous definition of `docsDevFilterLLCProtocol' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1610 [5] {units-added} units added to `docsDevFilterLLCMatches' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1623 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpDefault' draft-ietf-ipcdn-device-mibv2-09.txt:1623 [3] {defval-added} default value added to `docsDevFilterIpDefault' draft-ietf-ipcdn-device-mibv2-09.txt:1623 [5] {description-changed} description of `docsDevFilterIpDefault' changed rfc2669.txt:1014 [6] {previous-definition} previous definition of `docsDevFilterIpDefault' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1648 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpTable' draft-ietf-ipcdn-device-mibv2-09.txt:1648 [5] {description-changed} description of `docsDevFilterIpTable' changed rfc2669.txt:1029 [6] {previous-definition} previous definition of `docsDevFilterIpTable' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1713 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpEntry' rfc2669.txt:1079 [6] {previous-definition} previous definition of `docsDevFilterIpEntry' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1758 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpIndex' rfc2669.txt:1124 [6] {previous-definition} previous definition of `docsDevFilterIpIndex' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1768 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpStatus' rfc2669.txt:1134 [6] {previous-definition} previous definition of `docsDevFilterIpStatus' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1787 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpControl' draft-ietf-ipcdn-device-mibv2-09.txt:1787 [5] {description-changed} description of `docsDevFilterIpControl' changed rfc2669.txt:1158 [6] {previous-definition} previous definition of `docsDevFilterIpControl' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1817 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpIfIndex' draft-ietf-ipcdn-device-mibv2-09.txt:1817 [5] {description-changed} description of `docsDevFilterIpIfIndex' changed draft-ietf-ipcdn-device-mibv2-09.txt:1817 [5] {ref-added} reference added to `docsDevFilterIpIfIndex' rfc2669.txt:1182 [6] {previous-definition} previous definition of `docsDevFilterIpIfIndex' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1839 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpDirection' rfc2669.txt:1196 [6] {previous-definition} previous definition of `docsDevFilterIpDirection' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1859 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpBroadcast' rfc2669.txt:1216 [6] {previous-definition} previous definition of `docsDevFilterIpBroadcast' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1870 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpSaddr' rfc2669.txt:1227 [6] {previous-definition} previous definition of `docsDevFilterIpSaddr' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1883 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpSmask' rfc2669.txt:1240 [6] {previous-definition} previous definition of `docsDevFilterIpSmask' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1895 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpDaddr' draft-ietf-ipcdn-device-mibv2-09.txt:1895 [5] {description-changed} description of `docsDevFilterIpDaddr' changed rfc2669.txt:1252 [6] {previous-definition} previous definition of `docsDevFilterIpDaddr' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:1914 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpDmask' rfc2669.txt:1270 [6] {previous-definition} previous definition of `docsDevFilterIpDmask' --> ok, but s/must/MUST/ in DESCRIPTION clause [RW] Here is the modified object definition: docsDevFilterIpDmask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "A bit mask that is to be applied to the destination address prior to matching. This mask is not necessarily the same as a subnet mask, but 1's bits MUST be leftmost and contiguous." DEFVAL { '00000000'h } ::= { docsDevFilterIpEntry 10 } draft-ietf-ipcdn-device-mibv2-09.txt:1926 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpProtocol' draft-ietf-ipcdn-device-mibv2-09.txt:1926 [5] {ref-added} reference added to `docsDevFilterIpProtocol' rfc2669.txt:1282 [6] {previous-definition} previous definition of `docsDevFilterIpProtocol' --> ok, but I think the REFERENCE is incorrect; the file at that URL covers values outside the 0..256 range permitted by this object-type's syntax. [RW] You are correct; the reference has been changed to: REFERENCE "www.iana.org/assignments/protocol-numbers" draft-ietf-ipcdn-device-mibv2-09.txt:1938 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpSourcePortLow' draft-ietf-ipcdn-device-mibv2-09.txt:1938 [5] {description-changed} description of `docsDevFilterIpSourcePortLow' changed rfc2669.txt:1293 [6] {previous-definition} previous definition of `docsDevFilterIpSourcePortLow' --> ok, but I think the REFERENCE that was put on docsDevFilterIpProtocol belongs here [RW] You are correct; this reference has been added: REFERENCE "www.iana.org/assignments/port-numbers" draft-ietf-ipcdn-device-mibv2-09.txt:1950 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpSourcePortHigh' draft-ietf-ipcdn-device-mibv2-09.txt:1950 [5] {description-changed} description of `docsDevFilterIpSourcePortHigh' changed rfc2669.txt:1305 [6] {previous-definition} previous definition of `docsDevFilterIpSourcePortHigh' --> ok, but I think the REFERENCE that was put on docsDevFilterIpProtocol belongs here [RW] You are correct; this reference has been added: REFERENCE "www.iana.org/assignments/port-numbers" draft-ietf-ipcdn-device-mibv2-09.txt:1967 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpDestPortLow' draft-ietf-ipcdn-device-mibv2-09.txt:1967 [5] {description-changed} description of `docsDevFilterIpDestPortLow' changed rfc2669.txt:1322 [6] {previous-definition} previous definition of `docsDevFilterIpDestPortLow' --> ok, but I think the REFERENCE that was put on docsDevFilterIpProtocol belongs here [RW] You are correct; this reference has been added: REFERENCE "www.iana.org/assignments/port-numbers" draft-ietf-ipcdn-device-mibv2-09.txt:1979 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpDestPortHigh' draft-ietf-ipcdn-device-mibv2-09.txt:1979 [5] {description-changed} description of `docsDevFilterIpDestPortHigh' changed rfc2669.txt:1334 [6] {previous-definition} previous definition of `docsDevFilterIpDestPortHigh' --> ok, but I think the REFERENCE that was put on docsDevFilterIpProtocol belongs here [RW] You are correct; this reference has been added: REFERENCE "www.iana.org/assignments/port-numbers" draft-ietf-ipcdn-device-mibv2-09.txt:1991 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpMatches' draft-ietf-ipcdn-device-mibv2-09.txt:1991 [5] {units-added} units added to `docsDevFilterIpMatches' rfc2669.txt:1346 [6] {previous-definition} previous definition of `docsDevFilterIpMatches' -> ok, but the SYNTAX needs to be ZeroBasedCounter32, per MIB review guidelines section 4.6.1.2. This doesn't change anything on the wire, so it's a permissible SYNTAX change. (This comment applies to ALL zero-based counters in the document.) [RW] Here is the modified object definition (note that ZeroBasedCounter32 also needed to be IMPORTED from RMON2-MIB): docsDevFilterIpMatches OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "matches" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Counts the number of times this filter was matched. This object is initialized to 0 at boot, or at row creation, and is reset only upon reboot." ::= { docsDevFilterIpEntry 16 } draft-ietf-ipcdn-device-mibv2-09.txt:2002 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpTos' rfc2669.txt:1356 [6] {previous-definition} previous definition of `docsDevFilterIpTos' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2019 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpTosMask' rfc2669.txt:1373 [6] {previous-definition} previous definition of `docsDevFilterIpTosMask' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2029 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpContinue' rfc2669.txt:1383 [6] {previous-definition} previous definition of `docsDevFilterIpContinue' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2040 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterIpPolicyId' rfc2669.txt:1394 [6] {previous-definition} previous definition of `docsDevFilterIpPolicyId' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2065 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterPolicyTable' draft-ietf-ipcdn-device-mibv2-09.txt:2065 [5] {description-changed} description of `docsDevFilterPolicyTable' changed rfc2669.txt:1413 [6] {previous-definition} previous definition of `docsDevFilterPolicyTable' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2103 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterPolicyEntry' draft-ietf-ipcdn-device-mibv2-09.txt:2103 [5] {description-changed} description of `docsDevFilterPolicyEntry' changed rfc2669.txt:1450 [6] {previous-definition} previous definition of `docsDevFilterPolicyEntry' --> ok, but s/must/MUST/ in DESCRIPTION [RW] Here is the modified object definition: docsDevFilterPolicyEntry OBJECT-TYPE SYNTAX DocsDevFilterPolicyEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry in the docsDevFilterPolicyTable. Entries are created by Network Management. To create an entry, docsDevFilterPolicyId MUST be specified." INDEX { docsDevFilterPolicyIndex } ::= { docsDevFilterPolicyTable 1 } draft-ietf-ipcdn-device-mibv2-09.txt:2127 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterPolicyIndex' rfc2669.txt:1476 [6] {previous-definition} previous definition of `docsDevFilterPolicyIndex' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2134 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterPolicyId' draft-ietf-ipcdn-device-mibv2-09.txt:2134 [5] {description-changed} description of `docsDevFilterPolicyId' changed rfc2669.txt:1483 [6] {previous-definition} previous definition of `docsDevFilterPolicyId' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2153 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterPolicyStatus' draft-ietf-ipcdn-device-mibv2-09.txt:2153 [5] {description-changed} description of `docsDevFilterPolicyStatus' changed rfc2669.txt:1499 [6] {previous-definition} previous definition of `docsDevFilterPolicyStatus' --> ok, but note from the MIB review guidelines page 23: - 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. This should be checked for any other RowStatus objects in the i-d. [RW] Here is the modified object definition: docsDevFilterPolicyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Object used to create an entry in this table. There is no restriction in changing any object in a row while this object is set to active. The following object MUST have a valid value before this object can be set to active: docsDevFilterPolicyPtr." ::= { docsDevFilterPolicyEntry 5 } draft-ietf-ipcdn-device-mibv2-09.txt:2163 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterPolicyPtr' draft-ietf-ipcdn-device-mibv2-09.txt:2163 [5] {description-changed} description of `docsDevFilterPolicyPtr' changed rfc2669.txt:1508 [6] {previous-definition} previous definition of `docsDevFilterPolicyPtr' --> ok, but the "must" seems a bit odd. Is MUST intended? It's not clear whether a statement that strong is needed. [RW] The offending statement was changed as follows: Vendors are recommended to adhere to the same convention when adding vendor specific policy table extensions. draft-ietf-ipcdn-device-mibv2-09.txt:2199 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterTosTable' draft-ietf-ipcdn-device-mibv2-09.txt:2199 [5] {description-changed} description of `docsDevFilterTosTable' changed rfc2669.txt:1538 [6] {previous-definition} previous definition of `docsDevFilterTosTable' --> ok, but what's "&" doing in the formatted text? [RW] This was an XML formatting error, which has been corrected to: Set the tosBits of the packet to (tosBits & docsDevFilterTosAndMask) | docsDevFilterTosOrMask draft-ietf-ipcdn-device-mibv2-09.txt:2234 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterTosEntry' rfc2669.txt:1561 [6] {previous-definition} previous definition of `docsDevFilterTosEntry' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2250 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterTosIndex' rfc2669.txt:1582 [6] {previous-definition} previous definition of `docsDevFilterTosIndex' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2260 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterTosStatus' rfc2669.txt:1592 [6] {previous-definition} previous definition of `docsDevFilterTosStatus' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2279 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterTosAndMask' rfc2669.txt:1606 [6] {previous-definition} previous definition of `docsDevFilterTosAndMask' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2289 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterTosOrMask' draft-ietf-ipcdn-device-mibv2-09.txt:2289 [5] {description-changed} description of `docsDevFilterTosOrMask' changed rfc2669.txt:1617 [6] {previous-definition} previous definition of `docsDevFilterTosOrMask' --> ok, but the changed DESCRIPTION is no more helpful than the original. Also, the representation of the bitwise operations is not consistent with the conventions used in the DESCRIPTION of docsDevFilterTosTable [RW] Here is the modified object definition: docsDevFilterTosOrMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This value is bitwise OR'd with the result from the AND procedure, (tosBits & docsDevFilterTosAndMask). The result then replaces the packet's TOS bits." DEFVAL { '00'h } ::= { docsDevFilterTosEntry 4 } draft-ietf-ipcdn-device-mibv2-09.txt:2308 [3] {defval-added} default value added to `docsDevCpeEnroll' draft-ietf-ipcdn-device-mibv2-09.txt:2308 [5] {description-changed} description of `docsDevCpeEnroll' changed rfc2669.txt:1640 [6] {previous-definition} previous definition of `docsDevCpeEnroll' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2333 [3] {defval-added} default value added to `docsDevCpeIpMax' draft-ietf-ipcdn-device-mibv2-09.txt:2333 [5] {description-changed} description of `docsDevCpeIpMax' changed rfc2669.txt:1657 [6] {previous-definition} previous definition of `docsDevCpeIpMax' --> Though adding a DEFVAL is ok, I'm concerned that the DEFVAL added is different from the default value given in the DESCRIPTION in RFC 2669. Was there an error? [RW] This is an intentional change. Operators that relied on default behavior tend not to want to impose a limit to the number of computers working behind a cable modem. Operators that want to restrict the number of computers tend to use the DOCSIS configuration file to set the number of computers (aka CPEs) explicitly. Hence the default value of this object was changed. draft-ietf-ipcdn-device-mibv2-09.txt:2350 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevCpeTable' draft-ietf-ipcdn-device-mibv2-09.txt:2350 [5] {description-changed} description of `docsDevCpeTable' changed rfc2669.txt:1673 [6] {previous-definition} previous definition of `docsDevCpeTable' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2373 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevCpeEntry' draft-ietf-ipcdn-device-mibv2-09.txt:2373 [5] {description-changed} description of `docsDevCpeEntry' changed rfc2669.txt:1690 [6] {previous-definition} previous definition of `docsDevCpeEntry' --> ok, though splitting the persistance behaviour between this and docsDevCpeTable makes things less clear than they otherwise might be, since this DESCRIPTION explicitly forbids behaviour permitted by the DESCRIPTION of docsDevCpeTable. [RW] The discussion of persistance behavior was removed from dosDevCpeEntry. Here is the modified object definition: docsDevCpeEntry OBJECT-TYPE SYNTAX DocsDevCpeEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry in the docsDevFilterCpeTable. There is one entry for each IPv4 CPE seen or provisioned. If docsDevCpeIpMax is set to -1, this table is ignored, otherwise: Upon receipt of an IP packet from the customer interface of the CM, the source IP address is checked against this table. If the address is in the table, packet processing continues. If the address is not in the table, but docsDevCpeEnroll is set to any and the sum of the table sizes of docsDevCpeTable and docsDevCpeInetTable is less than docsDevCpeIpMax, the address is added to the table and packet processing continues. Otherwise, the packet is dropped. The filtering actions specified by this table occur after any LLC filtering (docsDevFilterLLCTable), but prior to any IP filtering (docsDevFilterIpTable, docsDevNmAccessTable)." INDEX { docsDevCpeIp } ::= {docsDevCpeTable 1 } draft-ietf-ipcdn-device-mibv2-09.txt:2412 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevCpeIp' draft-ietf-ipcdn-device-mibv2-09.txt:2412 [5] {description-changed} description of `docsDevCpeIp' changed rfc2669.txt:1720 [6] {previous-definition} previous definition of `docsDevCpeIp' --> the added DESCRIPTION text needs to be put into 2119-speak, e.g., something like: Attempts to set all zeros or all ones address values MUST be rejected. [RW] Here is the modified object definition: docsDevCpeIp OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The IPv4 address to which this entry applies. N.B. Attempts to set all zeros or all ones address values MUST be rejected." ::= { docsDevCpeEntry 1 } draft-ietf-ipcdn-device-mibv2-09.txt:2423 [2] {named-number-removed} named number `other' removed from type used in `docsDevCpeSource' draft-ietf-ipcdn-device-mibv2-09.txt:2423 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevCpeSource' draft-ietf-ipcdn-device-mibv2-09.txt:2423 [5] {description-changed} description of `docsDevCpeSource' changed rfc2669.txt:1728 [6] {previous-definition} previous definition of `docsDevCpeSource' --> removing a value from an enumeration isn't one of the permitted changes, as far as I know. You can use conformance statements to say that the value other(1) need not be supported (using WRITE-SYNTAX and READ-SYNTAX). [RW] We added 'other(1)' back to the definition. Here is the modified object definition: docsDevCpeSource OBJECT-TYPE SYNTAX INTEGER { other(1), manual(2), learned(3) } MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object describes how this entry was created. If the value is manual(2), this row was created by a network management action (either configuration or SNMP set). If set to learned(3), then it was found via looking at the source IPv4 address of a received packet. The value other(1) is used for any entries that do not meet manual(2) or learned(3) criteria." ::= { docsDevCpeEntry 2 } draft-ietf-ipcdn-device-mibv2-09.txt:2444 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevCpeStatus' rfc2669.txt:1749 [6] {previous-definition} previous definition of `docsDevCpeStatus' --> ok draft-ietf-ipcdn-device-mibv2-09.txt:2588 [5] {node-added} node `docsDevNotifications' has been added draft-ietf-ipcdn-device-mibv2-09.txt:306 [5] {node-added} scalar `docsDevIgmpModeControl' has been added draft-ietf-ipcdn-device-mibv2-09.txt:334 [5] {node-added} scalar `docsDevMaxCpe' has been added draft-ietf-ipcdn-device-mibv2-09.txt:544 [5] {node-added} column `docsDevNmAccessTrapVersion' has been added draft-ietf-ipcdn-device-mibv2-09.txt:700 [5] {node-added} scalar `docsDevSwServerAddressType' has been added draft-ietf-ipcdn-device-mibv2-09.txt:713 [5] {node-added} scalar `docsDevSwServerAddress' has been added draft-ietf-ipcdn-device-mibv2-09.txt:740 [5] {node-added} scalar `docsDevSwServerTransportProtocol' has been added draft-ietf-ipcdn-device-mibv2-09.txt:893 [5] {node-added} scalar `docsDevServerDhcpAddressType' has been added draft-ietf-ipcdn-device-mibv2-09.txt:908 [5] {node-added} scalar `docsDevServerDhcpAddress' has been added draft-ietf-ipcdn-device-mibv2-09.txt:919 [5] {node-added} scalar `docsDevServerTimeAddressType' has been added draft-ietf-ipcdn-device-mibv2-09.txt:929 [5] {node-added} scalar `docsDevServerTimeAddress' has been added draft-ietf-ipcdn-device-mibv2-09.txt:939 [5] {node-added} scalar `docsDevServerConfigTftpAddressType' has been added draft-ietf-ipcdn-device-mibv2-09.txt:954 [5] {node-added} scalar `docsDevServerConfigTftpAddress' has been added draft-ietf-ipcdn-device-mibv2-09.txt:1418 [5] {node-added} scalar `docsDevEvSyslogAddressType' has been added draft-ietf-ipcdn-device-mibv2-09.txt:1434 [5] {node-added} scalar `docsDevEvSyslogAddress' has been added draft-ietf-ipcdn-device-mibv2-09.txt:1446 [5] {node-added} scalar `docsDevEvThrottleThresholdExceeded' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2460 [5] {node-added} table `docsDevCpeInetTable' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2489 [5] {node-added} row `docsDevCpeInetEntry' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2524 [5] {node-added} column `docsDevCpeInetType' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2532 [5] {node-added} column `docsDevCpeInetAddr' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2552 [5] {node-added} column `docsDevCpeInetSource' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2568 [5] {node-added} column `docsDevCpeInetRowStatus' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2870 [5] {node-added} node `docsDevGroupsV2' has been added draft-ietf-ipcdn-device-mibv2-09.txt:2871 [5] {node-added} node `docsDevCompliancesV2' has been added --> additions are ok, will comment separately on any details draft-ietf-ipcdn-device-mibv2-09.txt:2692 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevNmAccessGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2692 [5] {description-changed} description of `docsDevNmAccessGroup' changed rfc2669.txt:1861 [6] {previous-definition} previous definition of `docsDevNmAccessGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2716 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevSoftwareGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2716 [5] {description-changed} description of `docsDevSoftwareGroup' changed rfc2669.txt:1876 [6] {previous-definition} previous definition of `docsDevSoftwareGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2737 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevServerGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2737 [5] {description-changed} description of `docsDevServerGroup' changed rfc2669.txt:1890 [6] {previous-definition} previous definition of `docsDevServerGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2764 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevEventGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2764 [5] {description-changed} description of `docsDevEventGroup' changed rfc2669.txt:1909 [6] {previous-definition} previous definition of `docsDevEventGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2793 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevFilterGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2793 [5] {description-changed} description of `docsDevFilterGroup' changed rfc2669.txt:1931 [6] {previous-definition} previous definition of `docsDevFilterGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2842 [5] {status-change} legal status change from `current' to `deprecated' for `docsDevCpeGroup' draft-ietf-ipcdn-device-mibv2-09.txt:2842 [5] {description-changed} description of `docsDevCpeGroup' changed rfc2669.txt:1977 [6] {previous-definition} previous definition of `docsDevCpeGroup' draft-ietf-ipcdn-device-mibv2-09.txt:3321 [5] {node-added} group `docsDevBaseIgmpGroup' has been added draft-ietf-ipcdn-device-mibv2-09.txt:3331 [5] {node-added} group `docsDevBaseMaxCpeGroup' has been added draft-ietf-ipcdn-device-mibv2-09.txt:3346 [5] {node-added} group `docsDevNmAccessExtGroup' has been added draft-ietf-ipcdn-device-mibv2-09.txt:3361 [5] {node-added} group `docsDevSoftwareGroupV2' has been added draft-ietf-ipcdn-device-mibv2-09.txt:3377 [5] {node-added} group `docsDevServerGroupV2' has been added draft-ietf-ipcdn-device-mibv2-09.txt:3399 [5] {node-added} group `docsDevEventGroupV2' has been added draft-ietf-ipcdn-device-mibv2-09.txt:3425 [5] {node-added} group `docsDevFilterLLCGroup' has been added draft-ietf-ipcdn-device-mibv2-09.txt:3443 [5] {node-added} group `docsDevInetCpeGroup' has been added --> ok, though some of the DESCRIPTIONs are a bit funky. (For example, the capitalized "Mandatory" seems like it's trying to do something like a 2119 keyword.) [RW] We left the "funky" wording alone, for the most part. :^) This is the end of the smidiff diagnostics. 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 From ipcdn-bounces@ietf.org Wed Jul 27 02:06:38 2005 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 ; 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" To: "Ipcdn \(E-mail\)" 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 List-Unsubscribe: , List-Post: List-Help: List-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" To: "Ipcdn (E-mail)" Cc: "Randy Presuhn" ; "Marez Kevin-MGI1375" ; "Woundy,Richard" 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