From exim@www1.ietf.org Mon Mar 1 15:14:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03410 for ; Mon, 1 Mar 2004 15:14:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axtnd-0005dG-Sf for ipcdn-archive@odin.ietf.org; Mon, 01 Mar 2004 15:14:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21KE10a021633 for ipcdn-archive@odin.ietf.org; Mon, 1 Mar 2004 15:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axtnc-0005cP-VP; Mon, 01 Mar 2004 15:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtnV-0005aX-Lm for ipcdn@optimus.ietf.org; Mon, 01 Mar 2004 15:13:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03350 for ; Mon, 1 Mar 2004 15:13:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxtnU-0002tY-00 for ipcdn@ietf.org; Mon, 01 Mar 2004 15:13:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axtmf-0002oY-00 for ipcdn@ietf.org; Mon, 01 Mar 2004 15:13:01 -0500 Received: from mms2.broadcom.com ([63.70.210.59]) by ietf-mx with esmtp (Exim 4.12) id 1Axtlj-0002ic-00 for ipcdn@ietf.org; Mon, 01 Mar 2004 15:12:03 -0500 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Mon, 01 Mar 2004 12:11:49 -0800 X-Server-Uuid: 011F2A72-58F1-4BCE-832F-B0D661E896E8 Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id MAA03378; Mon, 1 Mar 2004 12:11:20 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0741.brcm.ad.broadcom.com with Microsoft SMTPSVC(5.0.2195.5329) ; Mon, 1 Mar 2004 12:11:53 -0800 Content-class: urn:content-classes:message Subject: RE: [ipcdn] RE: IETF IPCDN Signaling MIB - Draft 3 - Last Callfor Comments (NEW ISSUE pktcSigDevToneDbLevel reference point) MIME-Version: 1.0 Date: Mon, 1 Mar 2004 12:11:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <24CDBA67F085904999751B3C4F9E8C0BE2CE4D@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] RE: IETF IPCDN Signaling MIB - Draft 3 - Last Callfor Comments (NEW ISSUE pktcSigDevToneDbLevel reference point) Thread-Index: AcPsRFhNPnXfnARlSPG5NgJ97IQa8QThLIjA From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" , ipcdn@ietf.org X-OriginalArrivalTime: 01 Mar 2004 20:11:53.0844 (UTC) FILETIME=[708F1340:01C3FFC9] X-WSS-ID: 6C5D468F1MS2331612-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable In general, we agree that that an analog reference point would be easier = to understand from the operator's standpoint. Our initial goal as stated = when this issue was raised was to eliminate the loss of SNR due to = combined requirements of the analog reference point and the high DLP for = some countries.=20 As you have stated previously, the largest signal level for voiceband = tones is 0dBm. However, this isn't the largest value that would need to = be generated out of the MTA. Rather this is the maximum of the range for = some signals that is acceptable for that tone. For example, in the UK, = dialtone can be between -27dBm and 0dBm to be valid, it doesn't mean = that dialtone of 0dBm needs to be generated. Even if we restricted the = MIB range slightly, we believe we would far exceed the requirements in = EN 300 001.=20 Therefore, we believe the range should further be restricted to -25dB to = -3dB to help alleviate this problem. If we could make this change, and = keep the analog reference point, then this should be an acceptable = solution to all of the concerns raised. Here is what the final = definition of this parameter would look like: pktcSigDevToneDbLevel OBJECT-TYPE=20 SYNTAX Integer32 (-250..-30)=20 UNITS "TenthdBm"=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION=20 " This is the decibel level at which tones could be generated at the a and b terminals (TE connection point)." DEFVAL { -4 }=20 ::=3D{pktcSigDevToneEntry 2 }=20 Eugene Nechamkin, Bradcom Corp. ph: (604) 233-8500 -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com] Sent: Thursday, February 05, 2004 3:55 PM To: 'ipcdn@ietf.org' Subject: RE: [ipcdn] RE: IETF IPCDN Signaling MIB - Draft 3 - Last Callfor Comments (NEW ISSUE pktcSigDevToneDbLevel reference point) Motorola does not agree with the proposed change to a digital reference = point. In looking at the PC NCS spec, there is guidance that the RJ11 connector = is the appropriate reference point. The MIB also supports RJ11 as the = reference point: "An endpoint or MTA endpoint is a standard RJ-11 telephony physical port = located on the MTA and used for attaching the telephone device to the = MTA." In addition, the Telecommunications industry uses the RJ11 connector as = the reference (interface) point. Newer standards also use this as the = demarcation between the Network Operator and the CPE, thus it is the = user "interface" reference. Changing to an internal reference point = (digital PCM code) does not have meaning since it cannot be directly = measured by the operator when the MTA is installed. Therefore, it is appropriate for the reference to be as presently stated = in the pktcSigDevToneDbLevel object. The MIB, which is provisioned by = the operator of the system must be "friendly" to the operators point of = view. To burden the operator with tracking loss plans (which may vary = from MTA to MTA or line to line) is not practical.=20 Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ 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 exim@www1.ietf.org Tue Mar 2 12:07:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19567 for ; Tue, 2 Mar 2004 12:07:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyDMH-0000JG-N0 for ipcdn-archive@odin.ietf.org; Tue, 02 Mar 2004 12:07:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22H75cb001150 for ipcdn-archive@odin.ietf.org; Tue, 2 Mar 2004 12:07:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyDMC-0000HB-Uc; Tue, 02 Mar 2004 12:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyDLn-0000CY-Lj for ipcdn@optimus.ietf.org; Tue, 02 Mar 2004 12:06:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19495 for ; Tue, 2 Mar 2004 12:06:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyDLm-00040D-00 for ipcdn@ietf.org; Tue, 02 Mar 2004 12:06:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyDKp-0003qY-00 for ipcdn@ietf.org; Tue, 02 Mar 2004 12:05:37 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AyDJu-0003bq-00; Tue, 02 Mar 2004 12:04:39 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i22H45ut003679; Tue, 2 Mar 2004 10:04:05 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Mar 2004 10:04:05 -0700 Message-ID: Thread-Topic: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Thread-Index: AcP/+FAa0cy3TLYoQ9G5WHj5Y4XgEQAc9PKQ From: "Eduardo Cardona" To: "Randy Presuhn" , Cc: "Ipcdn List (E-mail)" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Randy,=20 Few comments,=20 I review the MIB and appears compelling respect to previous RFC=20 Just one comment (*) traceRouteCtlMiscOptions=20 It appears to me an uncanny object and rather implementations may opt to extend the capabilities in the private branch, could leave with that to avoid deprecation, of if there are field implementations.=20 Regardless of the additions to the MIB I apologize for the late notice, Before sending a complete proposal and get your concept of the best approach, below is the proposal to add a simplified Compliance statement for devices not requiring to keep constant status of PING/TRACEROUTE operations, only remote operation per operator request. We are looking at your comments about the clear overlap in draft-ietf-disman-remops-mib-v2-01.txt With IPCDN draft http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00. txt ( currently out of date in IETF drafts site) which is clearly a subset of the DISMAN-PING-MIB=20 Lectors refer to http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00818. html Should the proposal below being include in the remops MIB or should we update IPCDN cable gateway Tools MIB module to be just the compliance statement outlined below?=20 RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null named log" default entry for devices not supporting the named log=20 Named log is analog to disman remops draft for "OwnerIndex" and "TestName" where default entries are created (null owner, null TestName) for a manager requested operation of PING/ TRACEROUTE, NSLOOKUP, mostly for small foot-print devices with no network monitoring role at the connectivity level as pretended with this updated RFC. In summary A new Compliance Statement for small devices with no monitoring capabilities to : 1) remove the constant pulling and login information=20 2) remove the test row creation=20 - CTL* Results* tables only default entries (null owner, null TestName) 3) History* tables not required. - New basicGroups to exclude History* objects and other objects which are not relevant to the simplified=20 system.=20 - Create an additional set of Compliance statements to require the new Groups and other objects Compliance=20 requirements MIN-ACCESS clauses mainly Schema of the content of the new Compliance statement:=20 List of objects not to include in basicPingGroup OBJECT-GROUP clause qnd/or hints for OBJECT Compliances: pingMaxConcurrentRequests -- remove pingCtlDataFill -- remove or MIN-ACCESS read-only default value is OK pingCtlFrequency -- remove Only one test pingCtlType -- remove or MIN-ACCESS read-only pingCtlByPassRouteTable -- remove or MIN-ACCESS read-only pingCtlDSField -- MIN-ACCESS read-only pingCtlStorageType -- remove=20 pingCtlRowStatus -- SYNTAX RowStatus (notReady(2) WRITE-SYNTAX RowStatus (active(1), notInService(3) =20 pingCtlIfIndex -- not to include pingProbeHistory* -- not to include. List of objects not to include in basicTraceRouteGroup OBJECT-GROUP clause and/or hints for OBJECT Compliances: traceRouteMaxConcurrentRequests -- remove traceRouteCtlType -- remove or MIN-ACCESS read-only traceRouteCtlDSField -- MIN-ACCESS read-only traceRouteCtlByPassRouteTable -- remove or MIN-ACCESS read-only traceRouteCtlIfIndex -- not to include traceRouteCtlMiscOptions -- not to include traceRouteCtlDontFragment -- remove or MIN-ACCESS read-only traceRouteCtlInitialTtl -- remove or MIN-ACCESS traceRouteCtlFrequency -- remove only one test traceRouteCtlDescr -- remove traceRouteCtlCreateHopsEntries -- remove HopsEntries not required. traceRouteCtlRowStatus -- SYNTAX RowStatus (notReady(2) WRITE-SYNTAX RowStatus (active(1), notInService(3) =20 traceRouteCtlStorageType -- remove traceRouteProbeHistory* -- not to include. List of objects not to include in basicLookupGroup OBJECT-GROUP clause and/or hints for OBJECT Compliances: lookupMaxConcurrentRequests -- remove lookupPurgeTime -- remove lookupCtlRowStatus -- SYNTAX RowStatus (notReady(2) WRITE-SYNTAX RowStatus (active(1), notInService(3) =20 Best Regards Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Monday, March 01, 2004 6:44 PM To: disman@ietf.org Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Hi - > From: Eduardo Cardona > Sent: Mar 2, 2004 9:25 AM > To: Randy Presuhn , disman@ietf.org > Subject: RE: [Disman] WG last call on=20 > draft-ietf-disman-remops-mib-v2-01.txt ... > One simple note, I tough last call was March 5th No, it was supposed to end March 2. However, I'm not going to hand it to our AD until I can be reasonably sure that it has received adequate review. > We at Cablelabs are interested in adding a simplified compliance=20 > statement for ad-hoc procedure call instead of a user entry schecule=20 > entry, so an user can do a one time execution e.g PING It would have been nice to have learned of this earlier, rather than during WG last call. > The draft we had is almost complete, > Would be that an opportunity to add that? I can post that tomorrow in > the list if compeling=20 ... I'd like to have this discussion sooner rather than later, so please make your specific proposal as quickly as you can. My opinion as a technical contributor is that the case for these changes would need to be fairly compelling if they would result in the remote operations MIB cycling at proposed rather than advancing to draft standard. As working group chair, I want to ensure that whatever course we take reflects WG consensus. So, balancing the need for bringing this to a conclusion with the need to ensure that the technical issues are properly considered, I'll entertain discussion of this issue ("ad hoc procedure call") until Friday noon (Korean Time). Shortly thereafter I'll make a call on whether there is consensus to modify the draft regarding this specific proposal. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Mar 2 19:14:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11816 for ; Tue, 2 Mar 2004 19:14:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyK1S-0005Np-DE for ipcdn-archive@odin.ietf.org; Tue, 02 Mar 2004 19:14:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i230E24M020687 for ipcdn-archive@odin.ietf.org; Tue, 2 Mar 2004 19:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyK1Q-0005N3-GY; Tue, 02 Mar 2004 19:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyK1H-0005M7-QZ for ipcdn@optimus.ietf.org; Tue, 02 Mar 2004 19:13:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11766 for ; Tue, 2 Mar 2004 19:13:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyK1G-000254-00 for ipcdn@ietf.org; Tue, 02 Mar 2004 19:13:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyK0H-0001vm-00 for ipcdn@ietf.org; Tue, 02 Mar 2004 19:12:50 -0500 Received: from tisch.mail.mindspring.net ([207.69.200.157]) by ietf-mx with esmtp (Exim 4.12) id 1AyJzJ-0001nA-00; Tue, 02 Mar 2004 19:11:49 -0500 Received: from [192.168.167.41] (helo=wamui03.slb.atl.earthlink.net) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AyJzJ-0000Fc-00; Tue, 02 Mar 2004 19:11:49 -0500 Message-ID: <29620639.1078272709925.JavaMail.root@wamui03.slb.atl.earthlink.net> Date: Wed, 3 Mar 2004 09:11:49 +0900 (GMT+09:00) From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Cc: "Ipcdn List (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,REMOVE_IN_QUOTES autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ipcdn] RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi - > From: Eduardo Cardona > Sent: Mar 3, 2004 2:04 AM > To: Randy Presuhn , disman@ietf.org > Cc: "Ipcdn List (E-mail)" > Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt ... Thanks for the comments! ... > (*) traceRouteCtlMiscOptions > It appears to me an uncanny object and rather implementations may opt to > extend the capabilities in the private branch, could leave with that to > avoid deprecation, of if there are field implementations. any suggested changes? ... > Should the proposal below being include in the remops MIB or should we > update IPCDN cable gateway Tools MIB module to be just the compliance > statement outlined below? Both seem reasonable. If we can include a "basic" compliance statement to suit your needs without jeopardizing progression, that seems like an option that I would prefer as a technical contributor, though I admit that it is not a strong preference and would like to hear other opinions. > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null named > log" default entry for devices not supporting the named log > Named log is analog to disman remops draft for "OwnerIndex" and > "TestName" where default entries are created > (null owner, null TestName) for a manager requested operation of PING/ > TRACEROUTE, NSLOOKUP, mostly for small foot-print devices with no > network monitoring role at the connectivity level as pretended with this > updated RFC. I have no problem with this in principle, and think it would be really nice if we can verify that the MIB definitions do not preclude operating this way. > In summary A new Compliance Statement for small devices with no > monitoring capabilities to : ... I'd phrase it a bit differently. Rather than "remove" information, I think the proposal is to ensure that it can function meaningfully using a small subset of the objects. I'd like to hear from Juergen (and others) regarding the details of the proposed compliance material, especially with regard to whether there are any details in the current object definitions that would prevent this usage. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Mar 5 11:44:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15602 for ; Fri, 5 Mar 2004 11:44:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIQc-0001rn-RP for ipcdn-archive@odin.ietf.org; Fri, 05 Mar 2004 11:44:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25Gi2eA007172 for ipcdn-archive@odin.ietf.org; Fri, 5 Mar 2004 11:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIQb-0001r1-3q; Fri, 05 Mar 2004 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIQI-0001qX-DT for ipcdn@optimus.ietf.org; Fri, 05 Mar 2004 11:43:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15574 for ; Fri, 5 Mar 2004 11:43:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzIQF-0007V8-00 for ipcdn@ietf.org; Fri, 05 Mar 2004 11:43:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzIPJ-0007L8-00 for ipcdn@ietf.org; Fri, 05 Mar 2004 11:42:42 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AzIOP-00071S-00; Fri, 05 Mar 2004 11:41:45 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i25GfCut003527; Fri, 5 Mar 2004 09:41:13 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Mar 2004 09:41:03 -0700 Message-ID: Thread-Topic: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Thread-Index: AcQAtHyjl1N9qd0FT+WG1twTQHhagQCGD5nQ From: "Eduardo Cardona" To: "Randy Presuhn" , Cc: "Ipcdn List (E-mail)" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,REMOVE_IN_QUOTES autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks for the comments,=20 I will wait as you for hearing from authors One note below ... > (*) traceRouteCtlMiscOptions > It appears to me an uncanny object and rather implementations may opt to > extend the capabilities in the private branch, could leave with that to > avoid deprecation, of if there are field implementations.=20 any suggested changes? In the revision history : ( if option is deprecation), something like=20 The MIB object traceRouteCtlMiscOptions is being deprecated, implementations willing to extend the traceRoute functionality with proprietary parameters can follow standard procedures of extending entry tables (e.g. AUGMENTS [RFC2578]) If willing to have a direct parameters reference in the CTL entry, similar to the existing traceRouteCtlMiscOptions, uses a new object with RowPointer syntax or an ID pointing to a private table entry, ( in some cases it may simplify the configuration model if the vendor feature is just a flag or a common parameter set for all owners/testNames, pointing the test to the same parameter definition, policy, etc. =20 As I said, it seems to me to be quite unusual object definition, Due the already RFC status could be left as is, or change it for one of the above options or any other alternative.=20 Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Tuesday, March 02, 2004 5:12 PM To: disman@ietf.org Cc: Ipcdn List (E-mail) Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Hi - > From: Eduardo Cardona > Sent: Mar 3, 2004 2:04 AM > To: Randy Presuhn , disman@ietf.org > Cc: "Ipcdn List (E-mail)" > Subject: RE: [Disman] WG last call on=20 > draft-ietf-disman-remops-mib-v2-01.txt ... Thanks for the comments! ... > (*) traceRouteCtlMiscOptions > It appears to me an uncanny object and rather implementations may opt to > extend the capabilities in the private branch, could leave with that to > avoid deprecation, of if there are field implementations.=20 any suggested changes? ... > Should the proposal below being include in the remops MIB or should we > update IPCDN cable gateway Tools MIB module to be just the compliance=20 > statement outlined below? Both seem reasonable. If we can include a "basic" compliance statement to suit your needs without jeopardizing progression, that seems like an option that I would prefer as a technical contributor, though I admit that it is not a strong preference and would like to hear other opinions. > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null=20 > named log" default entry for devices not supporting the named log=20 > Named log is analog to disman remops draft for "OwnerIndex" and=20 > "TestName" where default entries are created (null owner, null=20 > TestName) for a manager requested operation of PING/ TRACEROUTE,=20 > NSLOOKUP, mostly for small foot-print devices with no network=20 > monitoring role at the connectivity level as pretended with this=20 > updated RFC. I have no problem with this in principle, and think it would be really nice if we can verify that the MIB definitions do not preclude operating this way. > In summary A new Compliance Statement for small devices with no=20 > monitoring capabilities to : ... I'd phrase it a bit differently. Rather than "remove" information, I think the proposal is to ensure that it can function meaningfully using a small subset of the objects. I'd like to hear from Juergen (and others) regarding the details of the proposed compliance material, especially with regard to whether there are any details in the current object definitions that would prevent this usage. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Mar 5 19:04:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06976 for ; Fri, 5 Mar 2004 19:04:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzPIP-0000fQ-F7 for ipcdn-archive@odin.ietf.org; Fri, 05 Mar 2004 19:04:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26041cc002563 for ipcdn-archive@odin.ietf.org; Fri, 5 Mar 2004 19:04:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzPIO-0000fB-MB; Fri, 05 Mar 2004 19:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzPIL-0000et-Hx for ipcdn@optimus.ietf.org; Fri, 05 Mar 2004 19:03:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06941 for ; Fri, 5 Mar 2004 19:03:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzPII-0004Kq-00 for ipcdn@ietf.org; Fri, 05 Mar 2004 19:03:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzPHJ-00049U-00 for ipcdn@ietf.org; Fri, 05 Mar 2004 19:02:54 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1AzPGL-0003pa-00 for ipcdn@ietf.org; Fri, 05 Mar 2004 19:01:53 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id i26012BS011549 for ; Fri, 5 Mar 2004 17:01:02 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i2601crm015013 for ; Fri, 5 Mar 2004 18:01:38 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Fri, 5 Mar 2004 16:01:45 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'Wim De Ketelaere'" , Beacham Gordon-CGB005 , "'Eugene Nechamkin'" , ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Date: Fri, 5 Mar 2004 16:01:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_3 autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Wim, Thank you for your comments. If I understand proposed solution correctly, I believe you are suggesting a change could be made to the TC as follows: PktcRingCadence ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION This object represents a ring cadence and repeatable characteristics. The first two octets of the bit string represent the length in bits of the duration of the cadence. The third octet is used to represent repeatable characteristics. 00000000 means repeatable, and 10000000 means non repeatable. Each Bit after the third octet represents 50 ms and 1 represents ring and 0 represents silent. The first bit of the fourth octet is the first bit of the ring cadence. A total of 264 Bits can be set to represent 13200 ms of total cadence cycle. SYNTAX OCTET STRING (SIZE(4..36)) The following object descriptions would change (i.e., remove the duration and repeatable characteristics sentences) and the DEFVAL would be removed: pktcSigDevRgCadence pktcSigDevRsCadence pktcSigDevR0Cadence pktcSigDevR1Cadence pktcSigDevR2Cadence pktcSigDevR3Cadence pktcSigDevR4Cadence pktcSigDevR5Cadence pktcSigDevR6Cadence pktcSigDevR7Cadence The following object SYNTAX would change to use the PktcRingCadence TC: pktcSigDevRingCadence The following objects could then be deleted: pktcSigDevStandardRingCadence -> would now be covered by pktcSigDevRgCadence (L package) pktcSigDevRingSplashCadence -> would now be covered by pktcSigDevRsCadence (L package) You could then update your "Clarification of L Package for Euro-PacketCable Document v6.0 (2004/1/20)" to reflect these changes, if there is agreement. Gordon -----Original Message----- From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com] Sent: Monday, March 01, 2004 12:07 AM To: 'Beacham Gordon-CGB005'; 'Eugene Nechamkin'; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Hi Gordon, I asked you the difference between those two MIB-object a long time ago, and you pointed out that a different object was needed for Europe because of the difference in total time and needed granularity. If the total duration difference needs to be supported, it needs to be supported without the need for the E-package. As it is important that basic calls can be supported without an MTA that support the E-package, and you clarified that for Europe a longer cadence is needed. Based on that it seems the normal way to go to have the two extra MIB-objects. By that a CMS can support both European and US market without any changes on the CMS ! Please note that for now the E-package is still optional, as far as I know no CMS supports it ! A solution would be to have the definition adjusted for the MIB so it supports both US and European requirements: the duration of the cadence can be adjusted by having leading zeroes. The total number of bits needs to be increased to support a longer maximum length, and more granularity (50 ms). This would mean that the pktcSigDevRgCadence and RsCadence and r0 to r7 take the definition of the for now European-only cadence. This allow the needed flexibility while having only one mib-object to specify the cadences. This can be done by adjusting the textual convention (PktcRingCadence) This would mean that an MTA can have exactly the same mapping from NCS to MIB for the L-package, independent of the region in which it will be used, and independent from possible E-package support. Thanks, Best regards, Wim -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com] Sent: 27 February 2004 23:46 To: 'Eugene Nechamkin'; Beacham Gordon-CGB005; Wim De Ketelaere; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Exactly. This is precisely what the pktcSigDevRingCadenceTable object is defined to handle (international ring cadences to 13.2s) using the V5.x "cr(x)" mechanism noted in the object description. For example, an international operator could define cr5 for standard ring and cr9 for ring splash, etc for up to 128 international cadences. V5.x defined 128 possible ring cadences for international ring messages without concern for what those cadences are named. The 101 909-4 spec does not name these cadences either and the name should not be a concern for the MIB definitions. Gordon -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Friday, February 27, 2004 2:13 PM To: Beacham Gordon-CGB005; Wim De Ketelaere; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant It's might also be worth noting that the "pktcSigDevRgCadence" and "pktcSigDevRsCadence" on one hand, and "pktcSigDevStandardRingCadence" and "pktcSigDevRingSplashCadence" - on the other have different requirement for the Cadence timing granularity, hence the "pktcSigDevRgCadence" and "pktcSigDevRsCadence" could not have been used to represent Euro-PC Cadence resolution requirement reflected in "pktcSigDevStandardRingCadence" and "pktcSigDevRingSplashCadence". Eugene. -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Beacham Gordon-CGB005 Sent: Friday, February 27, 2004 1:59 PM To: 'Wim De Ketelaere'; Eugene Nechamkin; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Interesting. Thanks for pointing that out. However, I don't follow why the mapping has been made that way in the "Clarification of L Package for Euro-PacketCable Document v6.0 (2004/1/20)." The objects referenced in 2.19 and 2.21 for the L package rg and rs cadences are in the international group with a max cadence of 13.2s. The other distinctive ring cadences in the above document map to core L package objects r0..r7 with a max cadence of 6.0s. The cadence mapping seems to be inconsistent. I would have expected the 2.19 and 2.21 cadence for rg/rs to be mapped to the pktcSigDevRgCadence and pktcSigDevRsCadence core L package objects. International cadences would then be handled via the E package extensions and associated object (pktcSigDevRingCadenceTable). Wim, Can you comment/clarify why the rg/rs cadences are mapped to objects in the international group instead of the pktcSigDevRgCadence and pktcSigDevRsCadence objects? Thanks. Gordon -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Wednesday, February 25, 2004 5:21 PM To: Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence are redundant > The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence > objects are redundant. I am not sure I can completely agree with this statement (if I understand it correctly). Both of these objects are required for Euro-L-package, because of the way the RG and RS signalls are currently defined: For Euro-L-Package: - RG -> pktcSigDevStandardRingCadence - RS -> pktcSigDevRingSplashCadence The "pktcSigDevRingCadenceTable" contains the cadence values for the E-package. Having in mind that E-package is optional, and L-package is mandatory, I am not sure I understand how pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence can be "merged" into the "pktcSigDevRingCadenceTable". Or, are you suggesting that "pktcSigDevRingCadenceTable" should contain the RG and RS cadencies for Euro-L-Package along with the values for E-package? If yes, I think the proper mapping of the table indexes to the corresponding signal should be somehow defined, and corresponding modifications of the Euro-L-Package should also be put in place. Though from the MIB optimization stand point of view the proposed modification might make sense, however, from the currently imlemented and intended funtionality prospective it looks unnecessary (please correct me if my understanding of your proposal deviates from what you had in mind). Eugene Nechamkin, Broadcom Corp., ph: (604) 233-8500 -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Beacham Gordon-CGB005 Sent: Wednesday, February 25, 2004 11:01 AM To: ipcdn@ietf.org Subject: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence are redundant The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence objects are redundant. These objects are recommended to be deleted from the NCS Signaling MIB. The use of separate pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence objects is a carryover from the L line package and they are not needed in the E line package. Instead, normal ring and ring splash cadences can be defined using the pktcSigDevRingCadenceTable object. Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Mar 8 01:48:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29456 for ; Mon, 8 Mar 2004 01:48:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0EYY-0008A6-2D for ipcdn-archive@odin.ietf.org; Mon, 08 Mar 2004 01:48:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i286m55Y031364 for ipcdn-archive@odin.ietf.org; Mon, 8 Mar 2004 01:48:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0EYT-000866-JW; Mon, 08 Mar 2004 01:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0EXh-000834-J2 for ipcdn@optimus.ietf.org; Mon, 08 Mar 2004 01:47:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29206 for ; Mon, 8 Mar 2004 01:47:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0EXe-00062m-00 for ipcdn@ietf.org; Mon, 08 Mar 2004 01:47:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0EWf-0005uZ-00 for ipcdn@ietf.org; Mon, 08 Mar 2004 01:46:10 -0500 Received: from poros.telenet-ops.be ([195.130.132.44]) by ietf-mx with esmtp (Exim 4.12) id 1B0EVh-0005mS-00 for ipcdn@ietf.org; Mon, 08 Mar 2004 01:45:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by poros.telenet-ops.be (Postfix) with SMTP id 2C26B3800C5 for ; Mon, 8 Mar 2004 07:45:09 +0100 (MET) Received: from tcomlabs.com (D5E0060A.kabel.telenet.be [213.224.6.10]) by poros.telenet-ops.be (Postfix) with SMTP id BC0F1380096 for ; Mon, 8 Mar 2004 07:45:08 +0100 (MET) Received: (qmail 13387 invoked from network); 8 Mar 2004 06:43:42 -0000 Received: from unknown (HELO tComGateway.tComlabs.com) (127.0.0.1) by tcomlabs.com with SMTP; 8 Mar 2004 06:43:42 -0000 Received: from ([10.5.5.37]) by tComGateway.tComLabs.com (MailMonitor for SMTP v1.2.2 ) ; Mon, 8 Mar 2004 07:43:42 +0100 (CET) From: "Wim De Ketelaere" To: "'Beacham Gordon-CGB005'" , "'Eugene Nechamkin'" , Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Date: Mon, 8 Mar 2004 07:45:08 +0100 Message-ID: <001201c404d8$e5b5cb00$2505050a@LAPTOPWIM> 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, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_3 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Gordon, Yes, the more I look at it, the more I like it, it makes everything much easier, more uniform and cleaner I think ! Thanks, Best regards, Wim -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com] Sent: 06 March 2004 01:02 To: 'Wim De Ketelaere'; Beacham Gordon-CGB005; 'Eugene Nechamkin'; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Wim, Thank you for your comments. If I understand proposed solution correctly, I believe you are suggesting a change could be made to the TC as follows: PktcRingCadence ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION This object represents a ring cadence and repeatable characteristics. The first two octets of the bit string represent the length in bits of the duration of the cadence. The third octet is used to represent repeatable characteristics. 00000000 means repeatable, and 10000000 means non repeatable. Each Bit after the third octet represents 50 ms and 1 represents ring and 0 represents silent. The first bit of the fourth octet is the first bit of the ring cadence. A total of 264 Bits can be set to represent 13200 ms of total cadence cycle. SYNTAX OCTET STRING (SIZE(4..36)) The following object descriptions would change (i.e., remove the duration and repeatable characteristics sentences) and the DEFVAL would be removed: pktcSigDevRgCadence pktcSigDevRsCadence pktcSigDevR0Cadence pktcSigDevR1Cadence pktcSigDevR2Cadence pktcSigDevR3Cadence pktcSigDevR4Cadence pktcSigDevR5Cadence pktcSigDevR6Cadence pktcSigDevR7Cadence The following object SYNTAX would change to use the PktcRingCadence TC: pktcSigDevRingCadence The following objects could then be deleted: pktcSigDevStandardRingCadence -> would now be covered by pktcSigDevRgCadence (L package) pktcSigDevRingSplashCadence -> would now be covered by pktcSigDevRsCadence (L package) You could then update your "Clarification of L Package for Euro-PacketCable Document v6.0 (2004/1/20)" to reflect these changes, if there is agreement. Gordon -----Original Message----- From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com] Sent: Monday, March 01, 2004 12:07 AM To: 'Beacham Gordon-CGB005'; 'Eugene Nechamkin'; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Hi Gordon, I asked you the difference between those two MIB-object a long time ago, and you pointed out that a different object was needed for Europe because of the difference in total time and needed granularity. If the total duration difference needs to be supported, it needs to be supported without the need for the E-package. As it is important that basic calls can be supported without an MTA that support the E-package, and you clarified that for Europe a longer cadence is needed. Based on that it seems the normal way to go to have the two extra MIB-objects. By that a CMS can support both European and US market without any changes on the CMS ! Please note that for now the E-package is still optional, as far as I know no CMS supports it ! A solution would be to have the definition adjusted for the MIB so it supports both US and European requirements: the duration of the cadence can be adjusted by having leading zeroes. The total number of bits needs to be increased to support a longer maximum length, and more granularity (50 ms). This would mean that the pktcSigDevRgCadence and RsCadence and r0 to r7 take the definition of the for now European-only cadence. This allow the needed flexibility while having only one mib-object to specify the cadences. This can be done by adjusting the textual convention (PktcRingCadence) This would mean that an MTA can have exactly the same mapping from NCS to MIB for the L-package, independent of the region in which it will be used, and independent from possible E-package support. Thanks, Best regards, Wim -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com] Sent: 27 February 2004 23:46 To: 'Eugene Nechamkin'; Beacham Gordon-CGB005; Wim De Ketelaere; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Exactly. This is precisely what the pktcSigDevRingCadenceTable object is defined to handle (international ring cadences to 13.2s) using the V5.x "cr(x)" mechanism noted in the object description. For example, an international operator could define cr5 for standard ring and cr9 for ring splash, etc for up to 128 international cadences. V5.x defined 128 possible ring cadences for international ring messages without concern for what those cadences are named. The 101 909-4 spec does not name these cadences either and the name should not be a concern for the MIB definitions. Gordon -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Friday, February 27, 2004 2:13 PM To: Beacham Gordon-CGB005; Wim De Ketelaere; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant It's might also be worth noting that the "pktcSigDevRgCadence" and "pktcSigDevRsCadence" on one hand, and "pktcSigDevStandardRingCadence" and "pktcSigDevRingSplashCadence" - on the other have different requirement for the Cadence timing granularity, hence the "pktcSigDevRgCadence" and "pktcSigDevRsCadence" could not have been used to represent Euro-PC Cadence resolution requirement reflected in "pktcSigDevStandardRingCadence" and "pktcSigDevRingSplashCadence". Eugene. -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Beacham Gordon-CGB005 Sent: Friday, February 27, 2004 1:59 PM To: 'Wim De Ketelaere'; Eugene Nechamkin; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Interesting. Thanks for pointing that out. However, I don't follow why the mapping has been made that way in the "Clarification of L Package for Euro-PacketCable Document v6.0 (2004/1/20)." The objects referenced in 2.19 and 2.21 for the L package rg and rs cadences are in the international group with a max cadence of 13.2s. The other distinctive ring cadences in the above document map to core L package objects r0..r7 with a max cadence of 6.0s. The cadence mapping seems to be inconsistent. I would have expected the 2.19 and 2.21 cadence for rg/rs to be mapped to the pktcSigDevRgCadence and pktcSigDevRsCadence core L package objects. International cadences would then be handled via the E package extensions and associated object (pktcSigDevRingCadenceTable). Wim, Can you comment/clarify why the rg/rs cadences are mapped to objects in the international group instead of the pktcSigDevRgCadence and pktcSigDevRsCadence objects? Thanks. Gordon -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Wednesday, February 25, 2004 5:21 PM To: Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence are redundant > The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence > objects are redundant. I am not sure I can completely agree with this statement (if I understand it correctly). Both of these objects are required for Euro-L-package, because of the way the RG and RS signalls are currently defined: For Euro-L-Package: - RG -> pktcSigDevStandardRingCadence - RS -> pktcSigDevRingSplashCadence The "pktcSigDevRingCadenceTable" contains the cadence values for the E-package. Having in mind that E-package is optional, and L-package is mandatory, I am not sure I understand how pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence can be "merged" into the "pktcSigDevRingCadenceTable". Or, are you suggesting that "pktcSigDevRingCadenceTable" should contain the RG and RS cadencies for Euro-L-Package along with the values for E-package? If yes, I think the proper mapping of the table indexes to the corresponding signal should be somehow defined, and corresponding modifications of the Euro-L-Package should also be put in place. Though from the MIB optimization stand point of view the proposed modification might make sense, however, from the currently imlemented and intended funtionality prospective it looks unnecessary (please correct me if my understanding of your proposal deviates from what you had in mind). Eugene Nechamkin, Broadcom Corp., ph: (604) 233-8500 -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Beacham Gordon-CGB005 Sent: Wednesday, February 25, 2004 11:01 AM To: ipcdn@ietf.org Subject: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence are redundant The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence objects are redundant. These objects are recommended to be deleted from the NCS Signaling MIB. The use of separate pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence objects is a carryover from the L line package and they are not needed in the E line package. Instead, normal ring and ring splash cadences can be defined using the pktcSigDevRingCadenceTable object. Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Mar 8 15:55:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00698 for ; Mon, 8 Mar 2004 15:55:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RmC-0002oE-0d for ipcdn-archive@odin.ietf.org; Mon, 08 Mar 2004 15:55:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28Kt32O010798 for ipcdn-archive@odin.ietf.org; Mon, 8 Mar 2004 15:55:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RmB-0002nw-0n; Mon, 08 Mar 2004 15:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Rlf-0002lk-1E for ipcdn@optimus.ietf.org; Mon, 08 Mar 2004 15:54:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00605 for ; Mon, 8 Mar 2004 15:54:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Rld-0005ex-00 for ipcdn@ietf.org; Mon, 08 Mar 2004 15:54:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Rk3-0005Dq-00 for ipcdn@ietf.org; Mon, 08 Mar 2004 15:52:52 -0500 Received: from mms3.broadcom.com ([63.70.210.38]) by ietf-mx with esmtp (Exim 4.12) id 1B0Ri6-0004cU-00 for ipcdn@ietf.org; Mon, 08 Mar 2004 15:50:51 -0500 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Mon, 08 Mar 2004 12:50:39 -0800 X-Server-Uuid: 8D569F9F-42CF-4602-970D-AACC4BD5D310 Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id MAA15144; Mon, 8 Mar 2004 12:50:01 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0741.brcm.ad.broadcom.com with Microsoft SMTPSVC(5.0.2195.5329) ; Mon, 8 Mar 2004 12:50:34 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Mon, 8 Mar 2004 12:50:33 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0BE2CE9F@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Thread-Index: AcQE2O9UKDN+mezJQeKDl6r2XVCySwAbSU1A From: "Eugene Nechamkin" To: "Wim De Ketelaere" , "Beacham Gordon-CGB005" , ipcdn@ietf.org X-OriginalArrivalTime: 08 Mar 2004 20:50:34.0068 (UTC) FILETIME=[00696940:01C4054F] X-WSS-ID: 6C5203151NC4295743-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_3 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Broadcom would agree with this approach provided that (just to spell it = out explicitely): - the "PktcRingCadence" TC will be modified as per proposal, - the "pktcSigDevRtCadence" MIB object (in addition to already = mentioned) will also be affected by the new "PktcRingCadence" SYNTAX. We would also think that the following clarification in TC description = would be helpful: "The first bit of the fourth octet is the first bit of the ring cadence. = All bits are counted in the network order, such that the octet with only = 1st bit set will look like '10000000' bit sequence." And another suggestion which might be helpfull on the implemenaition = side: move the following sentence from the pktcSigDevRingCadenceTable = decsription to the new TC description: "There will be at most 3 on/off = transitions per cadence period." Eugene Nechamkin, Broadcom Corp, (604) 233-8500 -----Original Message----- From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com] Sent: Sunday, March 07, 2004 10:45 PM To: 'Beacham Gordon-CGB005'; Eugene Nechamkin; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Hi Gordon, Yes, the more I look at it, the more I like it, it makes everything much easier, more uniform and cleaner I think ! Thanks, Best regards, Wim -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com]=20 Sent: 06 March 2004 01:02 To: 'Wim De Ketelaere'; Beacham Gordon-CGB005; 'Eugene Nechamkin'; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Wim, Thank you for your comments. If I understand proposed solution correctly, I believe you are suggesting a change could be made to the TC as follows: PktcRingCadence ::=3D TEXTUAL-CONVENTION=20 STATUS current=20 DESCRIPTION This object represents a ring cadence and repeatable characteristics. The first two octets of the bit string represent the length in bits of=20 the duration of the cadence. The third octet is used to=20 represent repeatable characteristics. 00000000 means=20 repeatable, and 10000000 means non repeatable. Each Bit=20 after the third octet represents 50 ms and 1 represents=20 ring and 0 represents silent. The first bit of the fourth=20 octet is the first bit of the ring cadence. A total of 264=20 Bits can be set to represent 13200 ms of total cadence=20 cycle. SYNTAX OCTET STRING (SIZE(4..36)) The following object descriptions would change (i.e., remove the duration and repeatable characteristics sentences) and the DEFVAL would be removed: pktcSigDevRgCadence pktcSigDevRsCadence pktcSigDevR0Cadence pktcSigDevR1Cadence pktcSigDevR2Cadence pktcSigDevR3Cadence pktcSigDevR4Cadence pktcSigDevR5Cadence pktcSigDevR6Cadence pktcSigDevR7Cadence The following object SYNTAX would change to use the PktcRingCadence TC: pktcSigDevRingCadence The following objects could then be deleted: pktcSigDevStandardRingCadence -> would now be covered by pktcSigDevRgCadence (L package) pktcSigDevRingSplashCadence -> would now be covered by pktcSigDevRsCadence (L package) You could then update your "Clarification of L Package for Euro-PacketCable Document v6.0 (2004/1/20)" to reflect these changes, if there is agreement. Gordon -----Original Message----- From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com] Sent: Monday, March 01, 2004 12:07 AM To: 'Beacham Gordon-CGB005'; 'Eugene Nechamkin'; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Hi Gordon, I asked you the difference between those two MIB-object a long time ago, and you pointed out that a different object was needed for Europe because of the difference in total time and needed granularity. If the total duration difference needs to be supported, it needs to be supported without the need=20 for the E-package.=20 As it is important that basic calls can be supported without an MTA that support the E-package,=20 and you clarified that for Europe a longer cadence is needed. Based on that it seems the normal way to go to have the two extra MIB-objects. By that a CMS can support both European and US market without any changes on the CMS ! Please note that for now the E-package is still optional, as far as I know no CMS supports it ! A solution would be to have the definition adjusted for the MIB so it supports both US and European requirements: the duration of the cadence can be adjusted by having leading zeroes. The total number of bits needs to be increased to support a longer maximum length, and more granularity (50 ms). This would mean that the pktcSigDevRgCadence and RsCadence and r0 to r7 take the definition of the=20 for now European-only cadence. This allow the needed flexibility while having only one mib-object to specify the cadences. This can be done by adjusting the textual convention (PktcRingCadence) This would mean that an MTA can have exactly the same mapping from NCS to MIB for the L-package, independent of the region in which it will be used, and independent from possible E-package support. Thanks, Best regards, Wim -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com]=20 Sent: 27 February 2004 23:46 To: 'Eugene Nechamkin'; Beacham Gordon-CGB005; Wim De Ketelaere; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Exactly. This is precisely what the pktcSigDevRingCadenceTable object is defined to handle (international ring cadences to 13.2s) using the V5.x "cr(x)" mechanism noted in the object description. For example, an international operator could define cr5 for standard ring and cr9 for ring splash, etc for up to 128 international cadences. V5.x defined 128 possible ring cadences for international ring messages without concern for what those cadences are named. The 101 909-4 spec does not name these cadences either and the name should not be a concern for the MIB definitions. Gordon -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Friday, February 27, 2004 2:13 PM To: Beacham Gordon-CGB005; Wim De Ketelaere; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant It's might also be worth noting that the "pktcSigDevRgCadence" and "pktcSigDevRsCadence" on one hand, and "pktcSigDevStandardRingCadence" and "pktcSigDevRingSplashCadence" - on the other have different requirement for the Cadence timing granularity, hence the "pktcSigDevRgCadence" and "pktcSigDevRsCadence" could not have been used to represent Euro-PC Cadence resolution requirement reflected in "pktcSigDevStandardRingCadence" and "pktcSigDevRingSplashCadence". Eugene. -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Beacham Gordon-CGB005 Sent: Friday, February 27, 2004 1:59 PM To: 'Wim De Ketelaere'; Eugene Nechamkin; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Interesting. Thanks for pointing that out. However, I don't follow why the mapping has been made that way in the "Clarification of L Package for Euro-PacketCable Document v6.0 (2004/1/20)." The objects referenced in 2.19 and 2.21 for the L package rg and rs cadences are in the international group with a max cadence of 13.2s. The other distinctive ring cadences in the above document map to core L package objects r0..r7 with a max cadence of 6.0s. The cadence mapping seems to be inconsistent. I would have expected the 2.19 and 2.21 cadence for rg/rs to be mapped to the pktcSigDevRgCadence and pktcSigDevRsCadence core L package objects. International cadences would then be handled via the E package extensions and associated object (pktcSigDevRingCadenceTable). Wim, Can you comment/clarify why the rg/rs cadences are mapped to objects in the international group instead of the pktcSigDevRgCadence and pktcSigDevRsCadence objects? Thanks. Gordon -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Wednesday, February 25, 2004 5:21 PM To: Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence are redundant > The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence=20 > objects are redundant. I am not sure I can completely agree with this statement (if I understand it correctly). Both of these objects are required for Euro-L-package, because of the way the RG and RS signalls are currently defined: For Euro-L-Package:=20 - RG -> pktcSigDevStandardRingCadence - RS -> pktcSigDevRingSplashCadence The "pktcSigDevRingCadenceTable" contains the cadence values for the E-package. Having in mind that E-package is optional, and L-package is mandatory, I am not sure I understand how pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence can be "merged" into the "pktcSigDevRingCadenceTable". Or, are you suggesting that "pktcSigDevRingCadenceTable" should contain the RG and RS cadencies for Euro-L-Package along with the values for E-package? If yes, I think the proper mapping of the table indexes to the corresponding signal should be somehow defined, and corresponding modifications of the Euro-L-Package should also be put in place.=20 Though from the MIB optimization stand point of view the proposed modification might make sense, however, from the currently imlemented and intended funtionality prospective it looks unnecessary (please correct me if my understanding of your proposal deviates from what you had in mind). Eugene Nechamkin, Broadcom Corp., ph: (604) 233-8500 -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Beacham Gordon-CGB005 Sent: Wednesday, February 25, 2004 11:01 AM To: ipcdn@ietf.org Subject: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence are redundant The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence objects are redundant. These objects are recommended to be deleted from the NCS Signaling MIB. The use of separate pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence objects is a carryover from the L line package and they are not needed in the E line package. Instead, normal ring and ring splash cadences can be defined using the pktcSigDevRingCadenceTable object. Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Mar 8 17:30:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07599 for ; Mon, 8 Mar 2004 17:30:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TGK-00011Y-Lk for ipcdn-archive@odin.ietf.org; Mon, 08 Mar 2004 17:30:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MUGT0003935 for ipcdn-archive@odin.ietf.org; Mon, 8 Mar 2004 17:30:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TG5-00010F-QL; Mon, 08 Mar 2004 17:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFB-0000sm-DH for ipcdn@optimus.ietf.org; Mon, 08 Mar 2004 17:29:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07326 for ; Mon, 8 Mar 2004 17:29:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TF9-0000nX-00 for ipcdn@ietf.org; Mon, 08 Mar 2004 17:29:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEJ-0000bD-00 for ipcdn@ietf.org; Mon, 08 Mar 2004 17:28:12 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDD-0000PV-00 for ipcdn@ietf.org; Mon, 08 Mar 2004 17:27:03 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i28MR1AO008876 for ; Mon, 8 Mar 2004 15:27:01 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i28MQwrE026336 for ; Mon, 8 Mar 2004 16:26:58 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Mon, 8 Mar 2004 14:26:57 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'Eugene Nechamkin'" , Wim De Ketelaere , Beacham Gordon-CGB005 , ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Date: Mon, 8 Mar 2004 14:26:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_3 autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , > - the "pktcSigDevRtCadence" MIB object (in addition to already mentioned) will also be affected by the new "PktcRingCadence" SYNTAX. I don't follow this comment. The pktcSigDevRtCadence object does not exist in draft 3 of the NCS MIB. There were no objections raised at last call and pktcSigDevRtCadence was deleted as requested. See the IPCDN archives for 1/23/2004 item 2 for the reasoning. Gordon -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Monday, March 08, 2004 12:51 PM To: Wim De Ketelaere; Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Broadcom would agree with this approach provided that (just to spell it out explicitely): - the "PktcRingCadence" TC will be modified as per proposal, - the "pktcSigDevRtCadence" MIB object (in addition to already mentioned) will also be affected by the new "PktcRingCadence" SYNTAX. We would also think that the following clarification in TC description would be helpful: "The first bit of the fourth octet is the first bit of the ring cadence. All bits are counted in the network order, such that the octet with only 1st bit set will look like '10000000' bit sequence." And another suggestion which might be helpfull on the implemenaition side: move the following sentence from the pktcSigDevRingCadenceTable decsription to the new TC description: "There will be at most 3 on/off transitions per cadence period." Eugene Nechamkin, Broadcom Corp, (604) 233-8500 -----Original Message----- From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com] Sent: Sunday, March 07, 2004 10:45 PM To: 'Beacham Gordon-CGB005'; Eugene Nechamkin; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Hi Gordon, Yes, the more I look at it, the more I like it, it makes everything much easier, more uniform and cleaner I think ! Thanks, Best regards, Wim -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com] Sent: 06 March 2004 01:02 To: 'Wim De Ketelaere'; Beacham Gordon-CGB005; 'Eugene Nechamkin'; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Wim, Thank you for your comments. If I understand proposed solution correctly, I believe you are suggesting a change could be made to the TC as follows: PktcRingCadence ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION This object represents a ring cadence and repeatable characteristics. The first two octets of the bit string represent the length in bits of the duration of the cadence. The third octet is used to represent repeatable characteristics. 00000000 means repeatable, and 10000000 means non repeatable. Each Bit after the third octet represents 50 ms and 1 represents ring and 0 represents silent. The first bit of the fourth octet is the first bit of the ring cadence. A total of 264 Bits can be set to represent 13200 ms of total cadence cycle. SYNTAX OCTET STRING (SIZE(4..36)) The following object descriptions would change (i.e., remove the duration and repeatable characteristics sentences) and the DEFVAL would be removed: pktcSigDevRgCadence pktcSigDevRsCadence pktcSigDevR0Cadence pktcSigDevR1Cadence pktcSigDevR2Cadence pktcSigDevR3Cadence pktcSigDevR4Cadence pktcSigDevR5Cadence pktcSigDevR6Cadence pktcSigDevR7Cadence The following object SYNTAX would change to use the PktcRingCadence TC: pktcSigDevRingCadence The following objects could then be deleted: pktcSigDevStandardRingCadence -> would now be covered by pktcSigDevRgCadence (L package) pktcSigDevRingSplashCadence -> would now be covered by pktcSigDevRsCadence (L package) You could then update your "Clarification of L Package for Euro-PacketCable Document v6.0 (2004/1/20)" to reflect these changes, if there is agreement. Gordon -----Original Message----- From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com] Sent: Monday, March 01, 2004 12:07 AM To: 'Beacham Gordon-CGB005'; 'Eugene Nechamkin'; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Hi Gordon, I asked you the difference between those two MIB-object a long time ago, and you pointed out that a different object was needed for Europe because of the difference in total time and needed granularity. If the total duration difference needs to be supported, it needs to be supported without the need for the E-package. As it is important that basic calls can be supported without an MTA that support the E-package, and you clarified that for Europe a longer cadence is needed. Based on that it seems the normal way to go to have the two extra MIB-objects. By that a CMS can support both European and US market without any changes on the CMS ! Please note that for now the E-package is still optional, as far as I know no CMS supports it ! A solution would be to have the definition adjusted for the MIB so it supports both US and European requirements: the duration of the cadence can be adjusted by having leading zeroes. The total number of bits needs to be increased to support a longer maximum length, and more granularity (50 ms). This would mean that the pktcSigDevRgCadence and RsCadence and r0 to r7 take the definition of the for now European-only cadence. This allow the needed flexibility while having only one mib-object to specify the cadences. This can be done by adjusting the textual convention (PktcRingCadence) This would mean that an MTA can have exactly the same mapping from NCS to MIB for the L-package, independent of the region in which it will be used, and independent from possible E-package support. Thanks, Best regards, Wim -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com] Sent: 27 February 2004 23:46 To: 'Eugene Nechamkin'; Beacham Gordon-CGB005; Wim De Ketelaere; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Exactly. This is precisely what the pktcSigDevRingCadenceTable object is defined to handle (international ring cadences to 13.2s) using the V5.x "cr(x)" mechanism noted in the object description. For example, an international operator could define cr5 for standard ring and cr9 for ring splash, etc for up to 128 international cadences. V5.x defined 128 possible ring cadences for international ring messages without concern for what those cadences are named. The 101 909-4 spec does not name these cadences either and the name should not be a concern for the MIB definitions. Gordon -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Friday, February 27, 2004 2:13 PM To: Beacham Gordon-CGB005; Wim De Ketelaere; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant It's might also be worth noting that the "pktcSigDevRgCadence" and "pktcSigDevRsCadence" on one hand, and "pktcSigDevStandardRingCadence" and "pktcSigDevRingSplashCadence" - on the other have different requirement for the Cadence timing granularity, hence the "pktcSigDevRgCadence" and "pktcSigDevRsCadence" could not have been used to represent Euro-PC Cadence resolution requirement reflected in "pktcSigDevStandardRingCadence" and "pktcSigDevRingSplashCadence". Eugene. -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Beacham Gordon-CGB005 Sent: Friday, February 27, 2004 1:59 PM To: 'Wim De Ketelaere'; Eugene Nechamkin; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Interesting. Thanks for pointing that out. However, I don't follow why the mapping has been made that way in the "Clarification of L Package for Euro-PacketCable Document v6.0 (2004/1/20)." The objects referenced in 2.19 and 2.21 for the L package rg and rs cadences are in the international group with a max cadence of 13.2s. The other distinctive ring cadences in the above document map to core L package objects r0..r7 with a max cadence of 6.0s. The cadence mapping seems to be inconsistent. I would have expected the 2.19 and 2.21 cadence for rg/rs to be mapped to the pktcSigDevRgCadence and pktcSigDevRsCadence core L package objects. International cadences would then be handled via the E package extensions and associated object (pktcSigDevRingCadenceTable). Wim, Can you comment/clarify why the rg/rs cadences are mapped to objects in the international group instead of the pktcSigDevRgCadence and pktcSigDevRsCadence objects? Thanks. Gordon -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Wednesday, February 25, 2004 5:21 PM To: Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence are redundant > The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence > objects are redundant. I am not sure I can completely agree with this statement (if I understand it correctly). Both of these objects are required for Euro-L-package, because of the way the RG and RS signalls are currently defined: For Euro-L-Package: - RG -> pktcSigDevStandardRingCadence - RS -> pktcSigDevRingSplashCadence The "pktcSigDevRingCadenceTable" contains the cadence values for the E-package. Having in mind that E-package is optional, and L-package is mandatory, I am not sure I understand how pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence can be "merged" into the "pktcSigDevRingCadenceTable". Or, are you suggesting that "pktcSigDevRingCadenceTable" should contain the RG and RS cadencies for Euro-L-Package along with the values for E-package? If yes, I think the proper mapping of the table indexes to the corresponding signal should be somehow defined, and corresponding modifications of the Euro-L-Package should also be put in place. Though from the MIB optimization stand point of view the proposed modification might make sense, however, from the currently imlemented and intended funtionality prospective it looks unnecessary (please correct me if my understanding of your proposal deviates from what you had in mind). Eugene Nechamkin, Broadcom Corp., ph: (604) 233-8500 -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Beacham Gordon-CGB005 Sent: Wednesday, February 25, 2004 11:01 AM To: ipcdn@ietf.org Subject: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence are redundant The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence objects are redundant. These objects are recommended to be deleted from the NCS Signaling MIB. The use of separate pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence objects is a carryover from the L line package and they are not needed in the E line package. Instead, normal ring and ring splash cadences can be defined using the pktcSigDevRingCadenceTable object. Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Mar 8 17:43:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07958 for ; Mon, 8 Mar 2004 17:43:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TSh-00026w-Ia for ipcdn-archive@odin.ietf.org; Mon, 08 Mar 2004 17:43:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28Mh31N008091 for ipcdn-archive@odin.ietf.org; Mon, 8 Mar 2004 17:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TSg-00026I-TQ; Mon, 08 Mar 2004 17:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TSb-00025Z-Qg for ipcdn@optimus.ietf.org; Mon, 08 Mar 2004 17:42:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07950 for ; Mon, 8 Mar 2004 17:42:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TSZ-0002kV-00 for ipcdn@ietf.org; Mon, 08 Mar 2004 17:42:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TRc-0002c7-00 for ipcdn@ietf.org; Mon, 08 Mar 2004 17:41:57 -0500 Received: from mms3.broadcom.com ([63.70.210.38]) by ietf-mx with esmtp (Exim 4.12) id 1B0TR5-0002U0-00 for ipcdn@ietf.org; Mon, 08 Mar 2004 17:41:24 -0500 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Mon, 08 Mar 2004 14:40:59 -0800 X-Server-Uuid: 8D569F9F-42CF-4602-970D-AACC4BD5D310 Received: from nt-irva-0740.brcm.ad.broadcom.com ( nt-irva-0740.brcm.ad.broadcom.com [10.8.194.53]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA06748; Mon, 8 Mar 2004 14:40:18 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(5.0.2195.5329) ; Mon, 8 Mar 2004 14:40:51 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Mon, 8 Mar 2004 14:40:52 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0BE2CEA1@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Thread-Index: AcQFXPONL5p8a+ONTRSNFc7dRR7EcAAAP4wg From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" , "Wim De Ketelaere" , ipcdn@ietf.org X-OriginalArrivalTime: 08 Mar 2004 22:40:51.0496 (UTC) FILETIME=[68B4CA80:01C4055E] X-WSS-ID: 6C5229F11NC4315539-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_3 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > The pktcSigDevRtCadence object does not exist in=20 > draft 3 of the NCS MIB. There were no objections=20 > raised at last call and pktcSigDevRtCadence was=20 > deleted as requested.=20 Your comment is correct (wrong draft copy used): thanks for pointing = this out. All the rest in our comments still holds true. Eugene. -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com] Sent: Monday, March 08, 2004 2:27 PM To: Eugene Nechamkin; Wim De Ketelaere; Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant > - the "pktcSigDevRtCadence" MIB object (in addition to already = mentioned) will also be affected by the new "PktcRingCadence" SYNTAX. I don't follow this comment. The pktcSigDevRtCadence object does not = exist in draft 3 of the NCS MIB. There were no objections raised at last = call and pktcSigDevRtCadence was deleted as requested. See the IPCDN = archives for 1/23/2004 item 2 for the reasoning. Gordon=20 -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Monday, March 08, 2004 12:51 PM To: Wim De Ketelaere; Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Broadcom would agree with this approach provided that (just to spell it = out explicitely): - the "PktcRingCadence" TC will be modified as per proposal, - the "pktcSigDevRtCadence" MIB object (in addition to already = mentioned) will also be affected by the new "PktcRingCadence" SYNTAX. We would also think that the following clarification in TC description = would be helpful: "The first bit of the fourth octet is the first bit of the ring cadence. = All bits are counted in the network order, such that the octet with only = 1st bit set will look like '10000000' bit sequence." And another suggestion which might be helpfull on the implemenaition = side: move the following sentence from the pktcSigDevRingCadenceTable = decsription to the new TC description: "There will be at most 3 on/off = transitions per cadence period." Eugene Nechamkin, Broadcom Corp, (604) 233-8500 -----Original Message----- From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com] Sent: Sunday, March 07, 2004 10:45 PM To: 'Beacham Gordon-CGB005'; Eugene Nechamkin; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Hi Gordon, Yes, the more I look at it, the more I like it, it makes everything much easier, more uniform and cleaner I think ! Thanks, Best regards, Wim -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com]=20 Sent: 06 March 2004 01:02 To: 'Wim De Ketelaere'; Beacham Gordon-CGB005; 'Eugene Nechamkin'; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Wim, Thank you for your comments. If I understand proposed solution correctly, I believe you are suggesting a change could be made to the TC as follows: PktcRingCadence ::=3D TEXTUAL-CONVENTION=20 STATUS current=20 DESCRIPTION This object represents a ring cadence and repeatable characteristics. The first two octets of the bit string represent the length in bits of=20 the duration of the cadence. The third octet is used to=20 represent repeatable characteristics. 00000000 means=20 repeatable, and 10000000 means non repeatable. Each Bit=20 after the third octet represents 50 ms and 1 represents=20 ring and 0 represents silent. The first bit of the fourth=20 octet is the first bit of the ring cadence. A total of 264=20 Bits can be set to represent 13200 ms of total cadence=20 cycle. SYNTAX OCTET STRING (SIZE(4..36)) The following object descriptions would change (i.e., remove the duration and repeatable characteristics sentences) and the DEFVAL would be removed: pktcSigDevRgCadence pktcSigDevRsCadence pktcSigDevR0Cadence pktcSigDevR1Cadence pktcSigDevR2Cadence pktcSigDevR3Cadence pktcSigDevR4Cadence pktcSigDevR5Cadence pktcSigDevR6Cadence pktcSigDevR7Cadence The following object SYNTAX would change to use the PktcRingCadence TC: pktcSigDevRingCadence The following objects could then be deleted: pktcSigDevStandardRingCadence -> would now be covered by pktcSigDevRgCadence (L package) pktcSigDevRingSplashCadence -> would now be covered by pktcSigDevRsCadence (L package) You could then update your "Clarification of L Package for Euro-PacketCable Document v6.0 (2004/1/20)" to reflect these changes, if there is agreement. Gordon -----Original Message----- From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com] Sent: Monday, March 01, 2004 12:07 AM To: 'Beacham Gordon-CGB005'; 'Eugene Nechamkin'; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Hi Gordon, I asked you the difference between those two MIB-object a long time ago, and you pointed out that a different object was needed for Europe because of the difference in total time and needed granularity. If the total duration difference needs to be supported, it needs to be supported without the need=20 for the E-package.=20 As it is important that basic calls can be supported without an MTA that support the E-package,=20 and you clarified that for Europe a longer cadence is needed. Based on that it seems the normal way to go to have the two extra MIB-objects. By that a CMS can support both European and US market without any changes on the CMS ! Please note that for now the E-package is still optional, as far as I know no CMS supports it ! A solution would be to have the definition adjusted for the MIB so it supports both US and European requirements: the duration of the cadence can be adjusted by having leading zeroes. The total number of bits needs to be increased to support a longer maximum length, and more granularity (50 ms). This would mean that the pktcSigDevRgCadence and RsCadence and r0 to r7 take the definition of the=20 for now European-only cadence. This allow the needed flexibility while having only one mib-object to specify the cadences. This can be done by adjusting the textual convention (PktcRingCadence) This would mean that an MTA can have exactly the same mapping from NCS to MIB for the L-package, independent of the region in which it will be used, and independent from possible E-package support. Thanks, Best regards, Wim -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com]=20 Sent: 27 February 2004 23:46 To: 'Eugene Nechamkin'; Beacham Gordon-CGB005; Wim De Ketelaere; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Exactly. This is precisely what the pktcSigDevRingCadenceTable object is defined to handle (international ring cadences to 13.2s) using the V5.x "cr(x)" mechanism noted in the object description. For example, an international operator could define cr5 for standard ring and cr9 for ring splash, etc for up to 128 international cadences. V5.x defined 128 possible ring cadences for international ring messages without concern for what those cadences are named. The 101 909-4 spec does not name these cadences either and the name should not be a concern for the MIB definitions. Gordon -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Friday, February 27, 2004 2:13 PM To: Beacham Gordon-CGB005; Wim De Ketelaere; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant It's might also be worth noting that the "pktcSigDevRgCadence" and "pktcSigDevRsCadence" on one hand, and "pktcSigDevStandardRingCadence" and "pktcSigDevRingSplashCadence" - on the other have different requirement for the Cadence timing granularity, hence the "pktcSigDevRgCadence" and "pktcSigDevRsCadence" could not have been used to represent Euro-PC Cadence resolution requirement reflected in "pktcSigDevStandardRingCadence" and "pktcSigDevRingSplashCadence". Eugene. -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Beacham Gordon-CGB005 Sent: Friday, February 27, 2004 1:59 PM To: 'Wim De Ketelaere'; Eugene Nechamkin; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Interesting. Thanks for pointing that out. However, I don't follow why the mapping has been made that way in the "Clarification of L Package for Euro-PacketCable Document v6.0 (2004/1/20)." The objects referenced in 2.19 and 2.21 for the L package rg and rs cadences are in the international group with a max cadence of 13.2s. The other distinctive ring cadences in the above document map to core L package objects r0..r7 with a max cadence of 6.0s. The cadence mapping seems to be inconsistent. I would have expected the 2.19 and 2.21 cadence for rg/rs to be mapped to the pktcSigDevRgCadence and pktcSigDevRsCadence core L package objects. International cadences would then be handled via the E package extensions and associated object (pktcSigDevRingCadenceTable). Wim, Can you comment/clarify why the rg/rs cadences are mapped to objects in the international group instead of the pktcSigDevRgCadence and pktcSigDevRsCadence objects? Thanks. Gordon -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Wednesday, February 25, 2004 5:21 PM To: Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence are redundant > The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence=20 > objects are redundant. I am not sure I can completely agree with this statement (if I understand it correctly). Both of these objects are required for Euro-L-package, because of the way the RG and RS signalls are currently defined: For Euro-L-Package:=20 - RG -> pktcSigDevStandardRingCadence - RS -> pktcSigDevRingSplashCadence The "pktcSigDevRingCadenceTable" contains the cadence values for the E-package. Having in mind that E-package is optional, and L-package is mandatory, I am not sure I understand how pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence can be "merged" into the "pktcSigDevRingCadenceTable". Or, are you suggesting that "pktcSigDevRingCadenceTable" should contain the RG and RS cadencies for Euro-L-Package along with the values for E-package? If yes, I think the proper mapping of the table indexes to the corresponding signal should be somehow defined, and corresponding modifications of the Euro-L-Package should also be put in place.=20 Though from the MIB optimization stand point of view the proposed modification might make sense, however, from the currently imlemented and intended funtionality prospective it looks unnecessary (please correct me if my understanding of your proposal deviates from what you had in mind). Eugene Nechamkin, Broadcom Corp., ph: (604) 233-8500 -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Beacham Gordon-CGB005 Sent: Wednesday, February 25, 2004 11:01 AM To: ipcdn@ietf.org Subject: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence are redundant The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence objects are redundant. These objects are recommended to be deleted from the NCS Signaling MIB. The use of separate pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence objects is a carryover from the L line package and they are not needed in the E line package. Instead, normal ring and ring splash cadences can be defined using the pktcSigDevRingCadenceTable object. Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Mar 9 15:58:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23559 for ; Tue, 9 Mar 2004 15:58:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0oIe-0003Ie-34 for ipcdn-archive@odin.ietf.org; Tue, 09 Mar 2004 15:58:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29Kw46I012683 for ipcdn-archive@odin.ietf.org; Tue, 9 Mar 2004 15:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0oIb-0003HB-8Q; Tue, 09 Mar 2004 15:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0oI6-0003FH-Jt for ipcdn@optimus.ietf.org; Tue, 09 Mar 2004 15:57:30 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23246; Tue, 9 Mar 2004 15:57:28 -0500 (EST) Message-Id: <200403092057.PAA23246@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 09 Mar 2004 15:57:27 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-signaling-03.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Network-Based Call Signaling (NCS) Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs) Author(s) : G. Beacham, S. Kumar, S. Channabasappa Filename : draft-ietf-ipcdn-pktc-signaling-03.txt Pages : 60 Date : 2004-3-9 This memo defines the Signaling Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it provides a common data and format representation for PacketCable/IPCablecom compliant Multimedia Terminal Adapter devices. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2 [5][6][7]. The set of objects are consistent with the SNMP framework and existing SNMP standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-pktc-signaling-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-pktc-signaling-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-9161724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-signaling-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-signaling-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-9161724.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Mar 23 12:14:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12848 for ; Tue, 23 Mar 2004 12:14:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5pTr-0003a5-Sd for ipcdn-archive@odin.ietf.org; Tue, 23 Mar 2004 12:14:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NHENQ4013724 for ipcdn-archive@odin.ietf.org; Tue, 23 Mar 2004 12:14:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5pTY-0003VI-7y; Tue, 23 Mar 2004 12:14:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5pPx-00035k-9z for ipcdn@optimus.ietf.org; Tue, 23 Mar 2004 12:10:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12584 for ; Tue, 23 Mar 2004 12:10:17 -0500 (EST) From: jf.mule@cablelabs.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5pPu-0002EW-00 for ipcdn@ietf.org; Tue, 23 Mar 2004 12:10:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5pOv-00026V-00 for ipcdn@ietf.org; Tue, 23 Mar 2004 12:09:17 -0500 Received: from adsl-63-207-15-68.dsl.snfc21.pacbell.net ([63.207.15.68] helo=shade) by ietf-mx with smtp (Exim 4.12) id 1B5pMv-0001jW-00 for ipcdn@ietf.org; Tue, 23 Mar 2004 12:07:14 -0500 Date: Tue, 23 Mar 2004 09:07:53 -0800 To: ipcdn@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------gpwritqgxrqlucpjsvns" Subject: [ipcdn] Hey, dude, it's me ^_^ :P Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , ----------gpwritqgxrqlucpjsvns Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_FUNBAG.GEN in file TextFile.zip The uncleanable file is deleted. --------------------------------------------------------- ----------gpwritqgxrqlucpjsvns Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't bite, weah! pass: 27332 ----------gpwritqgxrqlucpjsvns Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) TextFile.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------gpwritqgxrqlucpjsvns-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Mar 30 11:38:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27657 for ; Tue, 30 Mar 2004 11:38:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8MFi-00009T-3F for ipcdn-archive@odin.ietf.org; Tue, 30 Mar 2004 11:38:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UGcEG8000558 for ipcdn-archive@odin.ietf.org; Tue, 30 Mar 2004 11:38:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8MFU-0008W0-UU; Tue, 30 Mar 2004 11:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8MFG-0008TB-VL for ipcdn@optimus.ietf.org; Tue, 30 Mar 2004 11:37:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27594 for ; Tue, 30 Mar 2004 11:37:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8MFF-0006Ke-00 for ipcdn@ietf.org; Tue, 30 Mar 2004 11:37:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8MEM-00067a-00 for ipcdn@ietf.org; Tue, 30 Mar 2004 11:36:50 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B8MDC-0005uJ-00 for ipcdn@ietf.org; Tue, 30 Mar 2004 11:35:38 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2UGZhrC004441 for ; Tue, 30 Mar 2004 09:35:44 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i2UGZXNa013095 for ; Tue, 30 Mar 2004 10:35:34 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Tue, 30 Mar 2004 08:35:33 -0800 Message-ID: From: Beacham Gordon-CGB005 To: ipcdn@ietf.org Date: Tue, 30 Mar 2004 08:35:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [ipcdn] Editorial Changes - NCS MIB Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , The following editorial changes have been suggested for the NCS MIB: 1. Remove the pktcSigEndPntConfigObjects defintion. All endpoint configuration objects are located under pktcNcsEndPntConfigObjects, while pktcSigEndPntConfigObjects has no objects. 2. Reorder the R0, R6 and R7 objects so that R0, R1, R2, R3, R4, R5, R6, R7, Rg and Rs form a sequential series. 3. Change pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 0 } to: pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 2 } Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Mar 30 13:38:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04355 for ; Tue, 30 Mar 2004 13:38:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8O7d-0001OA-Ha for ipcdn-archive@odin.ietf.org; Tue, 30 Mar 2004 13:38:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UIc16L005330 for ipcdn-archive@odin.ietf.org; Tue, 30 Mar 2004 13:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8O7c-0001NZ-Ot; Tue, 30 Mar 2004 13:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8O78-0001A9-HD for ipcdn@optimus.ietf.org; Tue, 30 Mar 2004 13:37:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04326 for ; Tue, 30 Mar 2004 13:37:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8O76-0003wZ-00 for ipcdn@ietf.org; Tue, 30 Mar 2004 13:37:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8O6K-0003on-00 for ipcdn@ietf.org; Tue, 30 Mar 2004 13:36:41 -0500 Received: from mms1.broadcom.com ([63.70.210.58]) by ietf-mx with esmtp (Exim 4.12) id 1B8O5Z-0003gb-00 for ipcdn@ietf.org; Tue, 30 Mar 2004 13:35:53 -0500 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Tue, 30 Mar 2004 10:35:51 -0800 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id KAA03459; Tue, 30 Mar 2004 10:35:04 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0741.brcm.ad.broadcom.com with Microsoft SMTPSVC(5.0.2195.5329) ; Tue, 30 Mar 2004 10:35:36 -0800 Content-class: urn:content-classes:message Subject: RE: [ipcdn] Editorial Changes - NCS MIB MIME-Version: 1.0 Date: Tue, 30 Mar 2004 10:35:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <24CDBA67F085904999751B3C4F9E8C0BE2D053@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] Editorial Changes - NCS MIB Thread-Index: AcQWdW0UpOv4z9xaS22l4ywcJMWvJgAD5eAg From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" , ipcdn@ietf.org X-OriginalArrivalTime: 30 Mar 2004 18:35:36.0242 (UTC) FILETIME=[CAD1B920:01C41685] X-WSS-ID: 6C77618D1NO10553023-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable All these seem to be reasonable changes. Any feedback on outstanding issue of "pktcSigDevToneDbLevel" ? Eugene Nechamkin, Broadcom Corp, ph: (604) 233-8500 -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Beacham Gordon-CGB005 Sent: Tuesday, March 30, 2004 8:35 AM To: ipcdn@ietf.org Subject: [ipcdn] Editorial Changes - NCS MIB The following editorial changes have been suggested for the NCS MIB: 1. Remove the pktcSigEndPntConfigObjects defintion. All endpoint = configuration objects are located under pktcNcsEndPntConfigObjects, while pktcSigEndPntConfigObjects has no = objects. 2. Reorder the R0, R6 and R7 objects so that R0, R1, R2, R3, R4, R5, R6, = R7, Rg and Rs form a sequential series. 3. Change pktcSigNotification OBJECT IDENTIFIER ::=3D { pktcSigMib 0 } = to: pktcSigNotification OBJECT IDENTIFIER ::=3D { pktcSigMib 2 } Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ 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 exim@www1.ietf.org Tue Mar 30 15:17:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09208 for ; Tue, 30 Mar 2004 15:17:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8PfS-0003dA-47 for ipcdn-archive@odin.ietf.org; Tue, 30 Mar 2004 15:17:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UKH2TX013931 for ipcdn-archive@odin.ietf.org; Tue, 30 Mar 2004 15:17:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8PfR-0003c5-F9; Tue, 30 Mar 2004 15:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Pf1-0003Ua-7y for ipcdn@optimus.ietf.org; Tue, 30 Mar 2004 15:16:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09046 for ; Tue, 30 Mar 2004 15:16:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8Pez-0003Jd-00 for ipcdn@ietf.org; Tue, 30 Mar 2004 15:16:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Pe2-0003Ck-00 for ipcdn@ietf.org; Tue, 30 Mar 2004 15:15:35 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8Pd5-00032i-00 for ipcdn@ietf.org; Tue, 30 Mar 2004 15:14:35 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2004 12:22:02 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2UKEXKj010519; Tue, 30 Mar 2004 12:14:34 -0800 (PST) Received: from cisco.com (sjc-vpn3-761.cisco.com [10.21.66.249]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ASL49078; Tue, 30 Mar 2004 12:14:33 -0800 (PST) Message-ID: <4069D529.5060706@cisco.com> Date: Tue, 30 Mar 2004 12:14:33 -0800 From: Azlina Ahmad Reply-To: azlina@cisco.com Organization: CIsco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Beacham Gordon-CGB005 CC: ipcdn@ietf.org Subject: Re: [ipcdn] Editorial Changes - NCS MIB References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Beacham Gordon-CGB005 wrote: > The following editorial changes have been suggested for the NCS MIB: > > 1. Remove the pktcSigEndPntConfigObjects defintion. All endpoint configuration objects are located under > pktcNcsEndPntConfigObjects, while pktcSigEndPntConfigObjects has no objects. > > 2. Reorder the R0, R6 and R7 objects so that R0, R1, R2, R3, R4, R5, R6, R7, Rg and Rs form a sequential series. > > 3. Change pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 0 } to: > pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 2 } Recommend keeping the notification as it is per Appendix D of the draft-ietf-ops-mib-review-guidelines-02.txt. Thanks, Azlina > > Gordon Beacham > Digital Core Gateways, BCS > Motorola, Inc. > 858-404-2335 > gordon.beacham@motorola.com > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Mar 30 15:29:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10066 for ; Tue, 30 Mar 2004 15:29:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Pr5-0005eX-NZ for ipcdn-archive@odin.ietf.org; Tue, 30 Mar 2004 15:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UKT3ls021729 for ipcdn-archive@odin.ietf.org; Tue, 30 Mar 2004 15:29:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Pr4-0005eF-5S; Tue, 30 Mar 2004 15:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Pr0-0005dG-4L for ipcdn@optimus.ietf.org; Tue, 30 Mar 2004 15:28:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10045 for ; Tue, 30 Mar 2004 15:28:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8Pqy-0004Hm-00 for ipcdn@ietf.org; Tue, 30 Mar 2004 15:28:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8PqM-0004Cv-00 for ipcdn@ietf.org; Tue, 30 Mar 2004 15:28:19 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx with esmtp (Exim 4.12) id 1B8PpS-00044g-00 for ipcdn@ietf.org; Tue, 30 Mar 2004 15:27:22 -0500 Message-ID: From: "Woundy, Richard" To: "'azlina@cisco.com'" , Beacham Gordon-CGB005 Cc: ipcdn@ietf.org Subject: RE: [ipcdn] Editorial Changes - NCS MIB Date: Tue, 30 Mar 2004 15:20:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , I agree with Azlina about not moving pktcSigNotification. In fact, goes further in section 4.7: 4.7. Notification Definitions RFC 2578 Section 8 specifies the rules for notification definitions. In particular: - Inaccessible objects MUST NOT appear in the OBJECTS clause. - For each object type mentioned in the OBJECTS clause, the DESCRIPTION clause MUST specify which object instance is to be present in the transmitted notification and MUST specify the information/meaning conveyed. - The OBJECT IDENTIFIER (OID) value assigned to each notification type MUST have a next-to-last sub-identifier of zero, so that it is possible to convert an SMIv2 notification definition into an SMIv1 trap definition and back again without information loss (see [RFC2576] Section 2.1.2) and possible for a multilingual proxy chain to translate an SNMPv2 trap into an SNMPv1 trap and back again without information loss (see [RFC2576] Section 3). In addition, the OID assigned to a notification definition MUST NOT also be assigned to another definition that results in OID registration. RFC 2578 Section 3.6 lists the constructs that create OID registrations. ... The key requirement above is that the "OBJECT IDENTIFIER (OID) value assigned to each notification type MUST have a next-to-last sub-identifier of zero". -- Rich -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Azlina Ahmad Sent: Tuesday, March 30, 2004 3:15 PM To: Beacham Gordon-CGB005 Cc: ipcdn@ietf.org Subject: Re: [ipcdn] Editorial Changes - NCS MIB Beacham Gordon-CGB005 wrote: > The following editorial changes have been suggested for the NCS MIB: > > 1. Remove the pktcSigEndPntConfigObjects defintion. All endpoint configuration objects are located under > pktcNcsEndPntConfigObjects, while pktcSigEndPntConfigObjects has no objects. > > 2. Reorder the R0, R6 and R7 objects so that R0, R1, R2, R3, R4, R5, R6, R7, Rg and Rs form a sequential series. > > 3. Change pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 0 } to: > pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 2 } Recommend keeping the notification as it is per Appendix D of the draft-ietf-ops-mib-review-guidelines-02.txt. Thanks, Azlina > > Gordon Beacham > Digital Core Gateways, BCS > Motorola, Inc. > 858-404-2335 > gordon.beacham@motorola.com > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Mar 30 18:30:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01343 for ; Tue, 30 Mar 2004 18:30:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjJ-0006WI-6i for ipcdn-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i218NAW5025973 for ipcdn-archive@odin.ietf.org; Mon, 1 Mar 2004 03:23:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axih1-0006WM-21; Mon, 01 Mar 2004 03:22:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axig0-0006IZ-4G for ipcdn@optimus.ietf.org; Mon, 01 Mar 2004 03:21:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01127 for ; Mon, 1 Mar 2004 03:21:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiUP-0003Rl-00 for ipcdn@ietf.org; Mon, 01 Mar 2004 03:09:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiTQ-0003Mj-00 for ipcdn@ietf.org; Mon, 01 Mar 2004 03:08:25 -0500 Received: from adicia.telenet-ops.be ([195.130.132.56]) by ietf-mx with esmtp (Exim 4.12) id 1AxiSr-0003HR-00 for ipcdn@ietf.org; Mon, 01 Mar 2004 03:07:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by adicia.telenet-ops.be (Postfix) with SMTP id 88B5B1F7232 for ; Mon, 1 Mar 2004 09:07:29 +0100 (MET) Received: from tcomlabs.com (D5E0060A.kabel.telenet.be [213.224.6.10]) by adicia.telenet-ops.be (Postfix) with SMTP id 9D4A81F7270 for ; Mon, 1 Mar 2004 09:07:28 +0100 (MET) Received: (qmail 20088 invoked from network); 1 Mar 2004 08:06:12 -0000 Received: from unknown (HELO tComGateway.tComlabs.com) (127.0.0.1) by tcomlabs.com with SMTP; 1 Mar 2004 08:06:12 -0000 Received: from ([10.5.5.37]) by tComGateway.tComLabs.com (MailMonitor for SMTP v1.2.2 ) ; Mon, 1 Mar 2004 09:06:12 +0100 (CET) From: "Wim De Ketelaere" To: "'Beacham Gordon-CGB005'" , "'Eugene Nechamkin'" , Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Date: Mon, 1 Mar 2004 09:07:28 +0100 Message-ID: <000c01c3ff64$3d722890$2505050a@LAPTOPWIM> 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, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_3 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Gordon, I asked you the difference between those two MIB-object a long time ago, and you pointed out that a different object was needed for Europe because of the difference in total time and needed granularity. If the total duration difference needs to be supported, it needs to be supported without the need for the E-package. As it is important that basic calls can be supported without an MTA that support the E-package, and you clarified that for Europe a longer cadence is needed. Based on that it seems the normal way to go to have the two extra MIB-objects. By that a CMS can support both European and US market without any changes on the CMS ! Please note that for now the E-package is still optional, as far as I know no CMS supports it ! A solution would be to have the definition adjusted for the MIB so it supports both US and European requirements: the duration of the cadence can be adjusted by having leading zeroes. The total number of bits needs to be increased to support a longer maximum length, and more granularity (50 ms). This would mean that the pktcSigDevRgCadence and RsCadence and r0 to r7 take the definition of the for now European-only cadence. This allow the needed flexibility while having only one mib-object to specify the cadences. This can be done by adjusting the textual convention (PktcRingCadence) This would mean that an MTA can have exactly the same mapping from NCS to MIB for the L-package, independent of the region in which it will be used, and independent from possible E-package support. Thanks, Best regards, Wim -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com] Sent: 27 February 2004 23:46 To: 'Eugene Nechamkin'; Beacham Gordon-CGB005; Wim De Ketelaere; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Exactly. This is precisely what the pktcSigDevRingCadenceTable object is defined to handle (international ring cadences to 13.2s) using the V5.x "cr(x)" mechanism noted in the object description. For example, an international operator could define cr5 for standard ring and cr9 for ring splash, etc for up to 128 international cadences. V5.x defined 128 possible ring cadences for international ring messages without concern for what those cadences are named. The 101 909-4 spec does not name these cadences either and the name should not be a concern for the MIB definitions. Gordon -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Friday, February 27, 2004 2:13 PM To: Beacham Gordon-CGB005; Wim De Ketelaere; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant It's might also be worth noting that the "pktcSigDevRgCadence" and "pktcSigDevRsCadence" on one hand, and "pktcSigDevStandardRingCadence" and "pktcSigDevRingSplashCadence" - on the other have different requirement for the Cadence timing granularity, hence the "pktcSigDevRgCadence" and "pktcSigDevRsCadence" could not have been used to represent Euro-PC Cadence resolution requirement reflected in "pktcSigDevStandardRingCadence" and "pktcSigDevRingSplashCadence". Eugene. -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Beacham Gordon-CGB005 Sent: Friday, February 27, 2004 1:59 PM To: 'Wim De Ketelaere'; Eugene Nechamkin; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Interesting. Thanks for pointing that out. However, I don't follow why the mapping has been made that way in the "Clarification of L Package for Euro-PacketCable Document v6.0 (2004/1/20)." The objects referenced in 2.19 and 2.21 for the L package rg and rs cadences are in the international group with a max cadence of 13.2s. The other distinctive ring cadences in the above document map to core L package objects r0..r7 with a max cadence of 6.0s. The cadence mapping seems to be inconsistent. I would have expected the 2.19 and 2.21 cadence for rg/rs to be mapped to the pktcSigDevRgCadence and pktcSigDevRsCadence core L package objects. International cadences would then be handled via the E package extensions and associated object (pktcSigDevRingCadenceTable). Wim, Can you comment/clarify why the rg/rs cadences are mapped to objects in the international group instead of the pktcSigDevRgCadence and pktcSigDevRsCadence objects? Thanks. Gordon -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Wednesday, February 25, 2004 5:21 PM To: Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence are redundant > The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence > objects are redundant. I am not sure I can completely agree with this statement (if I understand it correctly). Both of these objects are required for Euro-L-package, because of the way the RG and RS signalls are currently defined: For Euro-L-Package: - RG -> pktcSigDevStandardRingCadence - RS -> pktcSigDevRingSplashCadence The "pktcSigDevRingCadenceTable" contains the cadence values for the E-package. Having in mind that E-package is optional, and L-package is mandatory, I am not sure I understand how pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence can be "merged" into the "pktcSigDevRingCadenceTable". Or, are you suggesting that "pktcSigDevRingCadenceTable" should contain the RG and RS cadencies for Euro-L-Package along with the values for E-package? If yes, I think the proper mapping of the table indexes to the corresponding signal should be somehow defined, and corresponding modifications of the Euro-L-Package should also be put in place. Though from the MIB optimization stand point of view the proposed modification might make sense, however, from the currently imlemented and intended funtionality prospective it looks unnecessary (please correct me if my understanding of your proposal deviates from what you had in mind). Eugene Nechamkin, Broadcom Corp., ph: (604) 233-8500 -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Beacham Gordon-CGB005 Sent: Wednesday, February 25, 2004 11:01 AM To: ipcdn@ietf.org Subject: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence are redundant The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence objects are redundant. These objects are recommended to be deleted from the NCS Signaling MIB. The use of separate pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence objects is a carryover from the L line package and they are not needed in the E line package. Instead, normal ring and ring splash cadences can be defined using the pktcSigDevRingCadenceTable object. Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Mar 30 18:51:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06575 for ; Tue, 30 Mar 2004 18:51:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riz-0006Yx-3f for ipcdn-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0E6Ap012921 for ipcdn-archive@odin.ietf.org; Tue, 27 Jan 2004 19:14:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldLK-0003MB-9W; Tue, 27 Jan 2004 19:14:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlH0e-0007Jm-Gh for ipcdn@optimus.ietf.org; Mon, 26 Jan 2004 19:23:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26131 for ; Mon, 26 Jan 2004 19:23:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlH0c-0005vB-00 for ipcdn@ietf.org; Mon, 26 Jan 2004 19:23:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlGze-0005sr-00 for ipcdn@ietf.org; Mon, 26 Jan 2004 19:22:15 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AlGyv-0005qZ-00 for ipcdn@ietf.org; Mon, 26 Jan 2004 19:21:29 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i0R0LLvQ026844 for ; Mon, 26 Jan 2004 17:21:21 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i0R0LBfk000874 for ; Mon, 26 Jan 2004 18:21:12 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Mon, 26 Jan 2004 16:21:16 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Subject: RE: re: [ipcdn] Re: IETF IPCDN Signaling MIB - Draft 3 - Last Cal l for Comments Date: Mon, 26 Jan 2004 16:21:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Regarding statement (6): According to the PC Codec spec: 4.4.3 Voice Activity Detection (VAD) A vendor MAY employ VAD to reduce bandwidth consumption. If employed, this capability MUST be optional, allowing disabling. Some codecs have associated VAD implementations (e.g. G.729B), while many others do not (e.g. G.711 and G.728). In the latter cases, the VAD implementation MUST adhere to the IMTC Voice-Over-IP Forum Service Interoperability Implementation Agreement 1.0, dated December 1, 1997 [5]. If you are proposing a PC spec change, please raise the issue on the appropriate PC reflector and via the ECN process as necessary. >(6) pktcSigDevSilenceSuppression: per codec is better >>> snip Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Mar 30 18:51:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06613 for ; Tue, 30 Mar 2004 18:51:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riz-0006a4-1O for ipcdn-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0CSQH009723 for ipcdn-archive@odin.ietf.org; Tue, 27 Jan 2004 19:12:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldJg-0002UZ-D0; Tue, 27 Jan 2004 19:12:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlEmN-0002ju-Ne for ipcdn@optimus.ietf.org; Mon, 26 Jan 2004 17:00:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21489 for ; Mon, 26 Jan 2004 17:00:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlEmL-0006NL-00 for ipcdn@ietf.org; Mon, 26 Jan 2004 17:00:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlElO-0006JE-00 for ipcdn@ietf.org; Mon, 26 Jan 2004 16:59:22 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AlEkw-0006G5-00 for ipcdn@ietf.org; Mon, 26 Jan 2004 16:58:54 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i0QLwr2v022278 for ; Mon, 26 Jan 2004 14:58:53 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i0QLw5Xo032236 for ; Mon, 26 Jan 2004 15:58:48 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Mon, 26 Jan 2004 13:58:04 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Subject: re: [ipcdn] Re: IETF IPCDN Signaling MIB - Draft 3 - Last Call fo r Comments Date: Mon, 26 Jan 2004 13:57:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Regarding statements (3) and (5): Perhaps it would be better to eliminate the regional terms (i.e., North America), and instead use the term L package to refer to the core functionality (as defined by CableLabs/PacketCable) and E package to refer to extensions over and above the core package (defined in support of international requirements). The standards provide guidance on what to signal to use, and it is up to the operator and vendor to define what is required based on local requirements. Remember, in the international market there is a hybrid need. For example, some operators use the L package and require E package extensions. >(3) pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence >>> snip >(5) Mapping NCS signal requests (tones, rings) to MIB objects >>> snip Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Mar 30 18:51:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06653 for ; Tue, 30 Mar 2004 18:51:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riz-0006a4-40 for ipcdn-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S08FmF002457 for ipcdn-archive@odin.ietf.org; Tue, 27 Jan 2004 19:08:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldDC-0008PH-80; Tue, 27 Jan 2004 19:05:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlBv4-0001ID-EH for ipcdn@optimus.ietf.org; Mon, 26 Jan 2004 13:57:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15955 for ; Mon, 26 Jan 2004 13:57:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlBv2-00060c-00 for ipcdn@ietf.org; Mon, 26 Jan 2004 13:57:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlBu8-0005xB-00 for ipcdn@ietf.org; Mon, 26 Jan 2004 13:56:12 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AlBtO-0005uH-00 for ipcdn@ietf.org; Mon, 26 Jan 2004 13:55:27 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i0QItQ2v027648 for ; Mon, 26 Jan 2004 11:55:26 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i0QItO2u028269 for ; Mon, 26 Jan 2004 12:55:25 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Mon, 26 Jan 2004 10:55:24 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Subject: [ipcdn] Re: Signaling MIB - Draft 3 - Last Call - pktcSigDevToneT able (Issue4) Date: Mon, 26 Jan 2004 10:55:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , There is no need for any additional power objects for each frequency. The original comment submission is based on a misinterpretation of the specification. Here is how it works: The 300 001 specification states a RANGE of values for the frequency and power (i.e., x1=minimum level, x2=maximum level) that CPE (phones/fax/modems) should be able to accept as input from the various country/operator networks. The range explanation is in the text preceeding the Table 1.7.1 in 300 001. In reading an entry from the table, the frequency may be any value between f1 OR f2 but not both combined. For the power, the level will be in the RANGE that is stated regardless of the actual frequency being used. Thus, the single power level in the MIB is sufficient. This interpretation is further supported by supplement 2 to the ITU-T 181 specification which states: "f1//f2 in some exchanges frequency f1 is used and in others frequency f2 is used." Given the table 1.7.1 example for dial tone for Belgium, the correct interpretation is f1 (420 Hz would probably be 425 Hz +/- tolerance) or f2 (455 Hz would probably be 450 Hz +/- tolerance) at a SINGLE power level within the R! ANGE -20 dBm (p1) to -4 dBm (p2). Again, these are not the source specifications but a statement of the possible operating values that may be supplied to the CPE devices at the end of the local loop. The implication is that a source (eMTA) that generates a frequency at an amplitude within the stated ranges should be acceptable to CPE devices. Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Mar 30 18:52:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06873 for ; Tue, 30 Mar 2004 18:52:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riy-0006ZK-EF for ipcdn-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0H5an016986 for ipcdn-archive@odin.ietf.org; Tue, 27 Jan 2004 19:17:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldOC-0004Pb-JM; Tue, 27 Jan 2004 19:17:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldNq-0004KV-N1 for ipcdn@optimus.ietf.org; Tue, 27 Jan 2004 19:16:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03130 for ; Tue, 27 Jan 2004 19:16:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AldNp-0006mE-00 for ipcdn@ietf.org; Tue, 27 Jan 2004 19:16:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AldLL-0006Dw-00 for ipcdn@ietf.org; Tue, 27 Jan 2004 19:14:08 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1AldJu-0005xf-00 for ipcdn@ietf.org; Tue, 27 Jan 2004 19:12:38 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i0S0CWF0024592 for ; Tue, 27 Jan 2004 17:12:32 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i0S0A5l2011659 for ; Tue, 27 Jan 2004 18:10:05 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Tue, 27 Jan 2004 16:12:30 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Subject: RE: [ipcdn] Signaling MIB - Draft 3 - Last Call - pktcSigDevToneT ype (Issue 3) Date: Tue, 27 Jan 2004 16:12:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Upon review of ITU spec, supplement 2, and ES 201 970, Motorola further disagrees with the deletion of the following additional items from the pktcSigDevToneType object: alertingSignal(17), specialDial(18), specialInfo(19), release(20), congestion(21) To ensure these objects can also be signaled, Motorola is initiating a proposal to modify TS 909-101 part 4, appendix B.4 to include NCS line codes and other parameters. Gordon -----Original Message----- From: Beacham Gordon-CGB005 Sent: Friday, January 23, 2004 10:11 AM To: 'ipcdn@ietf.org' Subject: RE: [ipcdn] Signaling MIB - Draft 3 - Last Call - pktcSigDevToneType (Issue 3) Motorola disagrees with the deletion of the following items from the pktcSigDevToneType object: userDefined1 (13), userDefined2 (14), userDefined3 (15), userDefined4 (16) These objects are required by several international operators to support additional signals for their networks. To ensure these user defined objects can be signaled, Motorola is initiating a proposal to modify TS 909-101 part 4, appendix B.4 to include NCS line codes and other parameters. For example: Code Description Signal ps1 Programmable Signal 1 TO ps2 Programmable Signal 2 TO ps3 Programmable Signal 3 TO ps4 Programmable Signal 4 TO The ITU spec, supplement 2 to 180 will also be reviewed to see if more than four user defined signals are required for the pktcSigDevToneType object. Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Mar 30 18:57:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08264 for ; Tue, 30 Mar 2004 18:57:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riv-0006ZK-02 for ipcdn-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QL062o007897 for ipcdn-archive@odin.ietf.org; Fri, 26 Sep 2003 17:00:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2zh4-00022C-QF; Fri, 26 Sep 2003 17:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2zgw-000214-K9 for ipcdn@optimus.ietf.org; Fri, 26 Sep 2003 16:59:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23668 for ; Fri, 26 Sep 2003 16:59:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2zgu-0005jx-00 for ipcdn@ietf.org; Fri, 26 Sep 2003 16:59:52 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1A2zgt-0005ju-00 for ipcdn@ietf.org; Fri, 26 Sep 2003 16:59:51 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h8QKxoAg022122 for ; Fri, 26 Sep 2003 13:59:51 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h8QKxmCi020672 for ; Fri, 26 Sep 2003 15:59:49 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Fri, 26 Sep 2003 13:59:12 -0700 Message-ID: From: Beacham Gordon-CGB005 To: "'Ipcdn (E-mail)'" Date: Fri, 26 Sep 2003 13:59:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] RE: RE: Publication of PacketCable IETF MIBs - Signaling MIB draf t 02 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , My appologies. Correction on item 1 as follows: replace pktcSigCapablityTable with pktcSigCapabilityTable in the pktcSigEndPntCapabilityIndex object only. Gordon > -----Original Message----- > From: Beacham Gordon-CGB005 > Sent: Friday, September 26, 2003 8:55 AM > To: Ipcdn (E-mail) > Subject: RE: Publication of PacketCable IETF MIBs - Signaling MIB draft 02 > > Eugene, > My comments on the Sig MIB suggested changes: > 1. I can change the description in pktcSigEndPntCapabilityIndex to refer to the proper table. That is replace "pktcSigCapablityTable" with "pktcSigEndPntConfigTable" in the pktcSigEndPntCapabilityIndex object and "pktcSigEndPntTable" with "pktcSigEndPntConfigTable" in the pktcSigEndPntConfigStatus object. > If we want to delete the table and associated objects I'd like to see additional input from the IPCDN reflector. > 2. I agree this object is missing and needs to be added. I would instead recommend the syntax be: 500 to 800 to match the T3 range specified in 300 659-1. > 3. I agree these objects can be added. However, it is not clear to me that an operator would actually use different signaling methods on the SAME line. Just to be clear these additional VMWI objects are for on-hook data transmission not associated with ringing as specified in 300 659-1 section 6.2. > 4. Agree at present. Motorola has not found a scenario where more than 2 freqs are modulated. > 5. Agree with making these objects read-only. > Gordon > -----Original Message----- > From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] > Sent: Monday, September 22, 2003 7:28 PM > To: Beacham Gordon-CGB005; Jean-Francois Mule; Wim De Ketelaere; Woundy, Richard; Sumanth Channabasappa; Satish Kumar at Texas Instruments > Subject: RE: Publication of PacketCable IETF MIBs - Signaling MIB draft 02 > > Gordon, > The following are comments to draft-02 candidate: > 1. pktcSigEndPntCapabilityIndex MIB Object has a refernce to the "pktcSigCapablityTable" in description whereas the "pktcSigCapablityTable" does not exist in the SIG MIB. I think the "pktcSigEndPntConfigTable" should be eliminated . > 2. The following object seems to be required and is currently missing: > pktcSigDevCIDFskAfterRPAS > SYNTAX Unsigned32 (0..1000) > UNITS "Milliseconds" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > " This object is used for ETSI systems only. This object > specifies the delay between the end of the Ring Pulse Alert > Signal (RP-AS) and the start of the transmission of the > FSK containing the Caller ID information. This object is > only used when pktcSigDevCIDMode is rpAsETS. > pktcSigDevCIDMode pktcSigDevCIDFskAfterDTAS > duringringingETS 0 ms (not used) > dtAsETS 0 ms (not used) > rpAsETS 650 ms > lrAsETS 0 ms (not used)" > REFERENCE > " Refer to the ETS 300 659-1 Specification." > ::= { pktcSigPulseSignalEntry ??? } > 3. "pktcSigDevCIDMode" MIB Object currently refers only to on-hook caller-ID. We do not not have the corresponding object to select the off-hook caller-id method. Proposal is to use a set of the new objects for off-hook params: > pktcSigDevVmwiMode OBJECT-TYPE > SYNTAX INTEGER { > dtAsETS(1), > rpAsETS(2), > lrAsETS(3) > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > " This object is used for ETSI systems only. For visual message > waiting indicator (VMWI), pktcSigDevVmwiMode selects the alerting signal method. > For the dtAsETS, rpAsETS, and lrAsETS > methods, the FSK containing the VMWI information is > sent after an alerting signal. For the dtAsETS > method, the FSK is sent after the Dual Tone Alert Signal. > For the rpAsETS method, the FSK is sent after a Ring > Pulse. For the lrAsETS method, the Line Reversal occurs > first, then the Dual Tone Alert Signal, and finally the > FSK is sent." > DEFVAL { dtAsETS } > ::= {pktcSigDevConfigObjects > ??? } > pktcSigDevVmwiFskAfterDTAS OBJECT-TYPE > SYNTAX Unsigned32 (0..500) > UNITS "Milliseconds" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > " This object is used for ETSI systems only. This object > specifies the delay between the end of the Dual Tone Alert > Signal (DT-AS) and the start of the transmission of the > FSK containing the VMWI information. This object is > only used when pktcSigDevVMWIMode is dtAsETS or lrAsETS. > pktcSigDevVMWIMode pktcSigDevVMWIFskAfterDTAS > dtAsETS 50 ms > rpAsETS 0 ms (not used) > lrAsETS 50 ms" > REFERENCE > " Refer to the ETS 300 659-1 Specification." > DEFVAL { 50 } > ::= {pktcSigDevConfigObjects ?? } > pktcSigDevVmwiFskAfterRPAS OBJECT-TYPE > SYNTAX Unsigned32 (0..800) > UNITS "Milliseconds" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > " This object is used for ETSI systems only. This object > specifies the delay between the end of the Ring Pulse Alert > Signal (RP-AS) and the start of the transmission of the > FSK containing the VMWI information. This object is > only used when pktcSigDevVMWIMode is rpAsETS. > pktcSigDevVMWIMode pktcSigDevVMWIFskAfterDTAS > dtAsETS 0 ms (not used) > rpAsETS 650 ms > lrAsETS 0 ms (not used)" > REFERENCE > " Refer to the ETS 300 659-1 Specification." > DEFVAL { 50 } > ::= {pktcSigDevConfigObjects ??? } > pktcSigDevVmwiDTASAfterLR OBJECT-TYPE > SYNTAX Unsigned32 (0..655) > UNITS "Milliseconds" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > " This object is used for ETSI systems only. This object > specifies the delay between the end of the Line Reversal > and the start of the Dual Tone Alert Signal (DT-AS) for VMWI. This > object is only used when pktcSigDevVMWIMode is lrAsETS. > pktcSigDevVMWIMode pktcSigDevVMWIFskAfterLR > dtAsETS 0 ms (not used) > rpAsETS 0 ms (not used) > lrAsETS 250 ms" > REFERENCE > " Refer to the ETS 300 659-1 Specification." > DEFVAL { 250 } > ::= {pktcSigDevConfigObjects ??? } > 4. Clarification oin on "pktcSigDevToneFreqType" description for "allFrequenciesModulated" mode is required: > It seems that it makes sense to have only two frequencies and also an implementor needs to know which frequency modulates which. The clarifying propasal looks as follows: > allFrequenciesModulated indicates all frequencies > specified by pktcSigDevToneNumFrequencies are modulated to > form a single tone. The tone is then applied in sequence > using the number of on/off times specified in > pktcSigDevToneNumOnOffTimes. > For this tone type pktcSigDevToneNumFrequencies MUST be equal 2, > and the frequency in pktcSigDevToneFirstFrequency modulates the > frequency in pktcSigDevToneSecondFrequency." > 5. The following objects should be made "read-only" and configurable only from the MTA CFG File (because of the reasons similar to pktcSigPowerRingFrequency MIB Object): > pktcNcsEndPntConfigMinHookFlash, > pktcNcsEndPntConfigMaxHookFlash, > pktcNcsEndPntConfigPulseDialInterDigitTime, > pktcNcsEndPntConfigPulseDialMinMakeTime, > pktcNcsEndPntConfigPulseDialMaxMakeTime, > pktcNcsEndPntConfigPulseDialMinBreakTime, > and pktcNcsEndPntConfigPulseDialMaxBreakTime > Thanks, > Eugene. > > > Gordon Beacham > Digital Core Gateways, BCS > Motorola, Inc. > 858-404-2335 > gordon.beacham@motorola.com > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Mar 31 01:53:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03674 for ; Wed, 31 Mar 2004 01:53:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Zaw-00014H-B7 for ipcdn-archive@odin.ietf.org; Wed, 31 Mar 2004 01:53:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V6r281004106 for ipcdn-archive@odin.ietf.org; Wed, 31 Mar 2004 01:53:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Zau-00013x-OE; Wed, 31 Mar 2004 01:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Za3-00011P-0a for ipcdn@optimus.ietf.org; Wed, 31 Mar 2004 01:52:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03642 for ; Wed, 31 Mar 2004 01:52:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ZZz-0005n1-00 for ipcdn@ietf.org; Wed, 31 Mar 2004 01:52:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ZZ3-0005jK-00 for ipcdn@ietf.org; Wed, 31 Mar 2004 01:51:05 -0500 Received: from apate.telenet-ops.be ([195.130.132.57]) by ietf-mx with esmtp (Exim 4.12) id 1B8ZYB-0005fb-00 for ipcdn@ietf.org; Wed, 31 Mar 2004 01:50:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by apate.telenet-ops.be (Postfix) with SMTP id AD51E2B40D3 for ; Wed, 31 Mar 2004 08:50:11 +0200 (MEST) Received: from tcomlabs.com (D5E0B8ED.kabel.telenet.be [213.224.184.237]) by apate.telenet-ops.be (Postfix) with ESMTP id 99BD02B40C0 for ; Wed, 31 Mar 2004 08:50:11 +0200 (MEST) Received: (qmail 6427 invoked from network); 31 Mar 2004 08:49:42 +0200 Received: from localhost (HELO gateway) (127.0.0.1) by localhost with SMTP; 31 Mar 2004 08:49:42 +0200 Received: from ([10.5.5.72]) by gateway.tcomlabs.com (MailMonitor for SMTP v1.2.2 ) ; Wed, 31 Mar 2004 08:49:42 +0200 (CEST) From: "David De Reu" To: "IPCDN Mailing List" , , "Beacham Gordon-CGB005" Subject: RE: [ipcdn] Editorial Changes - NCS MIB Date: Wed, 31 Mar 2004 08:50:08 +0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-Reply-To: <4069D529.5060706@cisco.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > 3. Change pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 0 } to: > > pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 2 } > > Recommend keeping the notification as it is per Appendix D > of the draft-ietf-ops-mib-review-guidelines-02.txt. Good point indeed. We currently have pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 0 } pktcSigMibObjects OBJECT IDENTIFIER ::= { pktcSigMib 1 } pktcSigConformance OBJECT IDENTIFIER ::= { pktcSigMib 3 } When we follow the OID layout suggested in appendix D of , which is xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) then I suggest instead redefining pktcSigConformance as pktcSigConformance OBJECT IDENTIFIER ::= { pktcSigMib 2 } Thanks, Regards, David _____________________________________________________ David De Reu tComLabs Stapelplein 70/004 - 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