Message

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 From ipcdn-bounces@ietf.org Sat Jun 25 01:48:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm3WR-0007tP-9K; Sat, 25 Jun 2005 01:48:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm3WP-0007t6-9b for ipcdn@megatron.ietf.org; Sat, 25 Jun 2005 01: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 BAA05568 for ; Sat, 25 Jun 2005 01:48:01 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dm3up-0002y8-U0 for ipcdn@ietf.org; Sat, 25 Jun 2005 02:13:20 -0400 Received: from h-64-105-137-100.snvacaid.dynamic.covad.net ([64.105.137.100] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dm3W7-0005Ow-00 for ipcdn@ietf.org; Sat, 25 Jun 2005 01:47:47 -0400 Message-ID: <003f01c57949$eb2a0420$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn $E-mail$" References: <6EEEACD9D7F52940BEE26F5467C02C73807287@PACDCEXCMB01.cable.comcast.com> Date: Fri, 24 Jun 2005 22:51:22 -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: b4a0a5f5992e2a4954405484e7717d8c Subject: [ipcdn] idnits and smilint on Cable Device MIB Draft 09 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 - 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 From ipcdn-bounces@ietf.org Mon Jun 27 15:26:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmzFR-0001Ym-8i; Mon, 27 Jun 2005 15:26:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmzFO-0001Yh-9S for ipcdn@megatron.ietf.org; Mon, 27 Jun 2005 15:26:24 -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 PAA27493 for ; Mon, 27 Jun 2005 15:26:20 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmzeZ-0006TQ-Ij for ipcdn@ietf.org; Mon, 27 Jun 2005 15:52:25 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j5RJbHk1006608 for ; Mon, 27 Jun 2005 12:37:17 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j5RJTdR7016468 for ; Mon, 27 Jun 2005 14:29:39 -0500 (CDT) Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Jun 2005 12:26:08 -0700 Message-ID: From: Marez Kevin-MGI1375 To: Randy Presuhn , "Ipcdn \$E-mail\$" Subject: RE: [ipcdn] idnits and smilint on Cable Device MIB Draft 09 Date: Mon, 27 Jun 2005 12:26:05 -0700 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: 6d95a152022472c7d6cdf886a0424dc6 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 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 : - 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, Kevin Marez Motorola -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Friday, June 24, 2005 10:51 PM To: Ipcdn $E-mail$ Subject: [ipcdn] idnits and smilint on Cable Device MIB Draft 09 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 Mon Jun 27 17:03:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn0lD-0001BM-1D; Mon, 27 Jun 2005 17:03:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn0lA-0001BF-Im for ipcdn@megatron.ietf.org; Mon, 27 Jun 2005 17:03:16 -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 RAA19000 for ; Mon, 27 Jun 2005 17:03:13 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn1AM-00045X-Lw for ipcdn@ietf.org; Mon, 27 Jun 2005 17:29:19 -0400 Received: from h-64-105-137-71.snvacaid.dynamic.covad.net ([64.105.137.71] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dn0l7-0001Mm-00 for ipcdn@ietf.org; Mon, 27 Jun 2005 17:03:13 -0400 Message-ID: <007601c57b5c$2a5a5d20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn $E-mail$" References: Subject: Re: [ipcdn] idnits and smilint on Cable Device MIB Draft 09 Date: Mon, 27 Jun 2005 14:07:01 -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: 4adaf050708fb13be3316a9eee889caa 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: "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 > .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 From ipcdn-bounces@ietf.org Tue Jun 28 00:04:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn7LH-0008WR-6Y; Tue, 28 Jun 2005 00:04:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn7LE-0008WM-VD for ipcdn@megatron.ietf.org; Tue, 28 Jun 2005 00:04: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 AAA02160 for ; Tue, 28 Jun 2005 00:04:53 -0400 (EDT) Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn7kV-0005Ze-M7 for ipcdn@ietf.org; Tue, 28 Jun 2005 00:31:04 -0400 Received: from h-64-105-137-71.snvacaid.dynamic.covad.net ([64.105.137.71] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dn7LC-0005Ok-00 for ipcdn@ietf.org; Tue, 28 Jun 2005 00:04:54 -0400 Message-ID: <017a01c57b97$1315c880$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn $E-mail$" References: <6EEEACD9D7F52940BEE26F5467C02C7380723B@PACDCEXCMB01.cable.comcast.com> Date: Mon, 27 Jun 2005 21:08:42 -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: dd7e0c3fd18d19cffdd4de99a114001d Subject: [ipcdn] smidiff diagnostics for draft-ietf-ipcdn-device-mibv2-09.txt (part 1) 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 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. 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." 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. 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. 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? 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.... 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. 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. 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 From ipcdn-bounces@ietf.org Tue Jun 28 02:22:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn9UW-0000iw-6P; Tue, 28 Jun 2005 02:22:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn9UU-0000ha-1L for ipcdn@megatron.ietf.org; Tue, 28 Jun 2005 02:22: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 CAA02372 for ; Tue, 28 Jun 2005 02:22:36 -0400 (EDT) Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn9tm-00073U-IQ for ipcdn@ietf.org; Tue, 28 Jun 2005 02:48:46 -0400 Received: from h-64-105-137-71.snvacaid.dynamic.covad.net ([64.105.137.71] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dn9UO-0003uq-00 for ipcdn@ietf.org; Tue, 28 Jun 2005 02:22:32 -0400 Message-ID: <018401c57baa$4dd9bfe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn $E-mail$" Date: Mon, 27 Jun 2005 23:26:21 -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: b22590c27682ace61775ee7b453b40d3 Subject: [ipcdn] smidiff diagnostics for draft-ietf-ipcdn-device-mibv2-09.txt (part 2) 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'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." 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" 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? 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. 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." 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 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.) 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 From ipcdn-bounces@ietf.org Tue Jun 28 05:30:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnCQB-00057i-Dp; Tue, 28 Jun 2005 05:30:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnCQ9-00057d-Lz for ipcdn@megatron.ietf.org; Tue, 28 Jun 2005 05:30: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 FAA16821 for ; Tue, 28 Jun 2005 05:30:19 -0400 (EDT) Received: from adicia.telenet-ops.be ([195.130.132.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnCpT-0000ek-G7 for ipcdn@ietf.org; Tue, 28 Jun 2005 05:56:32 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by adicia.telenet-ops.be (Postfix) with SMTP id B7C7E4411F for ; Tue, 28 Jun 2005 11:30:06 +0200 (MEST) Received: from tcomlabs.com (d5152CA51.access.telenet.be [81.82.202.81]) by adicia.telenet-ops.be (Postfix) with ESMTP id 7D7EC44131 for ; Tue, 28 Jun 2005 11:30:06 +0200 (MEST) Received: (qmail 25863 invoked from network); 28 Jun 2005 11:30:06 +0200 Received: from unknown (HELO pcdavid) (10.5.5.72) by gateway.tcomlabs.com with SMTP; 28 Jun 2005 11:30:06 +0200 From: "David De Reu" To: , , "IPCDN Mailing List (E-mail)" Subject: RE: [ipcdn] Question on tone table definition in IETF SIG draft-8 Date: Tue, 28 Jun 2005 11:30:05 +0200 Message-ID: <000001c57bc3$f810b1d0$4805050a@pcdavid> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: 7bit Cc: msanchez@ti.com 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 Sumanth, Comments inline as well. > -----Original Message----- > From: ipcdn-bounces@ietf.org > [mailto:ipcdn-bounces@ietf.org]On Behalf Of > Sumanth Channabasappa > Sent: woensdag 22 juni 2005 23:33 > To: Satish Kumar at Texas Instruments; ipcdn@ietf.org > Cc: Sanchez, Mauricio > Subject: RE: [ipcdn] Question on tone table definition in IETF SIG > draft-8 > > > Satish, > > > Comments inline: > > Q1. According to NCS spec, "ROH Tone is generated by combining four > tones at frequencies of 1400 Hertz, 2060 Hertz, 2450 Hertz and 2600 > Hertz at a cadence of 0.1 second on, 0.1 second off, repeating." But > in the latest IETF signaling draft(ver 8), > pktcSigDevMultiFreqToneTable contains provision to store only two > frequency components.What would happen in the case that more than > two frequencies are required, like in the case of off-hook warning > notifications, where four frequencies are used?? > > [sumanth] Essentially, as pointed out by David ( > http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01625.h tml), > the cause for the change was Randy's original comment > (http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01466. > html) and subsequent offline discussions with Gordon. > > However, it is to be noted that multiple frequencies can be > supported as 'pktcSigDevMultiFreqToneTable' is indexed using two > indices ('pktcSigDevToneType' and 'pktcSigDevToneFrequencyNumber'). > > The MIB Objects 'pktcSigDevToneFreqPriCompValue' and > 'pktcSigDevToneFreqSecCompValue' are 'components' of a single > frequency as opposed to 'frequencies' themselves. > > > In summary, > 'pktcSigDevToneEntry' is indexed by 'pktcSigDevToneType'. > 'pktcSigDevMultiFreqToneTable' is indexed by > 'pktcSigDevToneType' and > 'pktcSigDevToneFrequencyNumber' > > Thus, for each tone (represented by 'pktcSigDevToneType') > one could > have multiple frequencies (represented by > 'pktcSigDevToneFrequencyNumber') > and each frequency in turn could have dual components (one if the > secondary is unused; > represented using 'pktcSigDevToneFreqPriCompValue' and > 'pktcSigDevToneFreqSecCompValue') > > See example later in this email. > > Does that help? I'm afraid not. As I tried to explain in http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01625.html, my interpretation is the following: In the new pktcSigDevMultiFreqToneTable, there can indeed be multiple frequencies, but at distinct times! For having two frequencies active at the same time, you need to use ... pktcSigDevToneFreqPriCompValue Unsigned32, pktcSigDevToneFreqSecCompValue Unsigned32, ... The reasoning behind this interpretation is that for the PriComp and SecComp, you can specify how the two frequencies should be combined (one of the options is to sum up the waves). But for multiple entries in the pktcSigDevMultiFreqToneTable, there is nothing in the MIB that indicates that some entries have to be played simultaneously or, in contrast, successively. Given the option to play the two frequency *components* of an entry simultaneously, the logical thing to expect --although a clarification would not do any harm-- is that the entries are all played in succession. This means that only two frequencies can actually be played *simultaneously* (through PriComp and SecComp), and this is not suffcient for the ROH Tone. This observation probably led to Shivakumar's proposal to introduce grouping of frequencies (see http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01627.html). > > 2. Could it be possible to have an example of complex signals > that were > used to define the requirements from this draft, in form of the MIB > elements (e.g. Japanese signal with the different element > definitions or > complex repetition signals) for testing purposes? > > [sumanth] > > > Gordon had provided an example earlier, which is reproduced > as follows: > > Gordon, is that: > Japan call waiting tone with the following definition per ITU-T E.180: > f1 mod f2, where f1=400 Hz AM modulated by 16 Hz, f2=400 Hz not AM > modulated > cadence: > First tone : 500ms ON then 0 to 400ms OFF *followed by* > Second tone: 50ms ON then 450ms OFF *followed by* > Third tone : 50ms ON then 3450ms OFF *followed by* > Fourth tone: 50ms ON then 450ms OFF *followed by* > Fifth tone : 50ms ON then 3450ms OFF > not repeated, not continuous Since that would indeed be what is represented by Sumanth's example below. Which raises again the question on what to do if you need four frequencies at the same time... > pktcSigDevToneFrequencyNumber 001 002 003 004 005 > > pktcSigDevToneFreqPriCompValue 400 400 400 400 400 > > pktcSigDevToneFreqSecCompValue 016 000 016 000 016 > > pktcSigDevToneFreqSecCompMode 001 003 001 003 001 > > pktcSigDevToneFreqSecCompPrtg 090 000 090 000 090 > > pktcSigDevToneFreqOnDuration 500 050 050 050 050 > > pktcSigDevToneFreqOffDuration 400 450 3450 450 3450 > > pktcSigDevToneFreqRepeatCount 000 000 0000 000 0000 > > > > Thus, for this tone type, the table 'pktcSigDevToneEntry' would have > entries indexed by: > X,1 > X,2 > X,3 > X,4 > X,5 > > Where X is the tone type being referenced. > > > 3. pktcSigDevToneFrequencyNumber is the index to > pktcSigDevMultiFreqToneTable and its value ranges from 5-16. > Why should > the index value start from 5??? > [sumanth] > > As you may recall, we initially had: > > > pktcSigDevToneFirstFrequency Unsigned32, > > pktcSigDevToneSecondFrequency Unsigned32, > > pktcSigDevToneThirdFrequency Unsigned32, > > pktcSigDevToneFourthFrequency Unsigned32, > > pktcSigDevToneFifthFrequency Unsigned32, > > Thus, to be compatible with the previous definitions, the lower limit > was set to 5 (I don't recall any other reason, apologies :( ) As I understand it, the pktcSigDevToneFrequencyNumber is the *actual* number of frequencies in the tone, so it should start from 1. The *maximum* number of frequencies is represented by pktcSigDevToneNumFrequencies (which should probably be read-only instead of read-write, in that case). Regards, David _____________________________________________________ David De Reu tComLabs Stapelplein 70 - 9000 Ghent - Belgium Tel: +32 9 269 22 91 - Fax: +32 9 329 31 74 www.tComLabs.com _____________________________________________________ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jun 28 13:55:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnKIg-0006ZU-MQ; Tue, 28 Jun 2005 13:55:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnKIg-0006ZM-2z for ipcdn@megatron.ietf.org; Tue, 28 Jun 2005 13:55: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 NAA05510 for ; Tue, 28 Jun 2005 13:55:08 -0400 (EDT) Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnKi3-0003pp-Fe for ipcdn@ietf.org; Tue, 28 Jun 2005 14:21:24 -0400 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 28 Jun 2005 10:54:52 -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 for ; Tue, 28 Jun 2005 10:54:37 -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 BGQ50693; Tue, 28 Jun 2005 10:54:37 -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 KAA07553 for ; Tue, 28 Jun 2005 10:54:36 -0700 (PDT) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-sjca-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 10:54:36 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [ipcdn] Tx-Rx loss plan and Tone Table Date: Tue, 28 Jun 2005 10:54:31 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B03122ADE@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] Tx-Rx loss plan and Tone Table thread-index: AcV36/skGkeRN1dvSvejoKh/MNbbrAEHU0Xw From: "Eugene Nechamkin" To: ipcdn@ietf.org X-OriginalArrivalTime: 28 Jun 2005 17:54:36.0433 (UTC) FILETIME=[729CE810:01C57C0A] X-WSS-ID: 6EDF51662784648085-01-01 X-Spam-Score: 0.9 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 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="===============1939087798==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============1939087798== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57C0A.6F7FF5FE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57C0A.6F7FF5FE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =20 We agree that the "pktcNcsEndPntConfigRxGain" and = "pktcNcsEndPntConfigTxGain" MIB Objects should be withdrawn from the draft-08. The description = clause of the "pktcSigDevToneDbLevel" should be correspondingly modified to = exclude the reference to the "pktcNcsEndPntConfigRxGain" object. Depending on the = ongoing discussion on the Tone Generation and multiple frequencies = representation, the description clause of "pktcSigDevToneDbLevel" should be adjusted appropriately without mentioning of the "pktcNcsEndPntConfigRxGain". =20 Eugene. ________________________________ From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf = Of Freyman Phillip-FPF300 Sent: Thursday, June 23, 2005 5:01 AM To: 'ipcdn@ietf.org' Subject: [ipcdn] Tx-Rx loss plan and Tone Table Collegues, =20 The email chain on these topics has been quite active begining with = IPCDN Digest, Vol 13, Issue 2 and through Issue 8. =20 I would like to make a few comments at this time. =20 The original submission to re-establish the Tx-Rx gain/loss requirement = was submitted to the distribution list on 15 February, 2005. So the reason = and rational for this re-statement goes back 4 MONTHS not 5 days. In that submission a number of Telephony standards across world markets were identified and quoted and the rational for the return of the = requirements was stated. =20 There are several points in the current gain/loss plan discussion. 1. Should the Tx-Rx gain/loss requirements be in the SigMIB? 2. If they are to be included, what is the range of values 3. If they are to be included, what are the default settings. =20 The current view of the respondents tends to focus on the need for the requirements in the SigMIB. This implies that no one has recognized the = need to change the gain/loss requirement on any dynamic basis, either on a = per call basis or within a call. Without support for this in the SigMIB, = the gain/loss requirement becomes fixed either by physical hardware design = or vendor specific provisioning MIB approaches. =20 The questions on the range of values and defaults are a "mute point" if = the basic Tx-Rx gain/loss is removed, however some considerations. 1. PacketCable defines gain/loss at -2 dB 2. ETSI defines gain/loss up to -11 dB 3. Most operators and field experience tend to set the loss to -4 dB. 3. Some worldwide operators tend to select values within these = settings. 4. Based on the various standards or operator requirements, a range of = 0 to -12 dB of gain (0 dB to 12 dB loss) seems acceptable. 5. Based on the various standards or operator requirements it would = appear Tx gain and Rx gain in PacketCable architectures should default to 4 dB = but ETSI based architectures should default to Tx at 4 dB but Rx at 11 dB. 6. Operators may defined other defaults based on local requirements. =20 However, since the group appears to believe a "fixed" gain/loss plan is adequate, then Motorola withdraws the 15 February, 2005 proposal to re-instate the requirements and the discussion of range and default = settings are a mute point. =20 This decision will also impact the pktcSigDevToneDbLevel since this requirement references the pktcNcsEndPntConfigRxGain entry. =20 The other point of discussion and the one which is more significant is = the Tone table structure. During the earlier SigMIB review process some = problems were found with some international tone requirements with the original = four frequency structure. Proposal to that structure were submitted to the working group to resolve the problems seen at that time. During review = of this proposed change, one of the "MIB Doctors" required a change to the structure to "simplify" the structure. Apparently the review of the MIB Doctor re-structuring of the Tone table focused on the problem at hand = but failed to fully review previous tone structures. This has resulted in = the current situation where the current SigMIB draft fails to meet the requirements of the original PacketCable Supervisory Tones such as ROH = Tone which is generated by combining four tones at frequencies of 1400 Hertz, = 2060 Hertz, 2450 Hertz and 2600 Hertz at a cadence of 0.1 second on, 0.1 = second off, repeating. =20 At this time only one proposal to correct the ToneTable structure has = been made and NO comments have been offered to provide alternate structures = or to accept the submission as it. =20 Personally I must still review the proposed ToneTable change but it does = seem the WG should re-focus their efforts on the significant issue at hand. =20 Regards, =20 Phillip Freyman Distinguished Member of the Technical Staff Science Advisory Board Associate Motorola, Inc. Connected Home Solutions IPS IP System Engineering 21440 West Lake Cook Road Deer Park, IL 60010 =20 =20 ------_=_NextPart_001_01C57C0A.6F7FF5FE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message

We agree that the "pktcNcsEndPntConfigRxGain" = and=20 "pktcNcsEndPntConfigTxGain" MIB Objects should be withdrawn from the = draft-08.=20 The description clause of the "pktcSigDevToneDbLevel" should = be=20 correspondingly modified to exclude the reference to the=20 "pktcNcsEndPntConfigRxGain" object. Depending on the ongoing discussion = on the=20 Tone Generation and multiple frequencies representation, the description = clause=20 of "pktcSigDevToneDbLevel" should be = adjusted=20 appropriately without mentioning of the=20 "pktcNcsEndPntConfigRxGain".

Eugene.

From: ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org] On Behalf Of Freyman=20 Phillip-FPF300
Sent: Thursday, June 23, 2005 5:01 = AM
To:=20 'ipcdn@ietf.org'
Subject: [ipcdn] Tx-Rx loss plan and Tone=20 Table

Collegues,

The = email chain on=20 these topics has been quite active begining with IPCDN Digest, Vol 13, = Issue 2=20 and through Issue 8.

I = would like to make=20 a few comments at this time.

The = original=20 submission to re-establish the Tx-Rx gain/loss requirement was = submitted to=20 the distribution list on 15 February, 2005. So the reason and = rational for=20 this re-statement goes back 4 MONTHS not 5 days. In that submission = a=20 number of Telephony standards across world markets were identified and = quoted=20 and the rational for the return of the requirements was=20 stated.

There = are several=20 points in the current gain/loss plan discussion.

1. Should the=20 Tx-Rx gain/loss requirements be in the SigMIB?

2. If they are=20 to be included, what is the range of values

3. If they are=20 to be included, what are the default settings.

The = current view of=20 the respondents tends to focus on the need for the requirements in the=20 SigMIB. This implies that no one has recognized the need to change = the=20 gain/loss requirement on any dynamic basis, either on a per call basis = or within=20 a call. Without support for this in the SigMIB, the gain/loss = requirement=20 becomes fixed either by physical hardware design or vendor specific = provisioning=20 MIB approaches.

The = questions on the=20 range of values and defaults are a "mute point" if the basic Tx-Rx = gain/loss is=20 removed, however some considerations.

1. PacketCable=20 defines gain/loss at -2 dB

2. ETSI=20 defines gain/loss up to -11 dB

3. Most=20 operators and field experience tend to set the loss to -4=20 dB.

3. Some=20 worldwide operators tend to select values within these=20 settings.

4. Based on=20 the various standards or operator requirements, a range of 0 to -12 dB = of gain=20 (0 dB to 12 dB loss) seems acceptable.

5. Based on=20 the various standards or operator requirements it would appear Tx gain = and Rx=20 gain in PacketCable architectures should default to 4 dB but ETSI based=20 architectures should default to Tx at 4 dB but Rx at 11 = dB.

6. Operators=20 may defined other defaults based on local = requirements.

However, since the=20 group appears to believe a "fixed" gain/loss plan is adequate, then = Motorola=20 withdraws the 15 February, 2005 proposal to re-instate the requirements = and the=20 discussion of range and default settings are a mute = point.

This = decision will=20 also impact the pktcSigDevToneDbLevel since this requirement references the=20 pktcNcsEndPntConfigRxGain = entry.

The other point = of discussion=20 and the one which is more significant is the Tone table structure. = During=20 the earlier SigMIB review process some problems were found with some=20 international tone requirements with the original four frequency=20 structure. Proposal to that structure were submitted to the = working group=20 to resolve the problems seen at that time. During review of this = proposed=20 change, one of the "MIB Doctors" required a change to the structure to=20 "simplify" the structure. Apparently the review of the MIB = Doctor=20 re-structuring of the Tone table focused on the problem at hand but = failed to=20 fully review previous tone structures. This has resulted in the = current=20 situation where the current SigMIB draft fails to meet the requirements = of the=20 original PacketCable Supervisory Tones such as ROH Tone = which is=20 generated by combining four tones at frequencies of 1400 Hertz, 2060 = Hertz, 2450=20 Hertz and 2600 Hertz at a cadence of 0.1 second on, 0.1 second off,=20 repeating.

At this time = only one proposal=20 to correct the ToneTable structure has been made and NO comments have = been=20 offered to provide alternate structures or to accept the submission as=20 it.

Personally I = must still review=20 the proposed ToneTable change but it does seem the WG should re-focus = their=20 efforts on the significant issue at=20 hand.

Regards,

Phillip = Freyman

Distinguished Member of = the Technical=20 Staff

Science Advisory Board=20 Associate

Motorola, = Inc.

Connected Home Solutions=20 IPS

IP System = Engineering

21440 West Lake Cook = Road

Deer Park, IL=20 60010

------_=_NextPart_001_01C57C0A.6F7FF5FE-- --===============1939087798== 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 --===============1939087798==-- From ipcdn-bounces@ietf.org Tue Jun 28 16:49:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnN13-0007fx-TZ; Tue, 28 Jun 2005 16:49:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnN11-0007Zz-H2 for ipcdn@megatron.ietf.org; Tue, 28 Jun 2005 16:49:07 -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 QAA20823 for ; Tue, 28 Jun 2005 16:48:58 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnNHq-0001bH-86 for ipcdn@ietf.org; Tue, 28 Jun 2005 17:06:31 -0400 Received: from h-64-105-35-218.snvacaid.dynamic.covad.net ([64.105.35.218] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DnMsO-0005iT-00 for ipcdn@ietf.org; Tue, 28 Jun 2005 16:40:12 -0400 Message-ID: <014401c57c22$1faa1660$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn $E-mail$" References: <000001c57bc3$f810b1d0$4805050a@pcdavid> Subject: Re: [ipcdn] Question on tone table definition in IETF SIG draft-8 Date: Tue, 28 Jun 2005 13:44:04 -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: 93238566e09e6e262849b4f805833007 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 - Based on what I'm reading in this thread so far... It seems to me that it would be much simpler to change pktcSigDevMultiFreqToneTable's indexing to include another index. In musical terms, the indexes could be { pktcSigDevToneType, pktSigDevChordIndex, pktSigDevNoteInChord } if you like to think of a tone as composed from a series of notes or chords. Alternatively, if you're more comfotable with polyphonic music, you could use { pktcSigDevToneType, pktSigDevVoiceIndex, pktSigDevNoteInVoice } In the first model, the duration is associated with the chord, which has some number of notes. In the second model, a tone is constructed from some number of concurrent voices, each playing a sequence of notes / silence, where duration is associated with each note. Just a thought - it all depends on what you need to be able to represent and what devices can actually do. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jun 28 21:26:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnRLC-0008J1-1t; Tue, 28 Jun 2005 21:26:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnRL8-0008It-Sd for ipcdn@megatron.ietf.org; Tue, 28 Jun 2005 21:26:12 -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 VAA20287 for ; Tue, 28 Jun 2005 21:26:08 -0400 (EDT) Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnRkY-0004r6-FI for ipcdn@ietf.org; Tue, 28 Jun 2005 21:52:29 -0400 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 28 Jun 2005 18:25:46 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD 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 for ; Tue, 28 Jun 2005 18:25:22 -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 BGS23403; Tue, 28 Jun 2005 18:25:22 -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 SAA00709 for ; Tue, 28 Jun 2005 18:25:22 -0700 (PDT) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-sjca-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 18:25:21 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 28 Jun 2005 18:25:21 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B03122B03@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: Tone Generation Proposal thread-index: AcV8I7u3gSGz2gvzRB+lCYQlwf35FQAHP7Cg From: "Eugene Nechamkin" To: "Ipcdn (E-mail)" X-OriginalArrivalTime: 29 Jun 2005 01:25:21.0513 (UTC) FILETIME=[6ABC9D90:01C57C49] X-WSS-ID: 6EDF27102AW4930742-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: quoted-printable 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: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org =20 After looking at the issues associated with the Tone Table definition, = here is the proposal which seems to have a potential to solve the following outstanding issues: 1. to be able to represent the tones with potentially any number of frequencies (as opposed to draft-07 with four frequencies limit, and = draft-08 with two frequencies limit) 2. to be flexible enough without adding unneccessary complexity to = satisify the MIB doctors requirement (MIB doctors coments for draft-07). 3. to be able to generate twist DB level between two freqs for a tone = (as opposed to draft-08) Before going into the MIB details, here is the basic idea illustrating = the approach: 1. Define the Frequency Group Table (FreqGroupTable), indexed by = FreqGrpIdx and FreqVal. This table can be viewed as the "Table of Chords" (using the analogy in = one of the recent e-mails): FreqGrpIdx FreqVal DbLevel CompMode =20 =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=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 1 1400 -100 1 1 2060 -100 1 1 2450 -100 1 1 2600 -100 1 2 440 -130 1 COMMENTS: - dBLevel - per frequency tone level. Darft-08 was not able to generate twist DB level between two freqs for a tone. Overall level of = all tones in a frequency group MUST NOT exceed -3dB. - CompMode - the following operations on the frequencies in each group are defined to aggregate them for the tone generation:=20 - sum of all frequencies in the table (=3D1), - modulation of the 1st one by the 2nd one (=3D2) - FIVE Freqs per group - MAX. 2. Define Group Sequence Table (GroupSeqTable), indexed by GrpSeqIdx and GrpNumIdx. This table can be viewed as the "Table of Musical Themes" (using the = analogy in one of the recent e-mails): GrpSeqIdx GrpNumIdx FreqGrpIdx DurationON DurationOFF RepeatCount =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=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 1 1 1 100 100 = 0 (no repeat) 2 1 2 100 100 = 0 (no repeat) 2 2 2 300 100 = 0 (no repeat) 2 3 2 100 100 = 0 (no repeat) COMMENTS: 16 Groups per Sequience (Tone) - MAX. 3. Define Tone Table (ToneTable), indexed by ToneType.=20 This table can be viewed as the "Table of Musics" (using the analogy in = one of the recent e-mails), with each "Music" corresponding to the = particular Tone being generated: ToneType GrpSeqIdx WholeToneRepeatCnt ToneSteady =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5 1 5000 2 (no) 12 2 700 2 (no) Here is how all these three tables would work together: 1. If EMTA needs to generate "offHookWarning(5)", it looks at the = Table-3 (ToneTable), 1st row. This row refers to the Group Sequence '1' = (GrpSeqIdx =3D=3D 1). The Group Sequence Index is located in the Group Sequence Table = (Table-2) (1st row for GrpSeqIdx=3D=3D1) which indicates that the Frequencey Group = 1 (FreqGrpIdx=3D1) should be used to generate the tone. The Table-1 = described the composition of this group with various frequencies for = FreqGrpIdx=3D=3D1, which tells the EMTA to take four frequencies, sum them up (CompMode=3D=3D1), = and play. Because there is no any more Frequencey Group pointed in the Table-2 for = the Group Sequence '1' (GrpSeqIdx =3D=3D 1), the "offHookWarning" tone is = generated by repeating this 5000 times (WholeToneRepeatCnt=3D=3D5000) with the = tone being not steady (ToneSteady=3D=3D2) =3D=3D=3D> Here is how this tone would sound 1) 1400Hz + 2060Hz + 2450Hz + 2600Hz on for 100ms 2) 1400Hz + 2060Hz + 2450Hz + 2600Hz off for 100ms 3) repeat (1) and (2) 5000 times 2. If EMTA needs to generate "callWaiting4(12)", it looks at the Table-3 (ToneTable), 2nd row. This row reffers to the Group Sequence '2' = (GrpSeqIdx =3D=3D 2). The Group Sequence Index is located in the Group Sequence = Table (Table-2) (2nd, 3rd abd 4th rows for SeqGrpIdx=3D=3D2) which indicates = that the Frequencey Group 2 (FreqGrpIdx=3D2) should be used to generate the tone, = and this Group should be played three times. The Table-1 described the composition of this group with various frequencies for reqGrpIdx=3D=3D2, = which tells the EMTA to take one frequency (Freq=3D440) and play it for the = 2nd row of the Table-2. Then 3rd row of the Table-2 is played and finally, 4th = row of the Table-2 is played. The whole "melody" of three repetion of the Group = #2 (FreqGrpIdx=3D=3D 2), plays the required tone by repeating this 700 = times (WholeToneRepeatCnt=3D=3D700) with the tone being not steady = (ToneSteady=3D=3D2). =3D=3D=3D> Here is how this tone would sound (1) 440Hz on for 100ms (2) 440Hz off for 100ms (3) 440Hz on for 300ms (4) 440Hz off for 100ms (5) 440Hz on for 100ms (6) 440Hz off for 100ms (7) repeat (1) through (6) 700 times Eugene Nechamkin, Broadcom Corp. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jun 29 02:00:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnVcC-0001pO-8q; Wed, 29 Jun 2005 02:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnVcA-0001om-8v for ipcdn@megatron.ietf.org; Wed, 29 Jun 2005 02:00:02 -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 CAA07088 for ; Wed, 29 Jun 2005 02:00:00 -0400 (EDT) Received: from go4.ext.ti.com ([192.91.75.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnW1c-0003Rk-EU for ipcdn@ietf.org; Wed, 29 Jun 2005 02:26:23 -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 j5T5xjtW025487; Wed, 29 Jun 2005 00:59:45 -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 j5T5xjN6021596; Wed, 29 Jun 2005 00:59: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 j5T5xhQn004457; Wed, 29 Jun 2005 00:59:44 -0500 (CDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [ipcdn] Tone Generation Proposal Date: Wed, 29 Jun 2005 11:29:42 +0530 Message-ID: Thread-Topic: [ipcdn] Tone Generation Proposal Thread-Index: AcV8I7u3gSGz2gvzRB+lCYQlwf35FQAHP7CgAAlKKjA= From: "T, Shivakumar" To: "Eugene Nechamkin" , "Ipcdn $E-mail$" X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 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 following issues are not addressed in this proposal.=20 1) Since the FreqVal is index to the FreqGroupTable, the frequencies used for playing a tone cannot be modified. 2) There is no way to increase or decrease the number of frequencies used to play a tone. 3) The entry with FreqGrpIdx=3D2 and FreqVal=3D440 in the FreqGroupTable = can be used for playing multiple tone types(callwaiting 1,2,3,4) and modifying any value in this row would affect the other tone type. 4) Why CompMode=3D2 be restricted to 1st and 2nd frequencies. All these issues are addressed in the following proposal: 1) Define a freq table(pktcSigDevToneFreqTable) indexed by pktcSigDevToneType,pktcSigDevToneFreqGrpNumber,pktcSigDevToneFreqIndex. pktcSigDevToneFreqGrpNumber: This MIB Object along with pktcSigDevToneType groups multiple frequency entries that has to be added to form a tone. ToneType FreqGrpNumber FreqIndex FreqValue DbLevel =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D 5 1 1 1400 -130 5 1 2 2060 -130 5 1 3 2450 -130 5 1 4 2600 -130 12 1 1 440 -130 2) Define a Multi Freq Tone table(pktcSigDevMultiFreqToneTable) indexed by pktcSigDevToneType, pktcSigDevToneFrequencyNumber. This Table is same as the one defined in draft-8 except that instead of specifying the frequency values in the PriCompValue and SecCompValue we'll specify the Freq Group Number(pktcSigDevToneFreqGrpNumber) for a specific tone type. Also CompMode can contain either ignoreSecondary(1) or primaryModulatedBySecondary(2). ToneType FreqNum PriGrp SecGrp CompMode CompPrtg OnDur OffDur RepeatCount =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=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 5 1 1 1 1 0 100 100 1 12 1 1 1 1 0 100 100 1 12 2 1 1 1 0 300 100 1 12 3 1 1 1 0 100 100 1 3) Define a tone table(pktcSigDevToneTable) indexed by pktcSigDevToneType. This table is same as the one defined in draft-8 except for the DbLevel is removed and two new columns are added to specify the number of frequencies(pktcSigDevToneNumFrequencies) and to specify the number of on-off sequence(pktcSigDevToneNumOnOffCount) required for each tone type. For any tone type the FreqIndex in the FreqTable MUST not exceed its corresponding value specified in pktcSigDevToneNumFrequencies and the FreqNum in the multi freq tone table MUST not exceed its corresponding value specified in pktcSigDevToneNumOnOffCount. ToneType RepeatCount Steady NumFreq NumOnOff =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=3D=3D=3D 5 5000 2 4 1 12 700 2 1 3 In order to play the offhookwarning tone(tone type=3D5), iterate over = all entries in the multi freq tone table with index 5. For each row in the multi freq tone table with index=3D5 select the corresponding PriGrp and SecGrp. PriGrp =3D 1 SecGrp =3D 1 The PriGrp specifies the group number of the primary component of the tone. This is specified in the FreqTable. This tone is generated by adding all frequencies specified in the freq table for that particular tone type and FreqGrpNumber(value specified in PriGrp). Primary Component of the Tone =3D 1400 + 2060 + 2450 + 2600 Since compMode is set to 1(ignoreSecondary) the secondary component is ignored. The resulting tone is played for 100msec ON(on dur) and 100msec OFF(off dur) once(repeat count). This entire sequence is repeated for the value specified in RepeatCount of the Tone Table. Repeat Count =3D 5000 ------------------------------------------------------------------------ - Shiva -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Eugene Nechamkin Sent: Wednesday, June 29, 2005 6:55 AM To: Ipcdn (E-mail) Subject: [ipcdn] Tone Generation Proposal =20 After looking at the issues associated with the Tone Table definition, here is the proposal which seems to have a potential to solve the following outstanding issues: 1. to be able to represent the tones with potentially any number of frequencies (as opposed to draft-07 with four frequencies limit, and draft-08 with two frequencies limit) 2. to be flexible enough without adding unneccessary complexity to satisify the MIB doctors requirement (MIB doctors coments for draft-07). 3. to be able to generate twist DB level between two freqs for a tone (as opposed to draft-08) Before going into the MIB details, here is the basic idea illustrating the approach: 1. Define the Frequency Group Table (FreqGroupTable), indexed by FreqGrpIdx and FreqVal. This table can be viewed as the "Table of Chords" (using the analogy in one of the recent e-mails): FreqGrpIdx FreqVal DbLevel CompMode =20 =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=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 1 1400 -100 1 1 2060 -100 1 1 2450 -100 1 1 2600 -100 1 2 440 -130 1 COMMENTS: - dBLevel - per frequency tone level. Darft-08 was not able to generate twist DB level between two freqs for a tone. Overall level of all tones in a frequency group MUST NOT exceed -3dB. - CompMode - the following operations on the frequencies in each group are defined to aggregate them for the tone generation:=20 - sum of all frequencies in the table (=3D1), - modulation of the 1st one by the 2nd one (=3D2) - FIVE Freqs per group - MAX. 2. Define Group Sequence Table (GroupSeqTable), indexed by GrpSeqIdx and GrpNumIdx. This table can be viewed as the "Table of Musical Themes" (using the analogy in one of the recent e-mails): GrpSeqIdx GrpNumIdx FreqGrpIdx DurationON DurationOFF RepeatCount =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=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 1 1 1 100 100 0 (no repeat) 2 1 2 100 100 0 (no repeat) 2 2 2 300 100 0 (no repeat) 2 3 2 100 100 0 (no repeat) COMMENTS: 16 Groups per Sequience (Tone) - MAX. 3. Define Tone Table (ToneTable), indexed by ToneType.=20 This table can be viewed as the "Table of Musics" (using the analogy in one of the recent e-mails), with each "Music" corresponding to the particular Tone being generated: ToneType GrpSeqIdx WholeToneRepeatCnt ToneSteady =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5 1 5000 2 (no) 12 2 700 2 (no) Here is how all these three tables would work together: 1. If EMTA needs to generate "offHookWarning(5)", it looks at the Table-3 (ToneTable), 1st row. This row refers to the Group Sequence '1' (GrpSeqIdx =3D=3D 1). The Group Sequence Index is located in the Group Sequence Table (Table-2) (1st row for GrpSeqIdx=3D=3D1) which indicates that the Frequencey Group = 1 (FreqGrpIdx=3D1) should be used to generate the tone. The Table-1 described the composition of this group with various frequencies for = FreqGrpIdx=3D=3D1, which tells the EMTA to take four frequencies, sum them up (CompMode=3D=3D1), = and play. Because there is no any more Frequencey Group pointed in the Table-2 for the Group Sequence '1' (GrpSeqIdx =3D=3D 1), the "offHookWarning" tone is generated by repeating this 5000 times (WholeToneRepeatCnt=3D=3D5000) with the = tone being not steady (ToneSteady=3D=3D2) =3D=3D=3D> Here is how this tone would sound 1) 1400Hz + 2060Hz + 2450Hz + 2600Hz on for 100ms 2) 1400Hz + 2060Hz + 2450Hz + 2600Hz off for 100ms 3) repeat (1) and (2) 5000 times 2. If EMTA needs to generate "callWaiting4(12)", it looks at the Table-3 (ToneTable), 2nd row. This row reffers to the Group Sequence '2' (GrpSeqIdx =3D=3D 2). The Group Sequence Index is located in the Group Sequence = Table (Table-2) (2nd, 3rd abd 4th rows for SeqGrpIdx=3D=3D2) which indicates = that the Frequencey Group 2 (FreqGrpIdx=3D2) should be used to generate the tone, and this Group should be played three times. The Table-1 described the composition of this group with various frequencies for reqGrpIdx=3D=3D2, which tells the EMTA to take one frequency (Freq=3D440) and play it for the = 2nd row of the Table-2. Then 3rd row of the Table-2 is played and finally, 4th row of the Table-2 is played. The whole "melody" of three repetion of the Group #2 (FreqGrpIdx=3D=3D 2), plays the required tone by repeating this 700 = times (WholeToneRepeatCnt=3D=3D700) with the tone being not steady (ToneSteady=3D=3D2). =3D=3D=3D> Here is how this tone would sound (1) 440Hz on for 100ms (2) 440Hz off for 100ms (3) 440Hz on for 300ms (4) 440Hz off for 100ms (5) 440Hz on for 100ms (6) 440Hz off for 100ms (7) repeat (1) through (6) 700 times Eugene Nechamkin, Broadcom Corp. _______________________________________________ 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 Jun 29 02:39:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnWEb-0003qk-1D; Wed, 29 Jun 2005 02:39:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnWEY-0003qV-T4 for ipcdn@megatron.ietf.org; Wed, 29 Jun 2005 02:39:42 -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 CAA15331 for ; Wed, 29 Jun 2005 02:39:41 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnWe3-0004dF-P9 for ipcdn@ietf.org; Wed, 29 Jun 2005 03:06:04 -0400 Received: from h-64-105-136-203.snvacaid.dynamic.covad.net ([64.105.136.203] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DnWEN-0005px-00 for ipcdn@ietf.org; Wed, 29 Jun 2005 02:39:32 -0400 Message-ID: <000d01c57c75$d8ef33a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn $E-mail$" Date: Tue, 28 Jun 2005 23:43:22 -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: 32a65c0bf5eb4ec26489239c7cdd0636 Subject: [ipcdn] smidiff diagnostics for draft-ietf-ipcdn-device-mibv2-09.txt (part 3) 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 - 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 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. 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 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 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 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 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.) 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 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. 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. 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? 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 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? 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. 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. 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). 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.) This is the end of the smidiff diagnostics. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jun 29 18:22:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnkx1-00018V-8W; Wed, 29 Jun 2005 18:22:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnkwz-00018Q-Lg for ipcdn@megatron.ietf.org; Wed, 29 Jun 2005 18:22:34 -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 SAA04362 for ; Wed, 29 Jun 2005 18:22:31 -0400 (EDT) Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnlMc-0005gY-Rt for ipcdn@ietf.org; Wed, 29 Jun 2005 18:49:03 -0400 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Wed, 29 Jun 2005 15:22:28 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD 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; Wed, 29 Jun 2005 15:22:04 -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 BGY39438; Wed, 29 Jun 2005 15:21:58 -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 PAA00819; Wed, 29 Jun 2005 15:21:57 -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); Wed, 29 Jun 2005 15:21:52 -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); Wed, 29 Jun 2005 15:21:57 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [ipcdn] Tone Generation Proposal Date: Wed, 29 Jun 2005 15:21:48 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B03122B1E@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] Tone Generation Proposal thread-index: AcV8I7u3gSGz2gvzRB+lCYQlwf35FQAHP7CgAAlKKjAAIwLfUA== From: "Eugene Nechamkin" To: "T, Shivakumar" , "Ipcdn (E-mail)" X-OriginalArrivalTime: 29 Jun 2005 22:21:57.0817 (UTC) FILETIME=[F66F9A90:01C57CF8] X-WSS-ID: 6EDDC0AE2AW5286205-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 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 Given the subject and the reflector's restrictions, I'll try to make my response as short as possible. Please, first see my answers to your = questions on our proposal in-line with your questions (marked with , ). = Then - please see the part which analyses your proposal immediately below (COMMENTS). First - general comment related to all tables participating in tone generation: the reasonable level of flexibility in changing the tone generation parameters (e.g. frequencies values, compositions of the = tones, and duration of the frequencies and their dB levels) is defined by the practical needs of the Operators in changing these parameters = "on-the-fly". The tone generation parameters, once established for the particular = Operator (e.g. geographical zone), are not changed until the EMTA is used in the = realm of this Operator. Hence - the real need for modifying these parameters "on-the-fly" is quite limited.=20 COMMENTS: =3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Having "ToneType" to be an index in ALL tables creates unneccessary interdependecies in the tables making processing logic unneccessary more complicated. For example, having the ToneTable Index in "FreqTable" = prohibits the re-use of the same Frequency Group (the same frequency composition) = for different tones. This results in the waste of resources of the MTA. Your example seems to demonstrate that the ToneType is not required when transitioning from multi-freq-tone table with ToneType=3D5 to the = FreqTable with PriGrp=3D1. Our approach demonstrates how this can be accomlished = simpler, without "ToneType" being an index in all tables. ***** If ToneType is eliminated from the "FreqTable", then this table = becomes almost identical to the "FreqGroupTable" of our proposal. 2. pktcSigDevMultiFreqToneTable:=20 - The number of groups for each tone is unneccessary restructed by = two. What if the tone requires more than two groups? - "CompMode" is not clearly defined: if it reffers to the Composition = of the Groups (as an example seems to state) then the control over = frequencies composition is not possible. If it reffers to the composition of the frequencises, then Groups composition is not defined. Also CompMode has = to have the Modulation option in which case it's not clear what's = modulating what - group over group or frequency over frequency. In both cases, it's = not defined how the modulation's done. - "FreqNum" is not neccessary as it's not being used in the tone generation (based on the example). ***** If "FreqNum" and "SecGrp" are eliminated from the pktcSigDevMultiFreqToneTable, then this table becomes almost identical = to the "GroupSeqTable" of our proposal with the index "ToneType" essentially = used the same way as "GrpSeqIdx" in our proposal. 3. pktcSigDevToneTable: - "NumOnOff" is not clearly defined, hence the restriction related to = it is not clear: "FreqNum in the multi freq tone table MUST not exceed its corresponding value specified in pktcSigDevToneNumOnOffCount". If it's = "the number of on-off sequence(pktcSigDevToneNumOnOffCount) required for each = tone type" (as stated by your description), then the numbers in the example = do not correspond to it: for ToneType=3D12, NumOnOff should be '5', not = '3'. If "NumOnOff" is the number of occurances of the particular ToneType in the pktcSigDevMultiFreqToneTable (but NOT the number of frequencies as the = name=20 "FreqNum" seems to suggest!), then this number equals to the number of = rows with same ToneType in pktcSigDevMultiFreqToneTable. In both cases = "NumOnOff" is not needed. - "NumFreq" is not needed as this number equals to the number of the = rows for the corresponding group in pktcSigDevToneFreqTable. ***** If "NumOnOff" and "NumFreq" are eliminated from the pktcSigDevToneTable, then this table becomes almost identical to the "ToneTable" of our proposal. Eugene Nechamkin, Broadcom Corp. -----Original Message----- From: T, Shivakumar [mailto:shivak@ti.com]=20 Sent: Tuesday, June 28, 2005 11:00 PM To: Eugene Nechamkin; Ipcdn (E-mail) Subject: RE: [ipcdn] Tone Generation Proposal The following issues are not addressed in this proposal.=20 1) Since the FreqVal is index to the FreqGroupTable, the frequencies = used for playing a tone cannot be modified. Respectfully disagree. If changing the frequency for the same group is = the requirement, it can be simply arranged by choosing a different index in = the MIB table (when we come to the MIB issues) or by just creating a new = group in the "FreqGroupTable" and, possibly, deleting the previous one (if = necessary). 2) There is no way to increase or decrease the number of frequencies = used to play a tone. Respectfully disagree for two reasons. Firstly - if necessary, this can = be easily done by just incuding an additional row in the "FreqGroupTable" = or deleting the row from the table. For example: say you want to introduce additional freq of 600 Hz to the "callWaiting4(12)" tone. This can be = easily done by just creating an additional row in the "FreqGroupTable": FreqGrpIdx FreqVal DbLevel CompMode =20 =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=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 2 600 -100 1 Secondly - there is no need to modify the frequency composition 'on the = fly'. The table should be setup ahead of time to meet the tone requirements. 3) The entry with FreqGrpIdx=3D2 and FreqVal=3D440 in the FreqGroupTable = can be used for playing multiple tone types(callwaiting 1,2,3,4) and modifying = any value in this row would affect the other tone type. Respectfully disagree for two reasons.=20 Firstly - it can be done by by introducing a new Frequency Group for = each tone (if neccesssary). Secondly - there is no need to modify the = frequency composition 'on the fly'. The table should be setup ahead of time to = meet the tone requirements. 4) Why CompMode=3D2 be restricted to 1st and 2nd frequencies. I cannot think of any other real example of the tone when more than two frequencies are participating in the modulation when generarting a = particular tone. I would appreciate any reference on such example. If this is realy required then we need to clearly define how to modulate more than 2 frequencies. All these issues are addressed in the following proposal: 1) Define a freq table(pktcSigDevToneFreqTable) indexed by pktcSigDevToneType,pktcSigDevToneFreqGrpNumber,pktcSigDevToneFreqIndex. pktcSigDevToneFreqGrpNumber: This MIB Object along with = pktcSigDevToneType groups multiple frequency entries that has to be added to form a tone. ToneType FreqGrpNumber FreqIndex FreqValue DbLevel =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D 5 1 1 1400 -130 5 1 2 2060 -130 5 1 3 2450 -130 5 1 4 2600 -130 12 1 1 440 -130 2) Define a Multi Freq Tone table(pktcSigDevMultiFreqToneTable) indexed = by pktcSigDevToneType, pktcSigDevToneFrequencyNumber. This Table is same as the one defined in draft-8 except that instead of specifying the frequency values in the PriCompValue and SecCompValue = we'll specify the Freq Group Number(pktcSigDevToneFreqGrpNumber) for a = specific tone type. Also CompMode can contain either ignoreSecondary(1) or primaryModulatedBySecondary(2). ToneType FreqNum PriGrp SecGrp CompMode CompPrtg OnDur OffDur = RepeatCount =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=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 5 1 1 1 1 0 100 100 1 12 1 1 1 1 0 100 100 1 12 2 1 1 1 0 300 100 1 12 3 1 1 1 0 100 100 1 3) Define a tone table(pktcSigDevToneTable) indexed by = pktcSigDevToneType. This table is same as the one defined in draft-8 except for the DbLevel = is removed and two new columns are added to specify the number of frequencies(pktcSigDevToneNumFrequencies) and to specify the number of = on-off sequence(pktcSigDevToneNumOnOffCount) required for each tone type. For any tone type the FreqIndex in the FreqTable MUST not exceed its corresponding value specified in pktcSigDevToneNumFrequencies and the = FreqNum in the multi freq tone table MUST not exceed its corresponding value specified in pktcSigDevToneNumOnOffCount. ToneType RepeatCount Steady NumFreq NumOnOff =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=3D=3D=3D 5 5000 2 4 1 12 700 2 1 3 In order to play the offhookwarning tone(tone type=3D5), iterate over = all entries in the multi freq tone table with index 5. For each row in the = multi freq tone table with index=3D5 select the corresponding PriGrp and = SecGrp. PriGrp =3D 1 SecGrp =3D 1 The PriGrp specifies the group number of the primary component of the = tone. This is specified in the FreqTable. This tone is generated by adding all frequencies specified in the freq table for that particular tone type = and FreqGrpNumber(value specified in PriGrp). Primary Component of the Tone =3D 1400 + 2060 + 2450 + 2600 Since compMode is set to 1(ignoreSecondary) the secondary component is ignored. The resulting tone is played for 100msec ON(on dur) and 100msec OFF(off dur) once(repeat count). This entire sequence is repeated for the value specified in RepeatCount = of the Tone Table. Repeat Count =3D 5000 ------------------------------------------------------------------------ - Shiva _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn